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

"Roy T. Fielding" <> Thu, 15 September 2016 20:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F40C512B023 for <>; Thu, 15 Sep 2016 13:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.528
X-Spam-Status: No, score=-8.528 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.001, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3hQzpVO2OoBh for <>; Thu, 15 Sep 2016 13:17:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F4E512B3AE for <>; Thu, 15 Sep 2016 13:17:57 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bkd2M-0007Oc-It for; Thu, 15 Sep 2016 20:13:34 +0000
Resent-Date: Thu, 15 Sep 2016 20:13:34 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bkd2G-0007Mn-DS for; Thu, 15 Sep 2016 20:13:28 +0000
Received: from ([] by with esmtps (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1bkd2D-0004MN-OO for; Thu, 15 Sep 2016 20:13:27 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 59FE760005307; Thu, 15 Sep 2016 13:13:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=qIzeSwIo3Km4YYTXPRpQA99NR0Y=; b=FS1zyv8KmNbEWC3EqDudsZfs/5XK X4Rk8EK19I6MJQXp+Mkgmg2ZvfMh858JWdCwGGHRHZVuUS1Vfm+pVO9jBE2Ej8bC rtRb9wJbXM/86rWi2YiR3KRrFdR9t5n2iPMnhGhQLl9xexqrBb0cUcninNY2ZLlx NYpOT6V7tbWYqVk=
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 2AE9660005306; Thu, 15 Sep 2016 13:13:02 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Thu, 15 Sep 2016 13:13:01 -0700
Cc: Kazuho Oku <>, Mark Nottingham <>, HTTP Working Group <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <>
To: Willy Tarreau <>
X-Mailer: Apple Mail (2.2104)
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.6
X-W3C-Hub-Spam-Report: AWL=0.930, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1bkd2D-0004MN-OO b9fdc7543362acb6c77dceb613531770
Subject: Re: Distinguishing 0-byte request body in HTTP/2
Archived-At: <>
X-Mailing-List: <> archive/latest/32403
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On Sep 15, 2016, at 12:00 AM, 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. 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.