Willy,
On 4/21/21 12:11 PM, Willy Tarreau wrote:
For the existing path ones I'd suggest:
http-request normalize-uri filesystem
that combines path-strip-dot, path-strip-dotdot, path-merge-slashes in an
useful order.
The only thing is that "filesystem" doesn't imply at all that it applies
to the path component of the URI. It could very well be about FS-like
parts in the query string for example. Instead I think that since the path
component is well defined, its name should at least be part of the action
(not sure if we'd want multiple actions once we can adhere to the standard).
While the path-strip-dot and path-strip-dotdot normalizers are indeed
defined in RFC 3986, section 6.2.2.3, the path-merge-slashes
normalization does not appear in RFC 3986 (or I might have missed it).
Testing with cURL confirms this: cURL normalizes '/./' and '/../' by
itself unless --path-as-is is given. However duplicate slashes are not
being normalized. This is especially interesting for empty path segments
in combination with '/../'.
$ 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.
Best regards
Tim Düsterhus
