Re: New Cookies Draft

Hi Anne,

On Tue, Dec 10, 2024 at 10:29:46AM +0100, Anne van Kesteren wrote:
> There's several goals we had in mind. In order of importance:
> 
> - Improving the integration between Cookies and a myriad of web
> platform specifications, such as Fetch, HTML's document.cookie, and
> Storage Access API.
> - Thereby better formalizing how "third-party" cookies are to be handled.
> - Integrating and standardizing the Partitioned attribute, assuming agreement.

OK!

> But I would not be opposed to further additions that reach agreement
> and are relatively straightforward to incorporate.

Of course, that's naturally a prerequisite.

> In particular your
> "logout" use case below seems similar to Yoav's Delete-Cookie header
> idea and it probably is too hard to clear cookies currently, so that
> seems worth looking into.

Ah you're right, I forgot about this one!

> > For example I'd really like to have a way for a server to clear all
> > (session?) cookies for the current site and possibly a path, the
> > typical "logout" button. I know there's no way to guarantee that,
> > but if we could do something like:
> >
> >   set-cookie: *=; Expires=Thu, 01 Jan 1970 00:00:00 GMT
> >
> > and let the browser flush all the cookies it knows for that site, that
> > would be a huge step into helping logout clear cookies. [ ... ]
> >
> > Another one would be to see if UAs support an expires between quotes,
> > because that could be the way forward to maybe one day support folding
> > multiple set-cookie header fields into a single, comma-delimited one.
> 
> Would this enable certain protocol optimizations as you no longer have
> the Set-Cookie header exception? This might be more difficult than
> just Expires as currently the name and value of a cookie can contain a
> comma as well.

I don't remember about this being permitted, but admittedly I haven't
rechecked in details for a while, and given that you've certainly worked
on such details recently I'm inclined to trust you :-) So that would
basically come down to saying "any field that includes a comma has to
be quoted".

> And although that is non-conforming I'm not sure you
> would want to tightly couple the value space of cookies to the HTTP
> protocol version. Opening an issue to think through the potential
> benefits and consider whether that ends up being worth it seems
> reasonable to me.

I think that just like it took 15 years or so to stop seeing
"pragma: no-cache" or case-sensitive matching of the "connection"
header field values (though maybe you have more accurate numbers
showing I'm wrong), teaching the consumer that the name, value,
expires etc may be quoted is a first step in the right direction. Then
we can imagine that for servers for which the number of response
headers is a problem, we'd encourage them to place non-critical
cookies together using quotes, assuming that a small portion may
be lost. For some of them the success rate might become high enough
to consider doing it by default all the time. After all, when "Host"
appeared, it took quite some time to become mandatory for most sites
and it now basically is.

The problem is always the breaking transition that prevents to fix
issues, but encouraging to be more liberal first, then to try to
adopt later tends to work over (a long) time.

cheers,
Willy

Received on Tuesday, 10 December 2024 09:57:56 UTC