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

[Mark Nottingham <[e-mail]>]

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/