Re: [Technical Errata Reported] RFC7231 (5806)

Willy Tarreau <w@1wt.eu> Mon, 12 August 2019 21:21 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 43C10120089 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 12 Aug 2019 14:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 jhEjSZI4mXjK for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 12 Aug 2019 14:21:40 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C809812126E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 11 Aug 2019 22:53:34 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hx3EM-0000v0-FN for ietf-http-wg-dist@listhub.w3.org; Mon, 12 Aug 2019 05:50:54 +0000
Resent-Date: Mon, 12 Aug 2019 05:50:54 +0000
Resent-Message-Id: <E1hx3EM-0000v0-FN@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <w@1wt.eu>) id 1hx3EI-0000uB-3L for ietf-http-wg@listhub.w3.org; Mon, 12 Aug 2019 05:50:50 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by titan.w3.org with esmtp (Exim 4.89) (envelope-from <w@1wt.eu>) id 1hx3EF-0000te-2Z for ietf-http-wg@w3.org; Mon, 12 Aug 2019 05:50:49 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x7C5nraj003148; Mon, 12 Aug 2019 07:49:53 +0200
Date: Mon, 12 Aug 2019 07:49:53 +0200
From: Willy Tarreau <w@1wt.eu>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: fielding@gbiv.com, julian.reschke@greenbytes.de, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, mnot@mnot.net, patrick.ducksong@gmail.com, tpauly@apple.com, andersk@mit.edu, ietf-http-wg@w3.org
Message-ID: <20190812054953.GA3133@1wt.eu>
References: <20190812022730.63FF7B8132E@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190812022730.63FF7B8132E@rfc-editor.org>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-6.8
X-W3C-Hub-Spam-Report: AWL=1.104, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hx3EF-0000te-2Z a0e8bf7c4cbea83418eb6219eecb810e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Technical Errata Reported] RFC7231 (5806)
Archived-At: <https://www.w3.org/mid/20190812054953.GA3133@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36970
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Sun, Aug 11, 2019 at 07:27:30PM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC7231,
> "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5806
> 
> --------------------------------------
> Type: Technical
> Reported by: Anders Kaseorg <andersk@mit.edu>
> 
> Section: 4.3.7
> 
> Original Text
> -------------
> A server MUST generate a Content-Length field with a value of "0" if no
> payload body is to be sent in the response.
> 
> Corrected Text
> --------------
> If no payload body is to be sent in the response, a server MUST
> generate a status code of 204 (No Content) or a Content-Length field
> with a value of "0" (but not both).
> 
> Notes
> -----
> The original text contradicts RFC 7230 ยง3.3.2: "A server MUST NOT send a
> Content-Length header field in any response with a status code of 1xx
> (Informational) or 204 (No Content)", unless the intention was to disallow
> all 204 responses to OPTIONS requests, which I assume it was not.

Indeed, it seems valid to me. With this said, I don't know how common
it is to respond with 204 to an OPTIONS request given that 204 is
reportedly cacheable by default (6.3.5) while OPTIONS is said not to
be. Thus more confusion may arise on this point as well.

Willy