- From: Tyler Close <tyler.close@gmail.com>
- Date: Tue, 9 Jun 2009 09:50:29 -0700
- To: Adam Barth <w3c@adambarth.com>
- Cc: "Mark S. Miller" <erights@google.com>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
On Tue, Jun 9, 2009 at 9:38 AM, Tyler Close<tyler.close@gmail.com> wrote: > On Tue, Jun 9, 2009 at 9:29 AM, Adam Barth<w3c@adambarth.com> wrote: >> On Tue, Jun 9, 2009 at 9:19 AM, Tyler Close<tyler.close@gmail.com> wrote: >>> On Tue, Jun 9, 2009 at 12:22 AM, Adam Barth<w3c@adambarth.com> wrote: >>>> Please send "Origin: null" in these cases. The problem with omitting >>>> the origin header is that the server can't tell if the request comes >>>> from a legacy client or if the header was removed in transit. >>> >>> For the GuestXMLHttpRequest scenario, why should the server >>> distinguish between these two cases? >> >> In one case, the request is coming from the non-guest part of the page >> in a legacy browser. > > And so isn't using GuestXMLHttpRequest. > >> In the other case, the request is coming from >> the guest part of the page in a supporting browser. > > And so is using GuestXMLHttpRequest. > >> Isn't the whole >> point of this feature to be able to distinguish guest and non-guest? > > So requests from XMLHttpRequest have an Origin header, and requests > from GuestXMLHttpRequest don't. The server should treat requests > coming from GuestXMLHttpRequest as bits arriving from an unknown > client (ie: a "guest"), and so only authorize them based on > information explicitly included in the request. The cases here are simpler than in your Origin work for XMLHttpRequest, since the browser does not add any user credentials to the request. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Tuesday, 9 June 2009 16:51:04 UTC