Re: [Technical Errata Reported] RFC7230 (4667)

"Roy T. Fielding" <fielding@gbiv.com> Thu, 14 April 2016 18:25 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 A86F212D7E0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Apr 2016 11:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.017
X-Spam-Level:
X-Spam-Status: No, score=-8.017 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, RP_MATCHES_RCVD=-0.996, 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 eyCs6quCENRr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Apr 2016 11:25:42 -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 4FD2012D665 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 14 Apr 2016 11:25:41 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aqlt2-0008DD-Ry for ietf-http-wg-dist@listhub.w3.org; Thu, 14 Apr 2016 18:21:04 +0000
Resent-Date: Thu, 14 Apr 2016 18:21:04 +0000
Resent-Message-Id: <E1aqlt2-0008DD-Ry@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 1aqlsy-0008CR-4v for ietf-http-wg@listhub.w3.org; Thu, 14 Apr 2016 18:21:00 +0000
Received: from sub4.mail.dreamhost.com ([69.163.253.135] helo=homiemail-a31.g.dreamhost.com) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <fielding@gbiv.com>) id 1aqlsu-0005E9-5x for ietf-http-wg@w3.org; Thu, 14 Apr 2016 18:20:59 +0000
Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 4E5C920206B; Thu, 14 Apr 2016 11:20:19 -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=ZY7m1eAdysTF2ikHalWHRNM3ZC4=; b=SZ4aft83lczKau0nvZa+TeLWnMT1 b013l3lwuRJdXSwylYwHzAf8zpKaGWF6Bk1eUOtutJ6kNypeOOKUofwb20qhpHDP o887B8C7AGy8YPwh+FG62HF9pRrDO9NYrT3UGJcRCxs0UPNzHK4zoLD7ttupksqr 9slPMrlba6sZj48=
Received: from [172.24.42.144] (unknown [192.150.9.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 59F4E202038; Thu, 14 Apr 2016 11:20:18 -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: <7D00E3E0-6502-4A53-BEA1-FF36E8AB3857@mnot.net>
Date: Thu, 14 Apr 2016 12:20:12 -0600
Cc: Willy Tarreau <w@1wt.eu>, RFC Errata System <rfc-editor@rfc-editor.org>, Julian Reschke <julian.reschke@greenbytes.de>, Ben Campbell <ben@nostrum.com>, Alissa Cooper <alissa@cooperw.in>, Alexey Melnikov <aamelnikov@fastmail.fm>, Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FAF05BB6-A4DA-400E-9F92-550E215BC637@gbiv.com>
References: <20160413160504.63AB6180006@rfc-editor.org> <20160413163615.GE3262@1wt.eu> <7D00E3E0-6502-4A53-BEA1-FF36E8AB3857@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.2104)
Received-SPF: none client-ip=69.163.253.135; envelope-from=fielding@gbiv.com; helo=homiemail-a31.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-6.9
X-W3C-Hub-Spam-Report: AWL=-0.151, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1aqlsu-0005E9-5x 843e32efb86dc3000ba1f9bef15e3359
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Technical Errata Reported] RFC7230 (4667)
Archived-At: <http://www.w3.org/mid/FAF05BB6-A4DA-400E-9F92-550E215BC637@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31458
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 Apr 13, 2016, at 7:34 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Digging into the history of this a bit, I see that the implied WSP was made explicit as of draft -16:
>  https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-16#section-6.2.1
> ... and subsequently, Julian started to convert it to OWS.
> 
> However, Roy took it out with this commit:
>  https://github.com/httpwg/http11bis/commit/9ff47b1d187bbf2a#diff-48ead163ebcead27fb688b09acb76a43L2282
> 
> There doesn't seem to have been any discussion of that change on the list or the issue that the commit was linked to, and no one seems to have noticed until now.
> 
> Roy, any additional context here?

We discussed it as an editorial issue #36, mostly in Newport Beach and later in Prague, IIRC.
The question was whether the implied whitespace rule from HTTP/1.0 had ever been
intended to apply to chunked encoding (a feature added for HTTP/1.1 in the body of
a message).  It had not.  The next was if there were any examples we knew of where space
was included there.  None.  [ICAP, by the way, is not HTTP.]  That was all discussed
as part of addressing #36.

