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
