- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 3 Feb 2021 05:25:23 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Mark, On Wed, Feb 03, 2021 at 11:40:41AM +1100, Mark Nottingham wrote: > A more limited approach would be to focus just on the cache's behaviour -- > e.g., to allow Cache-Control: no-cache in trailers,[2] updating the semantics > of the response to make sure that it's revalidated before it's reused. > > What do folks think - would this be useful? Obviously it would need to be > implemented in browsers and other caches. I think there could be some value in this, but please let's *not* reuse the same trailer name then. In my experience the vast majority of header producers have no idea what they do, and they just assemble a collection of header values+names gathered from Stackoverflow and Wikipedia as a way to "increase the likelihood this will work". Starting to send the signal that such an important header field could be placed in either the header or the trailer part will quickly result in anything important being sent in both parts "just in case", and I guess none of us wants to have to deal with that. But maybe working on the notion of a final status, or maybe an abort cause could prove useful over the long term. These could be used to indicate a change of decision regarding caching, deliver a user-friendly excuse message (e.g. "communication error with origin server"), timing information (e.g. "processing time 10 ms, transfer time 143 ms"), a content checksum etc. Willy
Received on Wednesday, 3 February 2021 04:25:43 UTC