Re: Cache control in trailers?

On Sat, Feb 06, 2021 at 10:31:42AM +0100, Greg Wilkins wrote:
> Sorry, I'm definitely guilty of getting distracted by the conversation and
> forgetting aspects of the trailer mechanism...
> 
> Going back to Mark's original post.   He had two proposals: "indicate the
> error in trailers"; "to allow Cache-Control: no-cache in trailers".
> 
> For the first proposal, I'll repeat my initial feedback: it is a bad idea
> to handle errors during generation by correctly terminating a 200 response
> in order to put an error status into the trailers.
> Clients/intermediaries that don't support the specific error/status field
> would see this as a valid response.  Specifically I think it is a bad idea
> to do:
>     HTTP/1/1 200 OK
>     Trailer: end-status
>     ... body...
>     End-Status: 500
> 
> I can only see this as being workable in a 200 response if there is a
> really reliable way for the client and all intermediaries to indicate their
> support of End-Status specifically and not just support for Trailers
> generally.

Agreed. In general I'm not against the use of a status, but we currently
don't have statuses that mean "suboptimal response, please don't rely too
much on it". Conversely, cache-control semantics allow to send a short
"max-age" and a "must-revalidate", to warn the client about possibly poor
content quality while letting the server recover from the bad condition.

This is why I'd prefer a trailer field completing cache-control, but I'd
be fine with just a status if we define one meaning just this.

Willy

Received on Saturday, 6 February 2021 09:42:22 UTC