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

@igrigorik my suggestion was based on the argument that trailers are not appropriate to use as they are too easily conflated with headers along the way. That seems to be more or less what rsleevi and davidben are arguing.

Based on that constraint, I argued that what you really require is not trailers but rather non header meta data and I observe that H2 has a mechanism for sending N blobs linked to a single client request (PUSH). Obviously, not everybody thinks about the mechanism in that way but I'm actually pretty excited about it. Its on my TODO list to propose a way to surface this generically in web space (there is a priv'd interface for Firefox bits to get it already). This is an obvious way to scope pushed notifications - for example.

The proposal here (which I'm not invested in, I've just enjoyed explaining some corners of the spec.. its like a ietf whatwg mashup :)) - uses a special case.

Its not hard to imagine this as a name/value map of N pushed resources rather than just "trailers".

fwiw I wouldn't expect you would cache  anything under the well-known URL cache key - you would add it to the fetch()d response on the side as some kind of metadata.. the same way you would presumably end up storing h1 trailers (because mixing them with headers is dangerous).

as for the argument that it requires new technology: guilty.

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