On Thu, Aug 25, 2016 at 9:16 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Thu, 25 Aug 2016, Nicholas Shanks wrote:
>
> Curl currently cannot perform an OPTIONS * request. Daniel said the main
>> issue is deciding how the changes necessary should be integrated.
>>
>
> For reference, I said it here: https://stackoverflow.com/ques
> tions/36925133/is-it-possible-to-send-options-with-curl/
> 36933053?noredirect=1#comment65626746_36933053
>
> I can't
>> really speak to that but would like to open the discussion. There is also
>> the question of how to invoke the request. One of my earliest attempts to
>> perform this was by using
>>
>
> $ curl -X OPTIONS http://www.example.com*
>>
>
> Another would be to put the asterisk in the method:
>>
>
> $ curl -X "OPTIONS*" http://www.example.com
>>
>
> Right, those certainly two approaches that probably won't break existing
> uses. But I think we need to answer some other fundamental questions first,
> or perhaps as well.
>
> Right now we can only request something that begins with a slash because
> that's how the internals work - they blindly assume paths.
>
> Should we make a change to allow ONLY '*' for OPTIONS or should we open up
> the ability to send arbitrary strings to arbitrary methods?
>
> Maybe the option should be "--strip-the-initial-slash-from-the-request-path"
> so that this would work:
>
> curl -X OPTIONS http://www.example.com/*
>
> but it would also allow super-crazy things like
>
> curl -X SHRUG http://www.example.com/%c2¯\_(ツ)_/¯
>
> (which I've had requests for in the past when poeple wanted to
> test/torture their servers with crafted things)
>
> Such an option might however be a bit harder for users to figure out. Not
> to mention that we'd need to figure out a name for it that is shorter than
> what I offered above.
>
> Or are there even better ways?
>
>
​"OPTIONS *" is server-wide OPTIONS request.​

Actually, OPTIONS is very interesting method. Doing this without proxy is
"OPTIONS * HTTP/1.1".
​According to ​http://tools.ietf.org/html/rfc7230#section-5.3.4, when we
perform server-wide via HTTP/1 proxy, we send "OPTIONS http://example.org
HTTP/1.1". Watch out for the absence of last "/". This is critical.
Adding "/" means OPTIONS request to "/", which is not server-wide request.

Since curl takes absolute URI in command-line (like in proxy request), we
can say that if we have no path component (e.g., http://example.com), then
it is server-wide OPTIONS request, and we will send "OPTIONS * HTTP/1.1"
without proxy case. Yes, we need to special case server-wide OPTIONS
request here. But it is done only when we serialize HTTP request in wire
format.

But curl probably doesn't like empty path component internally, so we
expect that some road blocks ahead.

Best regards,
Tatsuhiro Tsujikawa

> --
>
> / 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-08-25