- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Wed, 14 Jan 2009 13:18:04 -0800
- To: Anne van Kesteren <annevk@opera.com>, Bil Corry <bil@corry.biz>, Jonas Sicking <jonas@sicking.cc>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
On January 14, 2009 11:45 AM, Anne van Kesteren [mailto:annevk@opera.com] wrote: > On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry <bil@corry.biz> wrote: > > Jonas Sicking wrote on 1/14/2009 12:53 PM: > >> The problem I think is that the current name, 'Origin', is extremely > >> generic and so it's likely to cause confusion once we get other > >> headers containing origins. > >> What do other people think? > > > > I liked your suggestion that would marry the two: > > > > Jonas Sicking wrote on 1/12/2009 7:22 PM: > > > That said, here is a solution that might work for both Access- > Control > > > and CSRF protection: > > > > > > Site A makes a request to site B, > > > the UA adds the header "Origin: A" > > > Site B redirects the request to site C, > > > the UA adds the header "Origin: A, B" > > This would mean significant changes to the draft which would not work > well for Microsoft. Renaming I would like to consider, changing the > semantics drastically seems out of order at this point. Changing the semantics would unfortunately likely mean that IE8 would ship with behaviour that would be different to the spec. We probably won't be able to make that kind of change. I actually don't think that the generic name is a problem as long as the CSRF solution uses a different name for a different meaning. The value really is an Origin and could potentially be used for more than just participation in the Access Control negotiation. It could still be meaningful in other scenarios in future which would otherwise now have to define a new header with the same meaning. If the header name does change then we will cost out the work to make this change to see if we can do it. Clearly changing the strings used in the browser is a relatively constrained change but I'm concerned about the amount of churn in our test automation infrastructure that would be required and the risks involved. Cheers, Adrian.
Received on Wednesday, 14 January 2009 21:19:46 UTC