[Webkit-unassigned] [Bug 182328] [SOUP] Ensure domain is valid when converting a WebCore Cookie to Soup

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Feb 2 01:48:17 PST 2018


https://bugs.webkit.org/show_bug.cgi?id=182328

--- Comment #6 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #2)
> Comment on attachment 332753 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=332753&action=review
> 
> > Source/WebCore/platform/network/soup/CookieSoup.cpp:66
> > +    // soup_cookie_new() will handle the given domain as a hostname if it doesn't start with '.'.
> > +    auto cookieDomain = domain.utf8();
> > +    if (cookieDomain.length() && !g_hostname_is_ip_address(cookieDomain.data()) && cookieDomain.data()[0] != '.')
> > +        cookieDomain = makeString('.', domain).utf8();
> 
> I don't know. RFC 2965 says:
> 
>    Domain=value
>       OPTIONAL.  The value of the Domain attribute specifies the domain
>       for which the cookie is valid.  If an explicitly specified value
>       does not start with a dot, the user agent supplies a leading dot
> 
> The dot is actually significant and probably shouldn't change when
> converting from a WebCore::Cookie to SoupCookie. I'm worried that the dot
> should have already been prepended somewhere else.

You were indeed right, I missed an important point: "If an *explicitly* specified value". The spec also says:

"Defaults to the effective request-host.  (Note that because
there is no dot at the beginning of effective request-host,
the default Domain can only domain-match itself.)"

So, it can indeed be a hostname, when omitted in Set-Cookie header. In the case of user provided cookie, we should probably keep what the user is providing. So, yes this is not the right place to do this, because we don't know if that cookie came from the API or not. In the case of WebDriver, I'll file an issue in the spec to clarify if we should add the dot or not. I'll revert this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180202/58e65009/attachment.html>


More information about the webkit-unassigned mailing list