Cookie layering - Http prefix

[yoavweiss]

As discussed at IETF 122, this is a stab at integrating https://yoavweiss.github.io/httponly_prefix/draft-httponlyprefix-weiss-http.html with the Cookie layering processing model.

---

• Cookie Store API PR: __Http prefix WICG/cookie-store#262
• WPT coverage: https://chromium-review.googlesource.com/c/chromium/src/+/6638647/12/third_party/blink/web_tests/external/wpt/cookies/prefix/__Http.https.html

[yoavweiss]

Given https://lists.w3.org/Archives/Public/ietf-http-wg/2025AprJun/0188.html, maybe we want to land __HttpOnly first while we figure out what the compounding mechanism here should be?

[annevk]

It might be good to open an issue to discuss further, but my inclination would be that we turn this into some kind of table of prefix strings and their corresponding restrictions down the line. I don't think the combinatorial explosion is all that bad and allowing them in arbitrary order would in fact turn a simple prefix match into a parser question with all the resulting issues that come with that.

[yoavweiss]

Yeah, there's a discussion happening on that front in https://lists.w3.org/Archives/Public/ietf-http-wg/2025AprJun/0192.html

I think we can split this into two separate things:

1. Add an HttpOnly (or Http) prefix
2. Figure out a way to combine multiple prefixes

If that makes sense, I'm happy to turn this into (1) and open an issue to further discuss (2)

[annevk]

Unfortunately this will also need a corresponding PR to the Cookie Store API. Perhaps if we eventually abstract this convention somehow we can improve that.

[annevk]

I like the idea of the prefix being just Http for brevity's sake. I also think we should have an issue for the multiple discussion as it'll come back.

[yoavweiss]

I like the idea of the prefix being just Http for brevity's sake. I also think we should have an issue for the multiple discussion as it'll come back.

Revamped this PR to just handle the Http prefix, and opened #3111 for further discussion on prefix combinatorics.

[annevk]

I added a checklist to OP for what remains to be done. I suppose we also need to make some assessment as to whether this has broad enough support, but I think it has from the list discussion.

[yoavweiss]

@annevk - I tried to split out the conditions to separate algorithms, to make it easier/clearer when combining them for HostHttp. Let me know what you think.

[annevk]

I like it. I'm half-tempted to also suggest introducing a list of known prefixes so we can deduplicate some of that across specifications, but I think this is sufficient for now. At some point the abstractions might also impede clarity.

[miketaylr]

I realize you're inheriting this from the cookie layering draft, but is the empty string correct?

Above (in prose) this is described as:

Path attribute with a value of /

(that's also what 6265bis has in 5.7.21.3)

[yoavweiss]

In case there's a Path attribute, I see the following algorithm:

1. If _attributeName_ is a byte-case-insensitive match for `Path`:
    1. If _attributeValue_ is not empty and if the first byte of  _attributeValue_ is 0x2F (/), then set _cookie_'s path to _attributeValue_  split on 0x2F (/).

So I think a list of size 1 with an empty string is correct here.

In case there's no Path attribute, we fall back to the Cookie Default Path algorithm which I think intends to do the same thing and set the path as a list of size 1 with an empty string if the path contains only a single /.

At the same time, that algorithm operates on a list (and currently receives a URL). I'm also not sure if we should accept a __Host prefix if the cookie doesn't include an explicit Path=/ attribute.

[annevk]

We should not, according to bis: https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#section-5.7

However, that means we have to keep additional data around that we're currently not. We need to store some information about the attributes on the parsed cookie in some manner. That's unfortunate. #3112

[yoavweiss]

I'm also not sure if we should accept a __Host prefix if the cookie doesn't include an explicit Path=/ attribute.

RFC 6265bis suggests we shouldn't, but I'm not sure there's a way to make that distinction ATM. I can add a default_path flag that would enable it

[annevk]

I think it would be more natural to add a field to cookie along the lines of "had explicit path" that we then check here in addition to checking that it had the correct value.

Alternatively we could maybe compute ahead of time whether it's a host-prefix cookie and store that as a bit during parsing.

[yoavweiss]

Added a path-attribute boolean. Let me know if this makes sense (and if this should be split to a separate PR, as it impacts __Host)

[yoavweiss]

(I'm on train wifi, so I made the above comments oblivious to your comments. Apologies for any incoherence)