2010-01-04 10:16:05 -05:00
|
|
|
/*
|
2020-06-04 09:33:47 -04:00
|
|
|
* include/haproxy/sample-t.h
|
2012-04-27 15:52:18 -04:00
|
|
|
* Macros, variables and structures for sample management.
|
2010-01-04 10:16:05 -05:00
|
|
|
*
|
|
|
|
|
* Copyright (C) 2009-2010 EXCELIANCE, Emeric Brun <ebrun@exceliance.fr>
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
* Copyright (C) 2012-2013 Willy Tarreau <w@1wt.eu>
|
2010-01-04 10:16:05 -05:00
|
|
|
*
|
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
* License as published by the Free Software Foundation, version 2.1
|
|
|
|
|
* exclusively.
|
|
|
|
|
*
|
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
* License along with this library; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
|
*/
|
|
|
|
|
|
2020-06-04 09:33:47 -04:00
|
|
|
#ifndef _HAPROXY_SAMPLE_T_H
|
|
|
|
|
#define _HAPROXY_SAMPLE_T_H
|
2010-01-04 10:16:05 -05:00
|
|
|
|
2020-06-05 10:54:16 -04:00
|
|
|
#include <haproxy/api-t.h>
|
|
|
|
|
#include <haproxy/sample_data-t.h>
|
2010-01-04 10:16:05 -05:00
|
|
|
|
2023-06-06 13:03:45 -04:00
|
|
|
/* input and output sample types
|
|
|
|
|
*
|
|
|
|
|
* Some of them are pseudo types which means that they can be used for
|
|
|
|
|
* in_type and out_type in sample (fetches/conv) definitions (they serve as
|
|
|
|
|
* compatibility and conversion hints) but they cannot be emitted at runtime.
|
|
|
|
|
*/
|
2010-01-04 10:16:05 -05:00
|
|
|
enum {
|
2023-06-06 13:03:45 -04:00
|
|
|
SMP_T_ANY = 0, /* pseudo type: any type */
|
MEDIUM: sample: introduce 'same' output type
Thierry Fournier reported an annoying side-effect when using the debug()
converter.
Consider the following examples:
[1] http-request set-var(txn.test) bool(true),ipmask(24)
[2] http-request redirect location /match if { bool(true),ipmask(32) }
When starting haproxy with [1] example we get:
config : parsing [test.conf:XX] : error detected in frontend 'fe' while parsing 'http-request set-var(txn.test)' rule : converter 'ipmask' cannot be applied.
With [2], we get:
config : parsing [test.conf:XX] : error detected in frontend 'fe' while parsing 'http-request redirect' rule : error in condition: converter 'ipmask' cannot be applied in ACL expression 'bool(true),ipmask(32)'.
Now consider the following examples which are based on [1] and [2]
but with the debug() sample conv inserted in-between those incompatible
sample types:
[1*] http-request set-var(txn.test) bool(true),debug,ipmask(24)
[2*] http-request redirect location /match if { bool(true),debug,ipmask(32) }
According to the documentation, "it is safe to insert the debug converter
anywhere in a chain, even with non-printable sample types".
Thus we don't expect any side-effect from using it within a chain.
However in current implementation, because of debug() returning SMP_T_ANY
type which is a pseudo type (only resolved at runtime), the sample
compatibility checks performed at parsing time are completely uneffective.
(haproxy will start and no warning will be emitted)
The indesirable effect of this is that debug() prevents haproxy from
warning you about impossible type conversions, hiding potential errors
in the configuration that could result to unexpected evaluation or logic
while serving live traffic. We better let haproxy warn you about this kind
of errors when it has the chance.
With our previous examples, this could cause some inconveniences. Let's
say for example that you are testing a configuration prior to deploying
it. When testing the config you might want to use debug() converter from
time to time to check how the conversion chain behaves.
Now after deploying the exact same conf, you might want to remove those
testing debug() statements since they are no longer relevant.. but
removing them could "break" the config and suddenly prevent haproxy from
starting upon reload/restart. (this is the expected behavior, but it
comes a bit too late because of debug() hiding errors during tests..)
To fix this, we introduce a new output type for sample expressions:
SMP_T_SAME - may only be used as "expected" out_type (parsing time)
for sample converters.
As it name implies, it is a way for the developpers to indicate that the
resulting converter's output type is guaranteed to match the type of the
sample that is presented on the converter's input side.
(converter may alter data content, but data type must not be changed)
What it does is that it tells haproxy that if switching to the converter
(by looking at the converter's input only, since outype is SAME) is
conversion-free, then the converter type can safely be ignored for type
compatibility checks within the chain.
debug()'s out_type is thus set to SMP_T_SAME instead of ANY, which allows
it to fully comply with the doc in the sense that it does not impact the
conversion chain when inserted between sample items.
Co-authored-by: Thierry Fournier <thierry.f.78@gmail.com>
2023-05-30 10:34:39 -04:00
|
|
|
SMP_T_SAME, /* special: output type hint for converters that don't alter input type (out == in) */
|
2015-06-03 14:12:35 -04:00
|
|
|
SMP_T_BOOL, /* boolean */
|
2015-07-06 17:43:03 -04:00
|
|
|
SMP_T_SINT, /* signed 64bits integer type */
|
MEDIUM: sample: add missing ADDR=>? compatibility matrix entries
SMP_T_ADDR support was added in b805f71 ("MEDIUM: sample: let the cast
functions set their output type").
According to the above commit, it is made clear that the ADDR type is
a pseudo/generic type that may be used for compatibility checks but
that cannot be emitted from a fetch or converter.
With that in mind, all conversions from ADDR to other types were
explicitly disabled in the compatibility matrix.
But later, when map_*_ip functions were updated in b2f8f08 ("MINOR: map:
The map can return IPv4 and IPv6"), we started using ADDR as "expected"
output type for converters. This still complies with the original
description from b805f71, because it is used as the theoric output
type, and is never emitted from the converters themselves (only "real"
types such as IPV4 or IPV6 are actually being emitted at runtime).
But this introduced an ambiguity as well as a few bugs, because some
compatibility checks are being performed at config parse time, and thus
rely on the expected output type to check if the conversion from current
element to the next element in the chain is theorically supported.
However, because the compatibility matrix doesn't support ADDR to other
types it is currently impossible to use map_*_ip converters in the middle
of a chain (the only supported usage is when map_*_ip converters are
at the very end of the chain).
To illustrate this, consider the following examples:
acl test str(ok),map_str_ip(test.map) -m found # this will work
acl test str(ok),map_str_ip(test.map),ipmask(24) -m found # this will raise an error
Likewise, stktable_compatible_sample() check for stick tables also relies
on out_type[table_type] compatibility check, so map_*_ip cannot be used
with sticktables at the moment:
backend st_test
stick-table type string size 1m expire 10m store http_req_rate(10m)
frontend fe
bind localhost:8080
mode http
http-request track-sc0 str(test),map_str_ip(test.map) table st_test # raises an error
To fix this, and prevent future usage of ADDR as expected output type
(for either fetches or converters) from introducing new bugs, the
ADDR=>? part of the matrix should follow the ANY type logic.
That is, ADDR, which is a pseudo-type, must be compatible with itself,
and where IPV4 and IPV6 both support a backward conversion to a given
type, ADDR must support it as well. It is done by setting the relevant
ADDR entries to c_pseudo() in the compatibility matrix to indicate that
the operation is theorically supported (c_pseudo() will never be executed
because ADDR should not be emitted: this only serves as a hint for
compatibility checks at parse time).
This is what's being done in this commit, thanks to this the broken
examples documented above should work as expected now, and future
usage of ADDR as out_type should not cause any issue.
2023-06-06 09:58:49 -04:00
|
|
|
SMP_T_ADDR, /* pseudo type: could be ipv4 or ipv6 */
|
2012-04-20 14:49:27 -04:00
|
|
|
SMP_T_IPV4, /* ipv4 type */
|
|
|
|
|
SMP_T_IPV6, /* ipv6 type */
|
|
|
|
|
SMP_T_STR, /* char string type */
|
|
|
|
|
SMP_T_BIN, /* buffer type */
|
2013-12-16 19:10:10 -05:00
|
|
|
SMP_T_METH, /* contain method */
|
2012-04-20 14:49:27 -04:00
|
|
|
SMP_TYPES /* number of types, must always be last */
|
2010-01-04 10:16:05 -05:00
|
|
|
};
|
|
|
|
|
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
/* Sample sources are used to establish a relation between fetch keywords and
|
|
|
|
|
* the location where they're about to be used. They're reserved for internal
|
|
|
|
|
* use and are not meant to be known outside the sample management code.
|
2012-04-25 04:13:36 -04:00
|
|
|
*/
|
|
|
|
|
enum {
|
2021-03-26 06:56:11 -04:00
|
|
|
SMP_SRC_CONST, /* constat elements known at configuration time */
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
SMP_SRC_INTRN, /* internal context-less information */
|
|
|
|
|
SMP_SRC_LISTN, /* listener which accepted the connection */
|
|
|
|
|
SMP_SRC_FTEND, /* frontend which accepted the connection */
|
|
|
|
|
SMP_SRC_L4CLI, /* L4 information about the client */
|
|
|
|
|
SMP_SRC_L5CLI, /* fetch uses client information from embryonic session */
|
|
|
|
|
SMP_SRC_TRACK, /* fetch involves track counters */
|
|
|
|
|
SMP_SRC_L6REQ, /* fetch uses raw information from the request buffer */
|
|
|
|
|
SMP_SRC_HRQHV, /* fetch uses volatile information about HTTP request headers (eg: value) */
|
|
|
|
|
SMP_SRC_HRQHP, /* fetch uses persistent information about HTTP request headers (eg: meth) */
|
|
|
|
|
SMP_SRC_HRQBO, /* fetch uses information about HTTP request body */
|
|
|
|
|
SMP_SRC_BKEND, /* fetch uses information about the backend */
|
|
|
|
|
SMP_SRC_SERVR, /* fetch uses information about the selected server */
|
|
|
|
|
SMP_SRC_L4SRV, /* fetch uses information about the server L4 connection */
|
|
|
|
|
SMP_SRC_L5SRV, /* fetch uses information about the server L5 connection */
|
|
|
|
|
SMP_SRC_L6RES, /* fetch uses raw information from the response buffer */
|
|
|
|
|
SMP_SRC_HRSHV, /* fetch uses volatile information about HTTP response headers (eg: value) */
|
|
|
|
|
SMP_SRC_HRSHP, /* fetch uses persistent information about HTTP response headers (eg: status) */
|
|
|
|
|
SMP_SRC_HRSBO, /* fetch uses information about HTTP response body */
|
|
|
|
|
SMP_SRC_RQFIN, /* final information about request buffer (eg: tot bytes) */
|
|
|
|
|
SMP_SRC_RSFIN, /* final information about response buffer (eg: tot bytes) */
|
|
|
|
|
SMP_SRC_TXFIN, /* final information about the transaction (eg: #comp rate) */
|
REORG/MAJOR: session: rename the "session" entity to "stream"
With HTTP/2, we'll have to support multiplexed streams. A stream is in
fact the largest part of what we currently call a session, it has buffers,
logs, etc.
In order to catch any error, this commit removes any reference to the
struct session and tries to rename most "session" occurrences in function
names to "stream" and "sess" to "strm" when that's related to a session.
The files stream.{c,h} were added and session.{c,h} removed.
The session will be reintroduced later and a few parts of the stream
will progressively be moved overthere. It will more or less contain
only what we need in an embryonic session.
Sample fetch functions and converters will have to change a bit so
that they'll use an L5 (session) instead of what's currently called
"L4" which is in fact L6 for now.
Once all changes are completed, we should see approximately this :
L7 - http_txn
L6 - stream
L5 - session
L4 - connection | applet
There will be at most one http_txn per stream, and a same session will
possibly be referenced by multiple streams. A connection will point to
a session and to a stream. The session will hold all the information
we need to keep even when we don't yet have a stream.
Some more cleanup is needed because some code was already far from
being clean. The server queue management still refers to sessions at
many places while comments talk about connections. This will have to
be cleaned up once we have a server-side connection pool manager.
Stream flags "SN_*" still need to be renamed, it doesn't seem like
any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
|
|
|
SMP_SRC_SSFIN, /* final information about the stream (eg: #requests, final flags) */
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
SMP_SRC_ENTRIES /* nothing after this */
|
2012-04-25 04:13:36 -04:00
|
|
|
};
|
|
|
|
|
|
2013-03-25 09:52:41 -04:00
|
|
|
/* Sample checkpoints are a list of places where samples may be used. This is
|
|
|
|
|
* an internal enum used only to build SMP_VAL_*.
|
|
|
|
|
*/
|
|
|
|
|
enum {
|
|
|
|
|
SMP_CKP_FE_CON_ACC, /* FE connection accept rules ("tcp request connection") */
|
REORG/MAJOR: session: rename the "session" entity to "stream"
With HTTP/2, we'll have to support multiplexed streams. A stream is in
fact the largest part of what we currently call a session, it has buffers,
logs, etc.
In order to catch any error, this commit removes any reference to the
struct session and tries to rename most "session" occurrences in function
names to "stream" and "sess" to "strm" when that's related to a session.
The files stream.{c,h} were added and session.{c,h} removed.
The session will be reintroduced later and a few parts of the stream
will progressively be moved overthere. It will more or less contain
only what we need in an embryonic session.
Sample fetch functions and converters will have to change a bit so
that they'll use an L5 (session) instead of what's currently called
"L4" which is in fact L6 for now.
Once all changes are completed, we should see approximately this :
L7 - http_txn
L6 - stream
L5 - session
L4 - connection | applet
There will be at most one http_txn per stream, and a same session will
possibly be referenced by multiple streams. A connection will point to
a session and to a stream. The session will hold all the information
we need to keep even when we don't yet have a stream.
Some more cleanup is needed because some code was already far from
being clean. The server queue management still refers to sessions at
many places while comments talk about connections. This will have to
be cleaned up once we have a server-side connection pool manager.
Stream flags "SN_*" still need to be renamed, it doesn't seem like
any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
|
|
|
SMP_CKP_FE_SES_ACC, /* FE stream accept rules (to come soon) */
|
2013-03-25 09:52:41 -04:00
|
|
|
SMP_CKP_FE_REQ_CNT, /* FE request content rules ("tcp request content") */
|
|
|
|
|
SMP_CKP_FE_HRQ_HDR, /* FE HTTP request headers (rules, headers, monitor, stats, redirect) */
|
|
|
|
|
SMP_CKP_FE_HRQ_BDY, /* FE HTTP request body */
|
|
|
|
|
SMP_CKP_FE_SET_BCK, /* FE backend switching rules ("use_backend") */
|
|
|
|
|
SMP_CKP_BE_REQ_CNT, /* BE request content rules ("tcp request content") */
|
|
|
|
|
SMP_CKP_BE_HRQ_HDR, /* BE HTTP request headers (rules, headers, monitor, stats, redirect) */
|
|
|
|
|
SMP_CKP_BE_HRQ_BDY, /* BE HTTP request body */
|
|
|
|
|
SMP_CKP_BE_SET_SRV, /* BE server switching rules ("use_server", "balance", "force-persist", "stick", ...) */
|
|
|
|
|
SMP_CKP_BE_SRV_CON, /* BE server connect (eg: "source") */
|
|
|
|
|
SMP_CKP_BE_RES_CNT, /* BE response content rules ("tcp response content") */
|
|
|
|
|
SMP_CKP_BE_HRS_HDR, /* BE HTTP response headers (rules, headers) */
|
|
|
|
|
SMP_CKP_BE_HRS_BDY, /* BE HTTP response body (stick-store rules are there) */
|
|
|
|
|
SMP_CKP_BE_STO_RUL, /* BE stick-store rules */
|
|
|
|
|
SMP_CKP_FE_RES_CNT, /* FE response content rules ("tcp response content") */
|
|
|
|
|
SMP_CKP_FE_HRS_HDR, /* FE HTTP response headers (rules, headers) */
|
|
|
|
|
SMP_CKP_FE_HRS_BDY, /* FE HTTP response body */
|
REORG/MAJOR: session: rename the "session" entity to "stream"
With HTTP/2, we'll have to support multiplexed streams. A stream is in
fact the largest part of what we currently call a session, it has buffers,
logs, etc.
In order to catch any error, this commit removes any reference to the
struct session and tries to rename most "session" occurrences in function
names to "stream" and "sess" to "strm" when that's related to a session.
The files stream.{c,h} were added and session.{c,h} removed.
The session will be reintroduced later and a few parts of the stream
will progressively be moved overthere. It will more or less contain
only what we need in an embryonic session.
Sample fetch functions and converters will have to change a bit so
that they'll use an L5 (session) instead of what's currently called
"L4" which is in fact L6 for now.
Once all changes are completed, we should see approximately this :
L7 - http_txn
L6 - stream
L5 - session
L4 - connection | applet
There will be at most one http_txn per stream, and a same session will
possibly be referenced by multiple streams. A connection will point to
a session and to a stream. The session will hold all the information
we need to keep even when we don't yet have a stream.
Some more cleanup is needed because some code was already far from
being clean. The server queue management still refers to sessions at
many places while comments talk about connections. This will have to
be cleaned up once we have a server-side connection pool manager.
Stream flags "SN_*" still need to be renamed, it doesn't seem like
any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
|
|
|
SMP_CKP_FE_LOG_END, /* FE log at the end of the txn/stream */
|
2020-02-21 12:14:59 -05:00
|
|
|
SMP_CKP_BE_CHK_RUL, /* BE tcp-check rules */
|
2021-03-26 06:09:38 -04:00
|
|
|
SMP_CKP_CFG_PARSER, /* config parser (i.e. before boot) */
|
2021-03-26 10:29:35 -04:00
|
|
|
SMP_CKP_CLI_PARSER, /* command line parser */
|
2013-03-25 09:52:41 -04:00
|
|
|
SMP_CKP_ENTRIES /* nothing after this */
|
|
|
|
|
};
|
|
|
|
|
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
/* SMP_USE_* are flags used to declare fetch keywords. Fetch methods are
|
|
|
|
|
* associated with bitfields composed of these values, generally only one, to
|
|
|
|
|
* indicate where the contents may be sampled. Some fetches are ambiguous as
|
|
|
|
|
* they apply to either the request or the response depending on the context,
|
|
|
|
|
* so they will have 2 of these bits (eg: hdr(), payload(), ...). These are
|
|
|
|
|
* stored in smp->use.
|
|
|
|
|
*/
|
|
|
|
|
enum {
|
2021-03-26 06:56:11 -04:00
|
|
|
SMP_USE_CONST = 1 << SMP_SRC_CONST, /* constant values known at config time */
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
SMP_USE_INTRN = 1 << SMP_SRC_INTRN, /* internal context-less information */
|
|
|
|
|
SMP_USE_LISTN = 1 << SMP_SRC_LISTN, /* listener which accepted the connection */
|
|
|
|
|
SMP_USE_FTEND = 1 << SMP_SRC_FTEND, /* frontend which accepted the connection */
|
|
|
|
|
SMP_USE_L4CLI = 1 << SMP_SRC_L4CLI, /* L4 information about the client */
|
|
|
|
|
SMP_USE_L5CLI = 1 << SMP_SRC_L5CLI, /* fetch uses client information from embryonic session */
|
|
|
|
|
SMP_USE_TRACK = 1 << SMP_SRC_TRACK, /* fetch involves track counters */
|
|
|
|
|
SMP_USE_L6REQ = 1 << SMP_SRC_L6REQ, /* fetch uses raw information from the request buffer */
|
|
|
|
|
SMP_USE_HRQHV = 1 << SMP_SRC_HRQHV, /* fetch uses volatile information about HTTP request headers (eg: value) */
|
|
|
|
|
SMP_USE_HRQHP = 1 << SMP_SRC_HRQHP, /* fetch uses persistent information about HTTP request headers (eg: meth) */
|
|
|
|
|
SMP_USE_HRQBO = 1 << SMP_SRC_HRQBO, /* fetch uses information about HTTP request body */
|
|
|
|
|
SMP_USE_BKEND = 1 << SMP_SRC_BKEND, /* fetch uses information about the backend */
|
|
|
|
|
SMP_USE_SERVR = 1 << SMP_SRC_SERVR, /* fetch uses information about the selected server */
|
|
|
|
|
SMP_USE_L4SRV = 1 << SMP_SRC_L4SRV, /* fetch uses information about the server L4 connection */
|
|
|
|
|
SMP_USE_L5SRV = 1 << SMP_SRC_L5SRV, /* fetch uses information about the server L5 connection */
|
|
|
|
|
SMP_USE_L6RES = 1 << SMP_SRC_L6RES, /* fetch uses raw information from the response buffer */
|
|
|
|
|
SMP_USE_HRSHV = 1 << SMP_SRC_HRSHV, /* fetch uses volatile information about HTTP response headers (eg: value) */
|
|
|
|
|
SMP_USE_HRSHP = 1 << SMP_SRC_HRSHP, /* fetch uses persistent information about HTTP response headers (eg: status) */
|
|
|
|
|
SMP_USE_HRSBO = 1 << SMP_SRC_HRSBO, /* fetch uses information about HTTP response body */
|
|
|
|
|
SMP_USE_RQFIN = 1 << SMP_SRC_RQFIN, /* final information about request buffer (eg: tot bytes) */
|
|
|
|
|
SMP_USE_RSFIN = 1 << SMP_SRC_RSFIN, /* final information about response buffer (eg: tot bytes) */
|
|
|
|
|
SMP_USE_TXFIN = 1 << SMP_SRC_TXFIN, /* final information about the transaction (eg: #comp rate) */
|
REORG/MAJOR: session: rename the "session" entity to "stream"
With HTTP/2, we'll have to support multiplexed streams. A stream is in
fact the largest part of what we currently call a session, it has buffers,
logs, etc.
In order to catch any error, this commit removes any reference to the
struct session and tries to rename most "session" occurrences in function
names to "stream" and "sess" to "strm" when that's related to a session.
The files stream.{c,h} were added and session.{c,h} removed.
The session will be reintroduced later and a few parts of the stream
will progressively be moved overthere. It will more or less contain
only what we need in an embryonic session.
Sample fetch functions and converters will have to change a bit so
that they'll use an L5 (session) instead of what's currently called
"L4" which is in fact L6 for now.
Once all changes are completed, we should see approximately this :
L7 - http_txn
L6 - stream
L5 - session
L4 - connection | applet
There will be at most one http_txn per stream, and a same session will
possibly be referenced by multiple streams. A connection will point to
a session and to a stream. The session will hold all the information
we need to keep even when we don't yet have a stream.
Some more cleanup is needed because some code was already far from
being clean. The server queue management still refers to sessions at
many places while comments talk about connections. This will have to
be cleaned up once we have a server-side connection pool manager.
Stream flags "SN_*" still need to be renamed, it doesn't seem like
any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
|
|
|
SMP_USE_SSFIN = 1 << SMP_SRC_SSFIN, /* final information about the stream (eg: #requests, final flags) */
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
|
2019-07-16 08:16:10 -04:00
|
|
|
/* This composite one is useful to detect if an http_txn needs to be allocated */
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
SMP_USE_HTTP_ANY = SMP_USE_HRQHV | SMP_USE_HRQHP | SMP_USE_HRQBO |
|
|
|
|
|
SMP_USE_HRSHV | SMP_USE_HRSHP | SMP_USE_HRSBO,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Sample validity is computed from the fetch sources above when keywords
|
|
|
|
|
* are registered. Each fetch method may be used at different locations. The
|
|
|
|
|
* configuration parser will check whether the fetches are compatible with the
|
|
|
|
|
* location where they're used. These are stored in smp->val.
|
|
|
|
|
*/
|
|
|
|
|
enum {
|
|
|
|
|
SMP_VAL___________ = 0, /* Just used as a visual marker */
|
2013-03-25 09:52:41 -04:00
|
|
|
SMP_VAL_FE_CON_ACC = 1 << SMP_CKP_FE_CON_ACC, /* FE connection accept rules ("tcp request connection") */
|
REORG/MAJOR: session: rename the "session" entity to "stream"
With HTTP/2, we'll have to support multiplexed streams. A stream is in
fact the largest part of what we currently call a session, it has buffers,
logs, etc.
In order to catch any error, this commit removes any reference to the
struct session and tries to rename most "session" occurrences in function
names to "stream" and "sess" to "strm" when that's related to a session.
The files stream.{c,h} were added and session.{c,h} removed.
The session will be reintroduced later and a few parts of the stream
will progressively be moved overthere. It will more or less contain
only what we need in an embryonic session.
Sample fetch functions and converters will have to change a bit so
that they'll use an L5 (session) instead of what's currently called
"L4" which is in fact L6 for now.
Once all changes are completed, we should see approximately this :
L7 - http_txn
L6 - stream
L5 - session
L4 - connection | applet
There will be at most one http_txn per stream, and a same session will
possibly be referenced by multiple streams. A connection will point to
a session and to a stream. The session will hold all the information
we need to keep even when we don't yet have a stream.
Some more cleanup is needed because some code was already far from
being clean. The server queue management still refers to sessions at
many places while comments talk about connections. This will have to
be cleaned up once we have a server-side connection pool manager.
Stream flags "SN_*" still need to be renamed, it doesn't seem like
any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
|
|
|
SMP_VAL_FE_SES_ACC = 1 << SMP_CKP_FE_SES_ACC, /* FE stream accept rules (to come soon) */
|
2013-03-25 09:52:41 -04:00
|
|
|
SMP_VAL_FE_REQ_CNT = 1 << SMP_CKP_FE_REQ_CNT, /* FE request content rules ("tcp request content") */
|
|
|
|
|
SMP_VAL_FE_HRQ_HDR = 1 << SMP_CKP_FE_HRQ_HDR, /* FE HTTP request headers (rules, headers, monitor, stats, redirect) */
|
|
|
|
|
SMP_VAL_FE_HRQ_BDY = 1 << SMP_CKP_FE_HRQ_BDY, /* FE HTTP request body */
|
|
|
|
|
SMP_VAL_FE_SET_BCK = 1 << SMP_CKP_FE_SET_BCK, /* FE backend switching rules ("use_backend") */
|
|
|
|
|
SMP_VAL_BE_REQ_CNT = 1 << SMP_CKP_BE_REQ_CNT, /* BE request content rules ("tcp request content") */
|
|
|
|
|
SMP_VAL_BE_HRQ_HDR = 1 << SMP_CKP_BE_HRQ_HDR, /* BE HTTP request headers (rules, headers, monitor, stats, redirect) */
|
|
|
|
|
SMP_VAL_BE_HRQ_BDY = 1 << SMP_CKP_BE_HRQ_BDY, /* BE HTTP request body */
|
|
|
|
|
SMP_VAL_BE_SET_SRV = 1 << SMP_CKP_BE_SET_SRV, /* BE server switching rules ("use_server", "balance", "force-persist", "stick", ...) */
|
|
|
|
|
SMP_VAL_BE_SRV_CON = 1 << SMP_CKP_BE_SRV_CON, /* BE server connect (eg: "source") */
|
|
|
|
|
SMP_VAL_BE_RES_CNT = 1 << SMP_CKP_BE_RES_CNT, /* BE response content rules ("tcp response content") */
|
|
|
|
|
SMP_VAL_BE_HRS_HDR = 1 << SMP_CKP_BE_HRS_HDR, /* BE HTTP response headers (rules, headers) */
|
|
|
|
|
SMP_VAL_BE_HRS_BDY = 1 << SMP_CKP_BE_HRS_BDY, /* BE HTTP response body (stick-store rules are there) */
|
|
|
|
|
SMP_VAL_BE_STO_RUL = 1 << SMP_CKP_BE_STO_RUL, /* BE stick-store rules */
|
|
|
|
|
SMP_VAL_FE_RES_CNT = 1 << SMP_CKP_FE_RES_CNT, /* FE response content rules ("tcp response content") */
|
|
|
|
|
SMP_VAL_FE_HRS_HDR = 1 << SMP_CKP_FE_HRS_HDR, /* FE HTTP response headers (rules, headers) */
|
|
|
|
|
SMP_VAL_FE_HRS_BDY = 1 << SMP_CKP_FE_HRS_BDY, /* FE HTTP response body */
|
REORG/MAJOR: session: rename the "session" entity to "stream"
With HTTP/2, we'll have to support multiplexed streams. A stream is in
fact the largest part of what we currently call a session, it has buffers,
logs, etc.
In order to catch any error, this commit removes any reference to the
struct session and tries to rename most "session" occurrences in function
names to "stream" and "sess" to "strm" when that's related to a session.
The files stream.{c,h} were added and session.{c,h} removed.
The session will be reintroduced later and a few parts of the stream
will progressively be moved overthere. It will more or less contain
only what we need in an embryonic session.
Sample fetch functions and converters will have to change a bit so
that they'll use an L5 (session) instead of what's currently called
"L4" which is in fact L6 for now.
Once all changes are completed, we should see approximately this :
L7 - http_txn
L6 - stream
L5 - session
L4 - connection | applet
There will be at most one http_txn per stream, and a same session will
possibly be referenced by multiple streams. A connection will point to
a session and to a stream. The session will hold all the information
we need to keep even when we don't yet have a stream.
Some more cleanup is needed because some code was already far from
being clean. The server queue management still refers to sessions at
many places while comments talk about connections. This will have to
be cleaned up once we have a server-side connection pool manager.
Stream flags "SN_*" still need to be renamed, it doesn't seem like
any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
|
|
|
SMP_VAL_FE_LOG_END = 1 << SMP_CKP_FE_LOG_END, /* FE log at the end of the txn/stream */
|
2020-02-21 12:14:59 -05:00
|
|
|
SMP_VAL_BE_CHK_RUL = 1 << SMP_CKP_BE_CHK_RUL, /* BE tcp-check rule */
|
2021-03-26 06:09:38 -04:00
|
|
|
SMP_VAL_CFG_PARSER = 1 << SMP_CKP_CFG_PARSER, /* within config parser */
|
2021-03-26 10:29:35 -04:00
|
|
|
SMP_VAL_CLI_PARSER = 1 << SMP_CKP_CLI_PARSER, /* within command line parser */
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
|
|
|
|
|
/* a few combinations to decide what direction to try to fetch (useful for logs) */
|
|
|
|
|
SMP_VAL_REQUEST = SMP_VAL_FE_CON_ACC | SMP_VAL_FE_SES_ACC | SMP_VAL_FE_REQ_CNT |
|
|
|
|
|
SMP_VAL_FE_HRQ_HDR | SMP_VAL_FE_HRQ_BDY | SMP_VAL_FE_SET_BCK |
|
|
|
|
|
SMP_VAL_BE_REQ_CNT | SMP_VAL_BE_HRQ_HDR | SMP_VAL_BE_HRQ_BDY |
|
2020-02-21 12:14:59 -05:00
|
|
|
SMP_VAL_BE_SET_SRV | SMP_VAL_BE_CHK_RUL,
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
|
|
|
|
|
SMP_VAL_RESPONSE = SMP_VAL_BE_SRV_CON | SMP_VAL_BE_RES_CNT | SMP_VAL_BE_HRS_HDR |
|
|
|
|
|
SMP_VAL_BE_HRS_BDY | SMP_VAL_BE_STO_RUL | SMP_VAL_FE_RES_CNT |
|
2020-02-21 12:14:59 -05:00
|
|
|
SMP_VAL_FE_HRS_HDR | SMP_VAL_FE_HRS_BDY | SMP_VAL_FE_LOG_END |
|
|
|
|
|
SMP_VAL_BE_CHK_RUL,
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
};
|
|
|
|
|
|
2012-04-25 04:13:36 -04:00
|
|
|
/* Sample fetch options are passed to sample fetch functions to add precision
|
|
|
|
|
* about what is desired :
|
|
|
|
|
* - fetch direction (req/resp)
|
|
|
|
|
* - intermediary / final fetch
|
|
|
|
|
*/
|
|
|
|
|
enum {
|
|
|
|
|
SMP_OPT_DIR_REQ = 0, /* direction = request */
|
|
|
|
|
SMP_OPT_DIR_RES = 1, /* direction = response */
|
|
|
|
|
SMP_OPT_DIR = (SMP_OPT_DIR_REQ|SMP_OPT_DIR_RES), /* mask to get direction */
|
|
|
|
|
SMP_OPT_FINAL = 2, /* final fetch, contents won't change anymore */
|
2012-04-26 05:44:02 -04:00
|
|
|
SMP_OPT_ITERATE = 4, /* fetches may be iterated if supported (for ACLs) */
|
2012-04-25 04:13:36 -04:00
|
|
|
};
|
|
|
|
|
|
2012-04-23 08:24:58 -04:00
|
|
|
/* Flags used to describe fetched samples. MAY_CHANGE indicates that the result
|
|
|
|
|
* of the fetch might still evolve, for instance because of more data expected,
|
|
|
|
|
* even if the fetch has failed. VOL_* indicates how long a result may be cached.
|
|
|
|
|
*/
|
|
|
|
|
enum {
|
|
|
|
|
SMP_F_NOT_LAST = 1 << 0, /* other occurrences might exist for this sample */
|
|
|
|
|
SMP_F_MAY_CHANGE = 1 << 1, /* sample is unstable and might change (eg: request length) */
|
|
|
|
|
SMP_F_VOL_TEST = 1 << 2, /* result must not survive longer than the test (eg: time) */
|
|
|
|
|
SMP_F_VOL_1ST = 1 << 3, /* result sensitive to changes in first line (eg: URI) */
|
|
|
|
|
SMP_F_VOL_HDR = 1 << 4, /* result sensitive to changes in headers */
|
|
|
|
|
SMP_F_VOL_TXN = 1 << 5, /* result sensitive to new transaction (eg: HTTP version) */
|
|
|
|
|
SMP_F_VOL_SESS = 1 << 6, /* result sensitive to new session (eg: src IP) */
|
|
|
|
|
SMP_F_VOLATILE = (1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6), /* any volatility condition */
|
2013-12-16 18:20:33 -05:00
|
|
|
SMP_F_CONST = 1 << 7, /* This sample use constant memory. May diplicate it before changes */
|
2012-04-23 08:24:58 -04:00
|
|
|
};
|
2010-09-23 12:02:19 -04:00
|
|
|
|
2012-08-24 13:22:53 -04:00
|
|
|
/* needed below */
|
2015-04-03 19:47:55 -04:00
|
|
|
struct session;
|
REORG/MAJOR: session: rename the "session" entity to "stream"
With HTTP/2, we'll have to support multiplexed streams. A stream is in
fact the largest part of what we currently call a session, it has buffers,
logs, etc.
In order to catch any error, this commit removes any reference to the
struct session and tries to rename most "session" occurrences in function
names to "stream" and "sess" to "strm" when that's related to a session.
The files stream.{c,h} were added and session.{c,h} removed.
The session will be reintroduced later and a few parts of the stream
will progressively be moved overthere. It will more or less contain
only what we need in an embryonic session.
Sample fetch functions and converters will have to change a bit so
that they'll use an L5 (session) instead of what's currently called
"L4" which is in fact L6 for now.
Once all changes are completed, we should see approximately this :
L7 - http_txn
L6 - stream
L5 - session
L4 - connection | applet
There will be at most one http_txn per stream, and a same session will
possibly be referenced by multiple streams. A connection will point to
a session and to a stream. The session will hold all the information
we need to keep even when we don't yet have a stream.
Some more cleanup is needed because some code was already far from
being clean. The server queue management still refers to sessions at
many places while comments talk about connections. This will have to
be cleaned up once we have a server-side connection pool manager.
Stream flags "SN_*" still need to be renamed, it doesn't seem like
any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
|
|
|
struct stream;
|
2020-06-04 09:33:47 -04:00
|
|
|
struct arg;
|
2012-08-24 13:22:53 -04:00
|
|
|
|
2012-04-23 08:24:58 -04:00
|
|
|
/* a sample context might be used by any sample fetch function in order to
|
|
|
|
|
* store information needed across multiple calls (eg: restart point for a
|
|
|
|
|
* next occurrence). By definition it may store up to 8 pointers, or any
|
|
|
|
|
* scalar (double, int, long long).
|
|
|
|
|
*/
|
|
|
|
|
union smp_ctx {
|
|
|
|
|
void *p; /* any pointer */
|
|
|
|
|
int i; /* any integer */
|
|
|
|
|
long long ll; /* any long long or smaller */
|
|
|
|
|
double d; /* any float or double */
|
|
|
|
|
void *a[8]; /* any array of up to 8 pointers */
|
|
|
|
|
};
|
|
|
|
|
|
2015-08-19 03:00:18 -04:00
|
|
|
/* a sample is a typed data extracted from a stream. It has a type, contents,
|
|
|
|
|
* validity constraints, a context for use in iterative calls.
|
|
|
|
|
*/
|
|
|
|
|
struct sample {
|
|
|
|
|
unsigned int flags; /* SMP_F_* */
|
|
|
|
|
struct sample_data data;
|
2012-04-23 08:24:58 -04:00
|
|
|
union smp_ctx ctx;
|
2015-05-11 05:54:58 -04:00
|
|
|
|
|
|
|
|
/* Some sample analyzer (sample-fetch or converters) needs to
|
|
|
|
|
* known the attached proxy, session and stream. The sample-fetches
|
|
|
|
|
* and the converters function pointers cannot be called without
|
|
|
|
|
* these 3 pointers filled.
|
|
|
|
|
*/
|
|
|
|
|
struct proxy *px;
|
|
|
|
|
struct session *sess;
|
2016-03-10 05:47:01 -05:00
|
|
|
struct stream *strm; /* WARNING! MAY BE NULL! (eg: tcp-request connection) */
|
2015-05-11 09:25:29 -04:00
|
|
|
unsigned int opt; /* fetch options (SMP_OPT_*) */
|
2012-04-23 08:24:58 -04:00
|
|
|
};
|
|
|
|
|
|
2012-04-27 15:37:17 -04:00
|
|
|
/* Descriptor for a sample conversion */
|
|
|
|
|
struct sample_conv {
|
2010-01-04 10:16:05 -05:00
|
|
|
const char *kw; /* configuration keyword */
|
2015-05-11 09:20:49 -04:00
|
|
|
int (*process)(const struct arg *arg_p,
|
2015-02-23 09:11:11 -05:00
|
|
|
struct sample *smp,
|
2014-12-15 10:18:39 -05:00
|
|
|
void *private); /* process function */
|
2016-03-15 15:00:35 -04:00
|
|
|
uint64_t arg_mask; /* arguments (ARG*()) */
|
2012-04-20 09:52:36 -04:00
|
|
|
int (*val_args)(struct arg *arg_p,
|
2013-11-21 07:37:41 -05:00
|
|
|
struct sample_conv *smp_conv,
|
2014-02-11 08:00:19 -05:00
|
|
|
const char *file, int line,
|
2012-04-20 09:52:36 -04:00
|
|
|
char **err_msg); /* argument validation function */
|
2012-04-27 15:37:17 -04:00
|
|
|
unsigned int in_type; /* expected input sample type */
|
|
|
|
|
unsigned int out_type; /* output sample type */
|
2014-12-15 10:18:39 -05:00
|
|
|
void *private; /* private values. only used by maps and Lua */
|
2010-01-04 10:16:05 -05:00
|
|
|
};
|
|
|
|
|
|
2012-04-27 15:37:17 -04:00
|
|
|
/* sample conversion expression */
|
|
|
|
|
struct sample_conv_expr {
|
|
|
|
|
struct list list; /* member of a sample_expr */
|
|
|
|
|
struct sample_conv *conv; /* sample conversion used */
|
|
|
|
|
struct arg *arg_p; /* optional arguments */
|
2010-01-04 10:16:05 -05:00
|
|
|
};
|
|
|
|
|
|
2012-04-27 15:37:17 -04:00
|
|
|
/* Descriptor for a sample fetch method */
|
|
|
|
|
struct sample_fetch {
|
2010-01-04 10:16:05 -05:00
|
|
|
const char *kw; /* configuration keyword */
|
2015-05-11 09:42:45 -04:00
|
|
|
int (*process)(const struct arg *arg_p,
|
2013-07-22 10:29:32 -04:00
|
|
|
struct sample *smp,
|
2014-12-07 12:37:57 -05:00
|
|
|
const char *kw, /* fetch processing function */
|
|
|
|
|
void *private); /* private value. */
|
2016-03-15 15:00:35 -04:00
|
|
|
uint64_t arg_mask; /* arguments (ARG*()) */
|
2012-04-20 09:52:36 -04:00
|
|
|
int (*val_args)(struct arg *arg_p,
|
|
|
|
|
char **err_msg); /* argument validation function */
|
2012-04-27 15:37:17 -04:00
|
|
|
unsigned long out_type; /* output sample type */
|
MEDIUM: samples: use new flags to describe compatibility between fetches and their usages
Samples fetches were relying on two flags SMP_CAP_REQ/SMP_CAP_RES to describe
whether they were compatible with requests rules or with response rules. This
was never reliable because we need a finer granularity (eg: an HTTP request
method needs to parse an HTTP request, and is available past this point).
Some fetches are also dependant on the context (eg: "hdr" uses request or
response depending where it's involved, causing some abiguity).
In order to solve this, we need to precisely indicate in fetches what they
use, and their users will have to compare with what they have.
So now we have a bunch of bits indicating where the sample is fetched in the
processing chain, with a few variants indicating for some of them if it is
permanent or volatile (eg: an HTTP status is stored into the transaction so
it is permanent, despite being caught in the response contents).
The fetches also have a second mask indicating their validity domain. This one
is computed from a conversion table at registration time, so there is no need
for doing it by hand. This validity domain consists in a bitmask with one bit
set for each usage point in the processing chain. Some provisions were made
for upcoming controls such as connection-based TCP rules which apply on top of
the connection layer but before instantiating the session.
Then everywhere a fetch is used, the bit for the control point is checked in
the fetch's validity domain, and it becomes possible to finely ensure that a
fetch will work or not.
Note that we need these two separate bitfields because some fetches are usable
both in request and response (eg: "hdr", "payload"). So the keyword will have
a "use" field made of a combination of several SMP_USE_* values, which will be
converted into a wider list of SMP_VAL_* flags.
The knowledge of permanent vs dynamic information has disappeared for now, as
it was never used. Later we'll probably reintroduce it differently when
dealing with variables. Its only use at the moment could have been to avoid
caching a dynamic rate measurement, but nothing is cached as of now.
2013-01-07 09:42:20 -05:00
|
|
|
unsigned int use; /* fetch source (SMP_USE_*) */
|
|
|
|
|
unsigned int val; /* fetch validity (SMP_VAL_*) */
|
2014-12-07 12:37:57 -05:00
|
|
|
void *private; /* private values. only used by Lua */
|
2010-01-04 10:16:05 -05:00
|
|
|
};
|
|
|
|
|
|
2012-04-27 15:37:17 -04:00
|
|
|
/* sample expression */
|
|
|
|
|
struct sample_expr {
|
|
|
|
|
struct list list; /* member of list of sample, currently not used */
|
|
|
|
|
struct sample_fetch *fetch; /* sample fetch method */
|
|
|
|
|
struct arg *arg_p; /* optional pointer to arguments to fetch function */
|
2010-01-04 10:16:05 -05:00
|
|
|
struct list conv_exprs; /* list of conversion expression to apply */
|
|
|
|
|
};
|
|
|
|
|
|
2012-04-27 15:37:17 -04:00
|
|
|
/* sample fetch keywords list */
|
|
|
|
|
struct sample_fetch_kw_list {
|
|
|
|
|
struct list list; /* head of sample fetch keyword list */
|
|
|
|
|
struct sample_fetch kw[VAR_ARRAY]; /* array of sample fetch descriptors */
|
2010-01-04 10:16:05 -05:00
|
|
|
};
|
|
|
|
|
|
2012-04-27 15:37:17 -04:00
|
|
|
/* sample conversion keywords list */
|
|
|
|
|
struct sample_conv_kw_list {
|
|
|
|
|
struct list list; /* head of sample conversion keyword list */
|
|
|
|
|
struct sample_conv kw[VAR_ARRAY]; /* array of sample conversion descriptors */
|
2010-01-04 10:16:05 -05:00
|
|
|
};
|
|
|
|
|
|
2013-11-21 04:53:12 -05:00
|
|
|
typedef int (*sample_cast_fct)(struct sample *smp);
|
|
|
|
|
|
2020-06-04 09:33:47 -04:00
|
|
|
#endif /* _HAPROXY_SAMPLE_T_H */
|
