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

[Mark Nottingham <[e-mail]>]

Hi Valentin,

Thanks, I'll fix this up in the next revision. 

Cheers,


> On 4 Sep 2024, at 7:39 PM, Valentin Gosu <[e-mail]> wrote:
> 
> Hi Mark,
> 
> I have some feedback regarding the Cookie Section.
> 
> > 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 <[e-mail]> wrote:
> 
> > On 10 Jul 2024, at 2:33 AM, Rory Hewitt <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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/
> 
> 

--
Mark Nottingham   https://www.mnot.net/