Re: [fetch] Access to the HTTP trailer (#34)

I certainly agree that a precondition here is that *all* existing headers (*including* ETag and friends; allowing that is considerable complexity to a disk cache implementation) *must* be ignored in trailers. Though, even that might be troublesome. The client advertisement is simply "trailers", not a list of headers that may be put there. I don't know how enthusiastic existing servers will get if you start advertising support. Will ETags suddenly move to the trailer? What will happen if some browsers do support ETags in the trailer and some don't?

Even if that turns out fine (the install-base of servers probably does not include that many trailer users?), this is still a massive change to the core abstraction of the whole browser. The benefits have to outweigh the cost. If the use case is purely programmatic use by developers, it seems this is not the right time to propose the feature. The core capability (a stream of bytes) is already being provided by Fetch. In the spirit of the extensible web manifesto, JS code is free to parse out whatever additional structure it wishes. While we don't let you extend the HTTP parser, the difference between that and parsing out the body is minimal.

If it turns out everyone is effectively reimplementing HTTP trailers (unlikely), then it makes sense to move a construct of the sort into browsers. The reason one might wish to short-circuit this process is if some processing in the browser needs to interpret this. But we seem to both agree that the opposite is desirable.

(Nit: It's not accurate to say XHR lacking trailers is a de facto standard. This is de jure at this point. The specification is Fetch and friends. They say, on the web, HTTP trailers do not exist. This ticket exists specifically to propose changing that.)

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/34#issuecomment-119751143