On Wed, Aug 3, 2016 at 4:28 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Wed, Aug 3, 2016 at 1:53 PM, Roy T. Fielding <field...@gbiv.com> wrote: > >> > On Aug 3, 2016, at 11:44 AM, Jacob Champion <champio...@gmail.com> >> 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. > To ensure the patch is entirely correct on my 'next try', I'd like clarification here before resuming this code review and correction. If we know the spaces and tabs around an obs-fold, both leading - and trailing, are all collapsible to a single SP, and the leading and trailing spaces around the field value are all discarded, then the code and resulting patch gets simpler, not more confusing.
