Thanks for the feedback... On Thu, Aug 4, 2016 at 3:02 PM, Roy T. Fielding <[email protected]> wrote:
> On Aug 3, 2016, at 2:28 PM, William A Rowe Jr <[email protected]> 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.
