php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75586 WSDL parsing issue throws a fatal error instead of a SOAPFault exception
Submitted: 2017-11-28 21:33 UTC Modified: 2018-06-24 10:35 UTC
Votes:8
Avg. Score:4.5 ± 0.7
Reproduced:8 of 8 (100.0%)
Same Version:1 (12.5%)
Same OS:1 (12.5%)
From: ryan dot jentzsch at gmail dot com Assigned:
Status: Re-Opened Package: SOAP related
PHP Version: 7.1.18 OS: Linux Mint 18.3
Private report: No CVE-ID: None
 [2017-11-28 21:33 UTC] ryan dot jentzsch at gmail dot com
Description:
------------
Subclassing the SoapClient class and wrapping the call to the parent constructor will throw a fatal error even when wrapped in a try...catch(\Throwable $t).

With PHP 7 try...catch(\Throwable $t) being a convenient method of adding fault tolerance and graceful degradation -- it is therefore very frustrating when a WSDL PARSE issue is encountered that an UNCATCHABLE script exiting fatal error is issued.

Related: 60780, 45093, (XDEBUG specific: 34657, 49587)
SO "work-around": https://stackoverflow.com/questions/6952814/php-soap-error-catching

Test script:
---------------
<?php
class SoapAgent extends \SoapClient
{
    public function __construct(string $wsdl)
    {
        try {
            parent::__construct($wsdl);
            echo 'Success!' . PHP_EOL;
        } catch (\Throwable $t) {
            var_dump($t);
        }
    }
}

$client = new SoapAgent('bogus');


Expected result:
----------------
var_dump() of the Throwable object.

Actual result:
--------------
Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'bogus' : failed to load external entity "bogus"

Process finished with exit code 255

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-11-28 21:41 UTC] nikic@php.net
-Status: Open +Status: Feedback
 [2017-11-28 21:41 UTC] nikic@php.net
I can't reproduce this issue: The exception object is successfully dumped.

Please check whether your code works under php -n, and if it does, try to identify which extension is responsible for the behavior. My guess would be that the xdebug error handler interferes here.
 [2018-06-24 04:25 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2018-06-24 06:46 UTC] ryan dot jentzsch at gmail dot com
-Status: No Feedback +Status: Closed -PHP Version: 7.1.12 +PHP Version: 7.1.18
 [2018-06-24 06:46 UTC] ryan dot jentzsch at gmail dot com
running `php -n` is not useful since PHP will not compile dying on Line 2: Fatal error: Class 'SoapClient' not found in /home/ryan/wsdl.php on line 2


Now without the `-n` switch PHP emits a warning, and then PHP commits suicide:

```
PHP Warning:  SoapClient::SoapClient(): I/O warning : failed to load external entity "bogus" in /home/ryan/wsdl.php on line 7
PHP Stack trace:
PHP   1. {main}() /home/ryan/wsdl.php:0
PHP   2. SoapAgent->__construct() /home/ryan/wsdl.php:15
PHP   3. SoapAgent->SoapClient() /home/ryan/wsdl.php:7
PHP Fatal error:  SOAP-ERROR: Parsing WSDL: Couldn't load from 'bogus' : failed to load external entity "bogus"
 in /home/ryan/wsdl.php on line 7
PHP Stack trace:
PHP   1. {main}() /home/ryan/wsdl.php:0
PHP   2. SoapAgent->__construct() /home/ryan/wsdl.php:15
PHP   3. SoapAgent->SoapClient() /home/ryan/wsdl.php:7
```
 [2018-06-24 09:08 UTC] nikic@php.net
-Status: Closed +Status: Re-Opened
 [2018-06-24 09:12 UTC] nikic@php.net
This looks very similar to the issue that was supposed to be fixed by https://github.com/php/php-src/commit/024637378827ff03ccfb6b903c9d9b968d30af8d in PHP 7.1.14.
 [2018-06-24 10:35 UTC] ryan dot jentzsch at gmail dot com
nikic@php.net you are correct that it is similar. I just ran the phpt test and this fix is in place and works (if SoapClient is not extended). If the SoapClient class is extended with a try...catch in the __constructor() the point of failure is at parent::__construct('bogus);
Forcing other throwables will actually get caught. It is the `parent::__construct()` where the try...catch is short circuited. I traced the C code down for this a while ago. Internally PHP is calling some XML loading/handling utility modules. These have `zend_bail()` logic in them that is causing PHP to commit suicide.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Nov 05 17:01:30 2024 UTC