Transfer-Encoding: Chuxed

gistfile1.md

In HTTP/1.1, Transfer-Encoding: chunked allows servers to stream responses to clients in pieces without knowing the length in advance, which is useful in, for example, chat and live streaming applications.

HTTP/1.1 also allows request pipelining, which lets clients do multiple get requests in parallel, saving the latency overhead of opening a new TCP socket for each one.

It's not currently possible to use both of these things together, because chunks in HTTP chunked encoding don't have any information in them about which stream they came from. Chunks are <length field>\r\n<data>.

But if a new transfer-encoding were added that had stream ids, you could do multiple requsts in parallel even if the responses were streamed. Let's call this encoding Transfer-Encoding: chuxed (for "chunked, multiplexed").

There are two differences between chuxed and chunked:

1. The server sends a header in the response that contains a unique stream id for that response (eg: Stream-ID: 5)
2. Instead of each chunk being <length field>\r\n<data>, it's <stream-id>\r\n<length field>\r\ndata

A good way for the server to generate stream ids is by having a monotonically increasing counter that it increments with each request, but I don't see any reason to have the spec care about what format the stream id is in as long as it doesn't contain \r\n.

How do you multiplex response headers? How about request headers?

In this proposal it’s just request pipelining. You send a fixed number of requests at the beginning, and you wait for that many responses before you expect to start getting response bodies. That doesn’t allow you to send new requests down an already-open socket that you didn’t know about at the beginning.

If that was a thing that you wanted to do, you could have the client pick the stream ids, and prefix the beginning of HTTP responses with the stream id as well.