After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 691840 - cookies sometimes normalize domain
cookies sometimes normalize domain
Status: RESOLVED NOTABUG
Product: libsoup
Classification: Core
Component: Misc
unspecified
Other Mac OS
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2013-01-16 10:49 UTC by O Gorter
Modified: 2013-08-25 13:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed path to only set domain through soup_cookie_set_domain and normalize there (2.62 KB, patch)
2013-01-16 10:49 UTC, O Gorter
none Details | Review

Description O Gorter 2013-01-16 10:49:29 UTC
Created attachment 233578 [details] [review]
proposed path to only set domain through soup_cookie_set_domain and normalize there

In soup_cookie_parse() it will ensure the domain is prefixed with a dot "." but there are plenty of cases where this does not happen, like just soup_cookie_new().

That means writing and reading back a cookie is not idempotent and might result in duplication that acts "weird" because they are two distinct cookies that match equal. It breaks webkit behavior when javascript manipulates cookies.

A cookie from webkit comes in as domain=test.host.com, after writing and reading back, the domain becomes .test.host.com, now we have two cookies in the cookie jar that ought to be equal and result in a duplicate.

I am no expert on cookie behavior and this dot thing, but I fixed this by having soup_cookie_set_domain() normalize the expectations on domain names and only set the domain through this function, even internally. See attached patch.
Comment 1 Dan Winship 2013-02-06 14:26:34 UTC
(In reply to comment #0)
> That means writing and reading back a cookie is not idempotent and might result
> in duplication that acts "weird" because they are two distinct cookies that
> match equal. It breaks webkit behavior when javascript manipulates cookies.

Is there a specific webkit test this is breaking? And have you made sure that the patch doesn't break any webkit tests that are currently passin?
Comment 2 O Gorter 2013-03-04 12:42:15 UTC
As activevideo we have a different kind of webkit platform. Webkit-gtk or efl use a persistent libsoup cookie backend. Our platform does not have permanent storage, so we "manually" serialize the cookies. AFAIK we are the only one using these two functionalities together. So there is no webkit test breaking. However I cannot verify my patch does not break anything downstream, so I understand some reluctance to just apply this patch.

Fact is that either 1) libsoup should not make any assumptions on cookies and the prefixed dot. Or 2) it should make the same assumptions in all cases. This half thing is weird, and can put libsoup in a state where it thinks it has more cookies then it actually has. A version with the dot, and a version without. And it does not update both versions, so old cookies linger on when iterating all cookies, but are invisible when doing a lookup.

Because it seemed to me libsoup internally wants to assume cookie domains are prefixed with a dot, I just patched the code such that there are not any cases left where that assumption is broken. If this is not an assumption libsoup wants to make, then the serialization functions should probably leave the cookie domains alone too...
Comment 3 Dan Winship 2013-08-25 13:46:54 UTC
Sorry for the delay in dealing with this.

I've added to the soup_cookie_new() docs clarifying the semantics of the @domain parameter:

+ * If @domain starts with ".", that indicates a domain (which matches
+ * the string after the ".", or any hostname that has @domain as a
+ * suffix). Otherwise, it is a hostname and must match exactly.

The API needs to be able to create both kinds of cookies, so this distinction is needed. (Cookies with no domain attribute are host-only cookies, which get stored without the preceding ".".)

So in your case, the fix is that whatever is creating the cookies needs to add the "." prefix itself.