Bug #73043 [Com]: WSDL: import schema if WSDL uri does NOT end with a slash

From: Date: Fri, 09 Sep 2016 12:42:17 +0000
Subject: Bug #73043 [Com]: WSDL: import schema if WSDL uri does NOT end with a slash
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-203911@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=73043&edit=1

 ID:                 73043
 Comment by:         filip dot rydlo at gmail dot com
 Reported by:        filip dot rydlo at gmail dot com
 Summary:            WSDL: import schema if WSDL uri does NOT end with a
                     slash
 Status:             Feedback
 Type:               Bug
 Package:            SOAP related
 Operating System:   Debian 8.5 Jessie x64
 PHP Version:        5.6.26RC1
 Block user comment: N
 Private report:     N

 New Comment:

>> they are properly defined in the WSDL file
> I disagree.

Oh, NO! This cannot be. Can't be real! Sorry, that I am so shocked. But ... I just can't
believe this is happening!!

This WSDL is given to us, developers, by out government! It HAS TO BE correct and absolutely without
any error. :-(((

Considering how many millions of dollars it has *undoubtedly* cost us, the tax payers! It has to be
*perfect* , or we have NO chance ever implementing this webservice
(Which would/will, btw, help our country a lot, adding at least 0.5 billions of USD annually into
the state fund + probably even much more on taxes collected! )
---

Yes, I am pretty familiar with web development (13 years). Yet, I only was suspecting (feeling)
this, but NOT logically/consciously KNOW *this*.

And I would never suspect/expect an error in the WSDL given by the government in the first place!
---


> however PHP is behaving correctly.
Are You *absolutely* sure about all this?

Then please: Tell (explain) this to the government!

Thank You soooooooooooo much :-)


Previous Comments:
------------------------------------------------------------------------
[2016-09-08 04:10:00] requinix@php.net

> they are properly defined in the WSDL file
I disagree.

The XSD 1.1 Part 1 specification says [1]
> 4. When schema location values (i.e. schemaLocation attributes on ...<import>...)
> are... relative references, then the [base URI] of the [owner element] must be
> used to resolve the relative references.

In your example, the "owner" is the source WSDL document and the "base URI" is
https://pg.eet.cz/eet/services/EETServiceSOAP/v3?wsdl.

Unfortunately uncited in the XSD spec, RFC 3986 is what details [2] how to resolve relative
references, and if you're familiar with web development then you should already know that a
reference "a" relative to a base "b/c?d" resolves to "b/a", while
relative to "b/c/?d" resolves to "b/c/a". The trailing slash is very
significant.

Therefore "EETXMLSchema.xsd" relative to "https://pg.eet.cz/eet/services/EETServiceSOAP/v3?wsdl"
resolves to "https://pg.eet.cz/eet/services/EETServiceSOAP/EETXMLSchema.xsd".
Clearly this is not the intent of the WSDL's author, however PHP is behaving correctly. Can you
provide any references to suggest otherwise?

[1] https://www.w3.org/TR/xmlschema11-1/#schema-loc
[2] https://www.ietf.org/rfc/rfc3986.txt section
5.2

------------------------------------------------------------------------
[2016-09-07 21:02:11] filip dot rydlo at gmail dot com

Description:
------------
When loading WSDL:

PHP SoapClient FAILs to find *.XSD files despite the fact that they are properly defined in the WSDL
file downloaded from the server. They are defined like this:

<wsdl:definitions ...
...
<wsdl:types>
  <xsd:schema>
    <xsd:import namespace="http://fs.mfcr.cz/eet/schema/v3"  
schemaLocation="EETXMLSchema.xsd"/>
  </xsd:schema>
</wsdl:types>
...

WSDL addr. : https://pg.eet.cz/eet/services/EETServiceSOAP/v3?wsdl

Test script:
---------------
<?php
define('WSDL', 'https://pg.eet.cz:443/eet/services/EETServiceSOAP/v3?wsdl');
 // EET srvr NETOLERUJE koncove '/' za "v3"!!!
define('ENDPOINT_LOCATION', 'https://pg.eet.cz:443/eet/services/EETServiceSOAP/v3/');
 // NETOLERUJE koncove '/', bacha!

$options= array(
        'cache_wsdl' =>   WSDL_CACHE_NONE,
        'encoding' =>     'utf-8',
        'soap_version' => SOAP_1_1,
        'exceptions' =>   true,
        'trace' =>        1,
        'location' =>     ENDPOINT_LOCATION
);

$test_msg= "<EmptyTest>NODATA</EmptyTest>";
$input_args= new SoapVar($test_msg, XSD_ANYXML);

try
{
        xdebug_disable();
        //-------------------------------------
        $soap= new SoapClient(WSDL, $options);
        //-------------------------------------
        xdebug_enable();


        xdebug_disable();
        $out = $soap->__soapCall('OdeslaniTrzby', array($input_args), $options, null,
$output_headers);
        xdebug_enable();

        echo("<br />REQUEST :<br />".
htmlspecialchars($eet->__getLastRequest())  ."<br />");
        echo("<br />RESPONSE:<br />".
htmlspecialchars($eet->__getLastResponse()) ."<br />");
}
catch (SoapFault $fault)
{
        xdebug_enable();
        echo "Error:<br />" . nl2br($fault->faultcode) . '<br /><br
/>Error Details:<br />'. nl2br($fault->faultstring) . '<br />';
}


Expected result:
----------------
REQUEST : <dumped-xml-request..........>


In short:
It should successfully import the XSD schema from the correct location - DESPITE the webservice
location does NOT end with a slash "/".


In short: It should have looked for it here:

https://pg.eet.cz:443/eet/services/EETServiceSOAP/v3/EETXMLSchema.xsd

NOT here:

https://pg.eet.cz:443/eet/services/EETServiceSOAP/EETXMLSchema.xsd


Actual result:
--------------
PHP Fatal error: SOAP-ERROR: Parsing Schema: can't import schema from 'https://pg.eet.cz:443/eet/services/EETServiceSOAP/EETXMLSchema.xsd'
in /home/username/EET/src/testscript.php on line 21
Error:
WSDL

Error Details:
SOAP-ERROR: Parsing Schema: can't import schema from 'https://pg.eet.cz:443/eet/services/EETServiceSOAP/EETXMLSchema.xsd'



------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=73043&edit=1


Thread (10 messages)

« previous php.bugs (#203911) next »