To this end we are formatting the header names just like OTP does
except we do it for names of up to 32 characters, as there are
widely used header names of more than 20 characters, the limit that
OTP follows currently. An example of such header name would be
Sec-Websocket-Version.
The formatting itself is fairly simple: an uppercase character at
the start and after dashes, everything else lowercase.
Also sends a message 'shoot' that can be received by the protocol
to make sure Cowboy has had enough time to fully initialize the
socket. This message should be received before any socket-related
operations are performed.
WebSocket request connections are now moved from the pool 'default'
to the pool 'websocket', meaning we can have a lot of running
WebSockets despite having a low 'max_connections' setting.
Fixes issue #31.
Recursion shouldn't happen in a single catch statement or inside
a try .. catch statement. The only safe construct for catching
exceptions and perform recursion when everything goes well is
to put the recursive call inside a try .. of .. catch construct
in the of .. catch block.
Otherwise the stack gets filled with exception-related information
since they can still be caught if we were to send them and unfold
the whole thing.
Thanks go to lpgauth for reporting the issue and people on IRC
for explaining the hows and whys.
The dispatcher now accepts '...' as the leading segment of Host and the
trailing segment of Path, this special atom matches any remaining path tail.
When given "cowboy.bugs.dev-extend.eu", host rule ['...', <<"dev-extend">>,
<<"eu">>] matches and fills host_info with [<<"cowboy">>, <<"bugs">>].
When given "/a/b/c/d", path rule [<<"a">>, <<"b">>, '...'] matches and fills
path_info with [<<"c">>, <<"d">>].
The server now does a single recv (or more, but only if needed)
which is then sent to erlang:decode_packet/3 multiple times. Since
most requests are smaller than the default MTU on many platforms,
we benefit from this greatly.
In the case of requests with a body, the server usually read at
least part of the body on the first recv. This is bufferized
properly and used when later retrieving the body.
In the case of pipelined requests, we can end up reading many
requests in a single recv, which are then handled properly using
only the buffer containing the received data.
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.
