On 10 May 2016 at 00:30, Daniel Stenberg <daniel_at_haxx.se> 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: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-05-10