W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [CORS] HTTP error codes in preflight response

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 22 Sep 2010 11:22:26 -0700
Message-ID: <AANLkTikMFwFade0hwuLbtr+R66ASQu_gPB4Z9PpPZK7H@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Webapps WG <public-webapps@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC