cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: OPTIONS * requests

From: Nicholas Shanks <nickshanks_at_nickshanks.com>
Date: Fri, 26 Aug 2016 21:25:59 +0100

On Thursday, 25 August 2016, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Thu, 25 Aug 2016, Nicholas Shanks wrote:
>
> As someone without legacy code, doing
>> $ curl -X OPTIONS http://www.example.com
>> Would be my preferred choice, but I can easily see that existing code
>> would
>> expect that to be equal to
>> $ curl -X OPTIONS http://www.example.com/
>>
>
> It's not about legacy really, it is about what curl knows and does.
>
> Currently the existing code will always add a slash if there isn't one so
> the two lines above will end up the same internally.

That's what I mean about legacy users. I'd rather curl didn't add a slash
internally, and kept the path as an empty string. At the moment when you
realise you're not sending the request to a proxy and the full path has
been built but is still empty (and thus are about to emit "GET HTTP/1.1")
do you substitute an asterisk.

The two above would then not be equivalent, but if that's not a concern I'd
be pleased.

Then, curl doesn't know OPTIONS *at all* so in this case it would send
> "OPTIONS /" because we asked to send OPTIONS and the slash is derived from
> the path part.
>
> How would curl decide that the slash would suddenly be an asterisk? And
> what if you really wanted to do OPTIONS / ? And what if you want to be able
> to also do "ONIONS *".

curl -X ONIONS http://example.com
With no final slash.

> I'd like to avoid "hard-coding" curl to know that "*" is magic for OPTION.
> I prefer making it possible to send it without curl knowing its special.
>
> Something like
>
> curl -X OPTIONS http://example.com/* --strip-slash

Such a --strip-slash option leaks details of how curl internally does
things, and isn't intuitive IMHO.

As in the examples I gave, I think this is achievable without anything
after "com" in the above, curl only needs to know that the asterisk
represents a null/empty path where one has to be provided (for all methods)
and then to substitute it in the non-proxy case.

> One downside with this solution is that if you'd ask that to be used over
> a proxy, you'd have to change the URL to make curl send the right thing.
> But I think that's ine line with what curl does, it lets the user provide
> the URL and curl just passes it on.
>
> Tricky!

That doesn't apply in my suggestion as the empty string is appended to the
authority with no conversion to an asterisk occurring.

> How does curl format request lines with the host present?
>>
>
> The host is present in the request line when sent to a proxy, like
> Tatsuhiro showed.
>

I meant how is the request line built in the proxy case. I assume it is
scheme + ":" + ["//" + authority] + path
hence my suggestion that an empty path would work fine for proxies and need
to be substituted otherwise.

-- 
Nicholas.

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