W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2013

Re: CORS: Requirement for HTTP 200 response on preflight is not web-compatible and doesn't seem to be interoperably implemented

From: Odin Hørthe Omdal <odinho@opera.com>
Date: Thu, 28 Feb 2013 15:48:14 +0100
Message-Id: <1362062894.24123.140661198198873.28A3D4F2@webmail.messagingengine.com>
To: public-webappsec@w3.org
On Thu, Feb 28, 2013, at 03:24 PM, Boris Zbarsky wrote:
> CORS currently requires that a non-HTTP-200 response to a preflight be 
> treated like a network error.
> 
> When I changed Gecko to do that, we discovered that at least GitHub's 
> API sends 204 responses to preflights.  Furthermore, it appears that 
> neither Trident nor WebKit enforce this restriction to 200-only (and in 
> fact it's not clear to me whether they enforce any restrictions at all; 
> needs testing).
> 
> I am changing Gecko back to our old behavior of accepting any 2xx 
> response to a preflight, but the spec also needs to be changed.  It's 
> not clear to me what the spec should say here; possible options are "any 
> 2xx response" or "200 or 204" or something else.  Feedback from WebKit 
> and Trident folks on what they actually do is welcome.

There is a test for this in our testsuite:

http://test.s0.no/w3c-tests/webappsec/tests/cors/submitted/opera/staging/status-async.htm

WebKit does not restrict it to anything. My IE10 VM doesn't work anymore
so I can't check that right now.

Anyway, opening up for 2xx seems quite a-ok IMHO. I'd be more reluctant
to go the full buggy WebKit-route in the spec.

-- 
  Odin Hørthe Omdal
  odinho@opera.com
Received on Thursday, 28 February 2013 14:48:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 28 February 2013 14:48:37 GMT