Re: New Cookies Draft

Johann, are you looking for suggested (minor) wording changes here, or
should we just open PRs for them?

On Tue, Dec 10, 2024 at 2:01 AM Willy Tarreau <w@1wt.eu> wrote:

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

-- 
Rory Hewitt

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