SOAP Null response if HTTP Status 500 (Soap multipart)

[lampi87]

Description

I've created a soap request with integrated soapclient. As long as the request contains only valid data everything works fine.
But as soon as the request fails, the server returns HTTP Status 500 and __getLastResponse is NULL, even if data is returned. Below you can find the SOAP request and the expected answer based on SOAP UI request

<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://soap.elgaad.client.chipkarte.at"><SOAP-ENV:Body><ns1:medikationslisteAbrufen><ns1:dialogId>***</ns1:dialogId><ns1:svNummer>***</ns1:svNummer></ns1:medikationslisteAbrufen></SOAP-ENV:Body></SOAP-ENV:Envelope>

Resulted in this output:

NULL

But I expected this output instead (tested with SOAP UI):

HTTP/1.1 500 Internal Server Error
Date: Wed, 11 Dec 2024 11:45:00 GMT
X-XSS-Protection: 1; mode=block
x-svc-txid: 675D8D1E-6293-93B3-B3A878082-563637D226D2
content-type: multipart/related; type="application/xop+xml"; boundary="uuid:526138f4-3cc1-4d40-981e-39bdc32a6632"; start="<[email protected]>"; start-info="text/xml"
set-cookie: ddb0257ce6715b899a96f865ea470a48=ed27582e759691197e8e7df4d31746b7; path=/; HttpOnly; Secure; SameSite=None
Connection: close
Set-Cookie: TS01217861=011c0a1cd3e0f158877398dc50f674ad3149742906cc11e92156345a62410760a1a073c6c89be1bcbdc7fb3c6f84adeb44780a9915; Path=/; Secure; HTTPOnly
Transfer-Encoding: chunked


--uuid:526138f4-3cc1-4d40-981e-39bdc32a6632
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <[email protected]>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring></faultstring><detail><DialogException xmlns="http://exceptions.soap.base.client.chipkarte.at" xmlns:ns2="http://soap.base.client.chipkarte.at"><code>CL-01085</code><errorCode>1</errorCode><message>Der Dialog ist ungültig. Bitte melden Sie sich erneut an. (CL-01085)</message></DialogException></detail></soap:Fault></soap:Body></soap:Envelope>
--uuid:526138f4-3cc1-4d40-981e-39bdc32a6632--

Similar problems from other persons:
https://stackoverflow.com/questions/22375590/soapclient-returns-empty-response-on-http-500-error-when-body-is-not-empty
https://stackoverflow.com/questions/43815114/php-soapclient-returning-null-when-server-sends-back-an-error-response

Same behavior with PHP 8.1

PHP Version

PHP 8.3.13

Operating System

Windows Server 2016

[nielsdos]

Actually returning the response instead of null on failure in __goRequest would break a lot of code and would also need a new way to signal failure. I suppose for most cases it is enough to make sure __getLastResponse returns non-NULL, which you seem to hint at. This is doable but since it's a behaviour change this can only happen in the master branch.

[nielsdos]

I believe the old behaviour was intentional so this is more of a feature request anyway...

[lampi87]

After further investigation I think I mixed up two different things. The bug and the workaround I tried to fix this.

If the response has content-type: text/xml everything works fine and SoapFault is filled with details based on soap:Fault response.

} catch (\SoapFault $e) {
            var_dump($e->detail); // object(stdClass)#4951 (1) { ["DialogException"]=>... } }
}

As integrated SoapClient does not support multipart messages, I tried to extract soap content (including soap fault) from response. But due to http status code 500, the response is empty and I cannot extract soap fault.
Additionally SoapFault detail is empty, because response was multipart message

} catch (\SoapFault $e) {
            var_dump($e->detail); // is NULL
}

Any chance to fill $e->detail for multipart responses?
Otherwise its not possible to track soap:fault details with integrated soapclient

[nielsdos]

Filling in the data would require adding multipart support to the http layer of SOAP, something I had started work on some time ago but have yet to finish.
This also means this is a duplicate of https://bugs.php.net/bug.php?id=47810, but I'm keeping this open as we use GitHub nowadays to track issues.