On Mon, 9 May 2016, Alex Bligh wrote:

> If you fix this, you should fix URL processing to permit it in general, and
> I see no reason to do that.

The patch I posted in the issue actually changes the parsing for all URLs,
yes. Even when passed to curl as "http:/example.com"! :-O

But I could also mention that we're already since before doing things to URLs
that aren't in the spec when they arrive in a Location: just because browsers
set their own rules:

1 - we handle spaces and encode them as %20 before using the URL - a "real"
URL cannot have spaces

2 - we handle non-ascii letters and percent encode them. Legal URLs cannot
have such byte codes in the first place and certain browsers clearly do this
operation on their own.

After all, curl operates in the fuzzy area between a strict protocol
implemenation and the web as done and used by browsers. It isn't always easy.

Domenic Denicola pointed out to me on twitter [1] that the WHATWG URL spec
that the browsers are following allows _any_ number of slahes:

   https://url.spec.whatwg.org/#special-authority-ignore-slashes-state

He has subsequently posted an issue to the whatwg url github issue tracker
about this:

   https://github.com/whatwg/url/issues/118

[1] = https://twitter.com/domenic/status/729663205983793152

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html