Re: Cache control in trailers?

--------
Greg Wilkins writes:

> So in the case of Etag, would it be worthwhile for cache implementers to
> know that the content they are currently receiving will/may have an etag in
> the trailers?    If so, that suggests a more general mechanism for
> hinting at the contents of the trailers is needed.

There are three fundamental problems with current trailers;

1. You dont know which header-fields are only provisional.

2. Combining the header and trailer field values is fraught with
   peril, both for sender, middle-boxes and receivers.

3. Buggy-proxies will mangle things in transit.

The first problem can be solved with a new header which lists which
fields which might appear in the trailers:

	Provisional:  Cache-control, etag, Last-modfied

The second problem can be solved with a clear-cut rule which says that:

A) Header values for fields marked provisonal are discarded when
   the same field appears in the trailers[1].

B) Trailer fields not marked provisional in the headers are discarded.

Something like that could make me reconsider implementing trailers in Varnish.

But I still think it's much easier, more robust and almost as efficient
to simply transmit the all the semantic metadata fields after the body.

There is no solution for the third problem, except to make sure the
buggy-proxies break bad enough that somebody fixes them.

Poul-Henning

PS: Yes, I know IETF "does not do APIs" but we should at least
    think about how our solution can be used from a CGI API.


[1] There's a detail here:  We need to ensure that a trailer
    fields without content survive, so the sender can say "Sorry,
    didn't want an Etag anyway" etc.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Friday, 5 February 2021 09:49:57 UTC