Willy,

On 4/21/21 7:03 PM, Willy Tarreau wrote:
$ curl -v https://example.com/foo///bar 2>&1 |grep GET
GET /foo///bar HTTP/2
$ curl -v https://example.com/foo/../bar 2>&1 |grep GET
GET /bar HTTP/2
$ curl -v https://example.com/foo//../bar 2>&1 |grep GET
GET /foo/bar HTTP/2

I'm fine with prefixing 'path-' (i.e. 'path-filesystem'). Simply 'path'
might be misleading, because it includes non-standard normalization.

I agree that path alone could be confusing or misleading, at least because
it looks like the similar sample-fetch (and we must absolutely avoid having
conflicting names between sample fetch functions and converters otherwise
we will never be able to merge them). Why not "path-normalize" ? It seems
to describe exactly what it tries to do.

I'm still working on getting the `http-request normalize-uri` action that is being used for request ingestion from the clients correct.

  http-request normalize-uri path-normalize

would be pretty redundant. That's why I suggested path-filesystem. But I realize that most of the normalizer names could be used as-is for converters, but this combined normalizer cannot.

I *really* think that we should leave these combined normalizers out for the initial version and wait for users feedback (including real world tests by myself). It's a bit verbose in the configuration, but it works.

By the way be careful about RFC3986, as I remember that there is an
algorithm or an illustration program there explaining how to resolve
paths, and that contains a bug (like every single time code is offered
in RFCs). The ABNF was correct however. It might be mentioned in the
errata but I really don't remember the details, most likely something
related to the inability to resolve a missing component and causing a
".." to point to the wrong place.


I just had a look at the errata. There's indeed something about '../', but that is regarding combining relative URLs with a specific base URL. Additional leading '../' must be preserved. The normalizer already has an appropriate option.

Best regards
Tim Düsterhus

Reply via email to