Doc #78749 [Ver]: No comprehensive documentation on how SoapClient serializes data per the WSDL

From: Date: Tue, 05 Nov 2019 18:45:25 +0000
Subject: Doc #78749 [Ver]: No comprehensive documentation on how SoapClient serializes data per the WSDL
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-17043@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=78749&edit=1 ID: 78749 User updated by: tony at marston-home dot demon dot co dot uk Reported by: tony at marston-home dot demon dot co dot uk Summary: No comprehensive documentation on how SoapClient serializes data per the WSDL Status: Verified Type: Documentation Problem Package: SOAP related Operating System: Windows 10 PHP Version: 7.3.11 Block user comment: N Private report: N New Comment: I disagree completely with your assessment. In my WSDL the element <contacts> can occur 0 or 1 times. It is a container for any number of <contact> elements, and each <contact> contains its own group of elements which can occur 0 or 1 times each. The idea that the value of maxOccurs need not be validated is nonsense. The official specification at http://www.w3.org/TR/xmlschema-0/#OccurrenceConstraints contains the sentence "The maximum number of times an element may appear is determined by the value of a maxOccurs attribute in its declaration." To any reasonable person this would mean that if the WSDL provides a value for maxOccurs then the XML document should checked to ensure that this limit is not violated. Previous Comments: ------------------------------------------------------------------------ [2019-11-05 17:52:19] requinix@php.net Here's what is happening: If maxOccurs is 1 then the PHP value should not be a list. Because there's only possibly one. It doesn't make sense to have a list when there can only be a single entity/value in it. Like having the title be an array("Title") is weird. If maxOccurs is unbounded or >1, PHP does not validate against the count. It just doesn't. If the max is 2 and you give 3 then it will put in all 3 (which you can verify through __getLastRequest). So there's two issues here: 1. That behavior is undocumented. I think it's the most important aspect of this report, so I'm repurposing this as a doc bug. 2. The missing maxOccurs validation. I don't see this as high priority as it doesn't seem that SoapClient has any particular intention to perform validation beyond what is required to serialize the data to XML; maxOccurs when >1 isn't being validated, minOccurs when >1 isn't being validated, and there are probably other rules not being validated either. ------------------------------------------------------------------------ [2019-11-05 09:45:02] tony at marston-home dot demon dot co dot uk That structure is perfectly valid according to the WSDL definition, and it validates using third party tools such as OxygenXML and SOAPUI. The XML I supplied contains three occurrences of <contact> and the SOAP Server ->handle() method deals properly with these when the WSDL specifies maxOccurs of 3 or more. If I set maxOccurs to 1 the error message is entirely wrong. If I set maxOccurs to 2 there is no error message complaining that I have exceeded maxOccurs. It is your validation of the structure which is wrong and not the structure itself. ------------------------------------------------------------------------ [2019-11-04 21:31:18] camporter1 at gmail dot com It's possible that I'm not understanding the issue properly, but it seems like the issue here is that 'first_name' is trying to be accessed on the array of 'contact', which won't map to the type. Replacing ArrayOfContactInfo with: <xsd:complexType name="ArrayOfContactInfo"> <complexContent> <restriction base="SOAP-ENC:Array"> <attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="tns:contact[]"/> </restriction> </complexContent> </xsd:complexType> and removing the extra 'contact' array: 'contacts' => [ '0' => [ 'title' => 'Mr', 'first_name' => 'Joe', 'middle_name' => 'Xavier', 'last_name' => 'Soap', 'contact_role' => 'Account Manager', 'telephone' => '075 40008000' ], '1' => [ 'title' => 'Mrs', 'first_name' => 'Jane', 'last_name' => 'Doe', 'contact_role' => 'Assistant Account Manager', 'telephone' => '075 40008001' ], '2' => [ 'title' => 'Miss', 'first_name' => 'Dee', 'last_name' => 'Meanour', 'contact_role' => 'Deputy Assistant Account Manager', 'telephone' => '075 40008003', ], ], seems like it might be more in line with the expected behavior? ------------------------------------------------------------------------ [2019-10-25 17:11:24] tony at marston-home dot demon dot co dot uk I have created a zip file containing the two files necessary to reproduce this fault as it simply cannot be done in 20 lines of code or less. The WSDL file alone requires over 80 lines. This zip file is available at: https://www.tonymarston.net/php-mysql/gmx_soap_bug_report.zip The 'contact' element in the WSDL file has a 'maxOccurs' attribute which I am testing by sending 3 occurrences. If I set 'maxOccurs' to 1 it fails with "SOAP-ERROR: Encoding object has no 'first_name' property" even though the array does contain a value. If I set 'maxOccurs' to 2 it does not fail (which it should as I have violated the maximum) and it also sends all 3 occurrences to the server. ------------------------------------------------------------------------ [2019-10-24 19:43:07] requinix@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with <?php and ends with ?>, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. I may be misreading the source, but it looks like you're triggering a code path that only occurs when there is no value available. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=78749 -- Edit this bug report at https://bugs.php.net/bug.php?id=78749&edit=1

« previous php.doc.bugs (#17043) next »