W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: XMLHttpRequest. Support for "OPTIONS *" method.

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 05 Sep 2014 19:53:49 +0200
Message-ID: <5409F8AD.4000506@gmx.de>
To: Валерий Котов <kotov.valery@gmail.com>
CC: public-webapps@w3.org, Anne van Kesteren <annevk@annevk.nl>
On 2014-09-05 19:34, Валерий Котов wrote:
> ...
> Thank you everybody for responses!
>  > Out of curiosity - do you have a use case where you need to be able
> to send "OPTIONS *"?
> Unfortunately, I can't think of any specific use case except getting
> general server settings. For example (from specification), OPTIONS
> request can be used to test proxy for HTTP/1.1 conformance.

It could, but does it happen? Do the users of your API ever need to?

>  > This is the most up-to-date reference, btw:
> Please see quotation from rfc7230 below:

I'm aware of the text; I'm one of the editors :-)

> ...
> Does this mean that OPTIONS the request
> var req = new XMLHttpRequset();
> req.open("OPTIONS", "http://www.example.org:8001");
> Should be send as "OPTIONS *" request? Could I probably get something wrong?

No, that should be sent as "OPTIONS /".

>  > That is not supported. I suspect adding support for it might create a
>  > security vulnerability for servers as it is not something they
>  > anticipate a browser to do.
> Unfortunately, I do not have enough experience in that area. But I'm
> really curious to know it better. Could you please explain how "OPTIONS
> *" request can lead to security vulnerability?
> Just to make some conclusion. Is it true, that "OPTIONS *" request in
> not supported by XMLHttpRequest class (and will not be supported in future)?
> ...

That is at least the case right now (Anne can correct me if I'm wrong).

Best regards, Julian
Received on Friday, 5 September 2014 17:54:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC