Re: [cors] Set-Cookie / Referer / NTML / cache

On Wed, May 12, 2010 at 4:02 AM, Anne van Kesteren <annevk@opera.com> wrote:
> Thanks a lot for explaining this Jonas! In theory this seems like a bug in
> the server for not sending the appropriate Vary header, but it makes sense
> to not rely on the server for doing the right thing.
>
> However, it seems this means we end up with three separate caches. One for
> requests including user credentials, one for requests excluding user
> credentials but including Origin/Referer, and one for requests excluding
> user credentials and Origin/Referer.

I don't think that is needed. If I understand it correctly, your
concern is as follows:

1. User navigates to site A which includes an <iframe> with
src="http://foo.com/bar.cgi"
2. The browser requests "http://foo.com/bar.cgi" and sends along the
users cookies for the "foo.com" domain.
3. The foo.com server responds with a resource. The response includes
an "access-control-allow-origin: *" header.
4. The browser the resource in the internal HTTP cache for url
"http://foo.com/bar.cgi"
5. Site A then makes a CORS request to "http://foo.com/bar.cgi",
setting the .withCredentials flag to true.
6. The browser HTTP code sees the resource in the cache and returns it.
7. The CORS implementation receives a resource which includes
"access-control-allow-origin: *" and returns it to the page.

However this wouldn't work. In step 7 the CORS implementation would
reject the response as "*" is not a valid value for the
"access-control-allow-origin" header for requests that include
credentials. Also the "access-control-allow-credentials: true" header
is missing.

In order for the response to be approved in step 7, the response in
step 3 needs to include the headers:

access-control-allow-origin: A
access-control-allow-credentials: true

However if these headers are sent, I think it's ok for step 7 to
expose the response to site A.

/ Jonas

Received on Wednesday, 12 May 2010 20:19:47 UTC