Re: Handling Cookies is a Minefield

So primarily our concern is about the robustness principle and
backwards-compatibility? This isn't the first time, is it :(

Short of creating a new 'Set-Cookie2' and 'Cookie2' response/request header
pair that only allow a very well-documented set of characters, there is no
obvious solution.

Frankly, I'd be happy to see the creation of a 'Set-Cookie-Ascii' and
'Cookie-Ascii' header pair...

On Mon, Dec 2, 2024 at 1:31 AM Daniel Stenberg <daniel@haxx.se> wrote:

> 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
>
>

-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt