Subject: How exactly should HTTP/1.1-proxy process a request with chunked body?

From: Semyon Kholodnov <[email-masked]>
Date: Tue, 16 Dec 2014 17:07:37 +0000

First of all, I'd like to thank everyone involved in writing RFC
7230–7235. These RFCs cleaned up lots of gray areas, and organized the
material better and more concise than RFC 2616 did.

However, there is still one particular corner case (see the topic
line) that wasn't explicitly dealt with, and I am not completely sure
what exactly RFC 7230 implies for it.

So, there's the scenario when an HTTP/1.1-compliant proxy receives an
HTTP/1.1-request with "Transfer-Encoding: chunked" header field, and
decides to forward this request to the origin server. RFC 7230
(section 2.6) says that

> When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
> or a recipient whose version is unknown, the HTTP/1.1 message is
> constructed such that it can be interpreted as a valid HTTP/1.0
> message if all of the newer features are ignored.

First, this paragraph implies that if the proxy doesn't know that the
origin server supports HTTP/1.1 (and I would argue that a proxy
*never* know this), it should not forward "Transfer-Encoding: chunked"
header field, and instead—since it still has to forward the body—it
has to insert a "Connection-Length" header. OTOH, this paragraph has
no "MUST" or "SHOULD" or any such words in it, and the remaining text
doesn't actually mandates this behaviour (section 3.3.3 requires user
agents to send a valid Content-Length header field when they don't
know if the server will handle HTTP/1.1 requests, but a proxy is not a
user agent).

So should the proxy actually buffer the whole body before forwarding
it? May it hope for the best and forward it in chunked form? In the
latter case it should be prepared not only to handle 411 status code
responses, but responses with status code 400 that say something like
"Content-Length header not found" and re-try the request. Of course, a
proxy may itself just reply with 411 status code, but it just shifts
the burden of buffering to client.

As for proxies in the field, I've observed some proxies to buffer
small requests and forward with Content-Length added, and either
refuse large request or forward them as chunked, while other proxies
simply refuse to accept requests with chunked bodies (replying with
status code 400 or 501). Are those behaviours compliant with RFC 7230?