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

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.

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/
>
>
>