Re: Handling Cookies is a Minefield

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?

As the page notes, when (3) is not equal to or a superset of (2), you get
problems. If you do not gracefully handle a cookie that the user agent
might accept, you can get yourself wedged.

Ideally, the answer to all three of these would be the same. But we've also
left cookie handling ill-defined for so long that it may not be possible.
Practically speaking, I suspect the answer to (1) will be "ASCII-only" for
quite some time, given the situation outlined in the blog. It seems too
many web frameworks reject non-ASCII cookies. But it sounds like tightening
(2) to match is very challenging and might have a disproportionate
compatibility impact on clients in some non-English-speaking areas
<https://issues.chromium.org/u/1/issues/40061459#comment24>. Given that
reality, I suspect we need to widen (3) to match that and fix the
server frameworks.

On Mon, Nov 25, 2024 at 9:55 AM Watson Ladd <watsonbladd@gmail.com> wrote:

> On Mon, Nov 25, 2024 at 5:05 AM Stefan Eissing <stefan@eissing.org> wrote:
> >
> >
> >
> > > Am 25.11.2024 um 10:41 schrieb Yoav Weiss <yoav.weiss@shopify.com>:
> > >
> > > Thanks for sharing this, David!
> > >
> > > I'm wondering if folks have thoughts regarding: "In truth, the true
> fix for this issue almost certainly lies in the IETF HTTP Working Group
> updating the cookie specification to both align with itself and to be
> strict on how systems handling cookies should behave. Whether non-ASCII
> characters should be allowed should be identical regardless of whether
> server-side or on user agents. "
> > >
> > > It seems to me that regardless of what we'd specify here, browsers
> won't be able to ship further restrictions without breaking *some*
> websites, and that certain non-ascii chars may be easier to block than
> others. So I think experimentation and implementation would have to guide
> any efforts on that front.
> >
> > Agree. I would also like to point out that a standard is about how
> cookie *should* work sanely on the interwebs to the benefit of overall
> safety and interoperability. That implementations allow for quirks under
> certain conditions/configurations has always been the case with standards
> meeting the real world.
> >
> > We do not spec HTTP/1.x to allow for \n only terminated header lines,
> just because there are deployments that do this and implementations that
> can be configured to accept it.
>
> We can also write an informational doc saying what the easy and
> interopreable subset is.
>
> >
> > Cheers,
> > Stefan
> >
> > > On Sat, Nov 23, 2024 at 11:36 AM Daniel Stenberg <daniel@haxx.se>
> wrote:
> > > On Thu, 21 Nov 2024, David Schinazi wrote:
> > >
> > > > April King just published a really cool blog post [1] about cookies.
> In
> > > > particular, it mentions some ways in which our cookie specifications
> could
> > > > be improved. If you're interested in cookies, I highly recommend
> giving it a
> > > > read.
> > >
> > > Thanks David. I would like to just mention that I have previously
> raised
> > > several of those remarks against the cookie spec(s):
> > >
> > >   - the inexplicable different syntaxes for the two ends. I seem to be
> the only
> > >     person who insists that this is still a bad idea for a spec and I
> have
> > >     accepted my defeat.
> > >
> > >   - which octets should be allowed in identifiers and content - even
> very
> > >     recent 6265bis edits have changed these so right now I can't even
> say where
> > >     we are.
> > >
> > > --
> > >
> > >   / daniel.haxx.se
> > >
> >
> >
>
>
> --
> Astra mortemque praestare gradatim
>
>