Response header "Hm-Collection-Range" is missing - in Order Units with api sandbox keys

[Ivorius]

I try find order units over api sandbox keys from kaufland.de like this

$this->getClient()->orderUnits()->find('open', null, null, null, 'ts_created:desc', 30, 0); but it throws ServerException Response header "Hm-Collection-Range" is missing

After debugging on Hitmeister\Component\Api\Helper\Response::extractCursorPosition I see some json data in body and this headers

Array
(
    [Server] => Array
        (
            [0] => nginx
        )

    [Date] => Array
        (
            [0] => Tue, 17 Aug 2021 06:20:21 GMT
        )

    [Content-Type] => Array
        (
            [0] => application/json
        )

    [Transfer-Encoding] => Array
        (
            [0] => chunked
        )

    [Connection] => Array
        (
            [0] => keep-alive
        )

    [Set-Cookie] => Array
        (
            [0] => PHPSESSID=2jh1koq29eqo67sta43s3p4vr9; path=/
            [1] => x-storefront=de; Domain=.kaufland.de; Path=/; SameSite=none; Secure
        )

    [Expires] => Array
        (
            [0] => Thu, 19 Nov 1981 08:52:00 GMT
        )

    [Cache-Control] => Array
        (
            [0] => no-store, no-cache, must-revalidate
        )

    [Pragma] => Array
        (
            [0] => no-cache
        )

    [X-Hm-Sandbox-Mode] => Array
        (
            [0] => 1
        )

    [X-Backend] => Array
        (
            [0] => shop-api-backend03
        )

    [Age] => Array
        (
            [0] => 0
        )

    [X-Cache] => Array
        (
            [0] => MISS
        )

    [Accept-Ranges] => Array
        (
            [0] => bytes
        )

    [Content-Security-Policy] => Array
        (
            [0] => default-src https: 'unsafe-inline' 'unsafe-eval' data: blob:
        )

    [Referrer-Policy] => Array
        (
            [0] => strict-origin-when-cross-origin
        )

    [Strict-Transport-Security] => Array
        (
            [0] => max-age=63072000
        )

    [X-Content-Type-Options] => Array
        (
            [0] => nosniff
        )

    [X-Frame-Options] => Array
        (
            [0] => SAMEORIGIN
        )

    [X-XSS-Protection] => Array
        (
            [0] => 1
        )

)

Is problem with sandbox api keys? How else can I test the implementation?

[DamianoMazzara]

I've the same problem. Did you solve it?

[Ivorius]

No, it is problem with sandbox keys. Using own keys is ok.

[DamianoMazzara]

I can't believe the error was the following:

The entire sdk looks for headers in case-sensitive way.

For example, the issue you have shared here, is caused by the following code:

if (!isset($data['headers']['Hm-Collection-Range'][0])) { throw new ServerException('Response header "Hm-Collection-Range" is missing.'); }

But sometimes the headers are retrieved by web servers in lower case, in my case in fact the array contains hm-collection-range and not Hm-Collection-Range.

The reason is that respecting HTTP/2 standard headers MUST be lower case, this is why php-curl automatically changes (for example) Hm-Collection-Range to hm-collection-range.

8.1.2.  HTTP Header Fields

   HTTP header fields carry information as a series of key-value pairs.
   For a listing of registered HTTP headers, see the "Message Header
   Field" registry maintained at <https://www.iana.org/assignments/
   message-headers>.

   Just as in HTTP/1.x, header field names are strings of ASCII
   characters that are compared in a case-insensitive fashion.  However,
   header field names MUST be converted to lowercase prior to their
   encoding in HTTP/2.  A request or response containing uppercase
   header field names MUST be treated as malformed (Section 8.1.2.6).

Source

Anyway I can't waste time by adapting this sdk to work with HTTP/2 so i've changed the configuration of the server by forcing HTTP/1.

I hope this can help you or other people with the same problem.

[hassamchohan]

@Ivorius were you able to solve the problem as mentioned by Damiano ?

[DamianoMazzara]

@Ivorius were you able to solve the problem as mentioned by Damiano ?

In this issue one of the developers says he released a working version that forces HTTP 1.1
So I've tried to install an updated version of the develop branch but it gave me some other errors.
So I kept my old version and changed ['headers']['Hm-Collection-Range'] and ['headers']['Location'] with lowecase versions.
In this way I get the advantages of HTTP 2 instead of remaining with HTTP 1.1

Anyway I think that version 1.26.1 should force HTTP 1.1 and fix the problems by itself.

@Ivorius said it was working with his code by using own keys but I think he was using different servers and the development one (using sandbox keys) used HTTP 2.0, but I would wait his reply to understand if he still needs to make sdk work with http 2.

[mylemans]

Same issue here.