- From: Daniel Stenberg <daniel@haxx.se>
- Date: Mon, 2 Dec 2024 10:26:09 +0100 (CET)
- To: David Benjamin <davidben@chromium.org>
- cc: Watson Ladd <watsonbladd@gmail.com>, Stefan Eissing <stefan@eissing.org>, Yoav Weiss <yoav.weiss@shopify.com>, David Schinazi <dschinazi.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, 25 Nov 2024, David Benjamin wrote: > I'm not sure defining an easy / interoperable subset is sufficient. There > are several questions here: > > 1. As a server or bit of JavaScript trying to set a cookie, what cookie > values should you use for interoperability? > 2. As a user agent reacting to a Set-Cookie header or document.cookie call, > which cookie values should you accept? > 3. As a server processing a Cookie header, which cookie values must your > code be prepared to gracefully handle? I personally think an original problem source to all of this (except the fact that cookies were unspecified until RFC 6265 so there is a lot of legacy still out there) is the "double specification" because it leads to confusion and misunderstandings. What I mean with this is the way the cookie spec documents what a cookie can contain in two places, and they say different things. I repeatedly and often talk to people who cite one of those sections as "the truth". If we would make the cookie spec CLEARLY state exactly which byte values that are fine (and not fine) in names and content that would be a good start to build an undertstanding of what to expect. IMHO. Then we should work hard(er) to make sure implementations follow that. Right now, not even the big browsers have the same set of accepted byte values. Cookies that don't follow the required syntax should be ignored. We can of course not actually enforce this in any particular way so there will still be implementations that behave otherwise. -- / daniel.haxx.se
Received on Monday, 2 December 2024 09:26:15 UTC