On Tue, Jun 9, 2009 at 9:38 AM, Tyler Close<[email protected]> wrote: > On Tue, Jun 9, 2009 at 9:29 AM, Adam Barth<[email protected]> wrote: >> On Tue, Jun 9, 2009 at 9:19 AM, Tyler Close<[email protected]> wrote: >>> On Tue, Jun 9, 2009 at 12:22 AM, Adam Barth<[email protected]> 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
