Re: [Technical Errata Reported] RFC7230 (4667)

"Roy T. Fielding" <fielding@gbiv.com> Thu, 14 April 2016 22:44 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 2CB7E12DD77 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Apr 2016 15:44:51 -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 YK9cFcknnSHy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Apr 2016 15:44:49 -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 3790D12DC66 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 14 Apr 2016 15:44:49 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aqpvu-00008c-DK for ietf-http-wg-dist@listhub.w3.org; Thu, 14 Apr 2016 22:40:18 +0000
Resent-Date: Thu, 14 Apr 2016 22:40:18 +0000
Resent-Message-Id: <E1aqpvu-00008c-DK@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 1aqpvo-0008Vq-I4 for ietf-http-wg@listhub.w3.org; Thu, 14 Apr 2016 22:40:12 +0000
Received: from sub4.mail.dreamhost.com ([69.163.253.135] helo=homiemail-a85.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 1aqpvk-0005Nr-UB for ietf-http-wg@w3.org; Thu, 14 Apr 2016 22:40:12 +0000
Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 9BF14BBA076; Thu, 14 Apr 2016 15:39:45 -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=LAswJuXbNVr8xih0NKUlVInNEKY=; b=gN1MvE0ZggUwCm1x6n5CGfHZ2pO1 uZ24sAkXS/UUrG0Sw3BndTwN2Yw5X8sQmL0S13nmoXbp01TJ8S1RePiFbrYsqNqt cX5cf3tzR3R42HZhNA3wY7vD7A0UDjaX5TK+oofcohZhRnlpUD3xQu236ALvRJ25 Q2XiSYP0pbB0N3I=
Received: from [100.91.217.133] (118.sub-70-212-42.myvzw.com [70.212.42.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 300B9BBA075; Thu, 14 Apr 2016 15:39:45 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: "Roy T. Fielding" <fielding@gbiv.com>
X-Mailer: iPhone Mail (13E238)
In-Reply-To: <5710127C.1080007@measurement-factory.com>
Date: Thu, 14 Apr 2016 16:39:42 -0600
Cc: Mark Nottingham <mnot@mnot.net>, 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>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <38684D79-ED03-462E-8923-040EDD233F71@gbiv.com>
References: <20160413160504.63AB6180006@rfc-editor.org> <20160413163615.GE3262@1wt.eu> <7D00E3E0-6502-4A53-BEA1-FF36E8AB3857@mnot.net> <FAF05BB6-A4DA-400E-9F92-550E215BC637@gbiv.com> <5710127C.1080007@measurement-factory.com>
To: Alex Rousskov <rousskov@measurement-factory.com>
Received-SPF: none client-ip=69.163.253.135; envelope-from=fielding@gbiv.com; helo=homiemail-a85.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-6.7
X-W3C-Hub-Spam-Report: 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 1aqpvk-0005Nr-UB a0bb2f34980e715e7e226634aa3caa76
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Technical Errata Reported] RFC7230 (4667)
Archived-At: <http://www.w3.org/mid/38684D79-ED03-462E-8923-040EDD233F71@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31466
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>

Don't confuse the various lenient ways in which implementations parse HTTP with the requirements on generating HTTP messages that are defined by the ABNF. The ABNF is intended to be more restrictive. 

The scope of what Apache allows was reduced recently for security reasons, and I expect it to be reduced further the next time I get a chance to test and commit. Do not depend on such lenient parsing to exist in the future.  In many cases, we have just been waiting for RFC7230 to age enough before reducing the code substantially.

Likewise, don't confuse the parsing of ICAP messages (which are entirely defined by ICAP and its normative references) with requirements of RFC7230. If you need an exception, all you have to do is add it to ICAP  when (or if) that spec is updated to refer to RFC7230. ICAP hasn't changed until it does.

And, no, it is NEVER a good idea for new IETF protocols to effectively alias other IETF protocols. That has been proven many times by the three protocols that forked HTTP instead of just defining extensions within HTTP. Reuse of code in unexpected ways is just one of many problems that result.

....Roy


> On Apr 14, 2016, at 3:58 PM, Alex Rousskov <rousskov@measurement-factory.com> wrote:
> 
>> On 04/14/2016 12:20 PM, Roy T. Fielding wrote:
>> 
>> The next was if there were any examples we knew of where space
>> was included there.  None.
> 
>> Apache httpd [allows] for space-padding
>> of the chunk-size in fixed buffers
> 
> Too bad nobody from the Apache team was present during that discussion :-).
> 
> As you said, Apache httpd essentially uses the old syntax (and violates
> the new syntax in two places!) to accommodate space-padding (at least):
> 
>  chunk-ext = 0*10<BWS> ";" *( OWS / VCHAR / )
> 
> I know Squid and several ICAP agents that use HTTP parsers do similar
> things.
> 
> 
>> [ICAP, by the way, is not HTTP.]
> 
> ICAP is not HTTP but it explicitly uses big parts of HTTP syntax.
> AFAICT, such IETF protocol reuse is a good thing and should be
> encouraged and protected by IETF. If an HTTP*bis* RFC invalidates HTTP
> syntax very prominently used in another IETF RFC, something went wrong.
> Errata can fix that.
> 
> 
>> 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.  
> 
> Both choices break things. The HTTPbis choice to delete LWS in chunks
> breaks things today with a likelihood of 100% (my errata was inspired by
> a real-world bug report related to this change). When HTTPbis is fixed,
> someday, somewhere an implementation will misinterpret that whitespace.
> 
> Since that whitespace does exist in real messages, breaks ICAP RFC, and
> causes no known specific harm, we ought to undo this syntax change IMO.
> 
> 
>> I don't want to play errata ping pong.
> 
> The WG can always deny responsibility and add BWS instead of restoring
> OWS. BWS cannot cause errata ping pong AFAICT. BWS does screw ICAP, but
> nobody likes that kid anyway ;-).
> 
> 
> Thank you,
> 
> Alex.
> 
> 
> 
>>>> 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 ] )
>