On Thu, Aug 18, 2016 at 5:00 AM, William A Rowe Jr
wrote:
> Just FWIW, this still is not fixed for the legacy header parser.
>
> It *is* now fixed for the HTTP Request Line parser. Relaxing the
> whitespace rule (as we still do by default) only lets 1+ SP/HTAB
> slip
wrote:
> +1
>
> Regards
>
> Rüdiger
>
> > -Original Message-
> > From: Jacob Champion [mailto:champio...@gmail.com]
> > Sent: Donnerstag, 4. August 2016 22:35
> > To: dev@httpd.apache.org
> > Subject: Re: svn commit: r1754548 - /httpd/httpd/
+1
Regards
Rüdiger
> -Original Message-
> From: Jacob Champion [mailto:champio...@gmail.com]
> Sent: Donnerstag, 4. August 2016 22:35
> To: dev@httpd.apache.org
> Subject: Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
>
> On 08/04/2016 01:11
On Aug 5, 2016 3:43 PM, "William A Rowe Jr" wrote:
>
> 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
On Aug 4, 2016 3:02 PM, "Roy T. Fielding" wrote:
>>
>> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr
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
On 08/04/2016 01:11 PM, William A Rowe Jr wrote:
At our kindest, we would like to let people keep upgrading on the 2.2
or 2.4 branches of httpd for other fixes, without breaking their
deployments.
I'm 100% in favor of recognizing-and-rejecting (and terminating the
connection) for any obs-fold
Thanks for the feedback...
On Thu, Aug 4, 2016 at 3:02 PM, Roy T. Fielding wrote:
> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr wrote:
>
> So AIUI, the leading SP / TAB whitespace in a field is a no-op (usually
> represented by a single space by
> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr wrote:
>
> So AIUI, the leading SP / TAB whitespace in a field is a no-op (usually
> represented by a single space by convention), and trailing whitespace
> in the field value is a no-op, all leading tabs/spaces (beyond one
On Wed, Aug 3, 2016 at 4:28 PM, William A Rowe Jr
wrote:
> On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding wrote:
>
>> > On Aug 3, 2016, at 11:44 AM, Jacob Champion
>> wrote:
>> >
>> > On 07/31/2016 09:18 AM, William A Rowe Jr
On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding wrote:
> > On Aug 3, 2016, at 11:44 AM, Jacob Champion
> wrote:
> >
> > On 07/31/2016 09:18 AM, William A Rowe Jr wrote:
> >>> So all the trailing SP/HTAB are part of obs-fold IMHO.
> >>> Should we replace
On 08/03/2016 12:05 PM, Jacob Champion wrote:
So if there is an HTAB directly *before* the obs-fold CRLF, we should
not try to replace with a SP?
Ad never mind here; looks like we already strip trailing OWS from
the end of the line before the fold. That'll teach me to theorycraft
before
On 08/03/2016 12:05 PM, Jacob Champion wrote:
Right, I was just wondering out loud if condensing into a single space
could give anyone the chance to defeat a header length check in a
multi-layered system. It's admittedly a pretty "tinfoil hat" concern.
Never mind. It would need to be the other
On 08/03/2016 11:53 AM, Roy T. Fielding wrote:
Replacing each byte with a separate space (as opposed to condensing into a single space)
*might* help prevent adversaries from playing games with header length checks in more
complicated/layered systems. That's probably a stretch though. And if we
> On Aug 3, 2016, at 11:44 AM, Jacob Champion wrote:
>
> On 07/31/2016 09:18 AM, William A Rowe Jr wrote:
>>> So all the trailing SP/HTAB are part of obs-fold IMHO.
>>> Should we replace all of them (plus the CRLF) with a single SP or with
>>> as many SP?
>>
>> Hmmm...
On 07/31/2016 09:18 AM, William A Rowe Jr wrote:
So all the trailing SP/HTAB are part of obs-fold IMHO.
Should we replace all of them (plus the CRLF) with a single SP or with
as many SP?
Hmmm... Good point. Advancing over them in our HTTP_STRICT mode seems
best, if we have a consensus on this.
On Jul 31, 2016 3:17 AM, "Yann Ylavic" wrote:
>
> On Sun, Jul 31, 2016 at 12:56 AM, William A Rowe Jr
wrote:
> > On Jul 30, 2016 4:36 PM, "Yann Ylavic" wrote:
> >>
> >> On Sat, Jul 30, 2016 at 11:22 PM, Yann Ylavic
On Sun, Jul 31, 2016 at 12:56 AM, William A Rowe Jr wrote:
> On Jul 30, 2016 4:36 PM, "Yann Ylavic" wrote:
>>
>> On Sat, Jul 30, 2016 at 11:22 PM, Yann Ylavic
>> wrote:
>> > On Fri, Jul 29, 2016 at 6:24 PM,
On Jul 30, 2016 4:36 PM, "Yann Ylavic" wrote:
>
> On Sat, Jul 30, 2016 at 11:22 PM, Yann Ylavic
wrote:
> > On Fri, Jul 29, 2016 at 6:24 PM, wrote:
> >> Author: wrowe
> >> Date: Fri Jul 29 16:24:14 2016
> >> New Revision: 1754548
>
On Sat, Jul 30, 2016 at 11:22 PM, Yann Ylavic wrote:
> On Fri, Jul 29, 2016 at 6:24 PM, wrote:
>> Author: wrowe
>> Date: Fri Jul 29 16:24:14 2016
>> New Revision: 1754548
>>
>> URL: http://svn.apache.org/viewvc?rev=1754548=rev
>> Log:
>> Strictly observe
On Fri, Jul 29, 2016 at 6:24 PM, wrote:
> Author: wrowe
> Date: Fri Jul 29 16:24:14 2016
> New Revision: 1754548
>
> URL: http://svn.apache.org/viewvc?rev=1754548=rev
> Log:
> Strictly observe spec on obs-fold
>
> Modified:
> httpd/httpd/trunk/server/protocol.c
[]
>
>
20 matches
Mail list logo