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

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

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