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

I agree we should just give up on trailers in the browser context at this point.

There's first the huge mass of interop and security pitfalls. Browsers process existing headers everywhere. When I think about where we process them and what the headers are, they span a spectrum from:

* "We could accept this in a trailer, but what's the point?" (Alt-Svc, HSTS, HPKP, Connection, Refresh)
* "This might work, but there would be very surprising consequences" (Set-Cookie, Link)
* "I can understand would this would mean, but the complexity to the system is not worth it" (Location, all cache-related headers, auth headers)
* "This cannot possibly work, it MUST be in the header" (CSP, X-Content-Type-Options, really just about every header)

Not to mention the unbounded use of headers in web content. We can't make XHRs suddenly see trailers mixed into headers without warning.

Given that all existing code and headers have been designed without trailers in mind, I think the only answer is that we MUST break the correspondence between header and trailer semantics. Trailers and headers must be considered completely unrelated animals. Unless something is explicitly specified as a trailer, it will be treated as an unknown header. Anything else welcomes unexpected security problems, bizarre behaviors, and surprise interop failures when two implementations disagree on which headers would be too hard to process streaming.

Even after accepting that, there are significant costs. The current core data model for a network request is very simple: you have an atomic set of request headers, sometimes a body stream, and the net stack gives you back an atomic set of response headers followed by a body stream. There's side fluff around redirects and auth hooks and MIME sniffing and such, but that's the core abstraction. It's very clean. We can build a clear division of responsibility between the atomic response headers and streaming body. This is how navigation works, this is how some servers work (as Ryan noted), etc.

Changing that core data model is not a small change. This affects not just fetch, but everything in a browser's network stack from the low-level HTTP implementation to the disk cache to any hooks (extensions, etc.) to web content to all the layers in between.

I think the use cases need to be exceedingly compelling to entertain this.

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