Re: Handling Cookies is a Minefield

On Mon, Dec 02, 2024 at 08:35:06PM +0100, Daniel Stenberg wrote:
> A challenge with cookies in general is that there are so many different and
> separate implementations to check and fix, rather than just a few major
> libraries.

Definitely, an in fact there are plenty of applications relying on
borkenness of implementations :-(  I remember 15 years ago seeing an
application blindly concatenating the cookies received by the client
with its own, resulting in extending the cookie header field on each
round trip by multiplicating the session cookie. When we tried to
work around it by deleting the set-cookie response header matching
that cookie when it was already present, the application stopped
working because some part of it was counting the number of duplicate
cookies which couldn't be one...

> > Frankly, I'd be happy to see the creation of a 'Set-Cookie-Ascii' and
> > 'Cookie-Ascii' header pair...
> 
> Set-Cookie2 was attempted (and failed) in RFC 2965 (published in 2000). I
> don't think would be any easier to introduce a new header for this now.

I don't believe in this either. The only way to fix cookies is to gain
adoption, and for this, a new specification must offer some convenience
to application developers.

Among the needs I've identified quite a few times in the field (without
any judgement, let's stay courteous) are:
  1. the difficulty to store binary contents
  2. the difficulty to store arbitrarily long cookies
  3. the difficulty to purge all cookies associated with a given session
  4. the difficulty to make session cookies automatically expire after an
     idle time or a duration.

1. can be solved using base64, which inflates the contents by 33%,
   often starting to raise questions about 2.
2. can be worked around by splitting contents into multiple cookies,
   but when they're sent back, generally aggragated into a single
   request header field, sometimes that field remains too large for
   the server (or gateways before it)
3. that one is not trivial, particularly in multi-component applications
   where no single element dealing with logout knows all cookies, which
   makes applications want to go to 4.
4. if you put a date on a cookie, it's stored, and session ones do not
   expire by default (which is a problem for clients that are always
   connected). It's a well-known problem in load balancers where you
   store assigned servers in a cookie and don't want the same server
   to be assigned forever, otherwise it takes ages for a newly added
   server to be used, particularly after a temporary outage. The
   work-around consists in placing the idle+lifetime info in the cookie
   value itself.

If a new spec would address these shortcomings *without trying to
replace* "cookie/set-cookie", we could imagine that it would start to
get some adoption. Some info would be duplicated for some time, until
the point where it's considered sufficient to place most extra info
in the new version only. A typical first use case could simply be to
enumerate all known cookie header fields and the session's duration/idle
using the new format so that the application can bypass complex tricks
when facing these. And these values wouldn't be aggregated by default
(particularly not around ';' but using ',' instead) so that we wouldn't
have to deal forever with the "set-cookie" exception in our parsers nor
with the "cookie" exception in compressors.

BTW I think that using these to store session variables only would
solve quite some difficulties without risking to engage down the
painful route of stored cookies. We could call these "Session-var"
for example, and reserve a few variable names for meta-info such
as the creation date, and the lifetime for all variables at once
etc.

It could rely on a large alphabet, e.g. something around base240 or
base248 that passes over 8-bit except for a few HTTP delimitors (LWS,
comma, quote, CR, LF, NUL), resulting in 3 to 6% inflation, not 33.

I'm pretty sure that something around this could have some success in
complement to existing cookies and possibly permit to take over them
in 15-20 years to the point where disabling cookies in browsers
continues to work with the vast majority of sites.

Just my two cents ;-)
Willy

Received on Tuesday, 3 December 2024 06:24:48 UTC