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
