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

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

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40C512B023 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 15 Sep 2016 13:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.528
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hQzpVO2OoBh for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 15 Sep 2016 13:17:58 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4E512B3AE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 15 Sep 2016 13:17:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bkd2M-0007Oc-It for ietf-http-wg-dist@listhub.w3.org; Thu, 15 Sep 2016 20:13:34 +0000
Resent-Date: Thu, 15 Sep 2016 20:13:34 +0000
Resent-Message-Id: <E1bkd2M-0007Oc-It@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <fielding@gbiv.com>) id 1bkd2G-0007Mn-DS for ietf-http-wg@listhub.w3.org; Thu, 15 Sep 2016 20:13:28 +0000
Received: from sub5.mail.dreamhost.com ([208.113.200.129] helo=homiemail-a122.g.dreamhost.com) by lisa.w3.org with esmtps (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <fielding@gbiv.com>) id 1bkd2D-0004MN-OO for ietf-http-wg@w3.org; Thu, 15 Sep 2016 20:13:27 +0000
Received: from homiemail-a122.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a122.g.dreamhost.com (Postfix) with ESMTP id 59FE760005307; Thu, 15 Sep 2016 13:13:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=qIzeSwIo3Km4YYTXPRpQA99NR0Y=; b=FS1zyv8KmNbEWC3EqDudsZfs/5XK X4Rk8EK19I6MJQXp+Mkgmg2ZvfMh858JWdCwGGHRHZVuUS1Vfm+pVO9jBE2Ej8bC rtRb9wJbXM/86rWi2YiR3KRrFdR9t5n2iPMnhGhQLl9xexqrBb0cUcninNY2ZLlx NYpOT6V7tbWYqVk=
Received: from [192.168.1.3] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a122.g.dreamhost.com (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" <fielding@gbiv.com>
In-Reply-To: <20160915070000.GA4273@1wt.eu>
Date: Thu, 15 Sep 2016 13:13:01 -0700
Cc: Kazuho Oku <kazuhooku@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: 7bit
Message-Id: <0D85D464-2BF1-4959-A73F-7E43DD2CC8DD@gbiv.com>
References: <CANatvzzZsd1HfCWowjXc5UwmgDgUqjRs3vyyU1qtyvKkPub7Fw@mail.gmail.com> <EEF6459F-D45A-40B2-AEF9-8E2F1C4E1C24@mnot.net> <CANatvzxyBbk2DfGd+0B_+pMpgWN6C_6O3FYUy_HcC5P5EtrOvg@mail.gmail.com> <20160915070000.GA4273@1wt.eu>
To: Willy Tarreau <w@1wt.eu>
X-Mailer: Apple Mail (2.2104)
Received-SPF: none client-ip=208.113.200.129; envelope-from=fielding@gbiv.com; helo=homiemail-a122.g.dreamhost.com
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: lisa.w3.org 1bkd2D-0004MN-OO b9fdc7543362acb6c77dceb613531770
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Distinguishing 0-byte request body in HTTP/2
Archived-At: <http://www.w3.org/mid/0D85D464-2BF1-4959-A73F-7E43DD2CC8DD@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32403
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> 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