On Tue, 10 May 2016, Tor Arntsen wrote:
Presumably all browsers don't handle 'ftp:///' the same way as 'ftp://'? Because for ftp ftp:/// is valid and has a different meaning from ftp:// (as Daniel knows of course, it was mentioned earlier in the thread).
I think you mean the "ftp://hostname//"; case, with more than one slash after the host part? At least both Chrome and Firefox accept "ftp:///////////ftp.funet.fi"; (but normalizes it to use two colons after it has been entered). And honestly, even the two slashes after the host name isn't kosher according to spec irc as a leading slash in the path is supposed to be written with %2f: ftp://ftp.funet.fi/%2fetc/issue
file: URLs are treated separately (even in the WHATWG spec) and they are even according to the RFC spec using three slashes by default, like "file:///etc/issue" (because the host name part is normally just blanked). But then of course, supporting overly many slashes for file: makes sense since those will be passed straight on to the file system and at least most *nix like operating systems allow access to "///////////////////etc/issue"
To me this way of mishandling the slashes doesn't sit well in my gut. The glyph is '://', and should be handled as a single component. But let's try:
...
What we cannot accept IMO would be 'http:/something', the glyph is :// and if you strip one slash from there it must be rejected.
The WHATWG URL spec treats "http:/host" the same as "http:///host";. If we buy the arguments for supporting three slashes, then we get the argument for supporting a single slash bundled for free...
Believe me, this entire issue is causing me itches all over. -- / daniel.haxx.se ------------------------------------------------------------------- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
