Re: Cache control in trailers?

> Am 06.02.2021 um 10:42 schrieb Willy Tarreau <w@1wt.eu>:
> 
> 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.

tr-{xxx}: yyy      # replace header 'xxx' with value 'yyy', when this field appears in trailers

is that what we are discussing?

- Stefan

Received on Monday, 8 February 2021 10:13:12 UTC