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

2014-09-05 20:53 GMT+03:00 Julian Reschke <julian.reschke@gmx.de>:

> 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:
>>
>>> http://httpwg.github.io/specs/rfc7230.html#asterisk-form
>>>
>> 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
>

Thank you for your answer! It seems to be clear now.

I am a little unsure if users will really need to make "OPTIONS *" request
by using XMLHttpRequest class. It's a new feature. We will see it in time.
=)

Sincerely yours,
Valery Kotov