Willy,
On 4/17/21 12:09 PM, Willy Tarreau wrote:
With the renaming already made I consider the configuration syntax to be
stable enough for a 2.4. I'll leave the final decision regarding that up to
you, though. Especially since 2.4 is going to be an LTS.
What we can possibly do, if you're not completely sure about the naming
(it's often a very difficult aspect to deal with), is to merge the series,
ask users in the next release announcement to have a look and possibly
suggest updates before the release. We can then mark the new actions as
With the new names (1st patch this morning) I think that the naming is
good. It is descriptive and follows a well-defined naming scheme that
allows for future extension.
experimental in the doc, and remove the experimental status after a while.
Or if the features look solid enough and you're feeling ready to deal with
occasionally possible bug reports, we can merge them and even not pass via
an experimental status.
I added the experimental marking in the 3rd patch this morning.
Generally I think that it looks solid enough, though. During development
I carefully researched the relevant documentation (e.g. the URI RFC) and
tested the behavior of different clients and servers. It also comes with
quite a few tests ensuring that the normalizers behave like I expect
them to.
Nonetheless I might have missed something and correct handling of URIs
is a sensitive part of the request handling, so an experimental note
still is appropriate.
All in all: I think that the 8 v2 patches + the 3 patches from this
morning together result in something that is appropriate for HAProxy 2.4.
I'm open to various options. Anyway I do think that URI normalization is
a useful feature to have.
I think that some of the actions will probably end up being replicated
as converters, so maybe in the end the sequence below:
http-request normalize-uri path-merge-slashes
http-request normalize-uri path-strip-dotdot
could end up like this:
http-request set-path %[path,path-merge-slashes,path-strip-dotdot]
The pre-release period is the right one to evaluate such options, so
I'm not worried about any outcome.
I would advice against making them into converters, because it forces
the user to think about the appropriate fetch to use. As an example the
path-strip-dotdot normalizer probably should not be applied to the query
string! The actions hide this type of detail from the user which I
consider to be a good thing.
Best regards
Tim Düsterhus
