Re: p1: handling obs-fold

Willy Tarreau <> Sat, 20 April 2013 07:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A8E721F925B for <>; Sat, 20 Apr 2013 00:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cwtRuRueMNjx for <>; Sat, 20 Apr 2013 00:01:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 680DC21F920B for <>; Sat, 20 Apr 2013 00:01:39 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UTRnF-0004J4-KU for; Sat, 20 Apr 2013 07:01:05 +0000
Resent-Date: Sat, 20 Apr 2013 07:01:05 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UTRnC-0004IP-9p for; Sat, 20 Apr 2013 07:01:02 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UTRnA-0002dV-Ua for; Sat, 20 Apr 2013 07:01:02 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r3K70cKO028589; Sat, 20 Apr 2013 09:00:38 +0200
Date: Sat, 20 Apr 2013 09:00:38 +0200
From: Willy Tarreau <>
To: Mark Nottingham <>
Cc: " Group" <>
Message-ID: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.759, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.702, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UTRnA-0002dV-Ua 2c3df64ae8a1dbddeebc405f292c571d
Subject: Re: p1: handling obs-fold
Archived-At: <>
X-Mailing-List: <> archive/latest/17389
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Sat, Apr 20, 2013 at 02:07:39PM +1000, Mark Nottingham wrote:
> 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.

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.