You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Yann Ylavic <yl...@gmail.com> on 2016/07/30 21:22:54 UTC
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
On Fri, Jul 29, 2016 at 6:24 PM, <wr...@apache.org> wrote:
> Author: wrowe
> Date: Fri Jul 29 16:24:14 2016
> New Revision: 1754548
>
> URL: http://svn.apache.org/viewvc?rev=1754548&view=rev
> Log:
> Strictly observe spec on obs-fold
>
> Modified:
> httpd/httpd/trunk/server/protocol.c
[]
>
> memcpy(last_field + last_len, field, len +1); /* +1 for nul */
> + /* Replace obs-fold w/ SP per RFC 7230 3.2.4 */
> + if (conf->http_conformance & AP_HTTP_CONFORMANCE_STRICT) {
> + last_field[last_len] = ' ';
> + }
The wording is:
A user agent that receives an obs-fold in a response message that is
not within a message/http container MUST replace each received
obs-fold with one or more SP octets prior to interpreting the field
value.
Not sure if it means that one HTAB or more than one SP/HTAB of each
obs-fold should be replaced by a single SP (that's what I think), or
if it's that all HTAB should be replaced by a SP (keeping as many
"spaces").
In any case the above code will replace one HTAB only, we probably
need a loop here.
> last_len += len;
> folded = 1;
> }
Regards,
Yann.
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Aug 3, 2016 at 4:28 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
>
>> > On Aug 3, 2016, at 11:44 AM, Jacob Champion <ch...@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.
>
To ensure the patch is entirely correct on my 'next try', I'd like
clarification
here before resuming this code review and correction. If we know the spaces
and tabs around an obs-fold, both leading - and trailing, are all
collapsible
to a single SP, and the leading and trailing spaces around the field value
are all discarded, then the code and resulting patch gets simpler, not more
confusing.
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Aug 5, 2016 3:43 PM, "William A Rowe Jr" <wr...@rowe-clan.net> 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 headers to a backend or
bad data in a response.
RFC7230 3.5 provided the answer, no issue here since we don't propagate the
legacy behavior in our own requests or responses.
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Aug 4, 2016 3:02 PM, "Roy T. Fielding" <fi...@gbiv.com> wrote:
>>
>> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr <wr...@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?
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Aug 18, 2016 at 5:00 AM, William A Rowe Jr <wr...@rowe-clan.net>
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 through, and then recomposes with single SP delimiters.
>
> Of the subset \f \r \v \n I can't think of any possible application.
> Whitespace of ' ' and \t makes (some) sense in the real world.
> If anyone has a real-world example of a user-agent which used
> these legitimately, I'd love a pointer.
>
Committed in 1756847, either Strict or StrictWhitespace will reject
these quirks, Unsafe and LenientWhitespace together are required
to continue to handle such headers, and never permitted for the
request line itself.
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 through, and then recomposes with single SP delimiters.
Of the subset \f \r \v \n I can't think of any possible application.
Whitespace of ' ' and \t makes (some) sense in the real world.
If anyone has a real-world example of a user-agent which used
these legitimately, I'd love a pointer.
On Thu, Aug 18, 2016 at 4:34 AM, Plüm, Rüdiger, Vodafone Group <
ruediger.pluem@vodafone.com> wrote:
> +1
>
> Regards
>
> Rüdiger
>
> > -----Original Message-----
> > From: Jacob Champion [mailto:champion.p@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 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 occurrences on 2.6 / 3.0, if that's the
> > > group consensus.
> >
> > +1 to both.
> >
> > --Jacob
>
>
RE: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
+1
Regards
Rüdiger
> -----Original Message-----
> From: Jacob Champion [mailto:champion.p@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 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 occurrences on 2.6 / 3.0, if that's the
> > group consensus.
>
> +1 to both.
>
> --Jacob
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by Jacob Champion <ch...@gmail.com>.
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 occurrences on 2.6 / 3.0, if that's the
> group consensus.
+1 to both.
--Jacob
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Thanks for the feedback...
On Thu, Aug 4, 2016 at 3:02 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr <wr...@rowe-clan.net> 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 SP)
> in the obs-fold line is a no-op. Is there any reason to preserve trailing
> spaces before the obs-fold?
>
>
> Not given our implementation. The buffer efficiency argument is for other
> kinds of parsers that are not reading just one line at a time.
>
And because we are merging line-at-a-time, we have both factors, the cost
of stripping back trailing whitespace before an obs-fold (we should be doing
this at the end of the header field value in any case), v.s. buffer
allocation
for no-op whitespace.
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.
>
That solves that, thanks for the clarity.
> Note that obs-fold has been formally deprecated outside of message/http.
> We can remove its handling at any time we are willing to accept the risk
> of strange error reports. I do not believe it is part of our versioning
> contract.
>
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 occurrences on 2.6 / 3.0, if that's the group consensus.
It still must be supported in media type message/http, but that shouldn't
apply
to anything in the core of httpd. Third party module authors would have to
make
appropriate accommodations if they directly handle this content.
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr <wr...@rowe-clan.net> 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 SP)
> in the obs-fold line is a no-op. Is there any reason to preserve trailing
> spaces before the obs-fold?
Not given our implementation. The buffer efficiency argument is for other
kinds of parsers that are not reading just one line at a time.
> 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.
Note that obs-fold has been formally deprecated outside of message/http.
We can remove its handling at any time we are willing to accept the risk
of strange error reports. I do not believe it is part of our versioning contract.
....Roy
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> > On Aug 3, 2016, at 11:44 AM, Jacob Champion <ch...@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.
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by Jacob Champion <ch...@gmail.com>.
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?
Annnnd 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 reading the code.
Thanks Roy for the clarifications. :)
--Jacob
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by Jacob Champion <ch...@gmail.com>.
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 way around (expanding a header
value rather than contracting) to cause a problem for a backend.
--Jacob
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by Jacob Champion <ch...@gmail.com>.
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 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).
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.
>>>>> 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 if there is an HTAB directly *before* the obs-fold CRLF, we should
not try to replace with a SP?
--Jacob
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
> On Aug 3, 2016, at 11:44 AM, Jacob Champion <ch...@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.
....Roy
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by Jacob Champion <ch...@gmail.com>.
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.
>> > 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.
--Jacob
[1] https://www.ietf.org/mail-archive/web/httpbisa/current/msg23721.html
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Jul 31, 2016 3:17 AM, "Yann Ylavic" <yl...@gmail.com> wrote:
>
> On Sun, Jul 31, 2016 at 12:56 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> > On Jul 30, 2016 4:36 PM, "Yann Ylavic" <yl...@gmail.com> wrote:
> >>
> >> On Sat, Jul 30, 2016 at 11:22 PM, Yann Ylavic <yl...@gmail.com>
> >> wrote:
> >> > On Fri, Jul 29, 2016 at 6:24 PM, <wr...@apache.org> wrote:
> >> >> Author: wrowe
> >> >> Date: Fri Jul 29 16:24:14 2016
> >> >> New Revision: 1754548
> >> >>
> >> >> URL: http://svn.apache.org/viewvc?rev=1754548&view=rev
> >> >> Log:
> >> >> Strictly observe spec on obs-fold
> >> >>
> >> >> Modified:
> >> >> httpd/httpd/trunk/server/protocol.c
> >> > []
> >> >>
> >> >> memcpy(last_field + last_len, field, len +1); /* +1
> >> >> for nul */
> >> >> + /* Replace obs-fold w/ SP per RFC 7230 3.2.4 */
> >> >> + if (conf->http_conformance &
> >> >> AP_HTTP_CONFORMANCE_STRICT) {
> >> >> + last_field[last_len] = ' ';
> >> >> + }
> >> >
> >> > The wording is:
> >> > A user agent that receives an obs-fold in a response message that
is
> >> > not within a message/http container MUST replace each received
> >> > obs-fold with one or more SP octets prior to interpreting the
field
> >> > value.
> >>
> >> Please forget the "user agent" part, the wording for
> >> server/proxy/gateway is the same though, from "MUST replace each
> >> received..."
> >>
> >> >
> >> > Not sure if it means that one HTAB or more than one SP/HTAB of each
> >> > obs-fold should be replaced by a single SP (that's what I think), or
> >> > if it's that all HTAB should be replaced by a SP (keeping as many
> >> > "spaces").
> >> >
> >> > In any case the above code will replace one HTAB only, we probably
> >> > need a loop here.
> >> >
> >> >> last_len += len;
> >> >> folded = 1;
> >> >> }
> >> >
> >> > Regards,
> >> > Yann.
> >
> > So the obs-fold itself consists of CR LF [ SP | TAB ]
>
> obs-fold = CRLF 1*( SP / HTAB )
>
> 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.
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Sun, Jul 31, 2016 at 12:56 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Jul 30, 2016 4:36 PM, "Yann Ylavic" <yl...@gmail.com> wrote:
>>
>> On Sat, Jul 30, 2016 at 11:22 PM, Yann Ylavic <yl...@gmail.com>
>> wrote:
>> > On Fri, Jul 29, 2016 at 6:24 PM, <wr...@apache.org> wrote:
>> >> Author: wrowe
>> >> Date: Fri Jul 29 16:24:14 2016
>> >> New Revision: 1754548
>> >>
>> >> URL: http://svn.apache.org/viewvc?rev=1754548&view=rev
>> >> Log:
>> >> Strictly observe spec on obs-fold
>> >>
>> >> Modified:
>> >> httpd/httpd/trunk/server/protocol.c
>> > []
>> >>
>> >> memcpy(last_field + last_len, field, len +1); /* +1
>> >> for nul */
>> >> + /* Replace obs-fold w/ SP per RFC 7230 3.2.4 */
>> >> + if (conf->http_conformance &
>> >> AP_HTTP_CONFORMANCE_STRICT) {
>> >> + last_field[last_len] = ' ';
>> >> + }
>> >
>> > The wording is:
>> > A user agent that receives an obs-fold in a response message that is
>> > not within a message/http container MUST replace each received
>> > obs-fold with one or more SP octets prior to interpreting the field
>> > value.
>>
>> Please forget the "user agent" part, the wording for
>> server/proxy/gateway is the same though, from "MUST replace each
>> received..."
>>
>> >
>> > Not sure if it means that one HTAB or more than one SP/HTAB of each
>> > obs-fold should be replaced by a single SP (that's what I think), or
>> > if it's that all HTAB should be replaced by a SP (keeping as many
>> > "spaces").
>> >
>> > In any case the above code will replace one HTAB only, we probably
>> > need a loop here.
>> >
>> >> last_len += len;
>> >> folded = 1;
>> >> }
>> >
>> > Regards,
>> > Yann.
>
> So the obs-fold itself consists of CR LF [ SP | TAB ]
obs-fold = CRLF 1*( SP / HTAB )
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?
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Jul 30, 2016 4:36 PM, "Yann Ylavic" <yl...@gmail.com> wrote:
>
> On Sat, Jul 30, 2016 at 11:22 PM, Yann Ylavic <yl...@gmail.com>
wrote:
> > On Fri, Jul 29, 2016 at 6:24 PM, <wr...@apache.org> wrote:
> >> Author: wrowe
> >> Date: Fri Jul 29 16:24:14 2016
> >> New Revision: 1754548
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1754548&view=rev
> >> Log:
> >> Strictly observe spec on obs-fold
> >>
> >> Modified:
> >> httpd/httpd/trunk/server/protocol.c
> > []
> >>
> >> memcpy(last_field + last_len, field, len +1); /* +1
for nul */
> >> + /* Replace obs-fold w/ SP per RFC 7230 3.2.4 */
> >> + if (conf->http_conformance &
AP_HTTP_CONFORMANCE_STRICT) {
> >> + last_field[last_len] = ' ';
> >> + }
> >
> > The wording is:
> > A user agent that receives an obs-fold in a response message that is
> > not within a message/http container MUST replace each received
> > obs-fold with one or more SP octets prior to interpreting the field
> > value.
>
> Please forget the "user agent" part, the wording for
> server/proxy/gateway is the same though, from "MUST replace each
> received..."
>
> >
> > Not sure if it means that one HTAB or more than one SP/HTAB of each
> > obs-fold should be replaced by a single SP (that's what I think), or
> > if it's that all HTAB should be replaced by a SP (keeping as many
> > "spaces").
> >
> > In any case the above code will replace one HTAB only, we probably
> > need a loop here.
> >
> >> last_len += len;
> >> folded = 1;
> >> }
> >
> > Regards,
> > Yann.
So the obs-fold itself consists of CR LF [ SP | TAB ]
Any whitespace following the single sp/tab is field whitespace. I
considered and determined we do not further collapse whitespace, as these
may be in quoted field contents.
But the CR LF TAB becomes SP per spec.
Re: svn commit: r1754548 - /httpd/httpd/trunk/server/protocol.c
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Jul 30, 2016 at 11:22 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Fri, Jul 29, 2016 at 6:24 PM, <wr...@apache.org> wrote:
>> Author: wrowe
>> Date: Fri Jul 29 16:24:14 2016
>> New Revision: 1754548
>>
>> URL: http://svn.apache.org/viewvc?rev=1754548&view=rev
>> Log:
>> Strictly observe spec on obs-fold
>>
>> Modified:
>> httpd/httpd/trunk/server/protocol.c
> []
>>
>> memcpy(last_field + last_len, field, len +1); /* +1 for nul */
>> + /* Replace obs-fold w/ SP per RFC 7230 3.2.4 */
>> + if (conf->http_conformance & AP_HTTP_CONFORMANCE_STRICT) {
>> + last_field[last_len] = ' ';
>> + }
>
> The wording is:
> A user agent that receives an obs-fold in a response message that is
> not within a message/http container MUST replace each received
> obs-fold with one or more SP octets prior to interpreting the field
> value.
Please forget the "user agent" part, the wording for
server/proxy/gateway is the same though, from "MUST replace each
received..."
>
> Not sure if it means that one HTAB or more than one SP/HTAB of each
> obs-fold should be replaced by a single SP (that's what I think), or
> if it's that all HTAB should be replaced by a SP (keeping as many
> "spaces").
>
> In any case the above code will replace one HTAB only, we probably
> need a loop here.
>
>> last_len += len;
>> folded = 1;
>> }
>
> Regards,
> Yann.