Re: New Version Notification for draft-nottingham-http-availability-hints-01.txt

On Wed, Sep 4, 2024 at 5:42 AM Valentin Gosu <valentin.gosu@gmail.com>
wrote:

> Hi Mark,
>
> I have some feedback regarding the Cookie Section
> <https://www.ietf.org/archive/id/draft-nottingham-http-availability-hints-01.html#name-cookie>
> .
>
> > Note that this algorithm requires storing the cookies from the
> associated request with each response.
>
> In Firefox we currently store a hash of the Cookie header instead of the
> actual cookie value in order to deal with Vary: Cookie.
> This is because the cookies could be large in size, and because we don't
> want potentially sensitive information contained in cookies to be persisted
> in the HTTP cache.
> So I think you can implement the algorithm without storing the actual
> cookies in the response.
>

Chromium's (unshipped) implementation does this
<https://source.chromium.org/chromium/chromium/src/+/main:net/http/http_cookie_indices.cc;l=95-122;drc=8e948282d37c0e119e3102236878d6f4d5052c16>,
too. You need to store enough information to be able to confidently test
equality, though technically not the cookies themselves.


> I'm also wondering if this section should mention that the response may
> include a `Set-Cookie` header with one of the indices.
> I don't think anything special would need to happen, apart from this
> immediately invalidating the cache entry.
>
> Thanks
>
> On Wed, 10 Jul 2024 at 03:30, Mark Nottingham <mnot@mnot.net> wrote:
>
>>
>> > On 10 Jul 2024, at 2:33 AM, Rory Hewitt <rory.hewitt@gmail.com> wrote:
>> >
>> > The 'header explosion' concern is only part of it. My main point is
>> that using a single well-crafted header can both fill in the holes and also
>> provide more explicit preference information - covering the exact
>> edge-cases you mention in the design.
>>
>> The Variants header took that approach -- the WG came to the conclusion
>> that it wasn't workable, due to the complexity and difficult in
>> understanding. This is an attempt to split it up and simplify the space,
>> and it seems to be getting traction (e.g., partial prototyping in Chrome).
>>
>> > However, if you'd prefer to use multiple headers, I would strongly
>> suggest that you change "Cookie-Indices" to "Avail-Cookie" or
>> "Avail-Cookie-Indices" - all the related headers should have a common
>> "Avail-*" prefix, no?
>>
>> As the draft says, it's just a convention. The field names aren't
>> automatically processed.
>>
>> Cheers,
>>
>> >
>> > On Tue, Jul 9, 2024 at 12:29 AM Mark Nottingham <mnot@mnot.net> wrote:
>> > I'm not too concerned about an explosion of headers -- it only becomes
>> an issue if a resource negotiates on many axes, and even then things like
>> header compression work in our favour (splitting them into separate headers
>> often helps header compression). Client Hints took the same approach, and I
>> like the symmetry with them.
>> >
>> > Cheers,
>> >
>> >
>> > > On 9 Jul 2024, at 8:29 AM, Rory Hewitt <rory.hewitt@gmail.com> wrote:
>> > >
>> > > Hey Mark,
>> > >
>> > > My primary concern with this is the possible proliferation and
>> over-extensibility of `Avail-*` headers.
>> > >
>> > > This document includes Avail-Encoding|Format|Language|ECT (ECT is a
>> likely addition eventually) and Cookie-Indices, but those may need to be
>> extended in the future, leading to a large number of headers.
>> > >
>> > > To use the example you provide in the Introduction section:
>> > >
>> > > Vary: Accept-Encoding, Accept-Language, ECT
>> > > Avail-Encoding: gzip, br
>> > > Avail-Language: fr, en;d
>> > > Avail-ECT: ("slow-2g" "2g" "3g"), ("4g");d
>> > >
>> > > Naively, would it not make more sense to have a single
>> *Available-Responses* header, like this (apologies if the syntax isn't
>> quite correct for structured fields):
>> > >
>> > > Vary: Accept-Encoding, Accept-Language, ECT
>> > > Available-Responses: enc=gzip,br;lang=en,fr;ect=("4g"),("slow-2g"
>> "2g" "3g")
>> > >
>> > > Of course, this includes some assumptions:
>> > >
>> > > 1. The first option is the default - we have traditionally not done
>> that, and used things like Q-values (ugh!), but with brand new headers,
>> does it not make sense to start implementing a higher-level standard that
>> where multiple values are specified, they should be specified in a
>> prioritized list? For any given listable header, both clients and servers
>> know a preference order, and that should be implicit in the headers they
>> send and receive. Is this complete heresy to even suggest this?
>> > > 2. This may be less efficient when using things like QPACK static
>> tables to hold 'commonly-used' header values, but I don't believe that's
>> something that anyone is worrying about yet...
>> > >
>> > > On the plus side, it (kinda) simplifies the header size (not a big
>> issue with Huffman encoding and first-subsequent responses), but to me,
>> having a single response which specifies all the available response types
>> is an improvement to having multiple headers. As new response axes becomes
>> available, they can simply be added to the existing header.
>> > >
>> > > Additionally, it can be extended to include all the 'holes' and
>> various axes of preference mentioned - for example, the following shows
>> that the English-gzip is preferred over the French-brotli version (while
>> still making it clear that French-gzip and English-brotli versions are
>> available - the preference order symbolized here is explicitly:
>> > >
>> > > en-gzip
>> > > fr-gzip
>> > > fr-br
>> > > en-br
>> > >
>> > > based on the parenthesized grouping:
>> > >
>> > > Vary: Accept-Encoding, Accept-Language, ECT
>> > > Available-Responses:
>> (enc=gzip;lang=en,fr),(enc=br;lang=fr,en);ect=("4g"),("slow-2g" "2g" "3g")
>> > >
>> > >
>> > > To use an example of a 'hole', if a French-gzip version IS NOT
>> available, you'd have this:
>> > >
>> > > Vary: Accept-Encoding, Accept-Language, ECT Available-Responses:
>> (enc=br;lang=fr),(enc=gzip,br;lang=en);ect=("4g"),("slow-2g" "2g" "3g")
>> > >
>> > > which identifies the following preference order:
>> > >
>> > > br-fr
>> > > en-gzip
>> > > en-br
>> > >
>> > > An English client can use *either* gzip or br (gzip is preferred),
>> but a French client can *only* get a brotli response. Crucially though,
>> French-brotli is still preferred to either English-gzip or English-brotli,
>> even though there's only a single encoding option for French.
>> > >
>> > > Rory
>> > >
>> > > --
>> > > Rory Hewitt
>> > >
>> > > https://www.linkedin.com/in/roryhewitt
>> >
>> > --
>> > Mark Nottingham   https://www.mnot.net/
>> >
>> >
>> >
>> > --
>> > Rory Hewitt
>> >
>> > https://www.linkedin.com/in/roryhewitt
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>>