Re: [cors] Failed sharing check and cookies

On Mon, Oct 10, 2011 at 9:20 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Tue, 11 Oct 2011 12:53:35 +0900, Anne van Kesteren <annevk@opera.com>
> wrote:
>>
>> Currently if a resource sharing check fails cookies will still be set for
>> a credentialed request similarly to how they would be with <form> or <img>.
>> However, it seems that HTML defines for <img crossorigin> that the UA must
>> act as if there was no response at all. That does not work of course for the
>> normal <img> case where the server could still opt in to sharing, but would
>> work for XMLHttpRequest.
>>
>> I think I will try to adopt that stricter behavior. Please speak up if you
>> disagree.
>
> To make it more clear, currently if you XHR from A to B with withCredentials
> set to true, and B does a Set-Cookie, cookies will be set for B regardless
> of whether the resource sharing check for B passes or fails.
>
> If you do <img crossorigin> from A to B, and a resource sharing check for B
> fails, cookies must not be set (per my reading of the HTML specification).
>
> The question is whether XHR should align with this behavior.
>
>
> On IRC sicking brought up this might be harder for Gecko because of their
> HTTP library implementation (they currently do not conform for <img
> crossorigin> therefore). Is this an issue for WebKit? For Opera it does not
> matter, but we prefer the stricter behavior.

I don't necessarily dislike this idea, though I think we should
specify it on a CORS level rather than separately for <img
crossorigin>, XHR etc.

This will however be non-trivial to implement in Gecko as our HTTP
layer does the cookie handling, but the CORS implementation is built
on top of the HTTP layer. It's just software, so it's certainly
fixable. But I wanted to make sure that other browsers are able to
make this change too.

/ Jonas

Received on Tuesday, 11 October 2011 04:27:01 UTC