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

@sleevi I take your point about the separation of trust between header production & 'everything afterwards' in some systems but I don't think anyone should be relying on browsers as the last-line of defense against these issues. Caching / De-chunking proxies are free to promote trailers into headers & HTTP/1.1 keep-alive requires servers to observe a chunked response for termination.

I note that a lot of the discussion here is focused on how the browser should interpret and enforce policy around trailers when things like (Alt-Svc, Set-Cookie, HPKP are present in trailers). With the possible exception of ETag / Content-MD5 (and @mnot my have some others) my assumption was that the browser would continue to ignore headers from an internal processing perspective just as they do today. That is to say that trailers have no semantic meaning to the browser and they are simply made available for programmatic use by developers in the fetch API. 

@davidben - I don't think anyone is suggesting mixing trailers into headers in XHR. That's a de facto standard and changing it's contract would be a very bad idea. The proposal is to allow for them in fetch possibly as en explicitly separate feature from headers as it's an entirely new interface and so would not disrupt existing usages. 

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