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: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 28 Feb 2013 14:17:34 -0500
Message-ID: <512FAD4E.2010903@mit.edu>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
On 2/28/13 2:10 PM, Bjoern Hoehrmann wrote:
> * Boris Zbarsky wrote:
>> 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.
> It seems this requirement has been added in the 2012 draft, so the more
> interesting question would by what this is trying to accomplish.

The goal of prohibiting non-2xx responses (which did not use to be the 
case and which WebKit still allows) is to fail safe: if there's a server 
error that should not be viewed as a successful preflight.

The specific restriction to 200 only no one is arguing for, so I'm not 
sure it's worth discussing at all.  The only question is what should 
happen for response codes in the 2xx range that are not 200 or 204.

Received on Thursday, 28 February 2013 19:18:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:31 UTC