Bug 42773 - WSDL error causes HTTP 500 Response

18 years ago by nick loeve — view source — reply

unread

Hello,

I see that the bug was marked fixed in 5.2.5, and that a HTTP 500
response code is not automatically sent, but isn't the whole problem
that attempting to load a WSDL that cannot be loaded should raise an
exception and not fatal error?

Is this discussion appropriate for this bug, or should I open another?

Cheers

--
Nick Loeve

18 years ago by Alexey Zakhlestin — view source — reply

unread

imho, exceptions are preferrable in a lot of php's functions…
but core php programmers are usually against exceptions if it is not
an error of object-constructor

Hello,

I see that the bug was marked fixed in 5.2.5, and that a HTTP 500
response code is not automatically sent, but isn't the whole problem
that attempting to load a WSDL that cannot be loaded should raise an
exception and not fatal error?

Is this discussion appropriate for this bug, or should I open another?

Cheers

--
Nick Loeve

--

--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

18 years ago by nick loeve — view source — reply

unread

imho, exceptions are preferrable in a lot of php's functions…
but core php programmers are usually against exceptions if it is not
an error of object-constructor

Well in this case the constructor to the SoapClient class specifically
allows you to say you would like to use exceptions for SoapFaults. Is
this not a SoapFault... ?

Hello,

I see that the bug was marked fixed in 5.2.5, and that a HTTP 500
response code is not automatically sent, but isn't the whole problem
that attempting to load a WSDL that cannot be loaded should raise an
exception and not fatal error?

Is this discussion appropriate for this bug, or should I open another?

Cheers

--
Nick Loeve

--

--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

--
Nick Loeve
www.trickie.org

18 years ago by Lukas Kahwe Smith — view source — reply

unread

imho, exceptions are preferrable in a lot of php's functions…
but core php programmers are usually against exceptions if it is not
an error of object-constructor

Well in this case the constructor to the SoapClient class specifically
allows you to say you would like to use exceptions for SoapFaults. Is
this not a SoapFault... ?

well its not a soap fault .. since that is something that the service
should throw. the wsdl reading error occurs before you even talk to
the soap service. that being said, i do agree that this should not be
a fatal error. fopen() type hacks prevent the use of the wsdl cache
and are inefficient for obvious reasons.

regards,
Lukas

18 years ago by nick loeve — view source — reply

unread

Woops didn't CC the list

---------- Forwarded message ----------
From: nick loeve trickie@gmail.com
Date: Nov 23, 2007 4:21 PM
Subject: Re: [PHP-DEV] Bug 42773 - WSDL error causes HTTP 500 Response
To: Lukas Kahwe Smith mls@pooteeweet.org

imho, exceptions are preferrable in a lot of php's functions…
but core php programmers are usually against exceptions if it is not
an error of object-constructor

Well in this case the constructor to the SoapClient class specifically
allows you to say you would like to use exceptions for SoapFaults. Is
this not a SoapFault... ?

well its not a soap fault .. since that is something that the service
should throw. the wsdl reading error occurs before you even talk to
the soap service. that being said, i do agree that this should not be
a fatal error. fopen() type hacks prevent the use of the wsdl cache
and are inefficient for obvious reasons.

If i attempt to load a WSDL that does not exist I get two fatal
errors! One is a fatal error saying that i cannot load the WSDL, and
the other is that there is an uncaught exception (with the faultString
saying i cannot load the WSDL):

nick@nick ~/src/php_cvs/php5/ext/soap $ php -r '$client = new
SoapClient("thisdoesnotexist");'
PHP Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity "thisdoesnotexist" in Command line code on line 1

Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity "thisdoesnotexist" in Command line code on line 1
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from
'thisdoesnotexist' in Command line code on line 1
PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR:
Parsing WSDL: Couldn't load from 'thisdoesnotexist' in Command line
code:1
Stack trace:
#0 Command line code(1): SoapClient->SoapClient('thisdoesnotexis...')
#1 {main}
thrown in Command line code on line 1

Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from 'thisdoesnotexist' in Command line code:1
Stack trace:
#0 Command line code(1): SoapClient->SoapClient('thisdoesnotexis...')
#1 {main}
thrown in Command line code on line 1

If i then proceed to wrap the constructor in a try/catch then i can
catch the exception but i still get a fatal error:

