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 Maxim,

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

Exactly, but this will apply to HTTP/1.1 (HTTPbis) clients. Clients using
HTTP/1.0 (rfc1945) will be still allowed to use multi-line headers.

> Care to name a few?

Both Amazon S3 and Google Storage are allowing this behavior and
authentication signatures are generated from (among others) unfolded
multi-line headers, so if you want to proxy traffic to them through nginx
(with custom authentication policy) then you need to accept whole headers
and not just the first line.

>From client libraries that I know of there is only oauth-php (before r58).
However there are others, because I've seen number of complains against
different HTTP servers that don't support multi-line headers (nginx, older
IIS, OCJ4, Tornado, older Twisted, ...).

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

Do you imagine Igor accepting patch that changes most (if not all) code of
the state machine? Because I don't. And to be honest I don't see anything
wrong with the current way of handling this.

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

You're right, it is possible. I'll fix this later today.

Thanks for the code review!

Best regards,
Piotr Sikora < piotr.sikora@frickle.com >



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