A question about "immediately evicted" in cookie change event documentation

[wbamberg]

I hope it's OK to ask for a clarification here.

In https://github.com/mdn/content/pull/33462 we're fixing an error in the MDN docs for CookieChangeEvent, and we had a question about the meaning of "immediately evicted" in the documentation for cookie change events:

A newly-created cookie which is not immediately evicted is considered changed.

A newly-created cookie which is immediately evicted is considered deleted.

According to the example in https://github.com/mdn/content/pull/33462#issuecomment-2104778275, one way to have a cookie immediately evicted is for it to have an expiry date in the past. If we want to flesh out "immediately evicted", are there other cases we should mention? Is it worth explaining this in the specification as well?

Thank you!

[inexorabletash]

FYI, the reason for the odd phrasing is that we're trying to specify the API in terms of the semantics from the cookie RFC, which says things like this:

If the user agent receives a new cookie with the same cookie-name, domain-value, and path-value as a cookie that it has already stored, the existing cookie is evicted and replaced with the new cookie. Notice that servers can delete cookies by sending the user agent a new cookie with an Expires attribute with a value in the past.

re: other cases - from the perspective of a developer using the API, it may not be clear that delete() works by setting a cookie with an expiry date in the past, so it is for "immediately evicted"; it's probably worth explicitly mentioning that in the MDN article.

re: fleshing out "immediately evicted" - maybe? Ideally the cookie RFC would evolve to better support the API and we could avoid such awkward phrasing, but it hasn't been anyone's priority. We can leave this issue open to inspire future work.

[annevk]

@johannhof and I are in fact working on such an update (as also mentioned in some other issues).

We haven't looked at the requirements for events however. Looking at the specification for those there's a lot of assumptions about batching and such that are not really backed up by anything.

How is this envisioned to be implemented in interoperable fashion?

[inexorabletash]

With the caveats that it's been several years since I thought about this so I may be remembering incorrectly...

I think we settled on batching to deal with the most common case: cookies are updated as a result of response headers arriving, which will change or delete several cookies at the same time. We didn't want separate events to fire for each, although that would not be in violation of the spec.

I don't know if that exactly matches the implementation in Chromium, though - that is, if multiple cookie updates in a single response headers always result in a batch event, or if single cookie updates e.g. via document.cookie never result in a batch event.

[annevk]

I think that is something we should define if we want this to be something that websites can use reliably.

@johannhof initially convinced me that this could be implemented as wrapper algorithms around the Cookies I-D, but I'm now thinking that this needs more drastic changes as when we attempt to store a cookie we currently don't know if it

1. Was ignored.
2. Was accepted, but resulted in removal of itself.
3. Was accepted.

And our draft also doesn't really give good control over the more general eviction that might happen.

[johannhof]

Yeah, would be good to do some research on what happens in browsers in practice here, but I agree that if it turns out complex enough then that'll have to be mirrored in a more complex spec construct. Definitely agree that we need to specify this.