Multi-line headers patch
piotr.sikora at frickle.com
Wed Sep 22 08:42:45 MSD 2010
> 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
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!
Piotr Sikora < piotr.sikora at frickle.com >
More information about the nginx