cURL / Mailing Lists / curl-library / Single Mail


Re: http:/// and other slash amounts

From: Daniel Stenberg <>
Date: Tue, 10 May 2016 08:29:40 +0200 (CEST)

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:///////////" (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:

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.

List admin:
Received on 2016-05-10