Re: Cache control in trailers?

["Roy T. Fielding" <[e-mail]>]

If we are going to continue this conversation, I insist that participants
actually read the current definition of trailers under WGLC in 

  https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#trailer.fields

and

  https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#field.trailer

and then study existing use beyond what you have implemented yourself.

It takes only five minutes of searching to dig up many articles from people
using trailers in practice within APIs, CDNs, backend systems, etc.  E.g.,

   https://engineering.pivotal.io/post/http-trailers/
   https://www.fastly.com/blog/supercharging-server-timing-http-trailers
   https://webtide.com/http-trailers-in-jetty/
   https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md
   https://grpc.github.io/grpc/cpp/md_doc__p_r_o_t_o_c_o_l-_w_e_b.html
   https://golang.org/pkg/net/http/#example_ResponseWriter_trailers
   https://github.com/envoyproxy/envoy/issues/2394

HTTP is not limited by what browsers currently use! We should all know that
by now without me having to repeat it ad nauseum. Browsers are important
but make up less than 1% of the total HTTP implementations. Nevertheless,
we have deliberately fixed several aspects of trailers in the revision, specifically
so that they can be better implemented by intermediaries and browsers, and
won't override header field values by default.

This is not to say that the current description is perfect. It is somewhat
limited by past definition and usage of trailers and the various ways they
might be sent for HTTP/1, 2, and 3. We have worked hard to define what
has been implemented widely now and avoid prohibiting what has only
been implemented as experiments, such as mid-stream trailers.

Any statements suggesting that trailers are "not in current use" or that
"nobody implements trailers" are obviously false. They are being used.
They would be used a lot more if we don't arbitrarily break them without
understanding the existing implementations.

To answer the original question, there is nothing stopping a server from
sending

    Cache-Control: must-revalidate
    Trailer: cache-control
... body...
    Cache-Control: public

or

    Cache-Control: max-age=3200
    Trailer: end-status
... body...
    End-Status: 500

or

    Cache-Control: max-age=3200
    Trailer: end-cache-control
... body...
    End-Cache-Control: oops

and simply ask cache implementations to do the right thing once you define
what that right thing might be. These are already supported by the core spec,
but they would need to be defined as extensions to be interoperable.

Personally, I think end-status is the easiest and most reusable solution, for
any number of features that might need to know if something broke. However,
Willy is right that saying must-revalidate up front and then softening that
at the end would be the safer choice where completion is more important
than default performance. I suggest that choice needs to be resource-specific.

Please, if there is something specifically wrong with the current definitions
of Trailers in the specs currently in WGLC, and its not just a personal opinion
about their usage, suggest a better definition that doesn't break other
people's software, or suggest some additional sentences that might clarify
the work so that the next generation of apps can use this feature without
prior shared agreement.

....Roy