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.