php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49226 SoapServer failing on construction (cannot load wsdl)
Submitted: 2009-08-11 19:30 UTC Modified: 2009-12-21 01:00 UTC
Votes:36
Avg. Score:4.5 ± 0.8
Reproduced:31 of 31 (100.0%)
Same Version:20 (64.5%)
Same OS:17 (54.8%)
From: richard at rjharrison dot org Assigned:
Status: No Feedback Package: SOAP related
PHP Version: 5.3.0 OS: linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2009-08-11 19:30 UTC] richard at rjharrison dot org
Description:
------------
SoapServer is failing on construction. I pass an URL with *valid* WSDL xml, which is generated automatically.

- If I save the WSDL locally and load from disk it works.
- If I serve the WSDL remotely from a static .xml file it works.
- If I load the WSDL-url in my browser I get a well-formed XML response.
- I can access the dodgy-wsdl URL via file_get_contents.
- Using 5.2.6 on another machine it works fine.

I inspected the http requests and think it could be related to chunked encoding (it fails on the chunked encoding response). 

Reproduce code:
---------------
<?php
$url  = 'http://myserver/path?wsdl';
$serv = new SoapServer($url);
?>

I can probably provide a sample url privately.

Expected result:
----------------
$serv to be instantiated



Actual result:
--------------
SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://myserver/path?wsdl' : Premature end of data in tag definitions line 2


Below are the headers of the response that fails:-

Date: Tue, 11 Aug 2009 19:15:29 GMT
Server: Apache/2.2.8 (Unix) DAV/2 PHP/5.3.0
X-powered-by: PHP/5.3.0
Vary: Accept-Encoding,User-Agent
Connection: close
Transfer-encoding: chunked
Content-type: text/xml

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-12 10:52 UTC] stig dot woxholt at fotoknudsen dot no
We have started porting our soap services from 5.2.x to 5.3 and see the same problem here.

I have spend quite some time trying to identify the problem, and it seemes to me that when the wsdl reaches a certain size it stops working.

Ie. i have a service with 10 exposed methods. When all these methods are exposed i get an error, same as Richards. If i cut down on the number of exposed methods, to ie. 3 on the service it works.

This is services that is used in production on the 5.2.x builds, and works perfectly there.

Looks to me that there might be a bug in the XML parsing of the WSDL somewhere.
 [2009-08-12 11:39 UTC] sjoerd-php at linuxonly dot nl
Thank you for your bug report.

When you retrieve the WSDL over HTTP, does the Content-Length header match the length of the WSDL? You can try saving the WSDL to disk and load that one instead.
 [2009-08-12 13:05 UTC] richard at rjharrison dot org
@sjoerd,

When I load the WSDL over HTTP there is no content-length header, as the response is sent chunk-encoded. As stated in the original report, if I save the WSDL to disk then it works, for example:-

<?php
$data = file_get_contents('http://myserver/path?wsdl');
file_put_contents("wsdl.xml", $data);
$serv = new SoapServer("wsdl.xml"); // works
?>


@stig,

The behaviour you describe with different size WSDL might backup the theory that it's chunk-encoding related. With a small body size, I think PHP *does* send a content-length header; but if the body is larger than the output buffer (?) it will switch to chunk-encoding to allow for the unknown, variable length.
 [2009-08-12 14:01 UTC] stig dot woxholt at fotoknudsen dot no
The service works when using a local file.

I did some more tests, and have identified the actual problem.
Its not in the PHP 5.3 release, rather its a "bug" in the Zend AutoDiscover class provided by Zend.

I assume the reporter also might be using this to generate the WSDL's ?

I guess that in php 5.3 the soap server expects the content length to be set in the header inorder to parse the complete wsdl, but the AutoDiscover class does not send this.

By adding header('Content-Length: '.strlen($this->_wsdl->toXML())); to the handle function in the AutoDiscover class things are working 

I'll report the findings on the Zend bugtracker.
 [2009-08-12 17:24 UTC] richard at rjharrison dot org
"Its not in the PHP 5.3 release, rather its a bug in the Zend
AutoDiscover class"

If it works fine in 5.2(.6) but not in 5.3 then something changed in 5.3 that made things break, which suggests a bug in 5.3.

If adding a content-length header fixes things then that's great as a quick-fix, but SoapServer should be able to deal with chunk-encoded responses which don't, by their nature, have a content-length.
 [2009-08-24 12:51 UTC] sjoerd@php.net
Thank you both for your feedback.

