In D23376#517889, @dfaure wrote:

I admit that I'm quite lost between the Qt/KDE differences, what normalization does, and what a dot in front means. Something sounds fishy if normalizing twice isn't a no-op, indeed.

According to he specification, a Set-Cookie header can omit the Domain field. A missing Domain means that the browser must return the cookie only to the origin server. This means that a cookie received from abc.xyz.com with Domain=abc.xyz.com will be treated differently from a cookie received from the same host but with no Domain field: in the first case, the cookie will be returned also to, for example, www.abc.xyz.com; in the second case it will be returned only to abc.xyz.com. The specification also says that if the Domain field starts with a dot, the dot should be ignored: Domain=.abc.xyz.com is treated as Domain=abc.xyx.com.

A browser has to choose how to internally represent distinguish a cookie with a Domain field from a cookie with no Domain field. Unfortunately, QWebEngineStore and KCookieJar made two different choices:

• KCookieJar leaves an empty domain as it is and stores the origin host separately. For non-empty domains, a leading dot is added if it's not already there
• QWebEngineCookieStore uses a normalized QNetworkCookie to store cookies. In a normalized QNetworkCookie, the domain() function never returns an empty string: if the cookie had a Domain field, domain() returns a string starting with a dot; if the cookie didn't have the domain field, domain() returns the origin host, without a leading dot. (QNetworkCookie::normalize also replaces an empty Path with a /, but this doesn't causes issue since KCookieJar does the same).

I agree that one could expect that calling normalize twice would be a no-op (I thought so, too, before discovering, by chance, this bug). On second thought, however, there's a reason it can't be so. What normalize does is essentially:

• if the domain is empty, make it equal to the host given as argument with no leading dots
• if the domain is not empty, add a leading dot to it if it's not there.

After calling normalize() once, the domain won't be empty anymore, so the second call will simply add a leading dot to it. To avoid this behavior, normalize() should assume that a non-empty domain always starts with a dot, but can't do so (I guess) because the specification allows it. I think that the documentation for normalize() should emphasize this fact.

Another difference between KCookieServer and QWebEngineCookieStore which creates issues for Konqueror is that KCookieServer::addCookies requires the origin URL, but QWebEngineCookieStore doesn't provide it. What Konqueror currently does is to use the domain() field as origin host: this is correct if the cookie had no domain field (as explained above) and seems to be working in other cases, too. Actually, according to the specification, the origin domain shouldn't be needed at all for cookies with a domain field: however, if I understand correctly its source code, KCookieJar uses it to derive a key for the hash it stores cookies in.

I wonder whether it could be a good idea to file a bug report with Qt to ask to pass the origin URL in the QWebEngineCookieStore::cookieAdded signal.

"if the domain is not empty, add a leading dot to it if it's not there" << that's a weird thing to do, if the spec says leading dots are just superfluous.

This means you could have your own normalize function (which doesn't prepend a dot), but I can see how that might just be more confusing.

In D23376#517993, @dfaure wrote:

"if the domain is not empty, add a leading dot to it if it's not there" << that's a weird thing to do, if the spec says leading dots are just superfluous.

Sorry, I made a mistake: according to the documentation for QNetworkCookie, it follows a specification that is different (older?) than the one I was looking at. According to the correct specification, the domain, if not empty, must start with a dot. This is what distinguish a domain explicitly set from a missing domain (which means the origin host).

OK, then it's not just normalizing, but translating from the HTTP header to the internal representation. That can indeed only happens once.

Then you need to reason with "which code works with the http header" and "which code works with the internal representation".

In D23376#518013, @dfaure wrote:

OK, then it's not just normalizing, but translating from the HTTP header to the internal representation. That can indeed only happens once.

Not exactly. You can create a QNetworkCookie in two ways: parsing the Set-Cookie header, using the static QNetworkCookie::parseCookies() function or creating an empty cookie and setting its fields manually. I think normalize in this context means something like: fill the empty fields (domain and path, taking the values from the url passed as argument) and make sure the domain starts with a dot.

Then you need to reason with "which code works with the http header" and "which code works with the internal representation".

I think the workflow is supposed to be: receive the Set-Cookie header -> parse it using parseCookies -> call normalize -> forget the HTTPl representation and work only with the internal one. If you need to use the cookie again in an HTTP header, call QNetworkCookie::toRawForm and you have the header ready. Unfortunately, for Konqueror we need to work with two internal representations: one for QNetworkCookie and one for KCookieJar.