Re: #409: is parsing OBS-FOLD mandatory?

[Mark Nottingham <[e-mail]>]

On 20/01/2013, at 6:44 PM, Willy Tarreau <[e-mail]> wrote:

> Hi Mark,
> 
> Sorry for being silent so long, I was quite busy last two weeks :-/
> 
> On Sun, Jan 20, 2013 at 01:37:26PM +1100, Mark Nottingham wrote:
>> Anyone? Bueller?
>> 
>> To make it clear -- I propose we downgrade recipient support for OBS-FOLD to
>> a prose recommendation. 
> 
> Given the security impact it can have if processed the lazy way, we must at
> least have something normative. Practically, I don't know how this can be
> put into valid terms in a spec, but I'd like to see something which mandates
> detecting OBS-FOLD and then leaves the choice to the implementation to accept
> it or to reject the message. What I don't want to see is implementations which
> consider that the space is part of the next header field name, and which later
> trim the spaces and take this header field for another one. And we know for
> sure that lazy implementations are lazy in multiple areas (typically all
> those quickly written in scripting languages).

Understood.

I think it's a matter of either parsing obs-fold, or rejecting a message that has whitespace after a newline...

Current:

"""
Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type (Section 7.3.1). Senders MUST NOT generate messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the message is intended for packaging within the message/http media type. Recipients MUST accept line folding 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.
"""

Proposal:

"""
Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type (Section 7.3.1). Senders MUST NOT generate messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the message is intended for packaging within the message/http media type. Recipients MUST either:

  - accept line folding 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, or

  - reject a message with line folding present. Servers can do for requests by responding with 400 Bad Request and a representation explaining the condition; clients can only discard the message.

In particular, recipients who choose not to implement obs-fold processing (as described above) MUST NOT accept messages containing headers with leading whitespace, as this can expose them to attacks that exploit this difference in processing.
"""


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