On 26.03.20 09:42, Willy Tarreau wrote:
On Thu, Mar 26, 2020 at 09:25:31AM +0100, Christopher Faulet wrote:
It is a good idea. For now, I have only few idea though. For the header
part, it must not be a raw block. Because it will be really hard to keep the
same syntax with the HTX. I propose to keep same syntax than http-request
rules :
http-check add-header <name> <value>
And later :
http-check set-header <name> <value>
http-check del-header <name>
http-check replace-header <name> <regex> <value>
http-check replace-value <name> <regex> <value>
I don't think we'll need to perform such operations in health checks because
they're normally only useful for real traffic. Here everything is built from
scratch so deleting a header or replacing it will be of very limited use, it
just means they would have been added by a previous rule. Also thinking about
this when combined with multiple requests gives me a headache :-)
Well I think that could be required when the backend have different vhosts
and ssl-vhosts.
Can we add request|respone to make it a little bit clear when which header will
be set.
# set session cookie for example
http-check request set-header <name> <value>|<expression>
http-check request set-sni <name> <value>|<expression>
http-check response expect <regex>
# I'm not sure if there is a use case for that
http-check response del-header <name>
What I like is to be able to define a check backend and use the track keyword
for checks.
http://cbonte.github.io/haproxy-dconv/2.2/configuration.html#5.2-track
Will this be also available in the first implementation?
Another idea could be to have a syntax similar to the HTTP return action :
http-check hdr <name> <value> hdr <name> <value> string <body-str>
or
why not both => AND but only one is usable in one check sequence?
http-check hdr <name> <value> hdr <name> <value> file <body-file>
These ones do seem like good ideas. They continue to allow to fully
define a check in a simple statement. And maybe later when we start
to think about sending check sequences they will be very convenient
because each line could define an entire request (possibly reusing
parts from the previous response if needed).
The request URI is passed on the "option httpchk" line. But, maybe the
method, the path and the version may also be defined on such line.
Agreed.
There are many other problems to deal with. But it is a first step. The
content-length must be automatically deduced when a body is defined.
Fully agreed!
For
current versions, the connection header must also be added the same way it
is done today.
Sure. I'd say it's a "detail" in that it's not visible from the users' end.
During my refactoring, I can try to first work on a way to support such
syntax on current versions. But we must be sure to have the right syntax
first. It is the harder part :)
Yes, that's exactly my point as well. If we figure the long-term picture,
we can narrow it down for a first implementation.
Willy
