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

> On Sep 15, 2016, at 12:00 AM, Willy Tarreau <w@1wt.eu> 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. 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.

No.  It is never a good idea to send extra information just in case you
might encounter a broken server.  It is better to send less information and
let people fix their own broken code.  Otherwise, the Internet becomes a
cesspool of poorly imagined cases that are far less likely to exist than
the keel-over-waiting-for-the-extra-TCP-packets cases that always exist.

....Roy

Received on Thursday, 15 September 2016 20:13:28 UTC