SOAP retrieves the WSDL using HTTP/1.0, which does not have chunked transfers. Therefore, the server should provide a Content-length header. If it does not do that, SoapServer can not load the WSDL correctly. This is not a bug in PHP, since the content-length header is mandatory for HTTP/1.0 messages which have a body.

You could implement/request the feature that PHP can load WSDLs even if they don't have a content-length header, but it is not a bug in PHP itself.
 [2009-08-24 13:20 UTC] richard at rjharrison dot org
Sjoerd,

Respectfully, I think you're wrong. I am *far* from being a SOAP expert, but the specifications for SOAP 1.1[1] and for WSDL[2] both show use of HTTP 1.1.

1. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383526
2. http://www.w3.org/TR/wsdl#_http
 [2009-08-24 16:49 UTC] sjoerd@php.net
The specifications you supply do not describe how to retrieve the WSDL.

In this case, the WSDL is retrieved using HTTP. I don't think it is specified which HTTP version to use. The SoapServer class uses HTTP 1.0. If the server serving the WSDL implements HTTP 1.0, it should send a content-length header. If it does not implement HTTP 1.0, it should send a 505 HTTP Version Not Supported.
 [2009-08-24 17:53 UTC] richard at rjharrison dot org
Ok I understand your point (that the WSDL server is supposedly at fault for not providing an HTTP 1.0 response). 

I just tested again and watched my Apache access_log. With 5.2.10, the request is sent from SoapServer using HTTP 1.0, and the response from the WSDL server correctly includes a content-length header (and everything works fine).

When I test with 5.3, SoapServer sends the request using HTTP 1.1 (according to the Apache log) and the response is chunk-encoded causing SoapServer to error.

Therefore I believe that SoapServer in 5.3 is sending an HTTP 1.1 request but is unable to process an HTTP 1.1 response.
 [2009-08-24 19:22 UTC] sjoerd@php.net
PHP 5.3 indeed seems to request the WSDL using HTTP/1.1, I was wrong about that, I'm sorry.

However, it works fine with other WSDLs which are sent chunked. There seems to be something special about your setup which triggers this bug. Could you make a dump of the HTTP transaction with a sniffer? Note that you may have to disable the WSDL caching to force SoapServer to get the WSDL over HTTP.
 [2009-09-01 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2009-09-01 08:07 UTC] sjoerd@php.net
Bug #49397 describes the same problem, but with SoapClient.
 [2009-09-23 09:13 UTC] evrard at h2a dot lu
For everybody that are looking for a little fix for that, force SoapClient to send an HTTP 1.0 request and your script may run again. It is working for me with PHP 5.3.0, ZEND 1.9 (minimal package, via PEAR) and APACHE 2.2.12 on Windows XP.

<?php

try
{
       $context = stream_context_create( array(
         'http' => array(
           'protocol_version'=> '1.0' ,
           'header'=> 'Content-Type: text/xml;' ,
         ),
       ) );

       $options = array(
         'stream_context' => $context ,
       );

       $client = new SoapClient( 'http://myserver/path?wsdl' , $options );
}
catch( Exception $e )
{
  // You should not be here anymore
}
?>
 [2009-09-30 18:26 UTC] sjoerd@php.net
Evrard mailed me a HTTP trace, which I put here:
http://pastebin.com/f25b554f9

I could reproduce this with PHP 5.3, not PHP 5.3-HEAD, so this may have already been fixed in trunk.
 [2009-10-01 11:37 UTC] sjoerd@php.net
Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/


 [2009-10-07 16:25 UTC] petro at eps1lon dot com
I was having the same problem with SoapClient under 5.3.0.  It is working fine under 5.3.RC1.
 [2009-10-07 16:28 UTC] petro at eps1lon dot com
That should be 5.3.1RC1.
 [2009-10-07 18:30 UTC] Sjoerd@php.net
See also Bug #48216 PHP Fatal error: SOAP-ERROR: Parsing WSDL: Extra content at the end of the doc
 [2009-10-09 10:17 UTC] evalds at 2egames dot com
I am using latest PHP 5.3 and still having this annoying bug - 
the easy quick fix for SoapServer error is to add header like (thank you 
"stig dot woxholt at fotoknudsen dot no" for indentifiying the problem).

To fix this you have to add content-length in your wsdl generator code:

header('Content-Length: '.strlen($strWsdl));
echo $restOfWsdl;
 [2009-10-15 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2009-12-13 19:05 UTC] felipe@php.net
Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/


 [2009-12-21 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Apr 24 10:01:31 2024 UTC