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

I wouldn't say that the parsing separation is minimal overhead in the case of handling stream termination. JS code will rely on the HTTP parser for non-streaming status handling and stream initialization handling but will have to switch to payload parsing for stream termination status.

A payload and therefore it's mime type will have to describe how terminal statuses are encoded and make them reliable for the range of possible termination causes.  Consider an API like the Twitter streaming API which returns a homogeneous sequence of types in a stream

https://dev.twitter.com/streaming/reference/get/statuses/sample

If they wanted to convey a termination status after a period of time like 'Credential Expired' or 'Budget Spent' to a browser they are forced to change their schema. Today they just hard drop connections https://dev.twitter.com/streaming/overview/connecting which is not exactly pretty. 

Trailers solve this problem in a way that is also not subject to streamed message truncation causing the developers payload parser to get into an unrecoverable state which prevents it from parsing the special 'error' entry in the stream. 

It also wouldn't require new MIME types for commonly streamable formats like audio & video that want better termination handling though these are so valuable on the web that side-polling is used to bridge the gap when 'Rental Period Expired' kicks in :)

On the subject of compelling use-cases what kind of quantification would be persuasive?


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