Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <B6D1D25B-7BF0-4AA1-9E02-B7FD1AA18C5F@gbiv.com>
References: <20160729162414.B753A3A0056@svn01-us-west.apache.org>
 <CAKQ1sVOSETCrAG7MhzphFqJkZiWdHrDKLF0z006t2d13+2uG9w@mail.gmail.com>
 <CAKQ1sVPCmyQHOpEYkmQ0CxoLaDd3JPeXHbrULyaeunBJyREH-w@mail.gmail.com>
 <CACsi250N1R+mJDbP=LaXT9GWaZZwDK07_2YkrP0e_OcaJZYunA@mail.gmail.com>
 <CACsi2535oxQsKuierVV0qRnAiN68+wEFQTjuj8kCkPVhRwSAPw@mail.gmail.com>
 <CACsi253CxN=FW_cdxO2XOuXA=6pca5y4hzEQqhKNH-YVNF0N+g@mail.gmail.com>
 <CAKQ1sVOZcf-9iz0-o1hmF3=eVwv4sux=7qTfUor_D_vU=RGrtA@mail.gmail.com>
 <CACsi250Cun_HhQyTEY8gnUKC6v_S8ugjUrvt2Wbm1hMSJLNCTg@mail.gmail.com>
 <2e6b3df8-4aae-76d0-c458-96a0e9eda398@gmail.com> <566AF3BB-F41F-4680-8B55-4018B2295D08@gbiv.com>
 <CACsi251wu9=zkYHzkqnOmwgMFbpA5_OSV9MjX01gne-02brVJg@mail.gmail.com> <B6D1D25B-7BF0-4AA1-9E02-B7FD1AA18C5F@gbiv.com>
From: William A Rowe Jr <wrowe@rowe-clan.net>
Date: Fri, 5 Aug 2016 15:43:44 -0500
Message-ID: <CACsi253nDF1CU=-R3wWn44pAvYBSECnsNZfY3XV=nUkDqUh+tQ@mail.gmail.com>
Subject: Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
To: httpd <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=001a113f3a8867d96e0539591f93
archived-at: Fri, 05 Aug 2016 20:43:57 -0000

--001a113f3a8867d96e0539591f93
Content-Type: text/plain; charset=UTF-8

On Aug 4, 2016 3:02 PM, "Roy T. Fielding" <fielding@gbiv.com> wrote:
>>
>> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr <wrowe@rowe-clan.net>
wrote:
>
>> If not, then stripping trailing whitespace from the line prior to
obs-fold and
>> eating all leading whitespace on the obs-fold line will result in a
single SP
>> character, which should be just fine unless spaces were significant
within
>> a quoted value. The only way for the client to preserve such significant
>> spaces would be to place them after the opening quote before the
obs-fold.
>
> obs-fold is not allowed inside quoted text, so we need not worry about
> messing with such a construct.

Roy especially, and others familiar with the explicit purpose and meaning
of the spec...

We do not guard against an obs-fold occurring within a field-vchar segment,
our unfolding occurs beforehand...

field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]

From a security and integrity perspective I can find no reason to guard
against an obs-fold within a quoted string, for example. Whitespace
compression to a single SP occurs to that token sent by an inept client
still using obs-fold, but this appears to have no negative side-effects.

Our strict mode parsing still permits simple "\n" line termination rather
than the CRLF as defined by spec. Here again, I can't find a security or
integrity issue.

In neither case do we send bad data as request headers to a backend or bad
data in a response.

Is there any justification for changing either of these permissive
behaviors?

--001a113f3a8867d96e0539591f93
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On Aug 4, 2016 3:02 PM, &quot;Roy T. Fielding&quot; &lt;<a h=
ref=3D"mailto:fielding@gbiv.com">fielding@gbiv.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Aug 3, 2016, at 2:28 PM, William A Rowe Jr &lt;<a href=3D"mailt=
o:wrowe@rowe-clan.net">wrowe@rowe-clan.net</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; If not, then stripping trailing whitespace from the line prior to =
obs-fold and<br>
&gt;&gt; eating all leading whitespace on the obs-fold line will result in =
a single SP<br>
&gt;&gt; character, which should be just fine unless spaces were significan=
t within<br>
&gt;&gt; a quoted value. The only way for the client to preserve such signi=
ficant=C2=A0<br>
&gt;&gt; spaces would be to place them after the opening quote before the o=
bs-fold.<br>
&gt;<br>
&gt; obs-fold is not allowed inside quoted text, so we need not worry about=
<br>
&gt; messing with such a construct.</p>
<p dir=3D"ltr">Roy especially, and others familiar with the explicit purpos=
e and meaning of the spec...</p>
<p dir=3D"ltr">We do not guard against an obs-fold occurring within a field=
-vchar segment, our unfolding occurs beforehand...</p>
<p dir=3D"ltr">field-content =3D field-vchar [ 1*( SP / HTAB ) field-vchar =
]</p>
<p dir=3D"ltr">From a security and integrity perspective I can find no reas=
on to guard against an obs-fold within a quoted string, for example. Whites=
pace compression to a single SP occurs to that token sent by an inept clien=
t still using obs-fold, but this appears to have no negative side-effects.<=
/p>
<p dir=3D"ltr">Our strict mode parsing still permits simple &quot;\n&quot; =
line termination rather than the CRLF as defined by spec. Here again, I can=
&#39;t find a security or integrity issue.</p>
<p dir=3D"ltr">In neither case do we send bad data as request headers to a =
backend or bad data in a response.</p>
<p dir=3D"ltr">Is there any justification for changing either of these perm=
issive behaviors?<br>
</p>

--001a113f3a8867d96e0539591f93--