W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 17 Jun 2009 22:35:46 +0000 (UTC)
To: "Mark S. Miller" <erights@google.com>
Cc: Anne van Kesteren <annevk@opera.com>, Tyler Close <tyler.close@gmail.com>, Adam Barth <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.62.0906172227230.16244@hixie.dreamhostps.com>
On Wed, 17 Jun 2009, Mark S. Miller wrote:
> >>
> >> Does an xhr from a sandboxed unique origin iframe carry any 
> >> credentials in the sense in which we've been using in this thread:
> >> * HTTP auth info
> >> * cookies (I think the text implied not, but I'd like to check.)
> >> * client-side certs

Same-origin XHR will just fail with a sandboxed unique origin iframe.

If you mean cross-origin XHR2, then it will work the same as for any other 
cross-origin situation, which I believe means "it depends on the 
credentials flag", but I can't see where that is initialised so I don't 
know what the default is.


> >> * REFERRER

Changing the origin doesn't affect the referrer (that is, it doesn't 
affect the "document's current address" of any document), so assuming that 
XHR2 uses the 'fetch' definition from HTML5 or has equivalent text that 
invokes the "document's current address" to set Referer (sic), the 
referrer will be included.


> >> * identified Origin (clearly not if I understand the spec)

Right, this will be serialised as "null".


> >> If it does transmit any of these currently, are there any objections 
> >> to revising the spec so that it doesn't?

Why?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 17 June 2009 22:51:53 GMT

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