From: Gavin Lambert (boost_at_[hidden])
Date: 2021-10-19 21:54:54
On 20/10/2021 02:12, Phil Endecott wrote:
> Right. But why has it chosen that goal, rather than the alternatives?
> What's the rationale?
>
> It seems to me that a URL with redundant /s (e.g.
> http://foo.com/path/////to/file)
> is either (a) malicious or erroneous input, or (b) equivalent to the
> versions without the redundant /s. So a user might want to (a) get an
> exception or error, or (b) ignore the redundant segments. Under what
> circumstances would a user want to see the empty segments between those
> /s?
The rationale is the URI standard RFC. It is not permitted for URI
parsers to perform such collapsing because such URIs are entirely legal.
Unusual, certainly, especially for http[s] URIs that usually eventually
end up at a filesystem that would collapse consecutive slashes. Most
web servers (regardless of whether evaluating vs a filesystem or not)
will indeed collapse consecutive slashes too, at least while matching
against resource rules.
But URIs are not required to wind up leading to a filesystem or to be
served by a web server -- it's entirely possible that some other scheme
may treat additional consecutive slashes as significant for some purpose.