Re: Cache control in trailers?

On Fri, Feb 05, 2021 at 09:49:41AM +0000, Poul-Henning Kamp wrote:
> 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.

This is called Trailers :-)

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

I'm not that much worried about them nowadays. Plenty of them will
simply drop the trailers before forwarding. That's fine and permitted.
The ugliest ones will stop parsing after 0 CRLF, and will break when
finding that remaining string in the buffer, either when the connection
is left idle, or when they expect to parse the response to the second
request sent over that connection, thus breaking keep-alive. In any
case, these are not the ones we'll often find where decoding SSL is
required, nor inside the network where reliability is a business
metric so I consider that they're mostly off-path nowadays.

> 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.

Why ? CGIs do not even support chunked encoding in the first place,
let alone sending final meta-data past the body. The common failure
case for CGI is to exit() and let the server close the communication.

> [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.

Sure and actually this would tend to encourage not to merge headers
and trailers. I don't know how many intermediaries do merge them
nowadays, maybe we could check among implementations here and
complete the list started below ?

   - haproxy: drop chunked extensions, pass trailers as-is, no merge

Willy

Received on Friday, 5 February 2021 17:37:49 UTC