DOC: clarify the handling of URL fragments in requests
authorWilly Tarreau <w@1wt.eu>
Tue, 8 Aug 2023 17:35:25 +0000 (19:35 +0200)
committerVincent Bernat <bernat@debian.org>
Fri, 3 Oct 2025 06:03:00 +0000 (08:03 +0200)
Origin: https://git.haproxy.org/?p=haproxy-2.6.git;a=commit;h=c47814a58ec153a526e8e9e822cda6e66cef5cc2

We indicate in path/pathq/url that they may contain '#' if the frontend
is configured with "option accept-invalid-http-request", and that option
mentions the fragment as well.

(cherry picked from commit 7ab4949ef107a7088777f954de800fe8cf727796)
 [ad: backported as a companion to BUG/MINOR: h1: do not accept '#' as
  part of the URI component]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 965fb74eb180ab4f275ef907e018128e7eee0e69)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit e9903d6073ce9ff0ed8b304700e9d2b435ed8050)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
Gbp-Pq: Name DOC-clarify-the-handling-of-URL-fragments-in-request.patch

doc/configuration.txt

index be81b9a4fb79bb6dde3c92104fd815a93342fc0e..215d4f7a9b37a79bcb4950852f30185bc82feeb6 100644 (file)
@@ -8527,6 +8527,8 @@ no option accept-invalid-http-request
   option also relaxes the test on the HTTP version, it allows HTTP/0.9 requests
   to pass through (no version specified), as well as different protocol names
   (e.g. RTSP), and multiple digits for both the major and the minor version.
+  Finally, this option also allows incoming URLs to contain fragment references
+  ('#' after the path).
 
   This option should never be enabled by default as it hides application bugs
   and open security breaches. It should only be deployed after a problem has
@@ -20902,7 +20904,11 @@ path : string
   information from databases and keep them in caches. Note that with outgoing
   caches, it would be wiser to use "url" instead. With ACLs, it's typically
   used to match exact file names (e.g. "/login.php"), or directory parts using
-  the derivative forms. See also the "url" and "base" fetch methods.
+  the derivative forms. See also the "url" and "base" fetch methods. Please
+  note that any fragment reference in the URI ('#' after the path) is strictly
+  forbidden by the HTTP standard and will be rejected. However, if the frontend
+  receiving the request has "option accept-invalid-http-request", then this
+  fragment part will be accepted and will also appear in the path.
 
   ACL derivatives :
     path     : exact string match
@@ -20920,7 +20926,11 @@ pathq : string
   relative URI, excluding the scheme and the authority part, if any. Indeed,
   while it is the common representation for an HTTP/1.1 request target, in
   HTTP/2, an absolute URI is often used. This sample fetch will return the same
-  result in both cases.
+  result in both cases. Please note that any fragment reference in the URI ('#'
+  after the path) is strictly forbidden by the HTTP standard and will be
+  rejected. However, if the frontend receiving the request has "option
+  accept-invalid-http-request", then this fragment part will be accepted and
+  will also appear in the path.
 
 query : string
   This extracts the request's query string, which starts after the first
@@ -21153,7 +21163,11 @@ url : string
   "path" is preferred over using "url", because clients may send a full URL as
   is normally done with proxies. The only real use is to match "*" which does
   not match in "path", and for which there is already a predefined ACL. See
-  also "path" and "base".
+  also "path" and "base". Please note that any fragment reference in the URI
+  ('#' after the path) is strictly forbidden by the HTTP standard and will be
+  rejected. However, if the frontend receiving the request has "option
+  accept-invalid-http-request", then this fragment part will be accepted and
+  will also appear in the url.
 
   ACL derivatives :
     url     : exact string match