mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2024-12-16 16:34:42 +00:00
DOC: remove obsolete section about header manipulation
Cyril Bont reported that the doc contains two chapters number 6,
one of which is a leftover of the section about old header manipulation
directives that were removed by commit a6a56e6
("MEDIUM: config: Remove
parsing of req* and rsp* directives"). This patch removes this.
This commit is contained in:
parent
04400bc787
commit
1a753a2ead
@ -12361,107 +12361,6 @@ timeout <event> <time>
|
|||||||
hold obsolete 30s
|
hold obsolete 30s
|
||||||
|
|
||||||
|
|
||||||
6. HTTP header manipulation
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
In HTTP mode, it is possible to rewrite, add or delete some of the request and
|
|
||||||
response headers based on regular expressions. It is also possible to block a
|
|
||||||
request or a response if a particular header matches a regular expression,
|
|
||||||
which is enough to stop most elementary protocol attacks, and to protect
|
|
||||||
against information leak from the internal network.
|
|
||||||
|
|
||||||
If HAProxy encounters an "Informational Response" (status code 1xx), it is able
|
|
||||||
to process all rsp* rules which can allow, deny, rewrite or delete a header,
|
|
||||||
but it will refuse to add a header to any such messages as this is not
|
|
||||||
HTTP-compliant. The reason for still processing headers in such responses is to
|
|
||||||
stop and/or fix any possible information leak which may happen, for instance
|
|
||||||
because another downstream equipment would unconditionally add a header, or if
|
|
||||||
a server name appears there. When such messages are seen, normal processing
|
|
||||||
still occurs on the next non-informational messages.
|
|
||||||
|
|
||||||
This section covers common usage of the following keywords, described in detail
|
|
||||||
in section 4.2 :
|
|
||||||
|
|
||||||
- reqadd <string>
|
|
||||||
- reqallow <search>
|
|
||||||
- reqiallow <search>
|
|
||||||
- reqdel <search>
|
|
||||||
- reqidel <search>
|
|
||||||
- reqdeny <search>
|
|
||||||
- reqideny <search>
|
|
||||||
- reqpass <search>
|
|
||||||
- reqipass <search>
|
|
||||||
- reqrep <search> <replace>
|
|
||||||
- reqirep <search> <replace>
|
|
||||||
- reqtarpit <search>
|
|
||||||
- reqitarpit <search>
|
|
||||||
- rspadd <string>
|
|
||||||
- rspdel <search>
|
|
||||||
- rspidel <search>
|
|
||||||
- rspdeny <search>
|
|
||||||
- rspideny <search>
|
|
||||||
- rsprep <search> <replace>
|
|
||||||
- rspirep <search> <replace>
|
|
||||||
|
|
||||||
With all these keywords, the same conventions are used. The <search> parameter
|
|
||||||
is a POSIX extended regular expression (regex) which supports grouping through
|
|
||||||
parenthesis (without the backslash). Spaces and other delimiters must be
|
|
||||||
prefixed with a backslash ('\') to avoid confusion with a field delimiter.
|
|
||||||
Other characters may be prefixed with a backslash to change their meaning :
|
|
||||||
|
|
||||||
\t for a tab
|
|
||||||
\r for a carriage return (CR)
|
|
||||||
\n for a new line (LF)
|
|
||||||
\ to mark a space and differentiate it from a delimiter
|
|
||||||
\# to mark a sharp and differentiate it from a comment
|
|
||||||
\\ to use a backslash in a regex
|
|
||||||
\\\\ to use a backslash in the text (*2 for regex, *2 for haproxy)
|
|
||||||
\xXX to write the ASCII hex code XX as in the C language
|
|
||||||
|
|
||||||
The <replace> parameter contains the string to be used to replace the largest
|
|
||||||
portion of text matching the regex. It can make use of the special characters
|
|
||||||
above, and can reference a substring which is delimited by parenthesis in the
|
|
||||||
regex, by writing a backslash ('\') immediately followed by one digit from 0 to
|
|
||||||
9 indicating the group position (0 designating the entire line). This practice
|
|
||||||
is very common to users of the "sed" program.
|
|
||||||
|
|
||||||
The <string> parameter represents the string which will systematically be added
|
|
||||||
after the last header line. It can also use special character sequences above.
|
|
||||||
|
|
||||||
Notes related to these keywords :
|
|
||||||
---------------------------------
|
|
||||||
- these keywords are not always convenient to allow/deny based on header
|
|
||||||
contents. It is strongly recommended to use ACLs with the "block" keyword
|
|
||||||
instead, resulting in far more flexible and manageable rules.
|
|
||||||
|
|
||||||
- lines are always considered as a whole. It is not possible to reference
|
|
||||||
a header name only or a value only. This is important because of the way
|
|
||||||
headers are written (notably the number of spaces after the colon).
|
|
||||||
|
|
||||||
- the first line is always considered as a header, which makes it possible to
|
|
||||||
rewrite or filter HTTP requests URIs or response codes, but in turn makes
|
|
||||||
it harder to distinguish between headers and request line. The regex prefix
|
|
||||||
^[^\ \t]*[\ \t] matches any HTTP method followed by a space, and the prefix
|
|
||||||
^[^ \t:]*: matches any header name followed by a colon.
|
|
||||||
|
|
||||||
- for performances reasons, the number of characters added to a request or to
|
|
||||||
a response is limited at build time to values between 1 and 4 kB. This
|
|
||||||
should normally be far more than enough for most usages. If it is too short
|
|
||||||
on occasional usages, it is possible to gain some space by removing some
|
|
||||||
useless headers before adding new ones.
|
|
||||||
|
|
||||||
- keywords beginning with "reqi" and "rspi" are the same as their counterpart
|
|
||||||
without the 'i' letter except that they ignore case when matching patterns.
|
|
||||||
|
|
||||||
- when a request passes through a frontend then a backend, all req* rules
|
|
||||||
from the frontend will be evaluated, then all req* rules from the backend
|
|
||||||
will be evaluated. The reverse path is applied to responses.
|
|
||||||
|
|
||||||
- req* statements are applied after "block" statements, so that "block" is
|
|
||||||
always the first one, but before "use_backend" in order to permit rewriting
|
|
||||||
before switching.
|
|
||||||
|
|
||||||
|
|
||||||
6. Cache
|
6. Cache
|
||||||
---------
|
---------
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user