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

Kazuho Oku <kazuhooku@gmail.com> Tue, 20 September 2016 01:11 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 A8B5212B158 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Sep 2016 18:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.837
X-Spam-Level:
X-Spam-Status: No, score=-8.837 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.5, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 A6Vh_uBdBqDe for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Sep 2016 18:11:52 -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 75307127078 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 19 Sep 2016 18:11:52 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bm9XS-00040E-EK for ietf-http-wg-dist@listhub.w3.org; Tue, 20 Sep 2016 01:07:58 +0000
Resent-Date: Tue, 20 Sep 2016 01:07:58 +0000
Resent-Message-Id: <E1bm9XS-00040E-EK@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1bm9XG-0003xq-89 for ietf-http-wg@listhub.w3.org; Tue, 20 Sep 2016 01:07:46 +0000
Received: from mail-wm0-f46.google.com ([74.125.82.46]) by maggie.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1bm9XE-0003J4-HE for ietf-http-wg@w3.org; Tue, 20 Sep 2016 01:07:45 +0000
Received: by mail-wm0-f46.google.com with SMTP id a25so7032676wmi.1 for <ietf-http-wg@w3.org>; Mon, 19 Sep 2016 18:07:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JB7GoXPlBz3h+EDdRs27kSK9zOsUSBA29O/c9QEhnJs=; b=ksvKP3JKcNMJBs4tW6ptIPbfk3G85fDg+Qw+3raVANduOkbJEe8WOUxVuhdHxOjlgN AKhJSABwzCNKOEbvGcQ+yiuFULpZd/Rtc9TaZTU03ahvWQEjv0GKntGkvbd4N/NX7ny4 OvBpo49hR+SBPCZCs57AXpn+0EbFD0VFUg3StWZkiRAR85ITANvDg4kM5u/sCwI7zKVg Xzyrr8F27ZjRoNvH1QINpViOshMzXxK6Rc6KSxGsl5b6wRiahxdB8uVsTFwSvLIWD+4H tjeRthUS/7PTiPR175gIe8KIJ+HDZ0efAEirlXvpCNY3+vlA179hIKCj3BtorrHtSVyV +tnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JB7GoXPlBz3h+EDdRs27kSK9zOsUSBA29O/c9QEhnJs=; b=avMCX7ynHnGaG9H5nGCnHrf2ktj/f2Yhs8ljPyvsRPwTc1PBoW8lIF0sXFE2fRiqX8 dqah6F9PGkhzR6aVed7U6aCTv7AtE5t8BmbWqGkJVCPiDq0TSD5c1KlbNERgdpC1jEQl T/5GZO08tdoYtKS696hsqVUl74WEkSuf1045OA4Tm/n4P0DnZaLGdaek92Iqg1Hwodww PJusikz5FXPlzGZU2t30NfdBq5DQp8uc+FKxTYP2lSGsa77zz240tbSGptP5OsKvm31H Je5KiVhAWZdajKwte8Xk4/irehVAX+Z2hLPT7ao1qsx2doWPeT2dw/5aMABLtdUB0KNW RgUg==
X-Gm-Message-State: AE9vXwMAeeeGgMdI/OLZBQaWARWg3uWdJOSmGyQdkwpwQOImNxqXzLOCX5PkOZPo2R5gKjS9Oh20Ha8j2AS6RQ==
X-Received: by 10.194.68.8 with SMTP id r8mr25680755wjt.190.1474333637420; Mon, 19 Sep 2016 18:07:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.122.67 with HTTP; Mon, 19 Sep 2016 18:07:16 -0700 (PDT)
In-Reply-To: <20160915070000.GA4273@1wt.eu>
References: <CANatvzzZsd1HfCWowjXc5UwmgDgUqjRs3vyyU1qtyvKkPub7Fw@mail.gmail.com> <EEF6459F-D45A-40B2-AEF9-8E2F1C4E1C24@mnot.net> <CANatvzxyBbk2DfGd+0B_+pMpgWN6C_6O3FYUy_HcC5P5EtrOvg@mail.gmail.com> <20160915070000.GA4273@1wt.eu>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Tue, 20 Sep 2016 10:07:16 +0900
Message-ID: <CANatvzzbe+fNrp8qy1nhtiiZXwfir=guC+YjrHFJA=GsEO5FXA@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=74.125.82.46; envelope-from=kazuhooku@gmail.com; helo=mail-wm0-f46.google.com
X-W3C-Hub-Spam-Status: No, score=-5.2
X-W3C-Hub-Spam-Report: AWL=-1.030, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bm9XE-0003J4-HE ce6f20721549e5bea04805d399a25fb3
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/CANatvzzbe+fNrp8qy1nhtiiZXwfir=guC+YjrHFJA=GsEO5FXA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32411
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>

Hi, Willy, Mark, Roy,

Thank you for your insights.

2016-09-15 16:00 GMT+09:00 Willy Tarreau <w@1wt.eu>:

> 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.

Although there is no distinction between a request with a zero-byte
body and a request without a body, I agree that it might be a good
idea to send `content-length: 0` for some methods (e.g. POST), whereas
for others it would be a good idea to _not_ send `content-length: 0`
(e.g. GET).

I now understand that suggestions for existing methods are given in
RFC 7231. For example, section 4.3.1 states:

   A payload within a GET request message has no defined semantics;
   sending a payload body on a GET request might cause some existing
   implementations to reject the request.

Similar statements exist for other methods.

And the recommendation made for methods that are defined outside of
HTTP/1.1 is defined in section 8.1.2 (thanks to Mark for pointing it
out), quote:

   Since message parsing (Section 3.3 of [RFC7230]) needs to be
   independent of method semantics (aside from responses to HEAD),
   definitions of new methods cannot change the parsing algorithm or
   prohibit the presence of a message body on either the request or the
   response message.  Definitions of new methods can specify that only a
   zero-length message body is allowed by requiring a Content-Length
   header field with a value of "0".


> Regards,
> Willy



-- 
Kazuho Oku