Details
-
Bug
-
Resolution: Invalid
-
P3: Somewhat important
-
None
-
5.11.2
-
None
Description
I've been debugging why my network application was not getting the correct HTTP responses with a few websites and it turns out it's because some cookies being set from requests from the Set-Cookie header were not making it to the QNetworkCookieJar.
Turns out that the reason is that some of these cookies don't specify a domain attribute at all. Ex:
Set-Cookie: cookie_name=cookie_value; path=/
It seems a browsers behavior when they see this type of cookie is to just assume the domain should be the host from the original request.
In QNetworkCookiePrivate::parseSetCookieHeaderLine() I can see that if Qt does not find the domain attribute, the setDomain() call is skipped and no domain is set for the cookie.
When the cookie is supposed to get added to a QNetworkCookieJar, the validateCookie() will return false because of the empty domain() and the cookie will never get added to the jar and hence will never get sent in subsequent requests.
Looking at RFC 6265 they seem to have conflicting rules:
4.1.2.3 - "If the server omits the Domain attribute, the user agent will return the cookie only to the origin server."
To me this is saying that the cookie should not be ignored like Qt is doing and should be setting the cookies domain to the host domain in this case.
5.2.3 - "If the attribute-value is empty, the behavior is undefined. However, the user agent SHOULD ignore the cookie-av entirely."
I'm guessing in the this case they mean if there is no value for the domain attribute itself? Ex:
Set-Cookie: cookie_name=cookie_value; domain=; path=/
I use manual cookie handling with QNAM, so to work around this bug in my code is as simple as calling reply.header(QNetworkRequest::SetCookieHeader) and check if any of the cookies do not have a domain() and if so just set it to the host domain before trying to insert it into the QNetworkCookieJar.