Re: Cache control in trailers?

On Wed, Feb 03, 2021 at 06:38:50PM +1100, Mark Nottingham wrote:
> > 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.

I generally agree with this approach for the same reasons. I tend to think
however that it could be a very good example of how to make intelligent use
of trailers and possibly be extended or replicated in the future for similar
use cases.

I'm also thinking about something, we should not expect caches to follow
trailers for a while, so in order to put some incentive there, we should
have a two-phase response. For example, the cache would pass the request
with "TE: new-cache-header-name", and the server would then emit a
preliminary cache-control with a "no-cache; trailers" or some such value
so that non-compatible caches don't blindly cache the content, but that
compatible caches notice this "trailers" token indicating that the final
verdict will be in the trailers. The compatible cache can then start to
store the response, and decide to commit or destroy it when seeing the
trailer. Others will simply not cache it so a truncated or bogus response
wouldn't be stored anywhere by accident. At least it sounds reasonable to
me like this and I think I'm seeing how this could be implemented without
too much effort, thus encouraging adoption :-)

Willy

Received on Wednesday, 3 February 2021 07:52:02 UTC