MEDIUM: http: unify acl and sample fetch functions
The following sample fetch functions were only usable by ACLs but are now
usable by sample fetches too :
cook, cook_cnt, cook_val, hdr_cnt, hdr_ip, hdr_val, http_auth,
http_auth_group, http_first_req, method, req_proto_http, req_ver,
resp_ver, scook, scook_cnt, scook_val, shdr, shdr_cnt, shdr_ip,
shdr_val, status, urlp, urlp_val,
Most of them won't bring much benefit at the moment, or are even aliases of
existing ones, however they'll be needed for ACL->SMP convergence.
A new val_usr() function was added to resolve userlist names into pointers.
The http_auth_group ACL forgot to make its first argument mandatory, so
there was a check in cfgparse to report a vague error. Now that args are
correctly parsed, let's report something more precise.
All urlp* ACLs now support an optional 3rd argument like their sample
counter-part which is the optional delimiter.
The fetch functions have been renamed "smp_fetch_*".
Some args controls on the sample keywords have been relaxed so that we
can soon use them for ACLs :
- cookie now accepts to have an optional name ; it will return the
first matching cookie if the name is not set ;
- same for set-cookie and hdr
diff --git a/doc/configuration.txt b/doc/configuration.txt
index aef2a2c..8183daa 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -9612,17 +9612,35 @@
queue size. This is only used with ACLs. See the ACL "connslots"
keyword description for more information on possible caveats.
- cookie(<name>)
+ cook([<name>])
+ This extracts the last occurrence of the cookie name <name> on a
+ "Cookie" header line from the request, and returns its value as
+ string. If no name is specified, the first cookie value is
+ returned.
+
+ cookie([<name>])
This extracts the last occurrence of the cookie name <name> on a
"Cookie" header line from the request, or a "Set-Cookie" header
- from the response, and uses the corresponding value to match. A
- typical use is to get multiple clients sharing a same profile
- use the same server. This can be similar to what "appsession"
- does with the "request-learn" statement, but with support for
- multi-peer synchronization and state keeping across restarts.
+ from the response, and returns its value as a string. A typical
+ use is to get multiple clients sharing a same profile use the
+ same server. This can be similar to what "appsession" does with
+ the "request-learn" statement, but with support for multi-peer
+ synchronization and state keeping across restarts. If no name is
+ specified, the first cookie value is returned.
See also : "appsession"
+ cook_cnt([<name>])
+ Returns an integer value representing the number of occurrences of
+ the cookie <name> in the request, or all cookies if <name> is not
+ specified.
+
+ cook_val([<name>])
+ This extracts the last occurrence of the cookie name <name> on a
+ "Cookie" header line from the request, and converts its value to
+ an integer which is returned. If no name is specified, the first
+ cookie value is returned.
+
dst This is the destination IPv4 address of the session on the
client side, which is the address the client connected to.
It can be useful when running in transparent mode. It is of
@@ -9673,6 +9691,49 @@
last one. A typical use is with the X-Forwarded-For header once
converted to IP, associated with an IP stick-table.
+ hdr_cnt([<name>])
+ Returns an integer value representing the number of occurrences
+ of request header field name <name>, or the total number of
+ header fields if <name> is not specified.
+
+ hdr_ip([<name>[,<occ>]])
+ This extracts the last occurrence of header <name> in an HTTP
+ request, converts it to an IPv4 or IPv6 address and returns this
+ address. Optionally, a specific occurrence might be specified as
+ a position number. Positive values indicate a position from the
+ first occurrence, with 1 being the first one. Negative values
+ indicate positions relative to the last one, with -1 being the
+ last one. A typical use is with the X-Forwarded-For header.
+
+ hdr_val([<name>[,<occ>]])
+ This extracts the last occurrence of header <name> in an HTTP
+ request, and converts it to an integer value. Optionally, a
+ specific occurrence might be specified as a position number.
+ Positive values indicate a position from the first occurrence,
+ with 1 being the first one. Negative values indicate positions
+ relative to the last one, with -1 being the last one. A typical
+ use is with the X-Forwarded-For header.
+
+ http_auth(<userlist>)
+ http_auth_group(<userlist>)
+ Returns a boolean indicating whether the authentication data
+ received from the client match a username & password stored in
+ the specified userlist. These fetch functions are not really
+ useful outside of ACLs.
+
+ http_first_req
+ Returns true when the request being processed is the first one
+ of the connection. This can be used to add or remove headers
+ that may be missing from some requests when a request is not the
+ first one, or to help grouping requests in the logs.
+
+ method
+ Returns an integer value corresponding to the to the method in
+ the HTTP request. For example, "GET" equals 1 (check sources to
+ establish the matching). Value 9 means "other method" and may be
+ converted to a string extracted from the stream. This should not
+ be used directly, this is only meant to be used from ACLs.
+
nbsrv([<backend>])
Returns an integer value corresponding to the number of usable
servers of either the current backend or the named backend. This
@@ -9758,6 +9819,13 @@
req_len Returns an integer value corresponding to the number of bytes
present in the request buffer. This is mostly used in ACL.
+ req_proto_http
+ Returns true when data in the request buffer look like HTTP and
+ correctly parses as such. It is the same parser as the common
+ HTTP request parser which is used so there should be no
+ surprises. This test may be used to report the protocol in TCP
+ logs.
+
req_ssl_hello_type
Returns an integer value containing the type of the SSL hello
message found in the request buffer. Note that this only applies
@@ -9781,6 +9849,29 @@
data layer, so this will not work with "bind" lines having the
"ssl" option. This is mostly used in ACL.
+ req_ver Returns the version string from the HTTP request, for example
+ "1.1". This can be useful for logs, but is mostly there for ACL.
+
+ resp_ver Returns the version string from the HTTP response, for example
+ "1.1". This can be useful for logs, but is mostly there for ACL.
+
+ scook([<name>])
+ This extracts the last occurrence of the cookie name <name> on a
+ "Set-Cookie" header line from the response, and returns its
+ value as string. If no name is specified, the first cookie value
+ is returned.
+
+ scook_cnt([<name>])
+ Returns an integer value representing the number of occurrences of
+ the cookie <name> in the response, or all cookies if <name> is not
+ specified.
+
+ scook_val([<name>])
+ This extracts the last occurrence of the cookie name <name> on a
+ "Set-Cookie" header line from the response, and converts its
+ value to an integer which is returned. If no name is specified,
+ the first cookie value is returned.
+
set-cookie(<name>)
This fetch function is deprecated and has been superseded by the
"cookie" fetch which is capable of handling both requests and
@@ -9794,6 +9885,39 @@
See also : "appsession"
+ shdr(<name>[,<occ>])
+ This extracts the last occurrence of header <name> in an HTTP
+ response. Optionally, a specific occurrence might be specified
+ as a position number. Positive values indicate a position from
+ the first occurrence, with 1 being the first one. Negative
+ values indicate positions relative to the last one, with -1
+ being the last one. This can be useful to learn some data into
+ a stick-table.
+
+ shdr_cnt([<name>])
+ Returns an integer value representing the number of occurrences
+ of response header field name <name>, or the total number of
+ header fields if <name> is not specified.
+
+ shdr_ip([<name>[,<occ>]])
+ This extracts the last occurrence of header <name> in an HTTP
+ response, convert it to an IPv4 or IPv6 address and returns this
+ address. Optionally, a specific occurrence might be specified as
+ a position number. Positive values indicate a position from the
+ first occurrence, with 1 being the first one. Negative values
+ indicate positions relative to the last one, with -1 being the
+ last one. This can be useful to learn some data into a stick
+ table.
+
+ shdr_val([<name>[,<occ>]])
+ This extracts the last occurrence of header <name> in an HTTP
+ response, and converts it to an integer value. Optionally, a
+ specific occurrence might be specified as a position number.
+ Positive values indicate a position from the first occurrence,
+ with 1 being the first one. Negative values indicate positions
+ relative to the last one, with -1 being the last one. This can
+ be useful to learn some data into a stick table.
+
so_id Returns an integer containing the listening socket's id.
src This is the source IPv4 address of the client of the session.
@@ -10006,11 +10130,27 @@
Returns the symmetric cipher key size used in bits when the
incoming connection was made over an SSL/TLS transport layer.
+ status Returns an integer containing the HTTP status code in the HTTP
+ response, for example, 302. It is mostly used within ACLs.
+
url This extracts the request's URL as presented in the request. A
typical use is with prefetch-capable caches, and with portals
which need to aggregate multiple information from databases and
keep them in caches. See also "path".
+ urlp(<name>[,<delim>])
+ Note: all "urlp*" sample fetch methods apply only to the first
+ occurrence of the parameter <name> in the query string, which
+ is delimited by character <delim> if specified, otherwise '&'.
+ The parameter name is case-sensitive. This one extracts a string
+ corresponding to the value of the parameter <name>. This can be
+ used for session stickiness.
+
+ urlp_val(<name>[,<delim>])
+ See "urlp" above. This one extracts the URL parameter <name> in
+ the request and converts it ao an integer value. This can be
+ used for session stickiness.
+
url_ip This extracts the IP address from the request's URL when the
host part is presented as an IP address. Its use is very
limited. For instance, a monitoring system might use this field