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