HTTP/2 header issue: "Accept-Ranges" -> "Accept-Language"

[James Brown]

Here's a strange thing I've noticed:

When using HTTP/2, HAproxy is rewriting the "Accept-Ranges" response header
into "Accept-Language".

You can see this yourself by comparing the output of

curl --http2 -vs -o /dev/null https://www.easypost.com
curl --http1.1 -vs -o /dev/null https://www.easypost.com

Here's what I see

% diff <(curl --http1.1 -vs -o /dev/null https://www.easypost.com 2>&1 |
egrep -o '< [^:]+:' | sed -e 's/< //' | tr '[:upper:]' '[:lower:]') <(curl
--http2 -vs -o /dev/null https://www.easypost.com 2>&1 | egrep -o '<
[^:]+:' | sed -e 's/< //' | tr '[:upper:]' '[:lower:]')
14c14
< accept-ranges:
---
The backend in this case is HTTP/1.1; HAproxy is doing the 1.1 -> 2
conversion itself. This is with HAproxy 1.8.14. I have not tested with
HAproxy 1.9.

Any thoughts?

[Lukas Tribus]

Hi James,

When using HTTP/2, HAproxy is rewriting the "Accept-Ranges" response header into "Accept-Language".

Yup, exactly as you described, thanks for the report.

I assume this is a bug in the HPACK encoder, given that in the static
table definition [1], accept-language has index 17, while
accept-ranges has 18, which is correctly documented in
src/hpack-tbl.c, but the comment on line 105 in src/hpack-enc.c makes
me doubt our implementation:

out->str[len++] = 0x51; // literal with indexing --
name="accept-ranges" (idx 17)


Too much string magic going on there for me to provide prompt
solution, but I assume this will be a quick fix for Willy.

This bug is in there since the HPACK encoder was introduced in 1.8-rc1.



cheers,
lukas

[1] https://tools.ietf.org/html/rfc7541#appendix-A

[Willy Tarreau]

Hi guys,

Post by Lukas Tribus
Hi James,

When using HTTP/2, HAproxy is rewriting the "Accept-Ranges" response header into "Accept-Language".

Yup, exactly as you described, thanks for the report.
I assume this is a bug in the HPACK encoder, given that in the static
table definition [1], accept-language has index 17, while
accept-ranges has 18, which is correctly documented in
src/hpack-tbl.c, but the comment on line 105 in src/hpack-enc.c makes
out->str[len++] = 0x51; // literal with indexing --
name="accept-ranges" (idx 17)
Too much string magic going on there for me to provide prompt
solution, but I assume this will be a quick fix for Willy.

Gloups! I'm quite ashamed, totally ashamed, almost red. I'll take a
look at this tomorrow. Thanks for the report!

Willy

[Willy Tarreau]

Post by Willy Tarreau

Post by Lukas Tribus
I assume this is a bug in the HPACK encoder, given that in the static
table definition [1], accept-language has index 17, while
accept-ranges has 18, which is correctly documented in
src/hpack-tbl.c, but the comment on line 105 in src/hpack-enc.c makes
out->str[len++] = 0x51; // literal with indexing --
name="accept-ranges" (idx 17)
Too much string magic going on there for me to provide prompt
solution, but I assume this will be a quick fix for Willy.

Gloups! I'm quite ashamed, totally ashamed, almost red. I'll take a
look at this tomorrow. Thanks for the report!

I've just pushed the fix. I'm attaching the backported version for your
convenience (as it will not apply as-is to 1.8).

Thanks!
Willy

[James Brown]

I have tested that patch and it seems to work. https://www.easypost.com is
now returning the correct headers over HTTP/2.

Thanks for the quick turnaround!

Post by Willy Tarreau

Post by Willy Tarreau

Post by Lukas Tribus
I assume this is a bug in the HPACK encoder, given that in the static
table definition [1], accept-language has index 17, while
accept-ranges has 18, which is correctly documented in
src/hpack-tbl.c, but the comment on line 105 in src/hpack-enc.c makes
out->str[len++] = 0x51; // literal with indexing --
name="accept-ranges" (idx 17)
Too much string magic going on there for me to provide prompt
solution, but I assume this will be a quick fix for Willy.

Gloups! I'm quite ashamed, totally ashamed, almost red. I'll take a
look at this tomorrow. Thanks for the report!

I've just pushed the fix. I'm attaching the backported version for your
convenience (as it will not apply as-is to 1.8).
Thanks!
Willy

[Willy Tarreau]

Post by James Brown
I have tested that patch and it seems to work. https://www.easypost.com is
now returning the correct headers over HTTP/2.
Thanks for the quick turnaround!

Great, thanks for confirming the fix ;-)

Willy