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

I'm not sure I follow. Trailers don't have any magic as far as termination is concerned. If the connection to the server is shut off, we're not going to get the trailers either. HTTP/2, for all the bells and whistles, is still sent over a byte stream.

Changing the schema for a termination signal sounds about right? You're sending a sequence of objects terminated by another object. Trailers just make this more confusing. Now, as a client, I have to care about what it means if the peer sends half a status and then stops with a trailer.

In the case of extra formats, this proposal isn't going to help the video tag anyway, no? It's only if you do a low-level `fetch()` in JS. That data needs to be plumbed your video elements some other way (Media Source Extensions?). I dunno, if you're so set on trailers, you could just completely emulate them with a single outer MIME type which parses to a wrapper stream of inner MIME type + data + trailer. The outer MIME type really doesn't matter much because it's only processed by your JS code anyway.

It seems, even if `fetch()` gets this feature, you need this wrapper type anyway. Say your Twitter example wanted to use trailers. They still need a story for older browsers. (Given how incredibly invasive this change would be, I'm dubious every browser will be convinced, certainly not without demonstrated need.)

If there's no fundamental new capability, these kinds of polyfills are really the right way to get this kind of APIs into a browser. They are already necessary for deployment and can evolve much faster into the right solution for some use case, rather than the first one we thought of at the time. Successful JS experiments demonstrate need and use-cases. Those beget candidates for browser APIs. (Only candidates, not guarantees; again, changing the core data model like this is not a small change. This has one of the highest bars a network feature could have.)

Remember, HTTP trailers *do not exist* as far as browsers are concerned. You have to imagine this as if someone's proposing adding a brand new unheard of HTTP semantic to browsers. That they're already spec'd is, if anything, a drawback. That means the latent threat of compatibility problems is worse because the install-base may already try to speak it.

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