Multi-line headers patch

[Piotr Sikora]

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.

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.

> 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.

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.

Best regards,
Piotr Sikora < piotr.sikora at frickle.com >
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nginx__accept_and_unfold_multiline_headers.patch
Type: application/octet-stream
Size: 6156 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx/attachments/20100920/c20ab051/attachment-0001.obj>