cURL / Mailing Lists / curl-library / Single Mail


Re: http:/// and other slash amounts

From: bch <>
Date: Tue, 10 May 2016 15:53:25 -0700

On May 10, 2016 3:38 PM, "Daniel Stenberg" <> wrote:
> On Tue, 10 May 2016, bch wrote:
>> I wasn't really kidding when I posted
>> 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

That's the truth. Once support is in, it'll likely have to stay in. What I
was proposing was a sort of middle ground, but is option-based (and indeed
my current usage is practically mostly w libcurl), and may not be suitable
for the bulk of curl (command line) users.

Going "all-in" or "all-out" may indeed be best route. Regarding this, I'm
really glad you seem to be seriously considering resisting support for this.


> --
> /
> -------------------------------------------------------------------
> List admin:
> Etiquette:

List admin:
Received on 2016-05-11