httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Date Wed, 03 Aug 2016 21:28:01 GMT
On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> > On Aug 3, 2016, at 11:44 AM, Jacob Champion <champion.p@gmail.com>
> 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... Good point. Advancing over them in our HTTP_STRICT mode seems
> >> best, if we have a consensus on this.
> >
> > Agreed that we should process all the obs-fold whitespace, and not just
> one byte.
> >
> > 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 consume the CRLF in a different layer of logic,
> adding on two spaces just to keep everything "consistent" may also be a
> stretch. I'm not feeling strongly either way.
>
> What the spec is trying to say is that we can either replace all those
> bytes
> with a single SP (semantically speaking they are the same) or we we can
> replace
> them all with a sequence of SP (still the same, but doesn't require
> splitting
> or recomposing the buffer).
>
> > >> > So the obs-fold itself consists of CR LF [ SP | TAB ]
> > >>
> > >>    obs-fold = CRLF 1*( SP / HTAB )
> > >>
> >
> > Note that this section of the spec has Errata associated with it; I'm
> reading through the conversation [1] and it's seeming like they *may* want
> to treat OWS preceding the CRLF as part of the obs-fold as well. I don't
> know what our position is on adopting pieces of Errata that have been Held
> for Document Update.
>
> No, that is just an ABNF issue for matching purposes.  We don't use it.
>

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 SP)
in the obs-fold line is a no-op. Is there any reason to preserve trailing
spaces before the obs-fold?

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.

Mime
View raw message