internal whitespace in cookie names and values

[bagder]

When it comes to the client side parsing of cookies, both RFC 6265 as well as 6265bis-10 state:

the algorithm strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace),

1. We already previously discussed how browsers accept TABs in Set-Cookie: lines in general.
2. Firefox and Chrome both reject cookies with an "internal TAB", like if the name is self\tdestruct (I use \t here as a symbol for ASCII 9).
3. Firefox strips off TABs from the content so that name=one\ttwo becomes name=onetwo
4. Chrome seems to completely reject cookies with TABs in the content

Okay, this is but observations done on two widely used implementations but still.

How should a client implementation treat TABs in names and content?

[sbingler]

I believe you're correct that compliant UAs should allow cookies such as f\too=b\tar.

As for why Chrome rejects these:
There have been some changes regarding disallowed CTL chars in cookies and HTABs were a part of that at first. The spec has since been updated to allow for HTABs #1589 but Chrome hasn't caught up quite yet.

[bagder]

Isn't it weird to include that in a spec when two large implementers clearly don't adhere?

Is it not closer to reality to rather document that TABs embedded in names or content should not be used as they are not interoperable?

[sbingler]

Chrome intends to implement this behavior, Safari does already.

While I'm not sure if Firefox intends to implement it https://bugzilla.mozilla.org/show_bug.cgi?id=1702031 seems to indicate they do.

[bagder]

1. Obviously Firefox already accepts TABs in Set-Cookie:
2. The description in Firefox's bugzilla entry still says "0x01 through 0x09, 0x0b through 0x0c, and 0x0e through 0x1f cause the cookie to be rejected if they are present in the name"

I think this change of the spec was reckless and I object to it.

[sbingler]

What are your concerns?

[bagder]

That we stick to an interoperable syntax: I would prefer to discourage use of tabs in cookie names and content.

Clearly we cannot use cookies today with tabs like that - even though RFC 6265 has been around for over a decade, and we are not likely to be able to safely use them for it for a long time either (due to slow updates and the long tail of clients etc).

To me, it would make sense to say SHOULD NOT use to signal to the world that they are not interoperable like this.

[sbingler]

Seems worth looking into more, I'll reach out to the change's author and get a better idea of their intentions.

[bagder]

curl will reject cookies with "internal" tabs in name or content, starting in next release.

[sbingler]

After

• speaking with the change's author

• testing much older versions of Chrome

• considering that each of 3 majors browsers does something different

• and noting that disallowing HTABs brings us a tiny bit closer to aligning UAs' syntax with servers' syntax (4.1.1)

I'm slightly inclined to agree that HTABs should not be allowed as internal whitespace in cookies.

It's important to note however that earlier revisions of the draft were fairly clear in allowing any internal whitespace (which includes HTABs by the spec's definition) and only recently (~2 years) has that changed to be more restrictive.

I'm generally hesitant to reduce the allowed character set for UAs but given that Chrome has been disallowing this for over 4 years (intentionally or otherwise) I think the concern of new breakage is probably moot from our side.

I personally don't see a compelling use case to allow HTABs, but I hope that some of the other UAs could add their thoughts. @dveditz for Mozilla, @annevk for Apple

[annevk]

I don't see the problem here. A non-leading-non-trailing 0x09 is a perfectly valid header value byte. Seems rather arbitrary to restrict it and could break applications. I thought the HTTP WG was pretty firmly against backwards-incompatible changes?

Do implementations uniformly reject for the other CTLs?

(I'm reminded of how we never quite ended up with a satisfactory resolution to what a header value can contain as https://fetch.spec.whatwg.org/#header-value is quite a bit more open-ended compared to recent HTTP RFCs.)