Re: New Cookies Draft

QQ: In Section 5.1.1. (Cookie Store And Limits), you note:

   * A user agent has an associated *total cookies-per-host limit*, which
is an integer. It SHOULD be 50 or more.

   * A user agent has an associated *total cookies limit*, which is an
integer. It SHOULD be 3000 or more.

These are more specific replacements to the RFC6265 Section 5.3 (Storage
Model) which states:

   At any time, the user agent MAY "remove excess cookies" from the
   cookie store if the number of cookies sharing a domain field exceeds
   some implementation-defined upper bound (such as 50 cookies).

   At any time, the user agent MAY "remove excess cookies" from the
   cookie store if the cookie store exceeds some predetermined upper
   bound (such as 3000 cookies).

It's worth pointing out that the RFC6265 suggested limit of 50 cookies
references "cookies sharing a domain field" rather than being specific to a
host. In practice, most user-agents seem to treat this as a per-host limit
anyway. But it may be worth making this clear in that first bullet point,
e.g.:

   A user agent has an associated *total cookies-per-host limit*, which is
an integer. This limit is independent of the Domain or Path attributes of
those cookies, if specified. It SHOULD be 50 or more.

On Wed, Dec 11, 2024 at 10:18 AM Johann Hofmann <johannhof@google.com>
wrote:

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

-- 
Rory Hewitt

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