Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2E961182A5 for ; Mon, 15 Jun 2015 17:00:48 +0000 (UTC) Received: (qmail 33641 invoked by uid 500); 15 Jun 2015 17:00:47 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 33573 invoked by uid 500); 15 Jun 2015 17:00:47 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 33563 invoked by uid 99); 15 Jun 2015 17:00:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Jun 2015 17:00:47 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates 209.85.160.181 as permitted sender) Received: from [209.85.160.181] (HELO mail-yk0-f181.google.com) (209.85.160.181) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Jun 2015 16:58:33 +0000 Received: by ykfl8 with SMTP id l8so61522614ykf.1 for ; Mon, 15 Jun 2015 10:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NFg3DasNtVp4/si6zfVwrEYBsv3XaSMydiKwtCHasV0=; b=LYZKOd1byWI3PBJvpBUARye5U41fJH8sP5X7uWhnEt6wjTHrxsYoQsF7R2DI1vE88o ADQpHGa28BGhS7l7slOm+BXP42DIlKgPklLdsqit1galGFgxRwoPh2VNhwbh3Qs6uSkR KnL7i8+gH61SGIRePxjJgbb8W/CoUn489IwJAY1jOTBtwDTQ3tjS8qLwndCNZj/wjZQS 1Asye/eT/GjnHtDT9lbAAsF6PLip19Zh+U3sN+5Mp/t3z1jexmKzc08do9m4RO5mEd1v IJ1SlRTR0UxSuGmcf1+/CIujn0N8Selu1f8DuFIhLPRzSTKkrEr+Y1CFNTyIs0XPafAW oz6w== MIME-Version: 1.0 X-Received: by 10.129.97.213 with SMTP id v204mr35374407ywb.56.1434387621393; Mon, 15 Jun 2015 10:00:21 -0700 (PDT) Received: by 10.13.241.133 with HTTP; Mon, 15 Jun 2015 10:00:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 13:00:21 -0400 Message-ID: Subject: Re: TWS ";" LWS permitted by RFC 7230 4.1.1? Apparently, no. From: Jeff Trawick To: Apache HTTP Server Development List Content-Type: multipart/alternative; boundary=001a11492eeca4b96705189164c8 X-Virus-Checked: Checked by ClamAV on apache.org --001a11492eeca4b96705189164c8 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 15, 2015 at 12:33 PM, William A Rowe Jr wrote: > Reviewing the spec, I cannot find where Sambar server is permitted to > insert whitespace. I further reviewed the ABNF appendix, and it does not > appear there, either. > > The spec seems unambiguous; > > chunk = chunk-size [ chunk-ext ] CRLF > chunk-data CRLF > chunk-size = 1*HEXDIG > last-chunk = 1*("0") [ chunk-ext ] CRLF > > > There is no opportunity to use whitespace outside of chunk-ext. > > > chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) > chunk-ext-name = token > chunk-ext-val = token / quoted-string > > > The rules in section 3.2.3 have become extremely strict; > > > 3.2.3 . Whitespace > > This specification uses three rules to denote the use of linear > whitespace: OWS (optional whitespace), RWS (required whitespace), and > BWS ("bad" whitespace). > > The OWS rule is used where zero or more linear whitespace octets > might appear. For protocol elements where optional whitespace is > preferred to improve readability, a sender SHOULD generate the > optional whitespace as a single SP; otherwise, a sender SHOULD NOT > generate optional whitespace except as needed to white out invalid or > unwanted protocol elements during in-place message filtering. > > The RWS rule is used when at least one linear whitespace octet is > required to separate field tokens. A sender SHOULD generate RWS as a > single SP. > > The BWS rule is used where the grammar allows optional whitespace > only for historical reasons. A sender MUST NOT generate BWS in > messages. A recipient MUST parse for such bad whitespace and remove > it before interpreting the protocol element. > > > And section 3.6.1 of RFC2616 made no accommodation for whitespace, in the first place. > > > I think Sambar is wrong and we should not be supporting this. > > > If we make provision to support this, we should be disallowing > > by default and add a directive to change the behavior. > > > Thoughts? > > 1.3 (or 1.3-based servers) put whitespace there. 1.3.x, 2.0.x, 2.2.x, and 2.4.x (for all released x so far) accepts whitespace there. We can't change that by default in a stable branch. This could be perhaps implemented in conjunction with sf's HttpStrict (?) stuff in trunk (I have no clue what that does in practice, but it sounds right). -- Born in Roswell... married an alien... http://emptyhammock.com/ --001a11492eeca4b96705189164c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 15, 2015 at 12:33 PM, William A Rowe Jr <wrowe@rowe-clan.net= > wrote:
Revie= wing the spec, I cannot find where Sambar server is permitted to insert whi= tespace. I further reviewed the ABNF appendix, and it does not appear there= , either.

The spec seems unambiguous;

chunk          =3D chunk-size [ chunk-ext ] CRLF
                 chunk-data CRLF
chunk-size     =3D 1*HEXDIG
last-chunk     =3D 1*("0") [ chunk-ext ] CRLF

There is no opportunity to use whitespace=
 outside of chunk-ext.

chunk-ext      =3D *( ";" chunk-ext-name [ "=3D" chu=
nk-ext-val ] )
chunk-ext-name =3D token
chunk-ext-val  =3D token / quoted-string

The rules in se=
ction 3.2.3 have become extremely strict;

3.2.3.  Whitespace

   This specification uses three rules to denote the use of linear
   whitespace: OWS (optional whitespace), RWS (required whitespace), and
   BWS ("bad" whitespace).

   The OWS rule is used where zero or more linear whitespace octets
   might appear.  For protocol elements where optional whitespace is
   preferred to improve readability, a sender SHOULD generate the
   optional whitespace as a single SP; otherwise, a sender SHOULD NOT
   generate optional whitespace except as needed to white out invalid or
   unwanted protocol elements during in-place message filtering.

   The RWS rule is used when at least one linear whitespace octet is
   required to separate field tokens.  A sender SHOULD generate RWS as a
   single SP.

   The BWS rule is used where the grammar allows optional whitespace
   only for historical reasons.  A sender MUST NOT generate BWS in
   messages.  A recipient MUST parse for such bad whitespace and remove
   it before interpreting the protocol element.

And sect=
ion 3.6.1 of RFC2616 made no accommodation for whitespace, in the first pla=
ce.

I think Sambar is wrong and we should not be support=
ing this.

If we make provision to support this, we shoul=
d be disallowing
by default and add a directive to change the behavi=
or.

Thoughts?

1.3 (or 1.3-based s= ervers) put whitespace there.
1.3.x, 2.0.x,= 2.2.x, and 2.4.x (for all released x so far) accepts whitespace there.
We can't change that by default in a stabl= e branch.

This could be perhaps implemented in conjunction with sf's Http= Strict (?) stuff in trunk (I have no clue what that does in practice, but i= t sounds right).

--
Born in Roswe= ll... married an alien...
http://emptyhammock.com/

--001a11492eeca4b96705189164c8--