- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 22 Sep 2010 17:59:35 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Webapps WG <public-webapps@w3.org>
On 22.09.2010 16:15, Julian Reschke wrote: > On 21.09.2010 02:05, Jonas Sicking wrote: >> Hi All, >> >> CORS was recently clarified to say that error responses, such as >> 4xx/5xx responses, should not abort the various algorithms but instead >> such a response should be forwarded to, for example, the >> XMLHttpRequest implementation. >> >> However it seems somewhat strange to me to do this with responses to >> the preflight OPTIONS request. If a OPTIONS request results in a 404, >> then it seems to me that the request can not be considered successful, >> and that access to place the "real" request should not be granted. >> Otherwise we are essentially ignoring the status code and not exposing >> it anywhere, which seems strange. > > I just stumbled upon > <https://bugzilla.mozilla.org/show_bug.cgi?id=597301>, which is about a > server that 401s the OPTIONS request. > > It seems to me that CORS needs to handle this case. That is, the OPTIONS > request should be repeated with credentials. > ... Related to the same bug, see <https://bugzilla.mozilla.org/show_bug.cgi?id=597301#c8>: Also, out of curiosity: why is there a preflight request for PROPFIND anyway? CORS, 6.1.5.: "To protect resources against cross-origin access with methods that have side effects an preflight request is made to ensure that the resource is ok with the request." AS PROPFIND is a safe request, it doesn't seem to need the preflight request (per rational), so maybe it (and other safe methods) should be added to the list of "simple" methods. Speaking of which, POST is listed as "simple" but definitively *has* side effects. Maybe all of this needs to be rephrased .-). Best regards, Julian
Received on Wednesday, 22 September 2010 16:00:13 UTC