Improve handler interface and documentation

This change simplifies a little more the sub protocols mechanism.
Aliases have been removed. The renaming of loop handlers as long
polling handlers has been reverted.

Plain HTTP handlers now simply do their work in the init/2
callback. There is no specific code for them.

Loop handlers now follow the same return value as Websocket,
they use ok to continue and shutdown to stop.

Terminate reasons for all handler types have been documented.
The terminate callback is now appropriately called in all cases
(or should be).

Behaviors for all handler types have been moved in the module
that implement them. This means that cowboy_handler replaces
the cowboy_http_handler behavior, and similarly cowboy_loop
replaces cowboy_loop_handler, cowboy_websocket replaces
cowboy_websocket_handler. Finally cowboy_rest now has the
start of a behavior in it and will have the full list of
optional callbacks defined once Erlang 18.0 gets released.

The guide has been reorganized and should be easier to follow.

1 files changed, 0 insertions, 147 deletions

diff --git a/doc/src/guide/http_req_life.ezdoc b/doc/src/guide/http_req_life.ezdoc
deleted file mode 100644
index ffe5dfa..0000000
--- a/doc/src/guide/http_req_life.ezdoc
+++ /dev/null
@@ -1,147 +0,0 @@
-::: The life of a request
-
-This chapter explains the different steps a request
-goes through until a response is sent, along with
-details of the Cowboy implementation.
-
-:: Request/response
-
-As you already know, HTTP clients connect to the server and
-send a request for a resource; the server then sends a
-response containing the resource if it could obtain it.
-
-Before the server can send the resource, however, it
-needs to perform many different operations to read the
-request, find the resource, prepare the response being
-sent and often other related operations the user can
-add like writing logs.
-
-Requests take the following route in Cowboy:
-
-^"HTTP request/response flowchart^!http_req_resp.png
-
-This shows the default middlewares, but they may be
-configured differently in your setup. The dark green
-indicates the points where you can hook your own code,
-the light green is the Cowboy code that you can of
-course configure as needed.
-
-The `acceptor` is the part of the server that accepts
-the connection and create an Erlang process to handle
-it. The `parser` then starts reading from the socket
-and handling requests as they come until the socket
-is closed.
-
-A response may be sent at many different points in the
-life of the request. If Cowboy can't parse the request,
-it gives up with an error response. If the router can't
-find the resource, it sends a not found error. Your
-own code can of course send a response at any time.
-
-When a response is sent, you can optionally modify it
-or act upon it by enabling the `onresponse` hook. By
-default the response is sent directly to the client.
-
-:: And then?
-
-Behavior depends on what protocol is in use.
-
-HTTP/1.0 can only process one request per connection,
-so Cowboy will close the connection immediately after
-it sends the response.
-
-HTTP/1.1 allows the client to request that the server
-keeps the connection alive. This mechanism is described
-in the next section.
-
-SPDY is designed to allow sending multiple requests
-asynchronously on the same connection. Details on what
-this means for your application is described in this
-chapter.
-
-:: Keep-alive (HTTP/1.1)
-
-With HTTP/1.1, the connection may be left open for
-subsequent requests to come. This mechanism is called
-`keep-alive`.
-
-When the client sends a request to the server, it includes
-a header indicating whether it would like to leave the
-socket open. The server may or may not accept, indicating
-its choice by sending the same header in the response.
-
-Cowboy will include this header automatically in all
-responses to HTTP/1.1 requests. You can however force
-the closing of the socket if you want. When Cowboy sees
-you want to send a `connection: close` header, it will
-not override it and will close the connection as soon
-as the reply is sent.
-
-This snippet will force Cowboy to close the connection.
-
-``` erlang
-Req2 = cowboy_req:reply(200, [
-    {<<"connection">>, <<"close">>},
-], <<"Closing the socket in 3.. 2.. 1..">>, Req).
-```
-
-Cowboy will only accept a certain number of new requests
-on the same connection. By default it will run up to 100
-requests. This number can be changed by setting the
-`max_keepalive` configuration value when starting an
-HTTP listener.
-
-``` erlang
-cowboy:start_http(my_http_listener, 100, [{port, 8080}], [
-        {env, [{dispatch, Dispatch}]},
-        {max_keepalive, 5}
-]).
-```
-
-Cowboy implements the keep-alive mechanism by reusing
-the same process for all requests. This allows Cowboy
-to save memory. This works well because most code will
-not have any side effect impacting subsequent requests.
-But it also means you need to clean up if you do have
-code with side effects. The `terminate/3` function can
-be used for this purpose.
-
-:: Pipelining (HTTP/1.1)
-
-While HTTP is designed as a sequential protocol, with
-the client sending a request and then waiting for the
-response from the server, nothing prevents the client
-from sending more requests to the server without waiting
-for the response, due to how sockets work. The server
-still handles the requests sequentially and sends the
-responses in the same order.
-
-This mechanism is called pipelining. It allows reducing
-latency when a client needs to request many resources
-at the same time. This is used by browsers when requesting
-static files for example.
-
-This is handled automatically by the server.
-
-:: Asynchronous requests (SPDY)
-
-In SPDY, the client can send a request at any time.
-And the server can send a response at any time too.
-
-This means for example that the client does not need
-to wait for a request to be fully sent to send another,
-it is possible to interleave a request with the request
-body of another request. The same is true with responses.
-Responses may also be sent in a different order.
-
-Because requests and responses are fully asynchronous,
-Cowboy creates a new process for each request, and these
-processes are managed by another process that handles the
-connection itself.
-
-SPDY servers may also decide to send resources to the
-client before the client requests them. This is especially
-useful for sending static files associated with the HTML
-page requested, as this reduces the latency of the overall
-response. Cowboy does not support this particular mechanism
-at this point, however.