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

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.

On Mon, 25 Jan 2021 at 10:06, Seph Gentle <me@josephg.com> 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
>
>

Received on Monday, 25 January 2021 11:48:06 UTC