Re: Cache control in trailers?

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.   It could be argued that TE: trailers should indicate support
for all standard fields, but I can't see how it can be assumed to indicate
support for newly defined fields.

For the second proposal, as Roy indicates, it is already possible. So what
exactly is being proposed? Clarifications to the Cache-Control field
definition or a new Cache-Update field?   Again, either way, it does appear
that being able to indicate support for a specific field in the trailers
rather than the trailer mechanism in general would be valuable.






On Fri, 5 Feb 2021 at 20:04, Roy T. Fielding <fielding@gbiv.com> wrote:

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

-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com