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

[Glenn Strauss <[e-mail]>]

Should these Avail-* headers be sent in every response?
While HPACK and QPACK can reduce the number of bytes sent on the wire,
there is still the processing and encoding overhead on the server.

If a proxy (or an indexer) might find this information useful,
should these additional headers be sent only in response to OPTIONS
for that resource?  Alternatively, should a client or proxy
interested in this additional information send an additional request
header, such as Accept-Availability?  Or should a server send the
additional headers if the request included any Accept-* request
header, or with OPTIONS?

If not suggested otherwise by the draft, what will likely happen is
that admins will configure generic webservers to always send these
response headers with every single request.  (That may end up what
happens anyway in the common case.)

Cheers, Glenn

On Mon, Mar 13, 2023 at 05:57:14PM -0400, Glenn Strauss wrote:
> What about replacing "Accept-" in request from client
> with "Vary-" in response from server?  This might indicate
> to the client (or intermediate proxy) how the server might
> "vary" responses for that vector.  A client might choose to
> look at Vary-* only for related items listed in Vary.
> 
> This might extend to Vary-User-Agent, though that does not
> begin with Accept-*.  (If Accept-*, then Vary-* without
> repeating the Accept-, e.g. not Vary-Accept-Encoding).
> 
> BTW, the draft does not highlight that "Accept-" prefix for
> items in the Vary response header is not included in the name
> of the corresponding "Avail-*" response header.
> 
> Cheers, Glenn
> 
> On Mon, Mar 13, 2023 at 09:16:13PM +0100, Asbjørn Ulsberg wrote:
> > I too like the spec. I’m also +1 with Mike on the “Avail” prefix. If we want to save characters, can’t “Has” work instead? “Has-Encoding”, and “Has-Language” sounds good to me, at least.
> > 
> > --
> > Asbjørn Ulsberg    -=|=-    [e-mail]
> > «He's a loathsome offensive brute, yet I can't look away»
> > On 13 Mar 2023, 19:37 +0100, Mike Bishop <[e-mail]>, wrote:
> > > Broadly, I like it.  I think Variants had a lot of potential to improve caching and am disappointed it hasn’t made more progress; this might be an easier way to approach the problem.
> > >
> > > It seems like you’re moving in a direction where:
> > >
> > > • These headers are always lists
> > > • Equivalence classes MAY be indicated by including a sublist as a list element, for axes where it’s possible for different values to produce identical responses
> > > • One list element MAY be indicated as default, for axes where a default makes sense and isn’t already implicit
> > >
> > >
> > > It’d be nice to be able to define this more generally, but you may be on the right track that many of the Accept-* headers have enough individual quirks that they’ll all have to be separately defined.
> > >
> > > Minor nits:
> > >
> > > • I’m unenthused by “Avail” as a prefix here, purely because it’s an actual word that isn’t actually what you mean.  Do we really need to save those four characters?
> > > • 5.3, Avail-Format => Avail-Language
> > >
> > >
> > > From: Mark Nottingham <[e-mail]>
> > > Sent: Saturday, March 11, 2023 9:49 PM
> > > To: HTTP Working Group <[e-mail]>
> > > Subject: Fwd: New Version Notification for draft-nottingham-http-availability-hints-00.txt
> > >
> > > FYI - this is a draft that I think is suitable for replacing the Variants specification. It conveys roughly the same information, but in a much more simple and intuitive way. Many parts are just sketched out to be filled in later, but it should be possible to get the general idea being proposed.
> > >
> > > Thoughts? If there's interest, I might ask for five minutes in Yokohama to talk about adoption.
> > >
> > > Cheers,
> > >
> > >
> > >
> > > > Begin forwarded message:
> > > >
> > > > From: [e-mail]
> > > > Subject: New Version Notification for draft-nottingham-http-availability-hints-00.txt
> > > > Date: 12 March 2023 at 1:47:09 pm AEDT
> > > > To: "Mark Nottingham" <[e-mail]>
> > > >
> > > >
> > > > A new version of I-D, draft-nottingham-http-availability-hints-00.txt
> > > > has been successfully submitted by Mark Nottingham and posted to the
> > > > IETF repository.
> > > >
> > > > Name:                  draft-nottingham-http-availability-hints
> > > > Revision:              00
> > > > Title:                     HTTP Availability Hints
> > > > Document date:               2023-03-11
> > > > Group:                  Individual Submission
> > > > Pages:                  10
> > > > URL:            https://www.ietf.org/archive/id/draft-nottingham-http-availability-hints-00.txt
> > > > Status:         https://datatracker.ietf.org/doc/draft-nottingham-http-availability-hints/
> > > > Html:           https://www.ietf.org/archive/id/draft-nottingham-http-availability-hints-00.html
> > > > Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-http-availability-hints
> > > >
> > > >
> > > > Abstract:
> > > >   This specification defines availability hints, a new class of HTTP
> > > >   responses headers that augment the information in the Vary header
> > > >   field.
> > > >
> > > >
> > > >
> > > >
> > > > The IETF Secretariat
> > > >
> > >
> > > --
> > > Mark Nottingham   https://www.mnot.net/
> > >