Bug 102456

Summary: Expand PlatformCookieJar interface to allow for other ports
Product: WebKit Reporter: Mark Pilgrim (Google) <pilgrim>
Component: New BugsAssignee: Mark Pilgrim (Google) <pilgrim>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, ap, danw, fishd, gustavo, haraken, japhet, mrobinson, rakuco, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 99340    
Attachments:
Description Flags
Patch none

Mark Pilgrim (Google)
Reported 2012-11-15 19:03:40 PST
Expand PlatformCookieJar interface to allow for other ports
Attachments
Patch (11.91 KB, patch)
2012-11-15 19:06 PST, Mark Pilgrim (Google) 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Mark Pilgrim (Google)
Comment 1 2012-11-15 19:06:05 PST
Created attachment 174589 [details] Patch
Alexey Proskuryakov
Comment 2 2012-11-15 21:44:26 PST
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 3 2012-11-16 05:36:22 PST
Comment on attachment 174589 [details] Patch Clearing flags on attachment: 174589 Committed r134936: <http://trac.webkit.org/changeset/134936>
WebKit Review Bot
Comment 4 2012-11-16 05:36:26 PST
All reviewed patches have been landed. Closing bug.
Adam Barth
Comment 5 2012-11-16 08:47:54 PST
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
Comment 6 2012-11-16 09:56:04 PST
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
Comment 7 2012-11-16 10:05:20 PST
> 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
Comment 8 2012-11-16 10:29:23 PST
This may be the case indeed, depending on how the data is presented. Not showing existing cookies can be confusing, too.
Adam Barth
Comment 9 2012-11-16 11:02:15 PST
In any case, we should continue to pass this information. If you don't want to use it, please feel free to ignore it.
Note You need to log in before you can comment on or make changes to this bug.