From: Christopher Faulet Date: Tue, 16 Jul 2019 13:09:52 +0000 (+0200) Subject: DOC: config: Update as a result of the legacy HTTP removal X-Git-Tag: v2.1-dev2~342 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=159e6672560acc2e1dd73088b3c3773bbf2c5646;p=thirdparty%2Fhaproxy.git DOC: config: Update as a result of the legacy HTTP removal Doc about the options 'http-tunnel' and 'http-use-htx' were removed. --- diff --git a/doc/configuration.txt b/doc/configuration.txt index 8678b8028c..805ab0c58b 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -2295,14 +2295,6 @@ the backend's. HAProxy supports 4 connection modes : requests and responses are processed, and connections remain open but idle between responses and new requests. - - TUN: tunnel ("option http-tunnel") : this was the default mode for versions - 1.0 to 1.5-dev21 : only the first request and response are processed, and - everything else is forwarded with no analysis at all. This mode should not - be used as it creates lots of trouble with logging and HTTP processing. - And because it cannot work in HTTP/2, this option is deprecated and it is - only supported on legacy HTTP frontends. In HTX, it is ignored and a - warning is emitted during HAProxy startup. - - SCL: server close ("option http-server-close") : the server-facing connection is closed after the end of the response is received, but the client-facing connection remains open. @@ -2321,8 +2313,6 @@ weakest option and close is the strongest. ----+-----+-----+---- KAL | KAL | SCL | CLO ----+-----+-----+---- - TUN | TUN | SCL | CLO - Frontend ----+-----+-----+---- mode SCL | SCL | SCL | CLO ----+-----+-----+---- CLO | CLO | CLO | CLO @@ -2414,9 +2404,7 @@ option http-keep-alive (*) X X X X option http-no-delay (*) X X X X option http-pretend-keepalive (*) X - X X option http-server-close (*) X X X X -option http-tunnel (deprecated) (*) X X X - option http-use-proxy-header (*) X X X - -option http-use-htx (*) X X X X option httpchk X - X X option httpclose (*) X X X X option httplog X X X - @@ -6166,9 +6154,9 @@ no option http-keep-alive connections: for each connection it processes each request and response, and leaves the connection idle on both sides between the end of a response and the start of a new request. This mode may be changed by several options such - as "option http-server-close", "option httpclose" or "option http-tunnel". - This option allows to set back the keep-alive mode, which can be useful when - another mode was used in a defaults section. + as "option http-server-close" or "option httpclose". This option allows to + set back the keep-alive mode, which can be useful when another mode was used + in a defaults section. Setting "option http-keep-alive" enables HTTP keep-alive mode on the client- and server- sides. This provides the lowest latency on the client side (slow @@ -6202,9 +6190,9 @@ no option http-keep-alive timeout defined by "timeout http-keep-alive" or "timeout http-request" if not set. - This option disables and replaces any previous "option httpclose", "option - http-server-close" or "option http-tunnel". When backend and frontend options - differ, all of these 4 options have precedence over "option http-keep-alive". + This option disables and replaces any previous "option httpclose" or "option + http-server-close". When backend and frontend options differ, all of these 4 + options have precedence over "option http-keep-alive". See also : "option httpclose",, "option http-server-close", "option prefer-last-server", "option http-pretend-keepalive", @@ -6301,17 +6289,17 @@ no option http-server-close connections: for each connection it processes each request and response, and leaves the connection idle on both sides between the end of a response and the start of a new request. This mode may be changed by several options such - as "option http-server-close", "option httpclose" or "option http-tunnel". - Setting "option http-server-close" enables HTTP connection-close mode on the - server side while keeping the ability to support HTTP keep-alive and - pipelining on the client side. This provides the lowest latency on the client - side (slow network) and the fastest session reuse on the server side to save - server resources, similarly to "option httpclose". It also permits - non-keepalive capable servers to be served in keep-alive mode to the clients - if they conform to the requirements of RFC7230. Please note that some servers - do not always conform to those requirements when they see "Connection: close" - in the request. The effect will be that keep-alive will never be used. A - workaround consists in enabling "option http-pretend-keepalive". + as "option http-server-close" or "option httpclose". Setting "option + http-server-close" enables HTTP connection-close mode on the server side + while keeping the ability to support HTTP keep-alive and pipelining on the + client side. This provides the lowest latency on the client side (slow + network) and the fastest session reuse on the server side to save server + resources, similarly to "option httpclose". It also permits non-keepalive + capable servers to be served in keep-alive mode to the clients if they + conform to the requirements of RFC7230. Please note that some servers do not + always conform to those requirements when they see "Connection: close" in the + request. The effect will be that keep-alive will never be used. A workaround + consists in enabling "option http-pretend-keepalive". At the moment, logs will not indicate whether requests came from the same session or not. The accept date reported in the logs corresponds to the end @@ -6322,9 +6310,9 @@ no option http-server-close This option may be set both in a frontend and in a backend. It is enabled if at least one of the frontend or backend holding a connection has it enabled. - It disables and replaces any previous "option httpclose", "option http-tunnel" - or "option http-keep-alive". Please check section 4 ("Proxies") to see how - this option combines with others when frontend and backend options differ. + It disables and replaces any previous "option httpclose" or "option + http-keep-alive". Please check section 4 ("Proxies") to see how this option + combines with others when frontend and backend options differ. If this option has been enabled in a "defaults" section, it can be disabled in a specific instance by prepending the "no" keyword before it. @@ -6332,46 +6320,6 @@ no option http-server-close See also : "option httpclose", "option http-pretend-keepalive", "option http-keep-alive", and "1.1. The HTTP transaction model". - -option http-tunnel (deprecated) -no option http-tunnel (deprecated) - Disable or enable HTTP connection processing after first transaction. - May be used in sections : defaults | frontend | listen | backend - yes | yes | yes | no - Arguments : none - - Warning : Because it cannot work in HTTP/2, this option is deprecated and it - is only supported on legacy HTTP frontends. In HTX, it is ignored and a - warning is emitted during HAProxy startup. - - By default HAProxy operates in keep-alive mode with regards to persistent - connections: for each connection it processes each request and response, and - leaves the connection idle on both sides between the end of a response and - the start of a new request. This mode may be changed by several options such - as "option http-server-close", "option httpclose" or "option http-tunnel". - - Option "http-tunnel" disables any HTTP processing past the first request and - the first response. This is the mode which was used by default in versions - 1.0 to 1.5-dev21. It is the mode with the lowest processing overhead, which - is normally not needed anymore unless in very specific cases such as when - using an in-house protocol that looks like HTTP but is not compatible, or - just to log one request per client in order to reduce log size. Note that - everything which works at the HTTP level, including header parsing/addition, - cookie processing or content switching will only work for the first request - and will be ignored after the first response. - - This option may be set on frontend and listen sections. Using it on a backend - section will be ignored and a warning will be reported during the startup. It - is a frontend related option, so there is no real reason to set it on a - backend. - - If this option has been enabled in a "defaults" section, it can be disabled - in a specific instance by prepending the "no" keyword before it. - - See also : "option httpclose", "option http-server-close", - "option http-keep-alive", and "1.1. The HTTP transaction model". - - option http-use-proxy-header no option http-use-proxy-header Make use of non-standard Proxy-Connection header instead of Connection @@ -6402,40 +6350,6 @@ no option http-use-proxy-header See also : "option httpclose", and "option http-server-close". - -option http-use-htx -no option http-use-htx - Switch to the new HTX internal representation for HTTP protocol elements - May be used in sections : defaults | frontend | listen | backend - yes | yes | yes | yes - Arguments : none - - Historically, the HTTP protocol is processed as-is. Inserting, deleting, or - modifying a header field requires to rewrite the affected part in the buffer - and to move the buffer's tail accordingly. This mode is known as the legacy - HTTP mode. Since this principle has deep roots in haproxy, the HTTP/2 - protocol is converted to HTTP/1.1 before being processed this way. It also - results in the inability to establish HTTP/2 connections to servers because - of the loss of HTTP/2 semantics in the HTTP/1 representation. - - HTX is the name of a totally new native internal representation for the HTTP - protocol, that is agnostic to the version and aims at preserving semantics - all along the chain. It relies on a fast parsing, tokenizing and indexing of - the protocol elements so that no more memory moves are necessary and that - most elements are directly accessed. It supports using either HTTP/1 or - HTTP/2 on any side regardless of the other side's version. It also supports - upgrades from TCP to HTTP and implicit ones from HTTP/1 to HTTP/2 (matching - the HTTP/2 preface). - - This option indicates that HTX needs to be used. Since the version 2.0-dev3, - the HTX is the default mode. To switch back on the legacy HTTP mode, the - option must be explicitly disabled using the "no" prefix. For prior versions, - the feature has incomplete functional coverage, so it is not enabled by - default. - - See also : "mode http" - - option httpchk option httpchk option httpchk @@ -6496,7 +6410,7 @@ no option httpclose connections: for each connection it processes each request and response, and leaves the connection idle on both sides between the end of a response and the start of a new request. This mode may be changed by several options such - as "option http-server-close", "option httpclose" or "option http-tunnel". + as "option http-server-close" or "option httpclose". If "option httpclose" is set, HAProxy will close connections with the server and the client as soon as the request and the response are received. It will @@ -6510,10 +6424,9 @@ no option httpclose This option may be set both in a frontend and in a backend. It is enabled if at least one of the frontend or backend holding a connection has it enabled. - It disables and replaces any previous "option http-server-close", - "option http-keep-alive" or "option http-tunnel". Please check section 4 - ("Proxies") to see how this option combines with others when frontend and - backend options differ. + It disables and replaces any previous "option http-server-close" or "option + http-keep-alive". Please check section 4 ("Proxies") to see how this option + combines with others when frontend and backend options differ. If this option has been enabled in a "defaults" section, it can be disabled in a specific instance by prepending the "no" keyword before it. @@ -18212,12 +18125,6 @@ The cache won't store and won't deliver objects in these cases: - If the HTTP version of the request is smaller than 1.1 - If the request contains an Authorization header -Caution!: For HAProxy version prior to 1.9, due to the limitation of the -filters, it is not recommended to use the cache with other filters. Using them -can cause undefined behavior if they modify the response (compression for -example). For HAProxy 1.9 and greater, it is safe, for HTX proxies only (see -"option http-use-htx" for details). - 10.2. Setup -----------