Re: Cache control in trailers?

On Wed, Feb 3, 2021 at 10:13 AM Willy Tarreau <w@1wt.eu> wrote:

> On Wed, Feb 03, 2021 at 02:40:27PM +0000, Poul-Henning Kamp wrote:
> > Except it doesn't work, because nobody implements trailers - because they
> > dont want to deal with the complexity of merging headers and trailers.
>
> But why do you say "nobody" after I gave an example (gRPC). You don't
> necessarily *need* to merge them, just like some headers are forbidden
> in trailers, we can very well specify that some fields are only relevant
> in trailers. FWIW apparently gRPC does this as I seem to have read
> somewhere that a grpc-status trailer is mandatory and that as a corollary,
> you may never see an H2 data frame carrying the ES flag.


Do you have other examples? To say gRPC holds HTTP “weird” is a bit of an
understatement, in terms of resources and semantics. That is, while it
overlays on the wire protocol, the semantics themselves of gRPC’s
implementation don’t really align nicely with what folks might reasonably
think about HTTP with respect to resources, methods, headers, etc.

This is particularly important when considering that there really isn’t
anywhere near the level of intermediation for gRPC as there is for
“HTTP”/“the Web”. The intermediaries that do exist aren’t agnostic; they
understand the semantics of gRPC and are often gRPC implementations
themselves.

I do have to agree with PHK here: this sort of merging is a state machine
security nightmare, especially when thinking about the interaction with
resources, caching, and the overall semantics of HTTP. It’s exactly this
risk that has discouraged Chrome from exposing trailers, either in our
internal APIs for dealing with resources or in web-developer facing APIs.
Yes, we support it at the wireframe level in our H/2 implementation, but
that’s intentionally not surfaced beyond that. This does mean, for example,
that developers working on Google Chrome are (intentionally) not able to
use gRPC within Chrome: the complexity in implementation and security is
presently not justified.

Admittedly, (DAY-JOB) is primarily dealing in edge cases and weird states
in state machines, so I’m probably over indexed on those concerns, but I
wouldn’t be terribly excited for trailers precisely because it necessitates
careful re-review of every state machine, end to end, to make sure new
issues and surprises aren’t introduced by such semantics. So even if, in
the abstract, it’s good and useful, that sort of complexity may preclude
implementation.

>