- From: Odin Hørthe Omdal <odinho@opera.com>
- Date: Thu, 28 Feb 2013 15:48:14 +0100
- 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 UTC