Re: Transfer-Encoding chunked: preserved in the wild?

[Greg Wilkins <[e-mail]>]

I also do not think this is a workable solution.  Various middleman's
implemented with Jetty do not preserve chunk boundaries. Buffering and
processing may add extra chunks, amalgamate chunks or even replace them
with a content-length.   Also chunking is not applicable to HTTP >= 2.

There is server sent events... but not sure how well that is supported in
the wild.  We implement it, but have very little evidence of it being used.

Websocket or long polling are your best bet for multiple sending events
server to client.

cheers





On Mon, 25 Jan 2021 at 11:06, Seph Gentle <[e-mail]> wrote:

> Hi everyone!
>
> I’m working with Mike and others to figure out & clean up the protocol for
> braid. We want to add real-time subscriptions to http.
>
> For this we need to send a stream of messages (values and patches) in
> response to a single http request. The simplest way to encode that would be
> to lean on transfer-encoding: chunked and wrap each patch in exactly one
> http “chunk”, so we don’t need to do our own message framing.
>
> I want to lean on some collective wisdom here. Is this a bad idea? Does
> anyone know if middleman proxy servers ever move chunk boundaries around?
> Is that valid according to the protocol? Is that something we should worry
> about?
>
> (Server sent events do their own message framing on top of the transfer
> encoding. Is there a good reason for that?).
>
> -Seph
>
>
>

-- 
Greg Wilkins <[e-mail]> CTO http://webtide.com