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

From: "Seph Gentle" <[email-masked]>
Date: Fri, 22 Jan 2021 11:05:06 +1100

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 25 Jan 2021 10:07:33 +0000

--------
Seph Gentle writes:

> 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 ?

I would not do it if I were you.

I realize we're on the server siden, but Varnish Cache will not propagate
chunked boundaries unharmed.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 25 Jan 2021 11:23:00 +0100

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 <[email-masked]> 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.
>
> 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 <[email-masked]> CTO http://webtide.com

---

From: Cory Benfield <[email-masked]>
Date: Mon, 25 Jan 2021 11:47:39 +0000

I'll echo the concerns of the group, and add that the HTTP
specifications explicitly call out that this usage is not
interoperable. Citing the upcoming HTTP/1.1 message syntax draft § 6.1
Transfer Encoding
(https://www.ietf.org/archive/id/draft-ietf-httpbis-messaging-14.html#name-transfer-encoding):

>  Unlike Content-Encoding (Section 8.4.1 of [Semantics]), Transfer-
>  Encoding is a property of the message, not of the representation, and
>  any recipient along the request/response chain MAY decode the
>  received transfer coding(s) or apply additional transfer coding(s) to
>  the message body, assuming that corresponding changes are made to the
>  Transfer-Encoding field value.

In this case, I'd recommend just adding your own framing. The chunked
transfer encoding framing is essentially trivial (regular old
length-prefixed-framing plus some newlines for extra flavour), and
easily replicated within your message body if you're motivated to do
so.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 25 Jan 2021 12:55:12 +0100

> chunked boundaries unharmed.

Neither will haproxy. And any agent supporting both H1 and H2 will have
a hard time coping with this as well.

Willy

---

From: "Seph Gentle" <[email-masked]>
Date: Mon, 25 Jan 2021 23:00:25 +1100

Great; good to know; much appreciated. I knew http2 had a different chunking method, but I was curious about whats appropriate for http1.1.

I think the other danger would be gzip encoding. Because content is gzipped before its chunked, preserving chunk boundaries through gzip encoding would probably be tricky to implement on top of a lot of current HTTP server APIs.

Anyway, we'll stick to implementing our own chunking behaviour on top of HTTP.

Re: SSE, Server-sent events are quite well supported in the wild, but the browser's API for SSE has some serious limitations. The biggest issue is that it doesn't support passing authentication cookies. In an issue discussing the problem some chrome engineers said they support not fixing the issue because SSE can simply be reimplemented, better, on top of JS's fetch() api anyway. And if thats true, from the perspective of the server and the browser there's nothing special about server-sent events as a protocol. And no reason to use SSE in particular over something more specialized for the task.

-Seph

On Mon, Jan 25, 2021, at 9:23 PM, Greg Wilkins wrote:
> 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
> 
> 
> 
> 
>

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 25 Jan 2021 10:23:18 -0500

On 1/25/21 6:55 AM, Willy Tarreau wrote:
>>> Does 

>> Varnish Cache will not propagate chunked boundaries unharmed.

> Neither will haproxy.

Neither will Squid.

Alex.

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 25 Jan 2021 16:49:53 +0100

> Am 25.01.2021 um 16:23 schrieb Alex Rousskov <[email-masked]>:
> 

You may get lucky in Apache, for a while, when the wind blows in the right direction, but I would not count on it.

- Stefan