Welcome! Log In Create A New Profile

Advanced

Re: Multi-line headers patch

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
Maxim Dounin
September 21, 2010 11:14PM
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
Subject Author Posted

Multi-line headers patch

algorist August 12, 2009 06:51PM

Re: Multi-line headers patch

algorist August 13, 2009 05:52PM

Re: Multi-line headers patch

edogawaconan August 14, 2009 12:26AM

Re: Multi-line headers patch

algorist August 26, 2009 04:36PM

Re: Multi-line headers patch

Cliff Wells August 26, 2009 05:24PM

Re: Multi-line headers patch

Maxim Dounin August 26, 2009 07:21PM

Re: Multi-line headers patch Attachments

Piotr Sikora September 20, 2010 03:30PM

Re: Multi-line headers patch Attachments

Piotr Sikora September 21, 2010 09:42PM

Re: Multi-line headers patch

Maxim Dounin September 21, 2010 11:14PM

Re: Multi-line headers patch

Piotr Sikora September 22, 2010 12:46AM

Re: Multi-line headers patch Attachments

Piotr Sikora September 22, 2010 02:36AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 63
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready