Multi-line headers patch

[Piotr Sikora]

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