Private (conceptual) trailer support

[annevk]

To support something like https://w3c.github.io/server-timing/#server-timing-header-parsing-algorithm the response concept needs trailer support. I'm not sure if we need to add conceptual request trailer support as part of solving this issue as I'm not sure there are any dependencies. But any design should work for them as well, I suppose.

Per HTTP semantics trailers (a header list) can arrive "concurrently" with a message body and they can arrive multiple times (i.e., an asynchronous sequence of header lists). Server Timing does not appear to account for that.

(See #772 and #979 for prior takes on response trailer support.)

[noamr]

What's the current implementor interest around supporting trailers, and in particular for Server-Timing? There are no current WPTs supporting this. @yoavweiss can you help loop in the right people to respond?

[jasnell]

I do think it would be good to revisit support for HTTP trailers in responses and requests in general, particularly in light of things like https://aws.amazon.com/blogs/aws/new-additional-checksum-algorithms-for-amazon-s3/ which make direct use of trailers in both directions.

[yoavweiss]

/cc @ddragana @mcmanus - for their opinions from the Mozilla side as an implementer as well as from Fastly as a user.

From Chromium, I haven't heard of anyone interested in implementing trailers, even if just for Server-Timing. (but I'll ask around, as it's been a while)

@jasnell - does your use case require Server-Timing trailer support, or trailers in general?

[yoavweiss]

I dug up #34 which contains a bunch of arguments against trailer support. I'm not sure if those are still current, as it's been a while.

[noamr]

I dug up #34 which contains a bunch of arguments against trailer support. I'm not sure if those are still current, as it's been a while.

I read the thread. The arguments against mostly don't apply to Server-Timing. A lot of the argument are against exposing the trailers in fetch() / XHR, and that in many other standard header cases trailers would be nonsensical or harmful.

However timing info was presented there as an actual valid specific use case.

[yoavweiss]

Reading @davidben's reply there, I agree that Server-Timing exposure falls into the "I understand what this would mean" bucket. At the same time, the implementation complexity arguments (e.g. requiring trailer support implementation in the HTTP cache) still stand AFAIK.

[mnot]

Caches are allowed to drop trailers.

[jasnell]

@yoavweiss:

does your use case require Server-Timing trailer support, or trailers in general?

Trailers in general... but don't take it as a We Must Have It type of thing. We are looking at whether or not we could ever support that new AWS spec without resorting to non-standard extensions and it's looking most likely that we won't.

[yoavweiss]

Caches are allowed to drop trailers.

@mnot - while true, if we were to expose Server-Timing in trailers, whether caches drop them or not would be extremely web visible..