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 Thu, 04 Aug 2016 20:11:39 GMT
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 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
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
branches of httpd for other fixes, without breaking their deployments.

I'm 100% in favor of recognizing-and-rejecting (and terminating the
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
to anything in the core of httpd. Third party module authors would have to
appropriate accommodations if they directly handle this content.

View raw message