Re: [whatwg/fetch] Trailer support in the API (#981)

I would definitely like to see the conversation around this progress but I'm not sure the proposal is adequate here. In some cases when *sending* trailers we do not actually want to calculate the value of a trailer until after the body payload has been fully sent (largely because we won't know what the full body *is* until it is fully streamed. In these cases, timing exactly when and how to get the content of the trailing header can be tricky. For instance, in the Workers runtime (https://github.com/cloudflare/workerd), in many cases, when streaming the body does not actually require javascript to be run, we will actually move the entire stream out of the runtime and stop executing javascript *at all* after the `Response` has been provided. In these cases, it would be impossible for us to actually calculate a trailing header value based on the body payload content, which severely limits the use cases. If we know that we're going to send a trailer, we could avoid using this optimization but at the cost of increasing costs to the user by keeping the JS execution context around longer.

We use a similar optimization for certain `Request` objects that are received and are forwarded on to fetch subrequests. If the code attaches a continuation to the trailers promise as proposed here, it's not clear what should happen if the user code does, in fact, forward the request on, moving all remaining processing of that request out of JavaScript.

Now, I'm not suggesting that this be designed around the specific optimizations of the workers runtime, just using those as an example. If the content of the trailing header cannot be calculated in advance and we have to provide a means of calculating it at the end of the processing of the payload then we could end up surfacing implementation and timing details under the covers that could end up very inconsistent from one runtime to the next, or could end up forcing such optimizations to be disabled entirely, which is a problem.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/981#issuecomment-1642660851
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/981/1642660851@github.com>