W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: p1: handling obs-fold

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 20 Apr 2013 09:00:38 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <20130420070038.GG26517@1wt.eu>
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.

Received on Saturday, 20 April 2013 07:01:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC