Re: Cache control in trailers?

On Thu, Feb 04, 2021 at 02:11:46PM +0100, Greg Wilkins wrote:
> On Thu, 4 Feb 2021 at 11:05, Willy Tarreau <w@1wt.eu> wrote:
> 
> > On Thu, Feb 04, 2021 at 10:47:13AM +0100, Greg Wilkins wrote:
> > >    I've not yet seen a proposal for using headers that
> > >    addresses the problem of clients that don't know the new headers
> > mistaking
> > >    the 200 response as valid/complete.
> >
> > For me, pre-announcing cache-control in the headers was targetting this
> > requirement: if you indicate the response is not cacheable until the
> > final verdict, this is no more a problem.
> >
> 
> If the mechanism is only intended to deal with cache-control, then that is
> probably sufficient.
> However, I think the use-case of discovering after committing a response
> that the content is no longer going to be cacheable yet can be completed in
> a way that is still a valid response for the one request is vanishingly
> small.
> 
> Alternatively, if deferred cache-control is only an exemplar of a more
> general mechanism to signal that metadata fields are
> expected in the trailer, then I don't think it is sufficient.  Something
> like the 3xx proposal feels safest to avoid accidental interpretation of a
> 200 response.
> 
> I know Mark's proposed scope was just cache-control, but it's probably
> worthwhile at least considering if a more general solution is possible.

In fact I think that acting on the cache duration could solve many issues.
This would consist in only extending the caching duration. If an object was
rendered with some errors or incomplete information but was not aborted
during generation, it's probably still acceptable to be delivered again
for the time during which the service is expected to recover. So one could
imagine pre-setting the max-age to, say, 5 seconds in the header, and extend
it to one hour in the trailer if the result is satisfying. This might also
help avoiding the issue of cacheable vs non-cacheable etc, as it would be
much clearer that the decision doesn't change, only the validity duration.

Willy

Received on Thursday, 4 February 2021 15:03:51 UTC