Fetch: Consider removing trailers API

[domenic]

https://bugs.chromium.org/p/chromium/issues/detail?id=691599 was closed as WontFix today, and I don't recall anyone else interested in implementing.

[sleevi]

I dropped a note to @igrigorik who is out, since it looks like https://w3c.github.io/server-timing/ has a normative dependency on Trailers, at least in the current tip of tree

[annevk]

cc @valenting

[valenting]

AFAICT the server timing spec reference to trailers doesn't have a dependency on the fetch API.

[annevk]

I think it's more that if that's implemented already, you already need a robust trailer infrastructure that would be easyish to expose through an API. And arguably should be exposed at that point, as we want to give developers access to the primitives.

[mnot]

... and Firefox has implemented trailer support for Server-Timing.

I'd hope that one implementation deciding not to put resources into a feature doesn't mean we pull that feature from the Web platform; if that's the bar, Chrome is going to be out on its lonesome with a lot of features...

[igrigorik]

Given that Firefox implemented trailer support, I agree with @mnot and believe we should keep existing logic in Fetch.

@domenic @annevk close with no action?

[domenic]

Firefox has not implemented the trailers promise as far as my testing shows.

Furthermore, per the WHATWG working mode, we need multi-implementer interest to keep a feature. My understanding is that trailer support was added based on Firefox + Chrome interest, but Chrome has since withdrawn support.

[annevk]

At the time it seemed there was interest from most browsers at the HTTP workshop. And while Firefox has not implemented the promise, it has implemented trailers, which then argues for exposing it as per my earlier comment.

If Edge and Safari don't want to implement this though and are not implementing Server-Timing either (or at least the trailer aspect) I tend to agree that the case for keeping this would be non-existent.

[igrigorik]

If Edge and Safari don't want to implement this though and are not implementing Server-Timing either (or at least the trailer aspect) I tend to agree that the case for keeping this would be non-existent.

I'm not aware of any "negative" signals to that extent from either. ST is under consideration for Edge.

[domenic]

Maybe @youennf and @travisleithead can speak as to whether Safari/Edge intend to implement the trailers promise.

[travisleithead]

@aliams who can speak to the fetch trailers promise.

[annevk]

As an update, I've been trying to figure out how viable trailers are for browsers in https://github.com/httpwg/http-core/issues/16 and also https://github.com/httpwg/http-core/issues/18. I'm getting the impression they're more trouble than they're worth given that clients are allowed to combine them with "normal" headers.

[youennf]

For WebKit, this feature should be implementable.
This might be more a question of priority/potential usage.

I am not aware of requests being made to support this feature.
The only case I know of is Server-Timing.

[mnot]

There's pretty much a standing request from CDNs and some content engines to allow ETag and Last-Modified, as well as perhaps Cache-Control, to be sent in trailers, as that would allow them to avoid buffering dynamic content server-side in some situations.

[youennf]

This is somehow a bit orthogonal to a trailers API though.
Starting with using these trailers internally within a browser might be a good first step.

WPT tests specific to ETag/Last-Modified/Cache-Control trailers and how it impacts the various browser caches might help implementors, find potential edge cases...
Filing bugs pointing to those tests would also help.

[igrigorik]

A real-world use case and need for Trailer support and Server-Timing:
https://twitter.com/JJJ/status/1077988650602901505

tl;dr: we need trailers to emit timing and debug data about where time was spent as the page is being constructed, after the content is flushed. Forcing output buffering is both bad for user experience and performance, as well as causes random failures due to broken interleaving of flushes in real world applications like WordPress. If we had Trailers, we could collect the timing data and emit the header at the end — clean 'n simple.

[ioquatix]

I started implementing trailers in async-http and http-protocol. At face value it's not a very nice abstraction. It's not well supported by HTTP/1 since it can only be used with chunked transfer. It's the first thing I've encountered which has a significant semantic difference at the high level across HTTP versions. I'd be interested to hear more about how this should be implemented. For example, if user specifies a fixed length body, should we convert it to chunked encoding if the user also provides trailers?

[annevk]

@igrigorik that's not a request for the generic trailer API though, is it?

[annevk]

Also, how is Server-Timing supposed to work when it ends up in the header block?

[ioquatix]

I at least had an idea on how to solve this - use key - value where the value is a lambda that gets evaluated when it’s enumerated.

[igrigorik]

@igrigorik that's not a request for the generic trailer API though, is it?

What does "generic API" equate to in your head? As discussed previously, ideally what I would like to see is trailer headers be treated as inert (don't impact regular response processing) but readable from Fetch by the application. Specific use cases, like Server-Timing can then build on top of that to provide own layer of functionality.

Also, how is Server-Timing supposed to work when it ends up in the header block?

Not sure I follow.. As in, non-trailer header block? It would work as it does today.

[annevk]

@igrigorik okay, so a JavaScript API to get all trailers the server transmitted? As for the Server-Timing question, I was asking as trailers are apparently always allowed to be appended to the non-trailer headers by an intermediary, which seems rather sketchy to me. And that's also a concern for the JavaScript API, that folks might rely on getting some trailer header but a user behind an intermediary wouldn't have it and get some kind of failure.

[igrigorik]

@igrigorik okay, so a JavaScript API to get all trailers the server transmitted?

Yep.

I was asking as trailers are apparently always allowed to be appended to the non-trailer headers by an intermediary, which seems rather sketchy to me. And that's also a concern for the JavaScript API, that folks might rely on getting some trailer header but a user behind an intermediary wouldn't have it and get some kind of failure.

Right, I think that's WAI — @mnot please chime in here if not so. If you have an intermediary that's buffering the full response before flushing it (which is a terrible idea, but that's beside the point), they could move trailer content into the header block. I don't think we can stop that, and I'm also not sure that's a "problem" that we need to be concerned about.. After all, same intermediary may also arbitrarily strip headers due to various policies.

[mnot]

Agreed. The problems that are referred to AIUI are restricted to headers that the browser depends upon when it's processing the body (e.g., Content-Length, Content-Security-Policy), and can't revise in-flight or after the fact. Such an API would not affect these uses.

[annevk]

Per https://github.com/httpwg/http-core/issues/220 the current API only addresses a subset of the trailer use cases. A more complete trailer API would require FetchObserver (#607). I suspect we'd also have to support trailers on requests.

I'll remove the API for now as there's been no new interest in the past year and a half and open a new tracking issue to consider adding them back that lists the various new things that came to light as well as possible dependencies.

Edit: See #980 and #981 for adding trailer support back. And see #979 for removing the current take from the Fetch Standard for reasons in the prior comment.