Sorry for the delayed response. On Thu, Jun 4, 2026 at 5:10 PM PhistucK <[email protected]> wrote:
> > because such a cookie is serialized (to be sent in a Cookie header) as > "Foo=Bar", > How come? Where has the first equals sign gone? > In RFC 6265bis section 5.8.3, the procedure <https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-22.html#section-5.8.3-2.6.1> for serializing a cookie for the Cookie header field specifies that the "=" typically inserted between the name and value is only emitted if the name is non-empty. > Is that the same across browsers? > > According to the latest WPT.fyi runs <https://wpt.fyi/results/cookies/name/name.html?run_id=5099827099860992&run_id=5161311435751424&run_id=5135894758817792&run_id=6213798808780800>, Chrome/Edge/Firefox/Safari now all reject the cookie "=test=2" (the change that made Chromium behave this way was announced in this PSA). Firefox/Safari also reject "=test2c", but Chrome accepts it and serializes it as mentioned above, outputting "test2c". So it seems that Firefox/Safari don't accept cookies with an explicitly empty name (like "=Foo" or "=Foo=Bar") at all, whereas Chrome/Edge reject "=Foo=Bar", but accept "=Foo" and serialize it as a cookie with empty name as specified in RFC 6265bis. It also seems that browsers currently behave inconsistently for a cookie line without any equals sign (like "Foo" or "test11"): Chrome/Edge treat it as a cookie with empty name and value "test11" (serialized as "test11"), Firefox treats it as a cookie with name "test11" and empty value (serialized as "test11="), and Safari rejects it altogether. On this topic RFC 6265bis, section 5.6 <https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-22.html#section-5.6-7.3.1> says: "If the name-value-pair string lacks a %x3D ("=") character, then the name string is empty, and the value string is the value of name-value-pair" although section 4.1.1 <https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-22.html#section-4.1.1-4> warns that servers "MUST NOT produce nameless cookies (i.e.: an empty cookie-name) as such cookies may be unpredictably serialized by UAs when sent back to the server". > ☆*PhistucK* > > > On Thu, Jun 4, 2026 at 6:41 PM Lily Chen <[email protected]> wrote: > >> Hello blink-dev, >> >> This is a PSA that the following change to cookie parsing has shipped in >> Chromium in M148: crrev.com/c/7698176 >> >> Summary: >> >> A cookie line of the form "=Foo=Bar; <attributes>" is now rejected in >> parsing, both in HTTP Set-Cookie headers and JavaScript APIs such as >> `document.cookie`. >> >> Details: >> >> Previously, a cookie line such as "=Foo=Bar" would be parsed as a cookie >> with an empty name and a value "Foo=Bar". This cookie value is ambiguous, >> because such a cookie is serialized (to be sent in a Cookie header) as >> "Foo=Bar", which appears identical to a cookie whose name is "Foo" (with >> value "Bar"). This is problematic when such an ambiguous cookie shadows a >> different cookie that the server considers more privileged. >> >> A special case of this serialization ambiguity was previously addressed >> in crbug.com/40060319 for cookie lines that might shadow "__Host-" and >> "__Secure-" prefixed cookie names, by rejecting such cookies at creation >> time. The present change applies the same approach to all such ambiguous >> cookies: a cookie line whose first semicolon-delimited substring >> (containing its name and value) begins with an equals sign and contains at >> least one other equals sign will now be rejected at parsing time. >> >> Web compatibility and interoperability: >> >> The current prevalence of "=Foo=Bar" cookies is extremely rare: a >> UseCounter >> <https://chromestatus.com/metrics/feature/timeline/popularity/5772> >> shows that about 0.00006% of page visits result in attempting to set such a >> cookie. (On the other hand, cookies simply having an empty name are a >> superset of these ambiguous "=Foo=Bar" cookies and are set on about 0.4% >> of page visits >> <https://chromestatus.com/metrics/feature/timeline/popularity/5771>. >> This change does not affect cookies with an empty name that do not contain >> an equals sign in their value.) >> >> We will follow up with proposed changes to specification text and Web >> Platform Tests. >> >> Thanks, >> >> Lily >> >> o.b.o. Chromium //net/cookies maintainers >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24OxxH6suOcDUpomtPTsQPUn_wWHHKO_Q%2BFJdcKsyLZujffw%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24OxxH6suOcDUpomtPTsQPUn_wWHHKO_Q%2BFJdcKsyLZujffw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24Oxx4D2G%3DWEYk0bdxZYveDXYgQ08jQ5yiR1kfX5iKUKgvAA%40mail.gmail.com.
