The server shouldn't crash the request process when we have an error
while receiving headers. A case where this could happen is if the header
line is too long.
See also bfrog's report on ticket #3 on github.
After much testing and experimentation of all kinds I find lists to be both
faster and using less memory than binaries for request-line and headers
handling. This is more than likely due to the fact that headers are very
short and thus do not benefit from the advantages of refc binaries, meaning
they're copied, just like lists. The memory usage discrepancy is still a
mystery for the most part, although the hoops needed to perform operations
on the binaries are probably responsible for the extra memory use.
I'm thus giving up on trying to use binaries for request-line and headers.
Instead, this commit improves performances even more to the lists code,
making lists 5% faster than binaries. Lists are easier to work with too,
so I guess it's all a big win for everyone.
Of course the request body is still read as a binary, we're using the
binary type where it performs best.
Of course since requests are a record the response state can be explicitly
overriden, but standard use prevents errors by making sure only one reply
is sent.
* Handler:init shouldn't reply anything; send an error 500.
* Handler:handle may have sent something to the client; close the socket.
* Handler:terminate failed to clean itself up. Close the socket.
* Makes more sense to parse the host only once instead of for each path.
* Allows proper handling of: If the host is not a valid host on the server,
the response MUST be a 400 (Bad Request) error.
In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words,
if the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.
We need an init function in order to process upgrade instructions
for protocols like WebSockets, but also to request an active receive
mode for long-polling connections, both of which will be implemented
at a later time.
