Subject: p1: handling obs-fold

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Apr 2013 14:07:39 +1000

p1 3.2.4 defines requirements for handling obs-fold:

> When an obs-fold is received in a message, recipients MUST do one of:
> 
> 	• accept the message and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream;
> 	• if it is a request, reject the message by sending a 400 (Bad Request) response with a representation explaining that obsolete line folding is unacceptable; or,
> 	• if it is a response, discard the message and generate a 502 (Bad Gateway) response with a representation explaining that unacceptable line folding was received.
> 
> Recipients that choose not to implement obs-fold processing (as described above) MUST NOT accept messages containing header fields with leading whitespace, as this can expose them to attacks that exploit this difference in processing.

This seems to repeat itself; what is the difference between choosing to reject the request in the manner described in the last two bullet points, and not accepting the message?

I think that the last sentence can be removed.

--
Mark Nottingham   http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 20 Apr 2013 09:00:38 +0200

On Sat, Apr 20, 2013 at 02:07:39PM +1000, Mark Nottingham wrote:
> > 	? accept the message and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream;
> > 	? if it is a request, reject the message by sending a 400 (Bad Request) response with a representation explaining that obsolete line folding is unacceptable; or,
> > 	? if it is a response, discard the message and generate a 502 (Bad Gateway) response with a representation explaining that unacceptable line folding was received.
> > 

I think it was here before the addition above. In fact it targets a different
audience which is not aware of OBS at all. The simple fact that we talk about
prepending spaces before a header field means that the reader doesn't
understand that this field is not one but the continuation of previous one.

Maybe this confusing sentence should be removed and replaced with something
like this before the block you quoted :

  Presence of a space or tab character at the beginning of a line must not
  be taken as a new header field but as the continuation of previous header
  field (obs-fold). As such it cannot happen on the first header field.

That way readers looking for what to do with these spaces will find their
response here and will be able to decide what to do with the options that
are offered to them.

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Apr 2013 17:43:18 +1000

> response here and will be able to decide what to do with the options that

Seems reasonable; I think this one is largely editorial; the only way I'd be really concerned would be if nothing changed.

Recorded as:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/444
with suggestions.

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 20 Apr 2013 21:37:29 +1200

>    http://trac.tools.ietf.org/wg/httpbis/trac/ticket/444

I would just go with a MUST NOT on whitespace before or after the 
field-name. Not just between the field-name and its colon.

Amos