[Errata Rejected] RFC7231 (4351)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 01 June 2015 16: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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813AC1A0178 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 1 Jun 2015 09:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 SOOm6vL6YiyK for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 1 Jun 2015 09:11:02 -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 11C781B2C6A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 1 Jun 2015 09:04:09 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YzS8Y-0008RF-Dp for ietf-http-wg-dist@listhub.w3.org; Mon, 01 Jun 2015 16:00:26 +0000
Resent-Date: Mon, 01 Jun 2015 16:00:26 +0000
Resent-Message-Id: <E1YzS8Y-0008RF-Dp@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 <wwwrun@rfc-editor.org>) id 1YzS8J-0007dq-TY for ietf-http-wg@listhub.w3.org; Mon, 01 Jun 2015 16:00:11 +0000
Received: from rfc-editor.org ([4.31.198.49]) by lisa.w3.org with esmtp (Exim 4.80) (envelope-from <wwwrun@rfc-editor.org>) id 1YzS8I-0006Pl-N2 for ietf-http-wg@w3.org; Mon, 01 Jun 2015 16:00:11 +0000
Received: by rfc-editor.org (Postfix, from userid 30) id 1813D180092; Mon, 1 Jun 2015 08:57:23 -0700 (PDT)
To: nico@cryptonector.com, fielding@gbiv.com, julian.reschke@greenbytes.de
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: barryleiba@computer.org, iesg@ietf.org, ietf-http-wg@w3.org, rfc-editor@rfc-editor.org
Message-Id: <20150601155723.1813D180092@rfc-editor.org>
Date: Mon, 01 Jun 2015 08:57:23 -0700
Received-SPF: pass client-ip=4.31.198.49; envelope-from=wwwrun@rfc-editor.org; helo=rfc-editor.org
X-W3C-Hub-Spam-Status: No, score=-9.2
X-W3C-Hub-Spam-Report: AWL=3.748, BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1YzS8I-0006Pl-N2 f96f185959aadc72f37e0ab0fe0993bc
X-Original-To: ietf-http-wg@w3.org
Subject: [Errata Rejected] RFC7231 (4351)
Archived-At: <http://www.w3.org/mid/20150601155723.1813D180092@rfc-editor.org>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29672
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>
The following errata report has been rejected for RFC7231, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7231&eid=4351 -------------------------------------- Status: Rejected Type: Technical Reported by: Nicolas Williams <nico@cryptonector.com> Date Reported: 2015-04-29 Rejected by: Barry Leiba (IESG) Section: 4.3.6 Original Text ------------- A server MUST NOT send any Transfer-Encoding or Content-Length header fields in a 2xx (Successful) response to CONNECT. A client MUST ignore any Content-Length or Transfer-Encoding header fields received in a successful response to CONNECT. A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause some existing implementations to reject the request. Corrected Text -------------- Historically no semantics have been defined for request and 2xx (Successful) response bodies for CONNECT, but nonetheless some clients and some servers do use request and 2xx response bodies. Servers MUST NOT send a response body in a 2xx (Successful) response to CONNECT. Because some proxies send an initial flight of tunneled application data in 2xx response bodies, clients MUST accept response bodies in 2xx responses to CONNECT, and MUST treat the response body as the initial flight of application data. Servers that receive a CONNECT request body SHOULD treat it as the initial flight of tunneled application data. Notes ----- Implementing the original text ("A client MUST ignore...") has the effect that the client will leave in the lower layer's buffer any 2xx CONNECT response body, and when the Transfer-Encoding is the identity, then this will have the effect that the 2xx response body is seamlessly prepended to the tunneled application data in the server-to-client direction. It seems almost like this was the intent of the original text, but if so, then it would be much better to state this than to describe one possible implementation approach. Also, it seems rather unlikely that ignoring the Transfer-Encoding for any TE other than the identity. If the proxy really did use a compression or chunked transfer encoding, then ignoring this on the client side (and prepending the encoded 2xx response body to the server-to-client tunneled application data) would quite clearly be wrong. It also seems that some clients send the first flight of tunneled application data in a CONNECT request body. While historically the semantics of CONNECT request and 2xx response bodies have not been defined, it is worth pointing out that [it appears, so I'm told; see below] some clients and some proxies rely on CONNECT request and 2xx response bodies bearing the first flight of tunneled application data, and if so, then the RFC should mention it. I'm not sure how much evidence we can demand for such behaviors, but the RFC demands behavior that implies the intent described in this erratum and gives no evidence to support the need for such behavior, therefore it seems much better to describe the previously-implied intent explicitly and continue with a little-or-no-evidence approach that should nonetheless yield the most interoperability. Finally, I asked for clarification on the HTTPbis list, and the answers I received indicate that the intent may have been as described in these notes. See https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0260.html and follow-ups. --VERIFIER NOTES-- This is a change request, not an errata report. Such changes can be proposed in the working group's issue tracker, here: https://github.com/httpwg/http11bis/issues -------------------------------------- RFC7231 (draft-ietf-httpbis-p2-semantics-26) -------------------------------------- Title : Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content Publication Date : June 2014 Author(s) : R. Fielding, Ed., J. Reschke, Ed. Category : PROPOSED STANDARD Source : Hypertext Transfer Protocol Bis Area : Applications Stream : IETF Verifying Party : IESG
- [Technical Errata Reported] RFC7231 (4351) RFC Errata System
- Re: [Technical Errata Reported] RFC7231 (4351) Nico Williams
- Re: [Technical Errata Reported] RFC7231 (4351) Adrien de Croy
- Re: [Technical Errata Reported] RFC7231 (4351) Nico Williams
- Re: [Technical Errata Reported] RFC7231 (4351) Roy T. Fielding
- Re: [Technical Errata Reported] RFC7231 (4351) Nico Williams
- Re: [Technical Errata Reported] RFC7231 (4351) Roy T. Fielding
- Re: [Technical Errata Reported] RFC7231 (4351) Mark Nottingham
- Re: [Technical Errata Reported] RFC7231 (4351) Nico Williams
- Re: [Technical Errata Reported] RFC7231 (4351) Barry Leiba
- Re: [Technical Errata Reported] RFC7231 (4351) Amos Jeffries
- Re: [Technical Errata Reported] RFC7231 (4351) Willy Tarreau
- Re: [Technical Errata Reported] RFC7231 (4351) Mark Nottingham
- [Errata Rejected] RFC7231 (4351) RFC Errata System