Re: Distinguishing 0-byte request body in HTTP/2

> On 15 Sep 2016, at 5:00 PM, Willy Tarreau <> wrote:
> Hi Kazuho,
> On Thu, Sep 15, 2016 at 09:09:42AM +0900, Kazuho Oku wrote:
>> Hi,
>> Thank you very much for the clarification.
>> So to paraphrase, the general rule for handling request body is
>> defined in section 3.3.3 of RFC 7230 as:
>>   6.  If this is a request message and none of the above are true, then
>>       the message body length is zero (no message body is present).
>> which means that in HTTP, there is no distinction between a request
>> with zero-length body and a request _without_ a body.
>> That means it is completely up to the HTTP client to whether or not to
>> send `content-length: 0` for such requests, though each implementation
>> may decide to send or not, depending on interoperability issues that
>> might exist.
> In fact there exists a corner case, some servers return 411 in response
> to a POST without a content-length.

That's a bit different; the message is still delimited in the same way, but the server is saying that it wants to know the length up-front (for purposes other than figuring out where it ends; usually, to figure out if it's willing to accept it).

> Thus I'd suggest that the client
> always emits the content-length when it considers that semantically it
> emits a body even if it's empty. Let's imagine a disk backup tool uploading
> files over HTTP, using a few header fields to pass file name, permissions
> and various meta-data. Some files may be empty, and regardless of this they
> are sent. In this case it totally makes sense to emit "content-length: 0".
> I'd be tempted to simplify this as "if you're sending a body even an empty
> one, announce its size in content-length". Methods like POST and PUT expect
> a message body so that should always be done.

That's a bit too simple. Keep in mind that for HTTP/1.1,

"A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field." <>

Also, don't put C-L: 0 on 304 et al! :)


Mark Nottingham

Received on Thursday, 15 September 2016 08:48:02 UTC