- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 3 Feb 2021 18:38:50 +1100
- To: Willy Tarreau <w@1wt.eu>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
> On 3 Feb 2021, at 3:25 pm, Willy Tarreau <w@1wt.eu> wrote: > > 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. I think that's reasonable. > 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. What I'm trying to avoid is defining something amorphous and unclear about its effects -- such as setting a new status code would do. By limiting its effects to the cache, it's crisp and clear about what should happen. If we make it general, it gets very tricky very quickly. Of course, that doesn't prevent us from introducing other signals later on, or even adding new behaviours to a signal later. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 3 February 2021 07:39:10 UTC