nick@nick ~/src/php_cvs/php5/ext/soap $ php -r 'try { $client = new
SoapClient("asdasdasd");} catch(Exception $e){ echo "caught
exception"; }'
PHP Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity "asdasdasd" in Command line code on line 1

Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity "asdasdasd" in Command line code on line 1
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from
'asdasdasd' in Command line code on line 1

Does anyone else find this strange behavior? Or am I just missing
something simple?

I also looked at http://bugs.php.net/bug.php?id=34657 and I see that
it is marked nothing to fix in the SOAP extension, yet in php_sdl.c

240 wsdl = soap_xmlParseFile(struri TSRMLS_CC);
241
242 if (!wsdl) {
243 soap_error1(E_ERROR, "Parsing WSDL: Couldn't load
from '%s'", struri);
244 }

Which is triggering a fatal error. Should i make a new bug, request
that one of the previous ones is re-opened or is this behaviour never
going to change? I do not mind attempting to come up with a patch, but
it seems that quite a lot of operations in the SOAP ext just fatal out
also.

Cheers

regards,
Lukas

--
Nick Loeve
www.trickie.org

18 years ago by nick loeve — view source — reply

unread

---------- Forwarded message ----------
From: nick loeve trickie@gmail.com
Date: Nov 27, 2007 11:39 AM
Subject: Re: Fwd: [PHP-DEV] Bug 42773 - WSDL error causes HTTP 500 Response
To: Rob Richards rrichards@ctindustries.net

nick loeve wrote:

Woops didn't CC the list

---------- Forwarded message ----------
From: nick loeve trickie@gmail.com
Date: Nov 23, 2007 4:21 PM
Subject: Re: [PHP-DEV] Bug 42773 - WSDL error causes HTTP 500 Response
To: Lukas Kahwe Smith mls@pooteeweet.org

imho, exceptions are preferrable in a lot of php's functions…
but core php programmers are usually against exceptions if it is not
an error of object-constructor

Well in this case the constructor to the SoapClient class specifically
allows you to say you would like to use exceptions for SoapFaults. Is
this not a SoapFault... ?

well its not a soap fault .. since that is something that the service
should throw. the wsdl reading error occurs before you even talk to
the soap service. that being said, i do agree that this should not be
a fatal error. fopen() type hacks prevent the use of the wsdl cache
and are inefficient for obvious reasons.

If i attempt to load a WSDL that does not exist I get two fatal
errors! One is a fatal error saying that i cannot load the WSDL, and
the other is that there is an uncaught exception (with the faultString
saying i cannot load the WSDL):

nick@nick ~/src/php_cvs/php5/ext/soap $ php -r '$client = new
SoapClient("thisdoesnotexist");'
PHP Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity "thisdoesnotexist" in Command line code on line 1

Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity "thisdoesnotexist" in Command line code on line 1
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from
'thisdoesnotexist' in Command line code on line 1
PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR:
Parsing WSDL: Couldn't load from 'thisdoesnotexist' in Command line
code:1
Stack trace:
#0 Command line code(1): SoapClient->SoapClient('thisdoesnotexis...')
#1 {main}
thrown in Command line code on line 1

Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from 'thisdoesnotexist' in Command line code:1
Stack trace:
#0 Command line code(1): SoapClient->SoapClient('thisdoesnotexis...')
#1 {main}
thrown in Command line code on line 1

If i then proceed to wrap the constructor in a try/catch then i can
catch the exception but i still get a fatal error:

nick@nick ~/src/php_cvs/php5/ext/soap $ php -r 'try { $client = new
SoapClient("asdasdasd");} catch(Exception $e){ echo "caught
exception"; }'
PHP Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity "asdasdasd" in Command line code on line 1

Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity "asdasdasd" in Command line code on line 1
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from
'asdasdasd' in Command line code on line 1

Does anyone else find this strange behavior? Or am I just missing
something simple?

I also looked at http://bugs.php.net/bug.php?id=34657 and I see that
it is marked nothing to fix in the SOAP extension, yet in php_sdl.c

240 wsdl = soap_xmlParseFile(struri TSRMLS_CC);
241
242 if (!wsdl) {
243 soap_error1(E_ERROR, "Parsing WSDL: Couldn't load
from '%s'", struri);
244 }

Which is triggering a fatal error. Should i make a new bug, request
that one of the previous ones is re-opened or is this behaviour never
going to change? I do not mind attempting to come up with a patch, but
it seems that quite a lot of operations in the SOAP ext just fatal out
also.

You're seeing the fatal error because you have error logging on but
didnt specify an error log, so it is getting directed to STDOUT.

I know. I was just showing the list what errors get emitted, which
looks strange to me (two different fatals ?)

Rob

--

Nick Loeve
www.trickie.org

--
Nick Loeve
www.trickie.org

Bug 42773 - WSDL error causes HTTP 500 Response View as Markdown