H2: interoperability issue due to lack of CONTINUATION frame support
Closed this issue · 5 comments
(user hat on)
Output of haproxy -vv and uname -a
lukas@dev:~/haproxy-1.8$ ./haproxy -vv
HA-Proxy version 1.8.16 2018/12/21
Copyright 2000-2018 Willy Tarreau <willy@haproxy.org>
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-unused-label
OPTIONS = USE_GETADDRINFO=1 USE_OPENSSL=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
Running on OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built without PCRE or PCRE2 support (using libc's regex instead)
Built without compression support (neither USE_ZLIB nor USE_SLZ are set).
Compression algorithms supported : identity("identity")
Built with network namespace support.
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
lukas@dev:~/haproxy-1.8$ uname -a
Linux dev 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
lukas@dev:~/haproxy-1.8$
What's the configuration?
frontend h2
bind :443 ssl crt /etc/ssl/private/cert.pem alpn h2,http/1.1
Expected behavior
Forward and serve all quieries.
Actual behavior
Large H2 fail with Chrome 49.
Steps to reproduce the behavior
Make a large H2 request with Chrome 49 (large cookies or long URI).
Do you have any idea what may have caused this?
No.
Do you have an idea how to solve the issue?
No.
Chrome 49 is EOL, why use it?
user hat: only supported release on Windows XP.
haproxy is currently unable to handle CONTINUATION [1] frames (see haproxy/haproxy@61290ec).
If a client emits a CONTINUATION frame, we will break the connection and send GOAWAY due to INTERNAL_ERROR. This of course leads to interoperability issues.
Notably, older Chrome/Chromium releases (50.0.2645.4 and older), lacking chromium/chromium@a8bff211e ("Increase sent control frame fragment size to 16 kB") [3], will cap the maximum control frame size at 1024 bytes, triggering CONTINUATION, when large headers are used (long URIs, or large cookies).
This is considered a feature request, not a bug.
Feature is now in master haproxy/haproxy@ea18f86