RE: [cors] TAG request concerning CORS & Next Step(s)

> On Wednesday, June 24, 2009 8:25 PM, Mark S. Miller wrote:
> On Wed, Jun 24, 2009 at 8:17 PM, Adrian Bateman
> <adrianba@microsoft.com> wrote:
> On Wednesday, June 24, 2009 6:39 PM, Mark S. Miller wrote:
> > On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren <annevk@opera.com>
> wrote:
> > > I cannot comment on behalf of Opera on this. I can point out that
> Safari 4 and Chrome 2
> > > ship with it and that Firefox 3.5 will too. (No implementation will
> support redirects yet
> > > though, as I understand things.) Internet Explorer 8 supports a
> subset of the protocol.
> >
> > IIUC, the XDR subset IE8 supports does not include identified Origin
> or preflight,
> > and so avoids most of the problems created by full CORS. However, it
> still presents
> > user credentials (http auth, cookies, client-side certs, referer),
> and so still has
> > many of the same remaining ambient authority problems. Nevertheless,
> it remains a more
> > plausible starting point than identified Origin.
> IE8 strips user credentials such as cookies from XDR requests and
> supports only GET and POST. It does send the Origin header used for
> CORS and responds to Access-Control-Allow-Origin. We don't support
> preflight.
> 
> Hi Adrian, thanks for the clarification.
> 
> When you say it strips user credentials such as cookies, what about
> http auth info, client side certs, and referrer?
> 
> Regarding the Origin header, how does XDR handle redirects?

XDR is designed for accessing public resources. It passes no authentication information, requests for client certs are dropped, and since it's a one off request there is no referrer.

If I recall correctly, the Origin header is sent for each step of the redirect and each 30x response (and the final response) is expected to include an Access-Control-Allow-Origin header with either the value * or a string match of the value of the Origin header.

Received on Thursday, 25 June 2009 04:22:49 UTC