W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: CORS redirect behavior proposal

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>
Message-ID: <op.u0rdmvse64w2qv@annevk-t60>
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 GMT

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