From: Willy Tarreau Date: Tue, 7 Jul 2020 13:55:23 +0000 (+0200) Subject: DOC: configuration: remove obsolete mentions of H2 being converted to HTTP/1.x X-Git-Tag: v2.2.0~5 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=253c2519c2d3e394cc71630331dd79ceb14c57ec;p=thirdparty%2Fhaproxy.git DOC: configuration: remove obsolete mentions of H2 being converted to HTTP/1.x The first H2 implementation in version 1.8 used to turn HTTP/2 requests to HTTP/1.1, causing many limitations. This is not true anymore and we don't suffer from the lack of server-side H2 nor are we forced to close mode anymore, so let's remove such obsolete mentions. This could be backported to 2.0. --- diff --git a/doc/configuration.txt b/doc/configuration.txt index ff8483f0cb..85f228a262 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -201,11 +201,6 @@ HAProxy supports 4 connection modes : - server close : the server-facing connection is closed after the response. - close : the connection is actively closed after end of response. -For HTTP/2, the connection mode resembles more the "server close" mode : given -the independence of all streams, there is currently no place to hook the idle -server connection after a response, so it is closed after the response. HTTP/2 -is only supported for incoming connections, not on connections going to -servers. 1.2. HTTP request @@ -274,10 +269,6 @@ specific to the language, framework or application in use. HTTP/2 doesn't convey a version information with the request, so the version is assumed to be the same as the one of the underlying protocol (i.e. "HTTP/2"). -However, haproxy natively processes HTTP/1.x requests and headers, so requests -received over an HTTP/2 connection are transcoded to HTTP/1.1 before being -processed. This explains why they still appear as "HTTP/1.1" in haproxy's logs -as well as in server logs. 1.2.2. The request headers @@ -295,7 +286,10 @@ define a total of 3 values for the "Accept:" header. Contrary to a common misconception, header names are not case-sensitive, and their values are not either if they refer to other header names (such as the "Connection:" header). In HTTP/2, header names are always sent in lower case, -as can be seen when running in debug mode. +as can be seen when running in debug mode. Internally, all header names are +normalized to lower case so that HTTP/1.x and HTTP/2 use the exact same +representation, and they are sent as-is on the other side. This explains why an +HTTP/1.x request typed with camel case is delivered in lower case. The end of the headers is indicated by the first empty line. People often say that it's a double line feed, which is not exact, even if a double line feed