Hi,
I would like to validate a statement in "option accept-invalid-http-request"
section:
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20accept-invalid-http-request
By default, HAProxy complies with RFC2616 in terms of message parsing. This
means that invalid characters in header names are not permitted and cause an
error to be returned to the client. This is the desired behaviour as such
forbidden characters are essentially used to build attacks exploiting server
weaknesses, and bypass security filtering. Sometimes, a buggy browser or
server will emit invalid header names for whatever reason (configuration,
implementation) and the issue will not be immediately fixed. In such a case,
it is possible to relax HAProxy's header name parser to accept any character
even if that does not make sense, by specifying this option. Similarly, the
list of characters allowed to appear in a URI is well defined by RFC3986, and
chars 0-31, 32 (space), 34 ('"'), 60 ('<'), 62 ('>'), 92 ('\'), 94 ('^'), 96
('`'), 123 ('{'), 124 ('|'), 125 ('}'), 127 (delete) and anything above are
not allowed at all. Haproxy always blocks a number of them (0..32, 127). The
remaining ones are blocked by default unless this option is enabled.
What does it mean by "HAProxy always blocks a number of them (0..32, 127)."?
Does it mean HAProxy will not block the request with invalid char (0..32, 127)
in the header name all the time? Does HAProxy randomly block the bad request
with invalid char (0..32, 127) in the header name?
We have an application receiving "Bad Request 400" and the tcpdump shows an
invalid char %20 (space) in some of the header names.
However, application owner claimed sometimes these requests were not blocked by
HAProxy and went through without "Bad Request 400" error.
Please advise.
Thanks
Diana
