On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding <[email protected]> wrote:
> > On Aug 3, 2016, at 11:44 AM, Jacob Champion <[email protected]> > 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.
