Adding "OPTIONS *" support, what to call the option?

Post by Daniel Stenberg
I've submitted a first version of a pull-request [1] that gives the curl
tool the ability to issue an HTTP "OPTIONS *" request to a server, something
that isn't previously possible and has been mentioned in the TODO for a
while.
To send this request a special command line option needs to be used.
What should this option be called? I don't want it to be plain "--options"
because that doesn't properly reveal that it also sends the asterisk instead
of the path. You can already do -X OPTIONS to get the path-sending version
done without this new option.
My current version calls it --optionsstar but I'm not overly happy with this
name.
Ideas?

This seems a needlessly specific solution. Why not something more general, like
--raw-url that does no normalization of the URL sent to the server? It would
then be used like "curl --send-raw-url -X OPTIONS 'http://example.com/*'". If
some future HTTP standard extends the spec to e.g. allow * as a wildcard (to
make "OPTIONS FOO*" valid) or some other scheme needs more control over the
path, this would still work.

Dan

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https:

Daniel Stenberg

2017-05-04 09:14:16 UTC

Post by Daniel Stenberg
My current version calls it --optionsstar but I'm not overly happy with
this name.

This seems a needlessly specific solution.

I opted on that based on previous discussions we've had and it is mostly to
make it more obvious to users what the option would be used for. But I'm open
for discussing different takes.

Post by Dan Fandrich
Why not something more general,
like --raw-url that does no normalization of the URL sent to the server? It
would then be used like "curl --send-raw-url -X OPTIONS
'http://example.com/*'".

In this case it isn't really raw, it would actually just need to skip the
initial slash from the path in the HTTP request. --skip-path-slash ?

Post by Dan Fandrich
If some future HTTP standard extends the spec to e.g. allow * as a wildcard
(to make "OPTIONS FOO*" valid) or some other scheme needs more control over
the path, this would still work.

Right, or if you want to torture your web server and see how it likes getting
many asterisks with OPTIONS or whatever, you could do that as well...

--
/ daniel.haxx.se
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html

Dan Fandrich

2017-05-04 11:02:22 UTC

Why not something more general, like --raw-url that does no normalization
of the URL sent to the server? It would then be used like "curl
--send-raw-url -X OPTIONS 'http://example.com/*'".

In this case it isn't really raw, it would actually just need to skip the
initial slash from the path in the HTTP request. --skip-path-slash ?

One could argue that the initial slash isn't part of the path but rather a
separator. That view is more apparent in the sftp: scheme where
sftp://host/path/file denotes the relative path to the file "path/file" whereas
sftp://host//path/file denotes the absolute path "/path/file". And there have
been requests in the past to be able to undo the path canonicalization that
curl performs (e.g. http://example.com/foo/../bar/baz =>
http://example.com/bar/baz which the more general --raw-url approach would also
allow.

Dan

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail

Daniel Stenberg

2017-05-04 12:54:14 UTC

Post by Daniel Stenberg
In this case it isn't really raw, it would actually just need to skip the
initial slash from the path in the HTTP request. --skip-path-slash ?

One could argue that the initial slash isn't part of the path but rather a
separator.

A plain "curl https://curl.haxx.se/curl.css" etc would break with --raw-url
using that definition. Not thrilled about that, it would feel a bit
misleading.

Post by Dan Fandrich
And there have been requests in the past to be able to undo the path
canonicalization that curl performs (e.g.
http://example.com/foo/../bar/baz => http://example.com/bar/baz which the
more general --raw-url approach would also allow.

Right, the old classic: "curl https://curl.haxx.se/../../etc/passwd". I think
it would be neat to use a --raw-url option to set libcurl's CURLOPT_PATH_AS_IS
option, but even for this URL having it skip the separator (initial slash)
would make the server dislike you and you'd have to use "curl
https://curl.haxx.se//../../etc/passwd" - without it being very clear to a
user...

--
/ daniel.haxx.se
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail

Dan Fandrich

2017-05-04 16:01:05 UTC

Post by Daniel Stenberg
In this case it isn't really raw, it would actually just need to skip the
initial slash from the path in the HTTP request. --skip-path-slash ?

One could argue that the initial slash isn't part of the path but rather a
separator.

A plain "curl https://curl.haxx.se/curl.css" etc would break with --raw-url
using that definition. Not thrilled about that, it would feel a bit
misleading.

That's true.

Looks like that's already exposed as --path-as-is.

Post by Daniel Stenberg
separator (initial slash) would make the server dislike you and you'd have
to use "curl https://curl.haxx.se//../../etc/passwd" - without it being very
clear to a user...

--path-as-is plus a new --skip-path-slash (maybe --strip-path-slash?) might
just do it.

Post by Daniel Stenberg
Dan

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/

Jacob Champion via curl-users

2017-05-04 23:16:14 UTC