Later we deprecated extensions in #343, and then we brought them back but with
only the syntax that we know works (no implied whitespace).  Hence, we didn't have the
history or implementations to justify unnecessary whitespace.

Apache httpd's chunk parser doesn't make use of chunk-ext unless it is bypassed
(i.e., a module can implement its own chunk parser).  The core will allow up to
10 bad whitespace between the chunk-size and chunk-ext (to allow for space-padding
of the chunk-size in fixed buffers), and then skip anything other than invalid
control chars between the ";" and the end of line; i.e.,

   chunk-ext      = 0*10<BWS> ";" *( OWS / VCHAR / )

IOW, that parser would support such a fix, but only by accident.  I seriously doubt
we can assume that arbitrary HTTP implementations would expect whitespace in those
places.  It was a stretch to expect that all implementations can handle chunk-ext,
but at least for that we had examples of how they would be implemented.

I don't have a problem with adding whitespace back in there, but I am not at all
confidant that such a choice would be less likely to break things.  I don't want
to play errata ping pong.

....Roy

>> On 14 Apr 2016, at 2:36 AM, Willy Tarreau <w@1wt.eu> wrote:
>> 
>> On Wed, Apr 13, 2016 at 09:05:04AM -0700, RFC Errata System wrote:
>>> The following errata report has been submitted for RFC7230,
>>> "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
>>> 
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=7230&eid=4667
>>> 
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Alex Rousskov <rousskov@measurement-factory.com>
>>> 
>>> Section: 4.1.1
>>> 
>>> Original Text
>>> -------------
>>> chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
>>> 
>>> 
>>> Corrected Text
>>> --------------
>>> chunk-ext      = *( ";" OWS chunk-ext-name [ "=" chunk-ext-val ] )
>>> 
>>> Notes
>>> -----
>>> The infamous "implicit *LWS" syntax rule in RFC 2616 allowed whitespace between ";" and chunk-ext-name in chunk-ext. Some HTTP agents generate that whitespace. In my experience, HTTP agents that can parse chunk extensions usually can handle that whitespace. Moreover, ICAP, which generally relies on HTTP/1 for its message syntax, uses that whitespace when defining the "ieof" chunk extension in RFC 3507 Section 4.5:
>>> 
>>>     \r\n
>>>     0; ieof\r\n\r\n
>>> 
>>> IMHO, RFC 7230 should either allow OWS before chunk-ext-name or at the very least explicitly document the HTTP/1 syntax change and its effect on parsers used for both ICAP and HTTP/1 messages (a very common case for ICAP-supporting HTTP intermediaries and ICAP services).
>>> 
>>> I also recommend adding BWS around "=", for consistency and RFC 2616 backward compatibility reasons. HTTPbis RFCs already do that for transfer-parameter and auth-param that have similar syntax.
>>> 
>>> Please also consider adding OWS _before_ ";" for consistency and RFC 2616 backward compatibility reasons. HTTPbis RFCs already do that for transfer-extension, accept-ext,  t-ranking, and other constructs with similar syntax.
>>> 
>>> If all of the above suggestions are applied, the final syntax becomes:
>>> 
>>> chunk-ext      = *( OWS  ";" OWS chunk-ext-name [ BWS  "=" BWS chunk-ext-val ] )
>>> 
>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party (IESG)
>>> can log in to change the status and edit the report, if necessary. 
>>> 
>>> --------------------------------------
>>> RFC7230 (draft-ietf-httpbis-p1-messaging-26)
>>> --------------------------------------
>>> Title               : Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
>>> Publication Date    : June 2014
>>> Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
>>> Category            : PROPOSED STANDARD
>>> Source              : Hypertext Transfer Protocol Bis APP
>>> Area                : Applications
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>> 
>> 
>> I think Alex is prefectly right here. I remember we spent less time on
>> chunk extensions by lack of clearly identified users, so it's very likely
>> that some corner cases slipped through the cracks. 
>> 
>> FWIW, haproxy does indeed accept spaces above as Alex suggests them.
>> 
>> Regards,
>> Willy
>> 
>> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
>