Invalid response line returned from server

[Jaspero95]

After upgrading to version 1.8.0, we see a lot of API errors in the Paazl log on our test environments. As a result, the checkout widget does not load, and as a fallback only the Magento shipping methods show in the shipping step of the checkout.

[2021-10-19 06:47:04] Magento2.INFO: Token request: : {"reference":"885939"} [] []
[2021-10-19 06:47:04] Magento2.INFO: exception: API error [] []

When adding some additional logging, I found that the error we see is actually the following:
Invalid response line returned from server: HTTP/2 200

This error is thrown in \Paazl\CheckoutWidget\Model\Api\Http\Client::parseHeaders:

if ($this->_headerCount == 0) {
            $line = explode(" ", trim($data), 3);
            if (count($line) != 3) {
                $this->doError("Invalid response line returned from server: " . $data);
            }
            $code = intval($line[1]);

Looks like the client expects the status line in the response to consist of 3 parts, separated by spaces. However, in our case, it only consists of 2 parts ("HTTP/2" and "200"). The original method, \Magento\Framework\HTTP\Client\Curl::parseHeaders, does indeed only throw an error if there are less than 2 parts:

if ($this->_headerCount == 0) {
            $line = explode(" ", trim($data), 3);
            if (count($line) < 2) {
                $this->doError("Invalid response line returned from server: " . $data);
            }
            $this->_responseStatus = (int)$line[1];

Is there any reason for this? If I change the "!= 3" to "< 2" like in Magento's CURL client, the widget works just fine.

Paazl version: 1.8.0
Magento version: 2.4.3

[hostep]

Noticing the same over here since today.

Why are you guys writing your own http client instead of using some http client that ships with Magento itself?
Magento solved this HTTP/2 header parsing a couple of years ago: magento/magento2#19143

Did you guys recently changed your server infrastructure to switch to http/2 maybe?

Edit, on another environment I see this error happening only on 11 October 2021.

[hostep]

Okay, so it appears that at this time, only the staging environment of Paazl runs over HTTP/2:

$ curl -s -I https://api-acc.paazl.com/v1/ | grep -i http
HTTP/2 401

Production environment is still on HTTP/1.1:

$ curl -s -I https://api.paazl.com/v1/ | grep -i http
HTTP/1.1 401 Unauthorized

But from the log history I find, it appears this switch to HTTP/2 did happen on production as well on the 11 October for about 1 to 2 hours.

[Jaspero95]

Okay, so it appears that at this time, only the staging environment of Paazl runs over HTTP/2:

$ curl -s -I https://api-acc.paazl.com/v1/ | grep -i http
HTTP/2 401

Production environment is still on HTTP/1.1:

$ curl -s -I https://api.paazl.com/v1/ | grep -i http
HTTP/1.1 401 Unauthorized

But from the log history I find, it appears this switch to HTTP/2 did happen on production as well on the 11 October for about 1 to 2 hours.

Good catch, explains why so far only our test environments are currently experiencing this issue. For now we patched this temporarily, replacing the != 3 in the snippet from my previous comment with < 2 like in the Magento client. This at least allows us to use the Paazl widget on those environments again, and will hopefully prevent issues if they suddenly switch this on production. But I'm also wondering why Paazl is using a custom client, and when there will be an officiel bug fix for this.

[paazl-jaime]

Hi @Jaspero95 , @hostep ,

Many thanks for contacting us. We are indeed aware of this issue and are working on a patch. We are currently testing the outcome of the changes.

We will keep you posted about the release of the patch.

[Jaspero95]

Looks like the issue is fixed in version 1.9.1, so I'll close this issue. Thanks for the quick action!

[Frank-Magmodules]

HI @Jaspero95 , thanks for your confirmation, was just about to update you on this!   

About the question regarding the custom Client.; we use the customized CURL client for the PUT and DELETE request, which is not implemented in the Magento built-in client.  

Anyway, glad that this is fixed now! 👍