- From: Chris Fredrickson <cfredric@google.com>
- Date: Mon, 16 Jun 2025 17:16:06 -0400
- To: ietf-http-wg@w3.org
- Message-ID: <CAC79nvekTYw4yzqZ5uHJxy-r8bS6NnKA0ui3rpv6FZ1OEJFsqA@mail.gmail.com>
This comment is orthogonal to this proposal (by which I mean, I don't intend to block the proposal on solving this), but I noticed that this proposal wants, in principle, to convey a single boolean signal in the cookie name (i.e. whether the cookie was marked HttpOnly or not). But due to the fact that prefixes don't compose well, Yoav was forced to create two new prefixes instead of one (and it would have been worse if the new prefixes didn't happen to require the Secure attribute). I think this shows the current prefix-based approach is hard to extend, and if we wanted to add another prefix (e.g. __Unpartitioned-, just off the top of my head), we'd actually have to add a handful of variants, due to the combinatorial explosion. I think this is solvable if we design a prefix system that's order-insensitive. My gut instinct is to want something like: __Prefixed(Host,HttpOnly,Unpartitioned)-mycookie Some of those characters are forbidden in cookie names (which are tokens: https://datatracker.ietf.org/doc/html/rfc9110#name-tokens), though, so we could do something like this instead: __Prefixed!Host&HttpOnly&Unpartitioned!-mycookie I realize there's going to be a lot of details to work out on this regarding backward compatibility, forward compatibility, security, particulars about the spelling, etc. But it might be nice to make the system more extensible now, rather than the next time someone tries to extend it. Curious if anyone else has thoughts!
Received on Monday, 16 June 2025 21:16:38 UTC