Re: [CORS] HTTP error codes in preflight response

On Wed, Sep 22, 2010 at 7:15 AM, Julian Reschke <julian.reschke@gmx.de> 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.

First of all I assume that you're only talking about including
credentials if the 'credentials' flag is set, right?

This would require somewhat of a big change to CORS. Should we key the
'preflight result cache' on if the 'credentials' flag is set or not?
What if a preflight was made with credentials and another is needed
without, can a cached result from the previous request be used?

I'm not entirely opposed this change, but I'd like to know that it
really is a problem for servers to use the current setup. Can you
point to a server configuration that can't handle the current spec? My
understanding is that the server in the quoted bugzilla bug *is*
setting relevant headers, which means that CGI-like code is run and
the request isn't rejected by the server outright.

/ Jonas

Received on Wednesday, 22 September 2010 18:23:20 UTC