RepoMirrors/haproxy
1
0
Fork 0
mirror of http://git.haproxy.org/git/haproxy.git/ synced 2024-12-18 01:14:38 +00:00
Code Issues Packages Projects Releases Wiki Activity

DOC: config: Improve documentation of tune.http.maxhdr directive

Browse Source 
The description was inproved to clrealy mentionned it is applied on received
requests and responses. In addition, a comment was added about HTTP/2 and
HTTP/3 limitation when messages are encoded to be sent.
This commit is contained in:
Christopher Faulet 2024-11-20 18:02:35 +01:00
parent 3bd9a9e7d7
commit e863d8d681
1 changed files with 16 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
doc/configuration.txt
View File

@ -3787,15 +3787,22 @@ tune.http.logurilen <number>
The default value is 1024.
tune.http.maxhdr <number>
Sets the maximum number of headers in a request. When a request comes with a
number of headers greater than this value (including the first line), it is
rejected with a "400 Bad Request" status code. Similarly, too large responses
are blocked with "502 Bad Gateway". The default value is 101, which is enough
for all usages, considering that the widely deployed Apache server uses the
same limit. It can be useful to push this limit further to temporarily allow
a buggy application to work by the time it gets fixed. The accepted range is
1..32767. Keep in mind that each new header consumes 32bits of memory for
each stream, so don't push this limit too high.
Sets the maximum number of headers allowed in received HTTP messages. When a
message comes with a number of headers greater than this value (including the
first line), it is rejected with a "400 Bad Request" status code for a
request, or "502 Bad Gateway" for a response. The default value is 101, which
is enough for all usages, considering that the widely deployed Apache server
uses the same limit. It can be useful to push this limit further to
temporarily allow a buggy application to work by the time it gets fixed. The
accepted range is 1..32767. Keep in mind that each new header consumes 32bits
of memory for each stream, so don't push this limit too high.
Note that HTTP/1.1 is a text protocol, so there is no special limit when the
message is sent. The limit during the message parsing is sufficient. HTTP/2
and HTTP/3 are binary protocols and require an encoding step. A limit is set
too when headers are encoded to comply to limitation imposed by the
protocols. This limit is large enough but not documented on purpose. The same
limit is applied on the first steps of the decoding for the same reason.
tune.idle-pool.shared { on | off }
Enables ('on') or disables ('off') sharing of idle connection pools between