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

Re: [CORS] HTTP error codes in preflight response

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 23 Sep 2010 11:17:54 +0200
Message-ID: <4C9B1B42.5010303@gmx.de>
To: Jonas Sicking <jonas@sicking.cc>
CC: Webapps WG <public-webapps@w3.org>
On 22.09.2010 21:42, Jonas Sicking wrote:
> ...
> It's not a problem if servers use OPTIONS for things other than CORS
> and that those things require authentication. At some point you have
> to inspect the OPTIONS request anyway to determine if it's an OPTIONS
> request made for CORS, or one made for the other functionality. As
> long as you do that check before the authentication check you should
> be fine.
> ...

In servlet containers, (HTTP) authentication is usually done by the 

You *can* probably configure them to handle OPTIONS without 
authentication, but you can't do it selectively based on the actual 
message (headers, body).

Once the request reaches the servlet, you *could* return 200 or 401 
based on context, but it would be hard to send the right challenge, as 
that one is configured in a different layer.

So to me this sounds like broken by design. It would be less of a 
problem if this wasn't OPTIONS but something new instead.

Also, somewhere else it was pointed out that OPTIONS differs from 
PROPFIND in that PROPFIND can have a body. So can OPTIONS (see, for 
instance, <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.6.4>).

Best regards, Julian
Received on Thursday, 23 September 2010 09:18:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC