On Tue, 10 May 2016, bch wrote:

> I wasn't really kidding when I posted
> https://twitter.com/bcharder/status/728341342447800320
>
> I was thinking of support that is adjunct and switchable (on/off). A
> facility for "/-condensing" that has heuristics for ///.... -> // after the
> transport, and perhaps //... -> / in the path?

The old me would've done so immediately.

The current me thinks of the implications and on the users and how that option
would ever actually be used. And the weight of yet another option.

The primary problem with adding an option for this behavior is that user's
won't know before-hand what it should set this option to, and will then rather
just use the default.

Then, as these malformed URLs are probably occuring like no more than once in
a million (remember, we've only seen this in a single bug report), users won't
have the option set correctly to deal with them once they actually DO show up.

However hard it is to make a decision, I think it is better for us to either
accept or not accept such a syntax.

Right now, backed by the fact that a not insignificant browser share doesn't
support this, the lousy responses from whatwg on the matter and the fact that
I'm not aware of any non-browser tool or library that support 123-slashes, I'm
leaning towards NOT supporting them. Sticking to what we already have is also
the easier choice, as we can always go more laxed at a later point in time.
Switching back from a more accepting parser might be harder.

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