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