cURL and libcurl, Network, Web

“OPTIONS *” with curl

7 Comments

(Note: this blog post as been updated as the command line option changed after first publication, based on comments to this very post!)

curl is arguably a “Swiss army knife” of HTTP fiddling. It is one of the available tools in the toolbox with a large set of available switches and options to allow us to tweak and modify our HTTP requests to really test, debug and torture our HTTP servers and services.

That’s the way we like it.

In curl 7.55.0 it will take yet another step into this territory when we finally introduce a way for users to send “OPTION *” and similar requests to servers. It has been requested occasionally by users over the years but now the waiting is over. (brought by this commit)

“OPTIONS *” is special and peculiar just because it is one of the few specified requests you can do to a HTTP server where the path part doesn’t start with a slash. Thus you cannot really end up with this based on a URL and as you know curl is pretty much all about URLs.

The OPTIONS method was introduced in HTTP 1.1 already back in RFC 2068, published in January 1997 (even before curl was born) and with curl you’ve always been able to send an OPTIONS request with the -X option, you just were never able to send that single asterisk instead of a path.

In curl 7.55.0 and later versions, you can remove the initial slash from the path part that ends up in the request by using –request-target. So to send an OPTION * to example.com for http and https URLs, you could do it like:

$ curl --request-target "*" -X OPTIONS http://example.com
$ curl --request-target "*" -X OPTIONS https://example.com/

In classical curl-style this also opens up the opportunity for you to issue completely illegal or otherwise nonsensical paths to your server to see what it does on them, to send totally weird options to OPTIONS and similar games:

$ curl --request-target "*never*" -X OPTIONS http://example.com

$ curl --request-target "allpasswords" http://example.com

Enjoy!

7 thoughts on ““OPTIONS *” with curl”

  1. (Daniel’s edit: Evert’s comment here was made regarding the original command line options, which since was changed to match this suggestion)

    I get that curl is all about urls, but it definitely seems a bit like fitting a round peg in a square hole!

    I feel that something like

    curl https://example.com/ –request-target=”*”

    is a bit more semanticly meaningful, because it tells me: I’m using the url to figure out how to open the connection, but instead of using the path part of the url, I’m opting to override the request target with the following string.

    The asterisk is distinctly *not* a path part in a uri, and it’s actually one of 3 types of request targets that don’t start with a slash.

    1. That’s not a bad suggestion, thanks! It has the fine upside of being slightly more readable, even if it could make a user wonder where the path from the URL goes…

      (I’ve now implemented this in PR #1593 to allow us to try it out and maybe switch to this…)

        1. Right, but that doesn’t necessarily say that there won’t be people who want to try and send either “*” to other methods or send “**” etc to OPTIONS just to see how their servers like that…

Comments are closed.