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 Thu, 04 Aug 2016 20:11:39 GMT
Thanks for the feedback...

On Thu, Aug 4, 2016 at 3:02 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr <wrowe@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.

Mime
View raw message