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 :-)

> 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
> 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.


> 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.


Reply via email to