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/questions/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?

-- 
  / daniel.haxx.se

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