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

Rory Hewitt <rory.hewitt@gmail.com> Tue, 09 July 2024 16:35 UTC

Resent-Date: Tue, 09 Jul 2024 16:34:18 +0000
Resent-Message-Id: <E1sRDnG-00DewY-35@mab.w3.org>
Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2a00:1450:4864:20::234 as permitted sender) client-ip=2a00:1450:4864:20::234; envelope-from=roryhewitt@gmail.com; helo=mail-lj1-x234.google.com;
MIME-Version: 1.0
References: <CAEmMwDwFmK_wuQg4gnjj4rbVr5Wb_m+f3MFuTXFmA7ZMCvMKEA@mail.gmail.com> <AFB140A5-1611-49ED-9C33-9E5675201286@mnot.net>
In-Reply-To: <AFB140A5-1611-49ED-9C33-9E5675201286@mnot.net>
From: Rory Hewitt <rory.hewitt@gmail.com>
Date: Tue, 09 Jul 2024 09:33:58 -0700
Message-ID: <CAEmMwDzHKF=ZP4t80YMB9F_Y3kNie2HLR_11eiYPr5+cLGagqw@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000060a494061cd3192d"
Subject: Re: New Version Notification for draft-nottingham-http-availability-hints-01.txt
Archived-At: <https://www.w3.org/mid/CAEmMwDzHKF=ZP4t80YMB9F_Y3kNie2HLR_11eiYPr5+cLGagqw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

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.

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?

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

Fwd: New Version Notification for draft-nottingha… Mark Nottingham
Re: Fwd: New Version Notification for draft-notti… Rory Hewitt
Re: New Version Notification for draft-nottingham… Mark Nottingham
Re: New Version Notification for draft-nottingham… Rory Hewitt
Re: New Version Notification for draft-nottingham… Mark Nottingham