Re: [Technical Errata Reported] RFC7230 (4667)

Alex Rousskov <> Fri, 15 April 2016 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12DE712E53D for <>; Fri, 15 Apr 2016 09:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.917
X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cPwp2jGuQpSi for <>; Fri, 15 Apr 2016 09:56:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C74412E541 for <>; Fri, 15 Apr 2016 09:56:40 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ar6yU-0005o7-Kd for; Fri, 15 Apr 2016 16:52:06 +0000
Resent-Date: Fri, 15 Apr 2016 16:52:06 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ar6yQ-0005mj-PC for; Fri, 15 Apr 2016 16:52:02 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1ar6yP-0006Ej-HP for; Fri, 15 Apr 2016 16:52:02 +0000
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9E5D6E076; Fri, 15 Apr 2016 16:51:38 +0000 (UTC)
References: <> <> <> <> <> <>
From: Alex Rousskov <>
Cc: Amos Jeffries <>
Message-ID: <>
Date: Fri, 15 Apr 2016 10:51:03 -0600
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.9
X-W3C-Hub-Spam-Report: AWL=-1.002, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ar6yP-0006Ej-HP d7a6a1f0ef7e3801fb6c2f085be59151
Subject: Re: [Technical Errata Reported] RFC7230 (4667)
Archived-At: <>
X-Mailing-List: <> archive/latest/31476
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 04/15/2016 06:11 AM, Amos Jeffries wrote:

> Note that the Eratta proposed syntax, including the extra suggestions
> will still not successfully match what Squid is sighting. We would also
> need to allow BWS / OWS / SP trailing the chunk-size value when no
> chunk-ext is present.

As Roy has eloquently said, "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". This errata is about fixing
[other parts of] the ABNF for the reasons specified in the errata. Squid
will be fixed for other reasons, regardless of the errata acceptance or
the final ABNF shape.

Needless to say, somebody may submit another errata to accommodate
chunk-size space padding without chunk extensions. However, they would
face even greater obstacles justifying such change because it is
debatable whether the "implied *LWS" rule applies to that case -- CR is
not a "token" or "quoted string" that the poorly worded LWS rule kind of
requires... The best they can hope for, after hearing the "be lenient"
argument, is adding an informal RFC sentence alerting implementations of
known space padding issues.