- From: Anne van Kesteren <annevk@opera.com>
- Date: Thu, 24 Sep 2009 13:17:09 +0200
- To: "Adam Barth" <w3c@adambarth.com>
- Cc: "Collin Jackson" <collin@collinjackson.com>, "Mark Nottingham" <mnot@mnot.net>, "Ian Hickson" <ian@hixie.ch>, "HTTP Working Group" <ietf-http-wg@w3.org>, public-webapps@w3.org, "Tyler Close" <tyler.close@gmail.com>
On Wed, 23 Sep 2009 17:56:05 +0200, Adam Barth <w3c@adambarth.com> wrote: > On Wed, Sep 23, 2009 at 5:34 AM, Anne van Kesteren <annevk@opera.com> > wrote: >> For simple cross-origin requests Origin would be a space-separated list >> of origins indicating the redirect chain. > > When we used this syntax for the Sec-From header, Mark Nottingham > advocated using commas to separate the origins to better align with > other HTTP headers. That would also allow multiple headers to be used I think. Since Access-Control-Allow-Origin needs to have an identical value to the Origin header I do not think that would work well. Well, it would probably work, but would make all the processing a lot more complicated than it needs to be. (I'd prefer it to just be a simple string comparison.) >> What order would be best there? > > I think the simplest thing is to list the origins in the order in > which the user agent encounters them (with adjacent duplicates > removed). That sounds reasonable. >> This is more or less on what I'm planning to go with (will wait a day >> or so with specifying to allow for feedback) unless someone has a >> better idea that keeps things relatively simple and works with the >> preflight result cache. > > That sounds reasonable to me. I don't quite understand all the > constraints we get from the preflight cache, but the rest sounds fine. We do not really get constraints, but it just does not work with redirects at the moment. To explain this: BAR redirects to BAZ BAR and BAZ grants FOO access Now when FOO requests BAR a cache entry is stored for BAZ. However, the next time FOO requests BAR the cache entry for BAZ is not used. I guess to make this work a series of request URLs has to be stored rather than just the final one. In addition origin has to become a list too. And even with this I'm afraid I'm still missing a lot of subtle things. Deferring this to later seems acceptable though so I'll leave that out for now. (Unless someone comes up with a design that does consider all these things.) -- Anne van Kesteren http://annevankesteren.nl/
Received on Thursday, 24 September 2009 11:18:15 UTC