looks like we got no XML document - nice message, but why is it so? 🤔

[trailsnail]

What is it about?

We retrieve data via a SOAP api, a list of many offers.
These offers are created and maintained in the customer's ERP system. Employees sometimes copy text from Word or a PDF into the text fields of a offer. Sometimes special characters are inserted.

When decoding the request response in the ExtSoapDecoder::decode(), the error looks like we got no XML document occurs. The entire process aborts. The error-free offers cannot be processed due to an incorrect offer.

Unfortunately, it is not possible to retrieve each offer individually in order to bypass the incorrect one.

What can we do?

Debugging is currently the order of the day, narrowing down the period from when the error occurs and which offers could match it. Then retrieve the offer explicitly via Postman or debugging in the code, copy the response for decoding into the IDE or examine it with text editors to find the needle in the haystack that makes decoding impossible.

Is there another way?

It would be helpful to have an error output that provides us with information about where the error is in the data or even what exactly is causing the error.
Do you also struggle with such challenges or have you already found a solution? We would be delighted to hear your ideas and suggestions.

Kind regards

[veewee]

Hello,

The exception is coming from PHP's SoapClient and means it is unable to parse the provided XML response.

 is an invalid character in XML. The best way to overcome this error is to add a HTTP plugin/Middleware that makes sure the XML is parsable by for example cleaning up this and any other unsupported character you encounter before they get decoded by the SoapClient.

https://3v4l.org/PkH7j

$doc = new DOMDocument();
$doc->loadXML('<test>wor&#x2;ld</test>');

echo($doc->documentElement->nodeValue);

Warning: DOMDocument::loadXML(): xmlParseCharRef: invalid xmlChar value 2 in Entity,

[veewee]

Isn't the issue related to:

            } catch (Throwable $e) {
                // do nothing atm
            }

This results in the response being passed as-is with invalid XML chars.
You should be able to throw an exception in there which will result in the response not being passed to the SOAP decoder.

(note that you are not required to include an error callback in then(_, here))

[veewee]

BTW, moving from the old middleware to plugin, should be a matter of using this method - which is basically what the base Middleware class was providing : https://github.com/phpro/soap-client/blob/v1.7.x/src/Phpro/SoapClient/Middleware/Middleware.php

    public function handleRequest(RequestInterface $request, callable $next, callable $first): Promise
    {
        return $this->beforeRequest($next, $request)
            ->then(
                (function (ResponseInterface $response) {
                    return $this->afterResponse($response);
                })->bindTo($this),
                (function (Exception $exception) {
                    $this->onError($exception);
                })->bindTo($this)
            );
    }

(since interface MiddlewareInterface extends Plugin)

[trailsnail]

This results in the response being passed as-is with invalid XML chars.
You should be able to throw an exception in there which will result in the response not being passed to the SOAP decoder.

No, this doesn't work.

Here is a little bit more stacktrace from error:

Uncaught exception: 'Phpro\SoapClient\Exception\SoapException' with message 'looks like we got no XML document' (0)
> in /cluster/www/www/www/philipp/vendor/phpro/soap-client/src/Phpro/SoapClient/Exception/SoapException.php:19
Caused by 'SoapFault' with message 'looks like we got no XML document' (0)
> in /cluster/www/www/www/philipp/vendor/php-soap/ext-soap-engine/src/ExtSoapDecoder.php:26
Stack trace:
#0 /cluster/www/www/www/philipp/vendor/phpro/soap-client/src/Phpro/SoapClient/Caller/EngineCaller.php(37): Phpro\SoapClient\Exception\SoapException::fromThrowable()
#1 /cluster/www/www/www/philipp/vendor/phpro/soap-client/src/Phpro/SoapClient/Caller/EventDispatchingCaller.php(30): Phpro\SoapClient\Caller\EngineCaller->__invoke()
#2 /cluster/www/www/www/philipp/soap/offer/generated/OfferClient.php(60): Phpro\SoapClient\Caller\EventDispatchingCaller->__invoke()
#3 /cluster/www/www/www/philipp/app/portal/lib/navision/integration/OfferRepository.php(244): WebConnector\Offer\OfferClient->readMultiple()

👀 on working request

 public function handleRequest(RequestInterface $request, callable $next, callable $first): Promise
    {
        return $next($request)->then(function (ResponseInterface $response) {

            dump($response);
            
            try {
                // Check response for possible invalid characters
            } catch (Throwable $e) {
                // do nothing atm
            }

            return $response;
        }, function (\Http\Client\Exception $exception) {
            echo $exception->getMessage();

            throw $exception;
        });
    }

Here I have the Response to work with (screenshot dumped $response)

But the request which receives the XML with invalid character errors so hard that I can't even catch the exception in the middleware.
I don't know how it is possible to do something with the $response it is decoded there:

final class SimpleEngine implements Engine
{
	...
    public function request(string $method, array $arguments)
    {
        $request = $this->driver->encode($method, $arguments);
        $response = $this->transport->request($request);

        return $this->driver->decode($method, $response);
    }
	...
}

[veewee]

Hello,

It's a bit hard for me to see what is going wrong in your very specific code of course :)

Does the invalid request got dumped as well or not?
Given that you state "errors so hard that I can't even catch the exception", it hints me again that the response is not being parsed by this specific middleware. Would it be possible to comment out all other middlewares to make sure none of them are trying to parse the XML and to return the response as-is without skipping any next middleware?

You should be able to dump the exception from the middleware. If not, it's most likely another middleware that is interfering.

[trailsnail]

A huge apology from me and sorry for the inconvenience.

The original middleware did not have the purpose of intercepting the error "looks like we got no XML document" and creating corresponding feedback for the user.

Therefore, it is perfectly fine for the error to occur.
What did not work, I believed, was the test decoding to identify possible invalid characters.

But that also worked. What really didn't work was collecting the XML errors via libxml_use_internal_errors(true) in our Helper class called witzhin the afterResponse() middleware method. The flag libxml_use_internal_errors was reset too early, which resulted in libxml_get_errors() not returning any errors.

Conclusion: misinterpreted what can be misinterpreted, looked for in the wrong place.

Own middleware with handleRequest() and afterResponse() hook now works as expected.

Thanks for your support and have a nice time