Re: New Cookies Draft

Hi Rory, PRs are probably best, thanks!

On Wed, Dec 11, 2024, 13:06 Rory Hewitt <rory.hewitt@gmail.com> wrote:

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