Hi Tim,
On Sat, Apr 17, 2021 at 01:23:15PM +0200, Tim Düsterhus wrote:
> > 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.
I disagree with this line of reasoning, because developers must never
decide what users need (and that's something very difficult to do). We
must only help to figure what users really need (compared to what they
ask for), and estimate the technical feasibility and the consistency
with all other parts so that each feature doesn't look like it's been
developed differently.
Each time we tried to impose something it resulted in a specific feature
being corner-cased over time after we had to implement something cleaner
to put an end to horrible workarounds, just like we've seen a lot of
dummy headers being used before variables existed, or headers appended
after the HTTP version in health checks.
I already have counter examples for you here. Imagine I want to normalize
the Referer header in a request. What I'll have to do is:
http-request set-var(req.uri) url
http-request set-uri req.fhdr(referer)
http-request normalize-uri path-merge-slashes
http-request normalize-uri path-strip-dotdot
http-request set-header referer url
http-request set-uri var(req.uri)
And you can be certain that some users might end up with this one (then
they will complain they cannot clean up Location nor Link headers because
normalize-uri only works in the request context). And even when you say
that some users would apply it to the query-string, yes that's possible.
And so what, if they consider they need it ? For example you could have
a query string made of an optionally base64-encoded URL to redirect to
after a successful login. It could make sense for some users to decide
to base64-decode, normalize, and re-encode, to make sure it's not being
abused for example. Or in some cases it can make sense to apply the
transformation only for a match against certain patterns without applying
it to the request itself.
I perfectly understand that some transformations may require the whole
URI for various reasons, but for those that could be expressed on
individual parts, I do think that converters will be way more flexible
over the long term.
There's no rush on this, but I think it's something to keep in mind,
to see which ones might be separated and be provided as converters
as well. We may do that during 2.5-dev and possibly backport them
if there is some demand.
Cheers,
Willy
