On 10 May 2016 at 00:30, Daniel Stenberg <[email protected]> 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
