Re: _HttpOnly cookie prefix?

> A potentially simpler/shorter option could be: __Host__HttpOnly-mycookie
(where __HttpOnly__Host would work similarly, and we could also compound
future prefixes as well, e.g. __Unpartitioned__HttpOnly).

I raised this as a concern in a prior email several months ago:

"I'm not sure how the various __Secure-* and __Host-* cookies would play
with __HttpOnly-* cookies proposed by Yoav. Would this end up with cookie
names like "__HttpOnly__Secure-string"?"

I like Chris's idea of having a generic "__Prefixed{strings}" format, but
surely the actual double-underscore is itself the prefix? do we need more
than that?

IOW, can't we simply define it as:

    __{unordered-case-sensitive-prefixes}-{string}

where {unordered-case-sensitive-prefixes} is one or more of the following *in
any order*:

    *Secure*
    *Host*
    *Http* (I prefer this to "HttpOnly', simply because for some
reason we've gone for case-sensitive cookie names, and if we're talking
CamelCase prefixes, then that can confuse things)
    *Unpartitioned* (Chris's 'dummy' name)
    ...more to come...

So all of these would be equivalent:

    __SecureHttpUnpartioned-myname
    __HttpSecureUnpartioned-myname
    __UnpartitionedSecureHttp-myname

This would require some tinkering to ensure that the current rules that
apply to e.g. "__Secure-" and "__Host-" cookies can ensure that e.g. a
cookie named "__HostSecureUnpartitioned-myname" can't be created with a
Path prefix other than /, since that would clash with the existing "__Host"
cookie definitions. And, of course, the existing double-underscore cookie
naming would have to be ported in a backwards-compatible manner.

The nice thing is that just using a double-underscore with 1+ unordered
prefixes is simple and keeps the name of the cookie as small as possible.

Rory

On Mon, Jun 16, 2025 at 9:44 PM Yoav Weiss <yoav.weiss@shopify.com> wrote:

> Thanks!
>
> On Mon, Jun 16, 2025 at 11:19 PM Chris Fredrickson <cfredric@google.com>
> wrote:
>
>> 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
>>
>
> A potentially simpler/shorter option could be: __Host__HttpOnly-mycookie
> (where __HttpOnly__Host would work similarly, and we could also compound
> future prefixes as well, e.g. __Unpartitioned__HttpOnly).
>
>
>> 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!
>>
>

-- 
Rory Hewitt

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