Moved the Transport:listen call to cowboy_acceptors_sup. This make it
depend on a child of cowboy_listener_sup instead of cowboy_sup, which
isn't getting shut down when calling cowboy:stop_listener/1 and thus
didn't close the listening socket.
As requested by many people on IRC Cowboy is now a proper OTP application
to support soft code upgrades. It should also be easier to start and stop
listeners now using cowboy:start_listener/6 and cowboy:stop_listener/1.
* Cowboy isn't an OTP application anymore; just a supervisor.
* All processes started by Cowboy are now anonymous.
* All processes related to a listener are now part of its supervision tree.
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.