cURL / Mailing Lists / curl-library / Single Mail


Re: http:/// and other slash amounts

From: Tor Arntsen <>
Date: Tue, 10 May 2016 06:11:45 +0200

On 10 May 2016 at 00:30, Daniel Stenberg <> wrote:

> The rationale is not clear: The WHATWG spec allows an unlimited amount of
> slashes because "all browsers do". And all browsers (presumably) do what the
> spec says.
> It isn't consistent either; not all browsers accept unlimited amounts of
> slashes (for example when tested the other day, Safari rejected ten slashes
> in a Location: redirect). Not to mention all other non-browser tools and
> libraries that like us, haven't adopted the WHATWG spec.
> ... but then again, servers are obviously sending responses that are handled
> fine by browsers and some of those responses find themselves also received
> by curl and here we are! =)
> A slipperly slope.

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).

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:

The only way I can think of it as acceptable is to pretend that there
is a standard which says that if HTTP URL paths (what comes after
'://') start with slashes, they are ignored as superfluous because all
HTTP paths are absolute (unlike ftp paths). So for FTP that '/' after
the :// means (and it does) an absolute path from root, and without it
it's not. For HTTP one or more are ignored because it's absolute
anyway. As with 'ls -l /////', which works of course.

What we cannot accept IMO would be 'http:/something', the glyph is ://
and if you strip one slash from there it must be rejected.
List admin:
Received on 2016-05-10