diff --git a/doc/configuration.txt b/doc/configuration.txt
index 8678b80..805ab0c 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -2295,14 +2295,6 @@
     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 @@
             ----+-----+-----+----
             KAL | KAL | SCL | CLO
             ----+-----+-----+----
-            TUN | TUN | SCL | CLO
- Frontend   ----+-----+-----+----
    mode     SCL | SCL | SCL | CLO
             ----+-----+-----+----
             CLO | CLO | CLO | CLO
@@ -2414,9 +2404,7 @@
 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 @@
   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 @@
   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 @@
   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 @@
 
   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 @@
   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 @@
 
   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 <uri>
 option httpchk <method> <uri>
@@ -6496,7 +6410,7 @@
   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 @@
 
   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 @@
 - 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
 -----------