SOAP Client failed to load entry

Bug #1160336 reported by Jack
48
This bug affects 9 people
Affects Status Importance Assigned to Milestone
php5 (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

After upgrading php to

ii libapache2-mod-php5 5.3.10-1ubuntu3.6
ii php5-cli 5.3.10-1ubuntu3.6

We noticed that we've got some temporary problems with loading wsdl by soap client, it doesn't no matter about location of wsdl, this bug includes loading wsdl from local disk and from remote using http protocol. In php logs we've got only information:

[26-Mar-2013 10:55:15 UTC] PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from '/tmp/test_wsdl' : failed to load external entity "/tmp/test_wsdl"
 in /var/www/http/test.php:11
Stack trace:
#0 /var/www/http/test.php(11): SoapClient->SoapClient('/tmp/test_wsdl')
#1 {main}
  thrown in /var/www/http/test.php on line 11

And after restart apache instance it will works for a while, and then problem returns.

Important is, that this problem does not apply to CLI client, it applies only when you are trying to run file from apache instance.

As we can see in changelog there was some changes in soap and XML and maybe that is the reason of this problems. ( In the previous version of php we didn't have any problems with soap )

* SECURITY UPDATE: arbitrary file disclosure via XML External Entity
    - debian/patches/CVE-2013-1643.patch: disable the entity loader in
      ext/libxml/libxml.c, ext/libxml/php_libxml.h, ext/soap/php_xml.c.
    - CVE-2013-1643

PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch (cli) (built: Mar 11 2013 14:31:48)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

Server version: Apache/2.2.22 (Ubuntu)
Server built: Mar 8 2013 15:53:13
Server's Module Magic Number: 20051115:30
Server loaded: APR 1.4.6, APR-Util 1.3.12
Compiled using: APR 1.4.6, APR-Util 1.3.12
Architecture: 64-bit
Server MPM: Prefork
  threaded: no
    forked: yes (variable process count)

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04.2 LTS
Release: 12.04
Codename: precise

Tags: amd64
Jack (jack1234443)
description: updated
Jack (jack1234443)
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in php5 (Ubuntu):
status: New → Confirmed
Revision history for this message
Ron Stewart (rstewart-z) wrote :

We seem to be experiencing the same problem. In our case, it is both the SoapClient and the SoapServer class which fail to load wsdl files (with the same error message as above), regardless of where the files are located on our server. I found a workaround which is allowing the wsdl files to be loaded, but which may be causing unwanted changes in how our SOAP objects are delivered.

I changed:

$server = new SoapServer('/path/to/wsfile.wsdl');

to:

$server = new SoapServer(null, array('uri' => '/path/to/wsfile.wsdl'));

For the SoapClient code, I changed:

$client = new SoapClient('https://domain/path/to/wsfile.wsdl');

to:

$client = new SoapClient(null, array('uri' => 'https://domain/path/to/wsfile.wsdl', location => 'https://domain/path/to/wsfile.wsdl'));

This got our client code tests to successfully return SOAP objects, but one of our customers using existing client side code (which has not been changed) has been experiencing errors when attempting to parse the objects they are receiving.

Revision history for this message
Jack (jack1234443) wrote :

Is there any chance to fix this issue ? Because solution given by Ron, it's not a real fix..

Revision history for this message
Nate Smith (nsmith-smythsoft) wrote :

Seeing the same behavior with SoapClient and a WSDL file stored on the local machine. Sometimes it won't work, but then I refresh the PHP script in my browser, and it works fine, with Zero changes to that particular file.

Revision history for this message
Tomasz (Tomek) Muras (zabuch) wrote :

We are affected by (what seems) exactly the same issue on:

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty

php5 5.5.9+dfsg-1ubuntu4.4

Revision history for this message
Tomasz (Tomek) Muras (zabuch) wrote :

This must be a bug in mod php or PHP. The behaviour is random so it may relate to cache or some condition race.

The workaround for the issue is to add this:
libxml_disable_entity_loader(false);

before creating new SoapClient.

Revision history for this message
cljk (marcel-pokrandt) wrote :

Think I came to the same bug - took me a lot of time to identify this..... because it mainly made no sense.

My error described here.
http://stackoverflow.com/questions/33121809/mantis-soap-error-accessing-mantisconnect-php-eclipse-mylyn-plugin

For me disabling the wsdl-cache helped...... currently

Revision history for this message
Robie Basak (racb) wrote :

I see that five people are affected by this now so clearly there is some kind of issue here. But as a developer I don't think this bug is ready to be tackled by a developer.

Please could someone post exact steps to reproduce on a fresh Ubuntu system? We need a test case before anyone can really look into this properly, and then all those affected can determine if they have the same problem or a different problem.

Secondly, I see that some reporters have said that this is a regression found after upgrade, but I do not see information on what version works and what version didn't. Please tell me what release of Ubuntu you are using and what package versions of libapache2-mod-php5 (or equivalent) work and don't work.

Once this information is provided please change the bug status back to New. Thanks!

Changed in php5 (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
cljk (marcel-pokrandt) wrote :

The problem here is mainly about how to reproduce this issue.

Because sometimes the SoapClient worked for me... sometimes not. I´ll see if I have the possibility to build a reproducable test.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for php5 (Ubuntu) because there has been no activity for 60 days.]

Changed in php5 (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.