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

Got here with the following situation:

We have this long running job on the server triggered by a POST request. The job runs for minutes, and generates output bit by bit as it runs (that is; it reports its steps and progress indicators as it runs); the job not being my code I can't change it to make error messages follow a regular pattern. As the job never reads input, and because websocket security was designed wrong from the beginning, requiring much more code at the server endpoint to make it secure, a websocket is not appropriate.

At the very end I can check the exit code of the process and report it back to the javascript caller; the natural implementation of this is a trailer. Searching for how to get trailers found an older version of the fetch() specification that had a trailers property; but it does not actually exist.

The discussion points
* Caching: caching of POST requests is undesirable anyway.
* Trailers can't be read until the body is fully materialized: Correct; the point where my Javascript would look for them has already finished materializing the body (got the EOF indicator from read).
* Promise: I fail to see how making it another promise to get trailers does any good; it's just another awkward call at that point.

So I actually think the original spec got it right; trailers is just another property of the same type as headers that returns undefined until the body is fully read, at which point it returns the collection.

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

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