- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 23 Sep 2010 11:17:54 +0200
- 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 container. 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