- From: Vladimir Dzhuvinov <vladimir@dzhuvinov.com>
- Date: Wed, 29 Sep 2010 17:53:24 +0300
- 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 UTC