Bug 102456 – Expand PlatformCookieJar interface to allow for other ports

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Mark Pilgrim (Google)]

Expand PlatformCookieJar interface to allow for other ports

[Mark Pilgrim (Google)]

Created attachment 174589 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 174589 [details]
Patch

I understood why cookiesEnabled needs these arguments, and it's clear why cookieRequestHeaderFieldValue() does, too. What about getRawCookies? Isn't that a Web Inspector thing, which should be exempt from checks?

[WebKit Review Bot]

Comment on attachment 174589 [details]
Patch

Clearing flags on attachment: 174589

Committed r134936: <http://trac.webkit.org/changeset/134936>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Adam Barth]

Alexey, I'm sorry your questions weren't answered before this patch was landed.  Let me try to answer them now.

> I understood why cookiesEnabled needs these arguments, and it's clear why cookieRequestHeaderFieldValue() does, too. What about getRawCookies? Isn't that a Web Inspector thing, which should be exempt from checks?

These functions all need this information for the same reason.  In Safari, third-party cookie blocking only affects writing to the cookie jar.  In Chromium (and in some other browsers), third-party cookie block affects both reading and writing the cookie jar.  In order for cookieRequestHeaderFieldValue and getRawCookies to read the cookie jar accurately, Chromium needs to know the first party URL so that it can determine whether to block various cookies because of its third-party cookie blocking policy.

[Alexey Proskuryakov]

Yes, I understand this. What I'm saying is that getRawCookies appears to be used in Inspector only, and thus it's unclear why it needs the checks.

It is very clear why cookieRequestHeaderFieldValue needs the check - this function is used to build a cookie header for WebSockets.

[Adam Barth]

> Yes, I understand this. What I'm saying is that getRawCookies appears to be used in Inspector only, and thus it's unclear why it needs the checks.

It seems like the inspector for a given document should show the cookie related to that document in another context.  I would expect developers to be confused if the inspector showed cookies that weren't actually sent over the wire because they were blocked.

[Alexey Proskuryakov]

This may be the case indeed, depending on how the data is presented. Not showing existing cookies can be confusing, too.

[Adam Barth]

In any case, we should continue to pass this information.  If you don't want to use it, please feel free to ignore it.