Multi-line headers patch

[Maxim Dounin]

Hello!

On Mon, Sep 20, 2010 at 09:24:16PM +0200, Piotr Sikora wrote:

> Hi,
> 
> >Just a quick note:
> >
> >Multi-line headers is going to be deprecated by upcoming HTTPbis
> >specification.  See
> >
> >http://tools.ietf.org/id/draft-ietf-httpbis-p1-messaging-07.txt
> >
> >for details.
> 
> Yes, but only for senders.  The draft you linked (as well as its most
> recent update) states that:
> 
>   HTTP/1.1 recipients
>   SHOULD accept line folding and replace any embedded obs-fold
>   whitespace with a single SP prior to interpreting the field value or
>   forwarding the message downstream.

It's deprecated.  Senders MUST NOT produce, recipients SHOULD 
still accept.

> But please remember that this is still only a draft. Current
> standard allows senders to send multi-line headers, so I don't see
> why this shouldn't be supported by nginx.

The main reasons are: it's not supported, there is no good patch 
which adds support and it's not clear whether this is actually 
needed.

My message you replied was written more than a year ago - and 
nobody cared since then...

> >Could you please provide some details why do you actually need
> >this patch?
> 
> Some RESTful webservices (including Amazon S3) are using HTTP
> headers to transfer meta-data, which sometimes span over multiple
> lines. Other than that, there are broken OAuth clients out there
> that emit each parameter in new line.

Care to name a few?

> Attached patch is loosely based on algorist's version, but it also
> works for cases when whole request header wasn't yet received from
> the client and it unfolds multi-line headers (so it conforms to the
> HTTPbis drafts). I've also added '\t' as whitespace character, it
> seems that it should be treated like one.

I don't like the patch.  If we want to accept multi-line headers 
we should change state machine accordingly (i.e. mark header as 
done on next non-whitespace byte) instead of trying to 
look-ahead.

Additionally, I don't like the idea of allocations during header 
parsing as this consumes extra resources and opens additional 
attack vector.  It should be possible to unfold headers in-place.

Maxim Dounin