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

Re: [CORS] Suggested HTTP error codes on forbidden origin, unsupported method, etc.?

From: Vladimir Dzhuvinov <vladimir@dzhuvinov.com>
Date: Wed, 29 Sep 2010 17:53:24 +0300
Message-ID: <AANLkTim=F_W7XjwG0NTCqtN5zoxqu2q8LZ34z=Sq+Xr-@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: public-webapps <public-webapps@w3.org>
On 29 September 2010 13:48, Anne van Kesteren <annevk@opera.com> wrote:
> On Sun, 26 Sep 2010 12:01:59 +0200, Vladimir Dzhuvinov
> <vladimir@dzhuvinov.com> wrote:
>>
>> I looked at various CORS examples, but they were not particularly
>> instructional on how the server should respond if the origin is not
>> allowed or some other check fails. The CORS spec also seems to
>> deliberately avoid this and leave it to the implementers.
>>
>> For my CORS servlet filter I'm planning to respond with
>>
>> HTTP 403 Forbidden - on a origin that is not allowed
>> HTTP 405 Method not allowed - on an unsupported method
>>
>> Does this make sense?
>>
>> How should the server respond if it receives a custom header that is
>> not listed as supported?
>
> I suppose we could give advice, but it does not really matter as the client
> will always treat it as a network error to make it indistinguishable from
> other failures.

Yes, I see now. I just had this uncertainty, when I was coding the
filter, as to how to respond sensibly in case of a CORS exception.
While terminating the request silently wouldn't matter to end users, I
thought providing a meaningful error code and message might help
client-side developers to debug CORS calls with tools like FireBug (at
least, that helped debugging my own apps ;-)

-- 
Vladimir Dzhuvinov :: software.dzhuvinov.com
Received on Wednesday, 29 September 2010 15:55:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT