cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: http:/// and other slash amounts

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

On May 10, 2016 3:38 PM, "Daniel Stenberg" <daniel_at_haxx.se> wrote:
>
> 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.

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.

-bch

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

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-05-11