Open Bug 1339096 Opened 8 years ago Updated 7 months ago

Add Fetch's Response's trailer attribute

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

People

(Reporter: annevk, Unassigned)

Details

Tests: https://github.com/w3c/web-platform-tests/issues/4811. Standard: https://fetch.spec.whatwg.org/#dom-response-trailer (click on the definition to find where it was referenced from, you need to do this a few times and follow the links to get the full picture).
Priority: -- → P3
Component: DOM → DOM: Core & HTML
Severity: normal → S3

I think this could be closed as the feature was removed from the fetch spec [1] and from the web-platform-tests [2]

[1] https://github.com/whatwg/fetch/pull/979
[2] https://github.com/web-platform-tests/wpt/pull/20720

Feels like coming knocking and finding everything's been boarded up long ago.

I came across this day a real use case for HTTP Trailers in Javascript and found it was never implemented.

What happens on the server is this long task runs, and returns output while its running (over minutes), but at the very end you find out if the task succeeded or not. The only reasonable way to implement this is to stream the output and generate a trailer for the status code. The javascript on the page needs to consume all this and process it and react to success/failure. A websocket is really unsuitable here as it's far too heavyweight and there's no uplink back to the server while it is running.

(In reply to Joshua Hudson from comment #2)

Feels like coming knocking and finding everything's been boarded up long ago.

I came across this day a real use case for HTTP Trailers in Javascript and found it was never implemented.

What happens on the server is this long task runs, and returns output while its running (over minutes), but at the very end you find out if the task succeeded or not. The only reasonable way to implement this is to stream the output and generate a trailer for the status code. The javascript on the page needs to consume all this and process it and react to success/failure. A websocket is really unsuitable here as it's far too heavyweight and there's no uplink back to the server while it is running.

You may be interested in following/contributing at https://github.com/whatwg/fetch/issues/981

You need to log in before you can comment on or make changes to this bug.