httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Date Fri, 05 Aug 2016 20:43:44 GMT
On Aug 4, 2016 3:02 PM, "Roy T. Fielding" <> wrote:
>> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr <>
>> 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
>> 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 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

View raw message