This is a bit hard to reproduce, as generally speaking, a webserver with php will echo back an http response with status line and a couple of headers even if the php script aborts for any reason.

But in the case of VikingLine, the network connection might be unreliable to the point where the http response gotten back is completely empty (0 bytes, the socket being closed without a timeout).

This has been tested by introducing a tcp proxy in between the 2 servers doing REST-API calls, and setting the proxy to immediately drop the connections.

When this happens, the class eZRESTClient generates a couple of php warnings, but forwards to the upper layer of code a proper, albeit empty, response. And the upper layer of code might just accept an empty response as valid, depending on the design of the API.

The problem lies in bad error handling inside eZRESTClient::parseHTTTResponse(): instead of returning NULL, it returns an array.
Fixing that, the symptoms are gone, and empty responses do trigger error messages instead of 'all ok'