All files from this thread

File Name	File Size		Posted by	Date
nginx__accept_and_unfold_multiline_headers.patch	6 KB	open | download	Piotr Sikora	09/20/2010	Read message
accept_and_unfold_multiline_headers.t	3.7 KB	open | download	Piotr Sikora	09/21/2010	Read message
accept_and_unfold_multiline_headers_v2.patch	6.2 KB	open | download	Piotr Sikora	09/21/2010	Read message
accept_and_unfold_multiline_headers_v3.patch	5.5 KB	open | download	Piotr Sikora	09/22/2010	Read message

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@frickle.com >

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx