aboutsummaryrefslogtreecommitdiffstats
path: root/doc/src
diff options
context:
space:
mode:
authorLoïc Hoguin <[email protected]>2014-09-30 20:12:13 +0300
committerLoïc Hoguin <[email protected]>2014-09-30 20:12:13 +0300
commit0dc063ab7d94edb37c61f821b5d8e4c2da7f8ff1 (patch)
treeaaa71b552b0348fc403cc68ba8318e58f213d4fd /doc/src
parent5ce4c2bfb40ecc4b687a2941e612025a1c4ff913 (diff)
downloadcowboy-0dc063ab7d94edb37c61f821b5d8e4c2da7f8ff1.tar.gz
cowboy-0dc063ab7d94edb37c61f821b5d8e4c2da7f8ff1.tar.bz2
cowboy-0dc063ab7d94edb37c61f821b5d8e4c2da7f8ff1.zip
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.
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/guide/erlang_beginners.ezdoc5
-rw-r--r--doc/src/guide/getting_started.ezdoc6
-rw-r--r--doc/src/guide/handlers.ezdoc99
-rw-r--r--doc/src/guide/http_handlers.ezdoc132
-rw-r--r--doc/src/guide/index.ezdoc37
-rw-r--r--doc/src/guide/introduction.ezdoc11
-rw-r--r--doc/src/guide/loop_handlers.ezdoc28
-rw-r--r--doc/src/guide/multipart.ezdoc (renamed from doc/src/guide/multipart_req.ezdoc)49
-rw-r--r--doc/src/guide/multipart_intro.ezdoc50
-rw-r--r--doc/src/guide/overview.ezdoc (renamed from doc/src/guide/http_req_life.ezdoc)2
-rw-r--r--doc/src/guide/rest_handlers.ezdoc10
-rw-r--r--doc/src/guide/static_files.ezdoc (renamed from doc/src/guide/static_handlers.ezdoc)9
-rw-r--r--doc/src/guide/sub_protocols.ezdoc64
-rw-r--r--doc/src/guide/upgrade_protocol.ezdoc61
-rw-r--r--doc/src/guide/ws_handlers.ezdoc6
-rw-r--r--doc/src/guide/ws_protocol.ezdoc2
-rw-r--r--doc/src/manual/cowboy_handler.ezdoc88
-rw-r--r--doc/src/manual/cowboy_http_handler.ezdoc57
-rw-r--r--doc/src/manual/cowboy_loop.ezdoc100
-rw-r--r--doc/src/manual/cowboy_loop_handler.ezdoc91
-rw-r--r--doc/src/manual/cowboy_rest.ezdoc56
-rw-r--r--doc/src/manual/cowboy_websocket.ezdoc133
-rw-r--r--doc/src/manual/cowboy_websocket_handler.ezdoc133
-rw-r--r--doc/src/manual/index.ezdoc4
24 files changed, 604 insertions, 629 deletions
diff --git a/doc/src/guide/erlang_beginners.ezdoc b/doc/src/guide/erlang_beginners.ezdoc
index f62543f..74d3470 100644
--- a/doc/src/guide/erlang_beginners.ezdoc
+++ b/doc/src/guide/erlang_beginners.ezdoc
@@ -33,8 +33,3 @@ Instead of going into every single details of the language,
Joe focuses on the central concepts behind Erlang, and shows
you how they can be used to write a variety of different
applications.
-
-At the time of writing, the 2nd edition of the book is in beta,
-and includes a few details about upcoming Erlang features that
-cannot be used today. Choose the edition you want, then get
-reading!
diff --git a/doc/src/guide/getting_started.ezdoc b/doc/src/guide/getting_started.ezdoc
index 34f02dc..a959b45 100644
--- a/doc/src/guide/getting_started.ezdoc
+++ b/doc/src/guide/getting_started.ezdoc
@@ -150,15 +150,15 @@ $ make new t=cowboy_http n=hello_handler
```
You can then open the `src/hello_handler.erl` file and modify
-the `handle/2` function like this to send a reply.
+the `init/2` function like this to send a reply.
``` erlang
-handle(Req, State=#state{}) ->
+init(Req, Opts) ->
Req2 = cowboy_req:reply(200,
[{<<"content-type">>, <<"text/plain">>}],
<<"Hello Erlang!">>,
Req),
- {ok, Req2, State}.
+ {ok, Req2, Opts}.
```
What the above code does is send a `200 OK` reply, with the
diff --git a/doc/src/guide/handlers.ezdoc b/doc/src/guide/handlers.ezdoc
new file mode 100644
index 0000000..c0fb97e
--- /dev/null
+++ b/doc/src/guide/handlers.ezdoc
@@ -0,0 +1,99 @@
+::: Handlers
+
+Handlers are Erlang modules that handle HTTP requests.
+
+:: Plain HTTP handlers
+
+The most basic handler in Cowboy implements the mandatory
+`init/2` callback, manipulates the request, optionally
+sends a response and then returns.
+
+This callback receives the ^"Req object^req and the options
+defined during the ^"router configuration^routing^.
+
+A handler that does nothing would look like this:
+
+``` erlang
+init(Req, Opts) ->
+ {ok, Req, Opts}.
+```
+
+Despite sending no reply, a `204 No Content` reply will be
+sent to the client, as Cowboy makes sure that a reply is
+sent for every request.
+
+We need to use the Req object for sending a reply.
+
+``` erlang
+init(Req, Opts) ->
+ Req2 = cowboy_req:reply(200, [
+ {<<"content-type">>, <<"text/plain">>}
+ ], <<"Hello World!">>, Req),
+ {ok, Req2, Opts}.
+```
+
+As you can see we return a 3-tuple. `ok` means that the
+handler ran successfully. The Req object is returned as
+it may have been modified as is the case here: replying
+returns a modified Req object that you need to return
+back to Cowboy for proper operations.
+
+The last value of the tuple is a state that will be used
+in every subsequent callbacks to this handler. Plain HTTP
+handlers only have one additional callback, the optional
+`terminate/3`.
+
+:: Other handlers
+
+The `init/2` callback can also be used to inform Cowboy
+that this is a different kind of handler and that Cowboy
+should switch to it. To do this you simply need to return
+the module name of the handler type you want to switch to.
+
+Cowboy comes with three handler types you can switch to:
+^"cowboy_rest^rest_handlers^, ^"cowboy_websocket^ws_handlers^
+and ^"cowboy_loop^loop_handlers^. In addition to those you
+can define your own handler types.
+
+Switching is simple. Instead of returning `ok`, you simply
+return the name of the handler type you want to use. The
+following snippet switches to a Websocket handler:
+
+``` erlang
+init(Req, Opts) ->
+ {cowboy_websocket, Req, Opts}.
+```
+
+You can also switch to your own custom handler type:
+
+``` erlang
+init(Req, Opts) ->
+ {my_handler_type, Req, Opts}.
+```
+
+How to implement a custom handler type is described in the
+^"Sub protocols^sub_protocols chapter.
+
+:: Cleaning up
+
+All handlers coming with Cowboy allow the use of the optional
+`terminate/3` callback.
+
+``` erlang
+terminate(_Reason, Req, State) ->
+ ok.
+```
+
+This callback is strictly reserved for any required cleanup.
+You cannot send a response from this function. There is no
+other return value.
+
+If you used the process dictionary, timers, monitors or may
+be receiving messages, then you can use this function to clean
+them up, as Cowboy might reuse the process for the next
+keep-alive request.
+
+Note that while this function may be called in a Websocket
+handler, it is generally not useful to do any clean up as
+the process terminates immediately after calling this callback
+when using Websocket.
diff --git a/doc/src/guide/http_handlers.ezdoc b/doc/src/guide/http_handlers.ezdoc
deleted file mode 100644
index d846ffe..0000000
--- a/doc/src/guide/http_handlers.ezdoc
+++ /dev/null
@@ -1,132 +0,0 @@
-::: Handling plain HTTP requests
-
-The simplest way to handle a request is by writing a
-plain HTTP handler. It is modeled after Erlang/OTP's
-gen_server behaviour, although simplified, as Cowboy
-will simply call the three callbacks sequentially.
-
-:: Initialization
-
-The first callback, `init/2`, is common to all handlers,
-as it is used to identify the type of handler. Plain
-HTTP handlers just return `http`.
-
-``` erlang
-init(Req, Opts) ->
- {http, Req, Opts}.
-```
-
-This function receives the options associated with
-this route that you configured previously.
-
-You do not need to validate the options unless they
-are user configured. If they are, and there's a
-configuration error, you may choose to crash. For
-example, this will crash if the required `lang`
-option is not found.
-
-``` erlang
-init(Req, Opts) ->
- {_, Lang} = lists:keyfind(lang, 1, Opts),
- {http, Req, Lang}.
-```
-
-If your users are unlikely to figure out the issue
-without explanations, then you should send a more
-meaningful error back to the user. Since we already
-replied to the user, there's no need for us to
-continue with the handler code, so we use the
-`shutdown` return value to stop early.
-
-``` erlang
-init(Req, Opts) ->
- case lists:keyfind(lang, 1, Opts) of
- false ->
- Req2 = cowboy_req:reply(500, [
- {<<"content-type">>, <<"text/plain">>}
- ], "Missing option 'lang'.", Req),
- {shutdown, Req2, undefined};
- {_, Lang} ->
- {http, Req, Lang}
- end.
-```
-
-Once the options have been validated, we can use them
-safely. So we need to pass them onward to the rest of
-the handler. That's what the third element of the return
-tuple, the state, is for.
-
-You may use a state record for this. The record will make
-your handler code clearer and will allow Dialyzer to better
-type check your code.
-
-``` erlang
--record(state, {
- lang :: en | fr
- %% More fields here.
-}).
-
-init(Req, Opts) ->
- {_, Lang} = lists:keyfind(lang, 1, Opts),
- {http, Req, #state{lang=Lang}}.
-```
-
-You may also use a map. A map is interesting in that you
-do not need to define it beforehand, but is a little less
-efficient and not as well supported by Dialyzer.
-
-``` erlang
-init(Req, Opts) ->
- {_, Lang} = lists:keyfind(lang, 1, Opts),
- {http, Req, #{lang => Lang}.
-```
-
-:: Handling the request
-
-The second callback, `handle/2`, is specific to plain HTTP
-handlers. It's where you handle the request.
-
-A handle function that does nothing would look like this:
-
-``` erlang
-handle(Req, State) ->
- {ok, Req, State}.
-```
-
-There's no other return value. To obtain information about
-the request, or send a response, you would use the Req object
-here. The Req object is documented in its own chapter.
-
-The following handle function will send a fairly original response.
-
-``` erlang
-handle(Req, State) ->
- Req2 = cowboy_req:reply(200, [
- {<<"content-type">>, <<"text/plain">>}
- ], <<"Hello World!">>, Req),
- {ok, Req2, State}.
-```
-
-:: Cleaning up
-
-The third and last callback, `terminate/3`, is optional.
-
-``` erlang
-terminate(_Reason, Req, State) ->
- ok.
-```
-
-This callback is strictly reserved for any required cleanup.
-You cannot send a response from this function. There is no
-other return value.
-
-If you used the process dictionary, timers, monitors or may
-be receiving messages, then you can use this function to clean
-them up, as Cowboy might reuse the process for the next
-keep-alive request.
-
-The chances of any of this happening in your handler are pretty
-thin however. The use of the process dictionary is discouraged
-in Erlang code in general. And if you need to use timers, monitors
-or to receive messages, you are better off with a loop handler,
-a different kind of handler meant specifically for this use.
diff --git a/doc/src/guide/index.ezdoc b/doc/src/guide/index.ezdoc
index 300cea8..dbe75ff 100644
--- a/doc/src/guide/index.ezdoc
+++ b/doc/src/guide/index.ezdoc
@@ -1,35 +1,34 @@
::: Cowboy User Guide
The Cowboy User Guide explores the modern Web and how to make
-best use of Cowboy for writing powerful web applications.
+best use of Cowboy for writing powerful Web applications.
-:: Introducing Cowboy
+:: Rationale
-* ^"Introduction^introduction
* ^"The modern Web^modern_web
* ^"Erlang and the Web^erlang_web
-* ^"Erlang for beginners^erlang_beginners
+
+:: Introduction
+
+* ^"Introduction^introduction
* ^"Getting started^getting_started
+* ^"Request overview^overview
+* ^"Erlang for beginners^erlang_beginners
-:: HTTP
+:: Configuration
-* ^"The life of a request^http_req_life
* ^"Routing^routing
* ^"Constraints^constraints
-* ^"Handling plain HTTP requests^http_handlers
+* ^"Static files^static_files
+
+:: Request and response
+
+* ^"Handlers^handlers
* ^"The Req object^req
* ^"Reading the request body^req_body
* ^"Sending a response^resp
* ^"Using cookies^cookies
-
-:: Multipart
-
-* ^"Introduction to multipart^multipart_intro
-* ^"Multipart requests^multipart_req
-
-:: Static files
-
-* ^"Static handler^static_handlers
+* ^"Multipart^multipart
:: REST
@@ -43,14 +42,14 @@ best use of Cowboy for writing powerful web applications.
* ^"The Websocket protocol^ws_protocol
* ^"Handling Websocket connections^ws_handlers
-:: Server push
+:: Push technology
* ^"Loop handlers^loop_handlers
-:: Pluggable interface
+:: Extensions
* ^"Middlewares^middlewares
-* ^"Protocol upgrades^upgrade_protocol
+* ^"Sub protocols^sub_protocols
* ^"Hooks^hooks
:: Internals
diff --git a/doc/src/guide/introduction.ezdoc b/doc/src/guide/introduction.ezdoc
index 18345df..e1d2e60 100644
--- a/doc/src/guide/introduction.ezdoc
+++ b/doc/src/guide/introduction.ezdoc
@@ -16,9 +16,7 @@ features both a Function Reference and a User Guide.
:: Prerequisites
-No Erlang knowledge is required for reading this guide. The reader will
-be introduced to Erlang concepts and redirected to reference material
-whenever necessary.
+Beginner Erlang knowledge is recommended for reading this guide.
Knowledge of the HTTP protocol is recommended but not required, as it
will be detailed throughout the guide.
@@ -32,12 +30,15 @@ guarantee that the experience will be safe and smooth. You are advised
to perform the necessary testing and security audits prior to deploying
on other platforms.
-Cowboy is developed for Erlang/OTP R16B01, R16B02, R16B03-1, 17.0 and
-17.1.2.
+Cowboy is developed for Erlang/OTP 17.0, 17.1.2 and 17.3. By the time
+this branch gets released the target version will probably be 18.0 and
+above.
Cowboy may be compiled on other Erlang versions with small source code
modifications but there is no guarantee that it will work as expected.
+Cowboy uses the maps data type which was introduced in Erlang 17.0.
+
:: Versioning
Cowboy uses ^"Semantic Versioning 2.0.0^http://semver.org/^.
diff --git a/doc/src/guide/loop_handlers.ezdoc b/doc/src/guide/loop_handlers.ezdoc
index 445854c..8da2805 100644
--- a/doc/src/guide/loop_handlers.ezdoc
+++ b/doc/src/guide/loop_handlers.ezdoc
@@ -8,7 +8,7 @@ a response.
Loop handlers are used for requests where a response might not
be immediately available, but where you would like to keep the
connection open for a while in case the response arrives. The
-most known example of such practice is known as long-polling.
+most known example of such practice is known as long polling.
Loop handlers can also be used for requests where a response is
partially available and you need to stream the response body
@@ -21,12 +21,12 @@ and allow using built-in features like hibernation and timeouts.
Loop handlers essentially wait for one or more Erlang messages
and feed these messages to the `info/3` callback. It also features
-the `init/3` and `terminate/3` callbacks which work the same as
+the `init/2` and `terminate/3` callbacks which work the same as
for plain HTTP handlers.
:: Initialization
-The `init/3` function must return a `loop` tuple to enable
+The `init/2` function must return a `cowboy_loop` tuple to enable
loop handler behavior. This tuple may optionally contain
a timeout value and/or the atom `hibernate` to make the
process enter hibernation until a message is received.
@@ -35,7 +35,7 @@ This snippet enables the loop handler.
``` erlang
init(Req, Opts) ->
- {long_polling, Req, Opts}.
+ {cowboy_loop, Req, Opts}.
```
However it is largely recommended that you set a timeout
@@ -44,7 +44,7 @@ also makes the process hibernate.
``` erlang
init(Req, Opts) ->
- {long_polling, Req, Opts, 30000, hibernate}.
+ {cowboy_loop, Req, Opts, 30000, hibernate}.
```
:: Receive loop
@@ -61,9 +61,9 @@ message otherwise.
``` erlang
info({reply, Body}, Req, State) ->
Req2 = cowboy_req:reply(200, [], Body, Req),
- {ok, Req2, State};
+ {shutdown, Req2, State};
info(_Msg, Req, State) ->
- {loop, Req, State, hibernate}.
+ {ok, Req, State, hibernate}.
```
Do note that the `reply` tuple here may be any message
@@ -76,17 +76,17 @@ return a tuple indicating if more messages are to be expected.
The callback may also choose to do nothing at all and just
skip the message received.
-If a reply is sent, then the `ok` tuple should be returned.
+If a reply is sent, then the `shutdown` tuple should be returned.
This will instruct Cowboy to end the request.
-Otherwise a `loop` tuple should be returned.
+Otherwise an `ok` tuple should be returned.
:: Streaming loop
Another common case well suited for loop handlers is
streaming data received in the form of Erlang messages.
This can be done by initiating a chunked reply in the
-`init/3` callback and then using `cowboy_req:chunk/2`
+`init/2` callback and then using `cowboy_req:chunk/2`
every time a message is received.
The following snippet does exactly that. As you can see
@@ -96,15 +96,15 @@ and the loop is stopped by sending an `eof` message.
``` erlang
init(Req, Opts) ->
Req2 = cowboy_req:chunked_reply(200, [], Req),
- {long_polling, Req2, Opts}.
+ {cowboy_loop, Req2, Opts}.
info(eof, Req, State) ->
- {ok, Req, State};
+ {shutdown, Req, State};
info({chunk, Chunk}, Req, State) ->
cowboy_req:chunk(Chunk, Req),
- {loop, Req, State};
+ {ok, Req, State};
info(_Msg, Req, State) ->
- {loop, Req, State}.
+ {ok, Req, State}.
```
:: Cleaning up
diff --git a/doc/src/guide/multipart_req.ezdoc b/doc/src/guide/multipart.ezdoc
index 21762f6..d0b2e40 100644
--- a/doc/src/guide/multipart_req.ezdoc
+++ b/doc/src/guide/multipart.ezdoc
@@ -1,11 +1,60 @@
::: Multipart requests
+Multipart originates from MIME, an Internet standard that
+extends the format of emails. Multipart messages are a
+container for parts of any content-type.
+
+For example, a multipart message may have a part
+containing text and a second part containing an
+image. This is what allows you to attach files
+to emails.
+
+In the context of HTTP, multipart is most often used
+with the `multipart/form-data` content-type. This is
+the content-type you have to use when you want browsers
+to be allowed to upload files through HTML forms.
+
+Multipart is of course not required for uploading
+files, it is only required when you want to do so
+through HTML forms.
+
You can read and parse multipart messages using the
Req object directly.
Cowboy defines two functions that allows you to get
information about each part and read their contents.
+:: Structure
+
+A multipart message is a list of parts. Parts may
+contain either a multipart message or a non-multipart
+content-type. This allows parts to be arranged in a
+tree structure, although this is a rare case as far
+as the Web is concerned.
+
+:: Form-data
+
+In the normal case, when a form is submitted, the
+browser will use the `application/x-www-form-urlencoded`
+content-type. This type is just a list of keys and
+values and is therefore not fit for uploading files.
+
+That's where the `multipart/form-data` content-type
+comes in. When the form is configured to use this
+content-type, the browser will use one part of the
+message for each form field. This means that a file
+input field will be sent in its own part, but the
+same applies to all other kinds of fields.
+
+A form with a text input, a file input and a select
+choice box will result in a multipart message with
+three parts, one for each field.
+
+The browser does its best to determine the content-type
+of the files it sends this way, but you should not
+rely on it for determining the contents of the file.
+Proper investigation of the contents is recommended.
+
:: Checking the content-type
While there is a variety of multipart messages, the
diff --git a/doc/src/guide/multipart_intro.ezdoc b/doc/src/guide/multipart_intro.ezdoc
deleted file mode 100644
index b9a7fa9..0000000
--- a/doc/src/guide/multipart_intro.ezdoc
+++ /dev/null
@@ -1,50 +0,0 @@
-::: Introduction to multipart
-
-Multipart originates from MIME, an Internet standard that
-extends the format of emails. Multipart messages are a
-container for parts of any content-type.
-
-For example, a multipart message may have a part
-containing text and a second part containing an
-image. This is what allows you to attach files
-to emails.
-
-In the context of HTTP, multipart is most often used
-with the `multipart/form-data` content-type. This is
-the content-type you have to use when you want browsers
-to be allowed to upload files through HTML forms.
-
-Multipart is of course not required for uploading
-files, it is only required when you want to do so
-through HTML forms.
-
-:: Structure
-
-A multipart message is a list of parts. Parts may
-contain either a multipart message or a non-multipart
-content-type. This allows parts to be arranged in a
-tree structure, although this is a rare case as far
-as the Web is concerned.
-
-:: Form-data
-
-In the normal case, when a form is submitted, the
-browser will use the `application/x-www-form-urlencoded`
-content-type. This type is just a list of keys and
-values and is therefore not fit for uploading files.
-
-That's where the `multipart/form-data` content-type
-comes in. When the form is configured to use this
-content-type, the browser will use one part of the
-message for each form field. This means that a file
-input field will be sent in its own part, but the
-same applies to all other kinds of fields.
-
-A form with a text input, a file input and a select
-choice box will result in a multipart message with
-three parts, one for each field.
-
-The browser does its best to determine the content-type
-of the files it sends this way, but you should not
-rely on it for determining the contents of the file.
-Proper investigation of the contents is recommended.
diff --git a/doc/src/guide/http_req_life.ezdoc b/doc/src/guide/overview.ezdoc
index ffe5dfa..725ae4e 100644
--- a/doc/src/guide/http_req_life.ezdoc
+++ b/doc/src/guide/overview.ezdoc
@@ -1,4 +1,4 @@
-::: The life of a request
+::: Request overview
This chapter explains the different steps a request
goes through until a response is sent, along with
diff --git a/doc/src/guide/rest_handlers.ezdoc b/doc/src/guide/rest_handlers.ezdoc
index 294392a..8cdd12e 100644
--- a/doc/src/guide/rest_handlers.ezdoc
+++ b/doc/src/guide/rest_handlers.ezdoc
@@ -1,20 +1,20 @@
::: REST handlers
-REST is implemented in Cowboy as a protocol upgrade. Once upgraded,
-the request is handled as a state machine with many optional callbacks
+REST is implemented in Cowboy as a sub protocol. The request
+is handled as a state machine with many optional callbacks
describing the resource and modifying the machine's behavior.
-The REST handler is the recommended way to handle requests.
+The REST handler is the recommended way to handle HTTP requests.
:: Initialization
First, the `init/2` callback is called. This callback is common
to all handlers. To use REST for the current request, this function
-must return a `rest` tuple.
+must return a `cowboy_rest` tuple.
``` erlang
init(Req, Opts) ->
- {rest, Req, Opts}.
+ {cowboy_rest, Req, Opts}.
```
Cowboy will then switch to the REST protocol and start executing
diff --git a/doc/src/guide/static_handlers.ezdoc b/doc/src/guide/static_files.ezdoc
index f5eaac3..5a289d0 100644
--- a/doc/src/guide/static_handlers.ezdoc
+++ b/doc/src/guide/static_files.ezdoc
@@ -1,8 +1,9 @@
-::: Static handler
+::: Static files
-The static handler is a built-in REST handler for serving files.
-It is available as a convenience and provides a quick solution
-for serving files during development.
+Cowboy comes with a special handler built as a REST handler
+and designed specifically for serving static files. It is
+provided as a convenience and provides a quick solution for
+serving files during development.
For systems in production, consider using one of the many
Content Distribution Network (CDN) available on the market,
diff --git a/doc/src/guide/sub_protocols.ezdoc b/doc/src/guide/sub_protocols.ezdoc
new file mode 100644
index 0000000..d34f21e
--- /dev/null
+++ b/doc/src/guide/sub_protocols.ezdoc
@@ -0,0 +1,64 @@
+::: Sub protocols
+
+Sub protocols are used for creating new types of handlers that
+provide extra functionality in a reusable way. Cowboy uses this
+mechanism to provide its loop, REST and Websocket handlers.
+
+This chapter will explain how to create your own sub protocols
+and handler types.
+
+:: Usage
+
+To switch to a sub protocol, the `init/2` callback must return
+the name of the sub protocol module. Everything past this point
+is handled by the sub protocol.
+
+``` erlang
+init(Req, Opts) ->
+ {cowboy_websocket, Req, Opts}.
+```
+
+The return value may also have a `Timeout` value and/or the
+atom `hibernate`. These options are useful for long living
+connections. When they are not provided, the timeout value
+defaults to `infinity` and the hibernate value to `run`.
+
+The following snippet switches to the `my_protocol` sub
+protocol, sets the timeout value to 5 seconds and enables
+hibernation:
+
+``` erlang
+init(Req, Opts) ->
+ {my_protocol, Req, Opts, 5000, hibernate}.
+```
+
+If a sub protocol does not make use of these options, it should
+crash if it receives anything other than the default values.
+
+:: Upgrade
+
+After the `init/2` function returns, Cowboy will then call the
+`upgrade/6` function. This is the only callback defined by the
+`cowboy_sub_protocol` behavior.
+
+The function is named `upgrade` because it mimics the mechanism
+of HTTP protocol upgrades. For some sub protocols, like Websocket,
+an actual upgrade is performed. For others, like REST, this is
+only an upgrade at Cowboy's level and the client has nothing to
+do about it.
+
+The upgrade callback receives the Req object, the middleware
+environment, the handler and its options, and the aforementioned
+timeout and hibernate values.
+
+``` erlang
+upgrade(Req, Env, Handler, HandlerOpts, Timeout, Hibernate) ->
+ %% Sub protocol code here.
+```
+
+This callback is expected to behave like a middleware and to
+return an updated environment and Req object.
+
+Sub protocols are expected to call the `cowboy_handler:terminate/4`
+function when they terminate. This function will make sure that
+the optional `terminate/3` callback is called, if present.
diff --git a/doc/src/guide/upgrade_protocol.ezdoc b/doc/src/guide/upgrade_protocol.ezdoc
deleted file mode 100644
index ad2d25a..0000000
--- a/doc/src/guide/upgrade_protocol.ezdoc
+++ /dev/null
@@ -1,61 +0,0 @@
-::: Protocol upgrades
-
-Cowboy features many different handlers, each for different purposes.
-All handlers have a common entry point: the `init/2` function.
-This function returns the name of the protocol that will be
-used for processing the request, along with various options.
-
-Cowboy defines four built-in handler types. Three of them are
-implemented as sub protocols. More can be implemented by
-writing a custom sub protocol.
-
-The following table lists the built-in handler types.
-
-|| Alias Module Description
-|
-| http - Plain HTTP handler
-| long_polling cowboy_long_polling Long-polling handler
-| rest cowboy_rest REST handler
-| ws cowboy_websocket Websocket handler
-
-Both the alias or the module name can be used to specify the
-kind of handler. In addition, a user-defined module name can
-be used.
-
-``` erlang
-init(Req, Opts) ->
- {my_protocol, Req, Opts}.
-```
-
-The `init/2` function can also return some extra options for
-handlers that are meant to be long running, for example the
-`long_polling` and `ws` handler types. These options can also
-be passed on to custom sub protocols. For example the following
-`init/2` function defines both a timeout value and enables
-process hibernation:
-
-``` erlang
-init(Req, Opts) ->
- {my_protocol, Req, Opts, 5000, hibernate}.
-```
-
-It is up to the sub protocol to implement these (or reject
-them if they are not supported).
-
-The `cowboy_sub_protocol` behavior only requires one callback,
-`upgrade/6`. It receives the Req object, the middleware environment,
-the handler and options for this request, and the timeout and
-hibernate values. The default timeout value is `infinity` and
-the default hibernate value is `run`.
-
-``` erlang
-upgrade(Req, Env, Handler, HandlerOpts, Timeout, Hibernate) ->
- %% ...
-```
-
-This callback is expected to behave like a middleware. Please
-see the corresponding chapter for more information.
-
-Sub protocols are expected to call the `cowboy_handler:terminate/5`
-function when they terminate. This function will make sure that
-the optional `terminate/3` callback will be called, if present.
diff --git a/doc/src/guide/ws_handlers.ezdoc b/doc/src/guide/ws_handlers.ezdoc
index 893624b..cb30511 100644
--- a/doc/src/guide/ws_handlers.ezdoc
+++ b/doc/src/guide/ws_handlers.ezdoc
@@ -17,7 +17,7 @@ must return a `ws` tuple.
``` erlang
init(Req, Opts) ->
- {ws, Req, Opts}.
+ {cowboy_websocket, Req, Opts}.
```
Upon receiving this tuple, Cowboy will switch to the code
@@ -61,7 +61,7 @@ or enabling timers.
init(Req, _Opts) ->
self() ! post_init,
%% Register process here...
- {ws, Req, #state{}}.
+ {cowboy_websocket, Req, #state{}}.
websocket_info(post_init, Req, State) ->
%% Perform post_init initialization here...
@@ -161,7 +161,7 @@ A good timeout value is 60 seconds.
``` erlang
init(Req, _Opts) ->
- {ws, Req, #state{}, 60000}.
+ {cowboy_websocket, Req, #state{}, 60000}.
```
This value cannot be changed once it is set. It defaults to
diff --git a/doc/src/guide/ws_protocol.ezdoc b/doc/src/guide/ws_protocol.ezdoc
index 15aea2c..d283ae3 100644
--- a/doc/src/guide/ws_protocol.ezdoc
+++ b/doc/src/guide/ws_protocol.ezdoc
@@ -25,7 +25,7 @@ excluding the initial flawed draft sometimes known as
:: Implementation
Cowboy implements Websocket as a protocol upgrade. Once the
-upgrade is performed from the `init/3` callback, Cowboy
+upgrade is performed from the `init/2` callback, Cowboy
switches to Websocket. Please consult the next chapter for
more information on initiating and handling Websocket
connections.
diff --git a/doc/src/manual/cowboy_handler.ezdoc b/doc/src/manual/cowboy_handler.ezdoc
index 0495f28..b440b60 100644
--- a/doc/src/manual/cowboy_handler.ezdoc
+++ b/doc/src/manual/cowboy_handler.ezdoc
@@ -15,10 +15,96 @@ Environment output:
* result = ok
+This module also defines the `cowboy_handler` behaviour that
+defines the basic interface for handlers. All Cowboy handlers
+implement at least the `init/2` callback, and may implement
+the `terminate/3` callback optionally.
+
:: Types
None.
+:: Terminate reasons
+
+The following values may be received as the terminate reason
+in the optional `terminate/3` callback. Different handler types
+may define additional terminate reasons.
+
+: normal
+
+The connection was closed normally.
+
+: {crash, Class, Reason}
+
+A crash occurred in the handler. `Class` and `Reason` can be
+used to obtain more information about the crash. The function
+`erlang:get_stacktrace/0` can also be called to obtain the
+stacktrace of the process when the crash occurred.
+
+:: Callbacks
+
+: init(Req, Opts)
+ -> {ok, Req, State}
+ | {Module, Req, State}
+ | {Module, Req, State, hibernate}
+ | {Module, Req, State, Timeout}
+ | {Module, Req, State, Timeout, hibernate}
+
+Types:
+
+* Req = cowboy_req:req()
+* Opts = any()
+* State = any()
+* Module = module()
+* Timeout = timeout()
+
+Process the request.
+
+This function can be used to switch to an alternate handler
+type by returning the name of the module to be used, along
+with a few options.
+
+For basic handlers this is the function where the response
+should be sent. If no response is sent, Cowboy will ensure
+that a `204 No Content` response is sent.
+
+A crash in this callback will result in `terminate/3` being
+called if it is defined, with the `State` argument set to
+the value of `Opts` originally given to the `init/2` callback.
+
+: terminate(Reason, Req, State) -> ok
+
+Types:
+
+* Reason = any()
+* Req = cowboy_req:req()
+* State = any()
+
+Perform any necessary cleanup of the state.
+
+This callback should release any resource currently in use,
+clear any active timer and reset the process to its original
+state, as it might be reused for future requests sent on the
+same connection. Typical plain HTTP handlers rarely need to
+use it.
+
+A crash in this callback or an invalid return value will
+result in the closing of the connection and the termination
+of the process.
+
:: Exports
-None.
+: terminate(Reason, Req, State, Handler) -> ok
+
+Types:
+
+* Reason = any()
+* Req = cowboy_req:req()
+* State = any()
+* Handler = module()
+
+Call the optional `terminate/3` callback if it exists.
+
+This function should always be called at the end of the execution
+of a handler, to give it a chance to clean up or perform
+miscellaneous operations.
diff --git a/doc/src/manual/cowboy_http_handler.ezdoc b/doc/src/manual/cowboy_http_handler.ezdoc
deleted file mode 100644
index 6776598..0000000
--- a/doc/src/manual/cowboy_http_handler.ezdoc
+++ /dev/null
@@ -1,57 +0,0 @@
-::: cowboy_http_handler
-
-The `cowboy_http_handler` behaviour defines the interface used
-by plain HTTP handlers.
-
-Unless noted otherwise, the callbacks will be executed sequentially.
-
-:: Types
-
-None.
-
-:: Callbacks
-
-: init({TransportName, ProtocolName}, Req, Opts)
- -> {ok, Req, State} | {shutdown, Req, State}
-
-Types:
-
-* TransportName = tcp | ssl | atom()
-* ProtocolName = http | atom()
-* Req = cowboy_req:req()
-* Opts = any()
-* State = any()
-
-Initialize the state for this request.
-
-The `shutdown` return value can be used to skip the `handle/2`
-call entirely.
-
-: handle(Req, State) -> {ok, Req, State}
-
-Types:
-
-* Req = cowboy_req:req()
-* State = any()
-
-Handle the request.
-
-This callback is where the request is handled and a response
-should be sent. If a response is not sent, Cowboy will send
-a `204 No Content` response automatically.
-
-: terminate(Reason, Req, State) -> ok
-
-Types:
-
-* Reason = {normal, shutdown} | {error, atom()}
-* Req = cowboy_req:req()
-* State = any()
-
-Perform any necessary cleanup of the state.
-
-This callback should release any resource currently in use,
-clear any active timer and reset the process to its original
-state, as it might be reused for future requests sent on the
-same connection. Typical plain HTTP handlers rarely need to
-use it.
diff --git a/doc/src/manual/cowboy_loop.ezdoc b/doc/src/manual/cowboy_loop.ezdoc
new file mode 100644
index 0000000..1f3ab9e
--- /dev/null
+++ b/doc/src/manual/cowboy_loop.ezdoc
@@ -0,0 +1,100 @@
+::: cowboy_loop
+
+The `cowboy_loop` module implements a handler interface for
+long running HTTP connections. It is the recommended interface
+for long polling and server-sent events, amongst others.
+
+This module is a sub protocol that defines three callbacks to
+be implemented by handlers. The `init/2` and `terminate/3`
+callbacks are common to all handler types and are documented
+in the manual for the ^cowboy_handler module.
+
+The `info/3` callback is specific to loop handlers and will be
+called as many times as necessary until a reply is sent.
+
+It is highly recommended to return a timeout value from the
+`init/2` callback to ensure that the process is terminated
+when no data has been received during that timespan. The
+default timeout is `infinity`, which should only be used if
+you have alternate means of ending inactive connections.
+
+:: Types
+
+None.
+
+:: Terminate reasons
+
+The following values may be received as the terminate reason
+in the optional `terminate/3` callback.
+
+: normal
+
+The connection was closed normally before switching to the
+loop sub protocol. This typically happens if an `ok` tuple is
+returned from the `init/2` callback.
+
+: shutdown
+
+The handler requested to close the connection by returning
+a `shutdown` tuple.
+
+: timeout
+
+The connection has been closed due to inactivity. The timeout
+value can be configured from `init/2`. The response sent when
+this happens is a `204 No Content`.
+
+: {crash, Class, Reason}
+
+A crash occurred in the handler. `Class` and `Reason` can be
+used to obtain more information about the crash. The function
+`erlang:get_stacktrace/0` can also be called to obtain the
+stacktrace of the process when the crash occurred.
+
+: {error, overflow}
+
+The connection is being closed and the process terminated
+because the buffer Cowboy uses to keep data sent by the
+client has reached its maximum. The buffer size can be
+configured through the environment value `loop_max_buffer`
+and defaults to 5000 bytes.
+
+If the long running request comes with a body it is recommended
+to process this body before switching to the loop sub protocol.
+
+: {error, closed}
+
+The socket has been closed brutally without a close frame being
+received first.
+
+: {error, Reason}
+
+A socket error ocurred.
+
+:: Callbacks
+
+: info(Info, Req, State)
+ -> {ok, Req, State}
+ | {ok, Req, State, hibernate}
+ | {shutdown, Req, State}
+
+Types:
+
+* Info = any()
+* Req = cowboy_req:req()
+* State = any()
+
+Handle the Erlang message received.
+
+This function will be called every time an Erlang message
+has been received. The message can be any Erlang term.
+
+The `shutdown` return value can be used to stop the receive loop,
+typically because a response has been sent.
+
+The `hibernate` option will hibernate the process until
+it receives another message.
+
+:: Exports
+
+None.
diff --git a/doc/src/manual/cowboy_loop_handler.ezdoc b/doc/src/manual/cowboy_loop_handler.ezdoc
deleted file mode 100644
index 0811a9a..0000000
--- a/doc/src/manual/cowboy_loop_handler.ezdoc
+++ /dev/null
@@ -1,91 +0,0 @@
-::: cowboy_loop_handler
-
-The `cowboy_loop_handler` behaviour defines the interface used
-by HTTP handlers that do not send a response directly, instead
-requiring a receive loop to process Erlang messages.
-
-This interface is best fit for long-polling types of requests.
-
-The `init/3` callback will always be called, followed by zero
-or more calls to `info/3`. The `terminate/3` callback will
-always be called last.
-
-:: Types
-
-None.
-
-:: Callbacks
-
-: init({TransportName, ProtocolName}, Req, Opts)
- -> {loop, Req, State}
- | {loop, Req, State, hibernate}
- | {loop, Req, State, Timeout}
- | {loop, Req, State, Timeout, hibernate}
- | {shutdown, Req, State}
-
-Types:
-
-* TransportName = tcp | ssl | atom()
-* ProtocolName = http | atom()
-* Req = cowboy_req:req()
-* Opts = any()
-* State = any()
-* Timeout = timeout()
-
-Initialize the state for this request.
-
-This callback will typically be used to register this process
-to an event manager or a message queue in order to receive
-the messages the handler wants to process.
-
-The receive loop will run for a duration of up to `Timeout`
-milliseconds after it last received data from the socket,
-at which point it will stop and send a `204 No Content` reply.
-By default this value is set to `infinity`. It is recommended
-to either set this value or ensure by any other mechanism
-that the handler will be closed after a certain period of
-inactivity.
-
-The `hibernate` option will hibernate the process until it
-starts receiving messages.
-
-The `shutdown` return value can be used to skip the receive
-loop entirely.
-
-: info(Info, Req, State) -> {ok, Req, State} | {loop, Req, State}
- | {loop, Req, State, hibernate}
-
-Types:
-
-* Info = any()
-* Req = cowboy_req:req()
-* State = any()
-
-Handle the Erlang message received.
-
-This function will be called every time an Erlang message
-has been received. The message can be any Erlang term.
-
-The `ok` return value can be used to stop the receive loop,
-typically because a response has been sent.
-
-The `hibernate` option will hibernate the process until
-it receives another message.
-
-: terminate(Reason, Req, State) -> ok
-
-Types:
-
-* Reason = {normal, shutdown} | {normal, timeout} | {error, closed} | {error, overflow} | {error, atom()}
-* Req = cowboy_req:req()
-* State = any()
-
-Perform any necessary cleanup of the state.
-
-This callback will typically unregister from any event manager
-or message queue it registered to in `init/3`.
-
-This callback should release any resource currently in use,
-clear any active timer and reset the process to its original
-state, as it might be reused for future requests sent on the
-same connection.
diff --git a/doc/src/manual/cowboy_rest.ezdoc b/doc/src/manual/cowboy_rest.ezdoc
index 9fe5c77..f128a22 100644
--- a/doc/src/manual/cowboy_rest.ezdoc
+++ b/doc/src/manual/cowboy_rest.ezdoc
@@ -3,12 +3,13 @@
The `cowboy_rest` module implements REST semantics on top of
the HTTP protocol.
-This module cannot be described as a behaviour due to most of
-the callbacks it defines being optional. It has the same
-semantics as a behaviour otherwise.
+This module is a sub protocol that defines many callbacks
+be implemented by handlers. The `init/2` and `terminate/3`
+callbacks are common to all handler types and are documented
+in the manual for the ^cowboy_handler module.
-The only mandatory callback is `init/3`, needed to perform
-the protocol upgrade.
+All other callbacks are optional, though some may become
+required depending on the return value of previous callbacks.
:: Types
@@ -43,46 +44,23 @@ The media-type is the content-type, excluding the charset.
This value is always defined after the call to
`content_types_provided/2`.
-:: Callbacks
-
-: init({TransportName, ProtocolName}, Req, Opts)
- -> {upgrade, protocol, cowboy_rest}
- | {upgrade, protocol, cowboy_rest, Req, Opts}
-
-Types:
-
-* TransportName = tcp | ssl | atom()
-* ProtocolName = http | atom()
-* Req = cowboy_req:req()
-* Opts = any()
-
-Upgrade the protocol to `cowboy_rest`.
-
-This is the only mandatory callback.
-
-: rest_init(Req, Opts) -> {ok, Req, State}
+:: Terminate reasons
-Types:
+The following values may be received as the terminate reason
+in the optional `terminate/3` callback.
-* Req = cowboy_req:req()
-* Opts = any()
-* State = any()
+: normal
-Initialize the state for this request.
+The connection was closed normally.
-: rest_terminate(Req, State) -> ok
+: {crash, Class, Reason}
-Types:
+A crash occurred in the handler. `Class` and `Reason` can be
+used to obtain more information about the crash. The function
+`erlang:get_stacktrace/0` can also be called to obtain the
+stacktrace of the process when the crash occurred.
-* Req = cowboy_req:req()
-* State = any()
-
-Perform any necessary cleanup of the state.
-
-This callback should release any resource currently in use,
-clear any active timer and reset the process to its original
-state, as it might be reused for future requests sent on the
-same connection.
+:: Callbacks
: Callback(Req, State) -> {Value, Req, State} | {halt, Req, State}
diff --git a/doc/src/manual/cowboy_websocket.ezdoc b/doc/src/manual/cowboy_websocket.ezdoc
index 59a6248..889ddd7 100644
--- a/doc/src/manual/cowboy_websocket.ezdoc
+++ b/doc/src/manual/cowboy_websocket.ezdoc
@@ -2,8 +2,25 @@
The `cowboy_websocket` module implements the Websocket protocol.
-The callbacks for websocket handlers are defined in the manual
-for the `cowboy_websocket_handler` behaviour.
+This module is a sub protocol that defines four callbacks to
+be implemented by handlers. The `init/2` and `terminate/3`
+callbacks are common to all handler types and are documented
+in the manual for the ^cowboy_handler module.
+
+The `websocket_handle/3` and `websocket_info/3` callbacks are
+specific to Websocket handlers and will be called as many times
+as necessary until the Websocket connection is closed.
+
+The `init/2` callback can be used to negotiate Websocket protocol
+extensions with the client. It is highly recommended to return a
+timeout value from this callback to ensure that the process is
+terminated when no data has been received during that timespan.
+The default timeout is `infinity`, which should only be used if
+you have alternate means of ending inactive connections.
+
+Cowboy will terminate the process right after closing the
+Websocket connection. This means that there is no real need to
+perform any cleanup in the optional `terminate/3` callback.
:: Types
@@ -31,6 +48,118 @@ Type: 7 | 8 | 13
The version of the Websocket protocol being used.
+:: Terminate reasons
+
+The following values may be received as the terminate reason
+in the optional `terminate/3` callback.
+
+: normal
+
+The connection was closed normally before establishing a Websocket
+connection. This typically happens if an `ok` tuple is returned
+from the `init/2` callback.
+
+: remote
+
+The remote endpoint closed the connection without giving any
+further details.
+
+: {remote, Code, Payload}
+
+The remote endpoint closed the connection with the given
+`Code` and `Payload` as the reason.
+
+: shutdown
+
+The handler requested to close the connection, either by returning
+a `shutdown` tuple or by sending a `close` frame.
+
+: timeout
+
+The connection has been closed due to inactivity. The timeout
+value can be configured from `init/2`.
+
+: {crash, Class, Reason}
+
+A crash occurred in the handler. `Class` and `Reason` can be
+used to obtain more information about the crash. The function
+`erlang:get_stacktrace/0` can also be called to obtain the
+stacktrace of the process when the crash occurred.
+
+: {error, badencoding}
+
+A text frame was sent by the client with invalid encoding. All
+text frames must be valid UTF-8.
+
+: {error, badframe}
+
+A protocol error has been detected.
+
+: {error, closed}
+
+The socket has been closed brutally without a close frame being
+received first.
+
+: {error, Reason}
+
+A socket error ocurred.
+
+:: Callbacks
+
+: websocket_handle(InFrame, Req, State)
+ -> {ok, Req, State}
+ | {ok, Req, State, hibernate}
+ | {reply, OutFrame | [OutFrame], Req, State}
+ | {reply, OutFrame | [OutFrame], Req, State, hibernate}
+ | {shutdown, Req, State}
+
+Types:
+
+* InFrame = {text | binary | ping | pong, binary()}
+* Req = cowboy_req:req()
+* State = any()
+* OutFrame = frame()
+
+Handle the data received from the Websocket connection.
+
+This function will be called every time data is received
+from the Websocket connection.
+
+The `shutdown` return value can be used to close the
+connection. A close reply will also result in the connection
+being closed.
+
+The `hibernate` option will hibernate the process until
+it receives new data from the Websocket connection or an
+Erlang message.
+
+: websocket_info(Info, Req, State)
+ -> {ok, Req, State}
+ | {ok, Req, State, hibernate}
+ | {reply, OutFrame | [OutFrame], Req, State}
+ | {reply, OutFrame | [OutFrame], Req, State, hibernate}
+ | {shutdown, Req, State}
+
+Types:
+
+* Info = any()
+* Req = cowboy_req:req()
+* State = any()
+* OutFrame = frame()
+
+Handle the Erlang message received.
+
+This function will be called every time an Erlang message
+has been received. The message can be any Erlang term.
+
+The `shutdown` return value can be used to close the
+connection. A close reply will also result in the connection
+being closed.
+
+The `hibernate` option will hibernate the process until
+it receives another message or new data from the Websocket
+connection.
+
:: Exports
None.
diff --git a/doc/src/manual/cowboy_websocket_handler.ezdoc b/doc/src/manual/cowboy_websocket_handler.ezdoc
deleted file mode 100644
index 0d31a54..0000000
--- a/doc/src/manual/cowboy_websocket_handler.ezdoc
+++ /dev/null
@@ -1,133 +0,0 @@
-::: cowboy_websocket_handler
-
-The `cowboy_websocket_handler` behaviour defines the interface used
-by Websocket handlers.
-
-The `init/3` and `websocket_init/3` callbacks will always be called,
-followed by zero or more calls to `websocket_handle/3` and
-`websocket_info/3`. The `websocket_terminate/3` will always
-be called last.
-
-:: Types
-
-None.
-
-:: Callbacks
-
-: init({TransportName, ProtocolName}, Req, Opts)
- -> {upgrade, protocol, cowboy_websocket}
- | {upgrade, protocol, cowboy_websocket, Req, Opts}
-
-Types:
-
-* TransportName = tcp | ssl | atom()
-* ProtocolName = http | atom()
-* Req = cowboy_req:req()
-* Opts = any()
-
-Upgrade the protocol to `cowboy_websocket`.
-
-: websocket_init(TransportName, Req, Opts)
- -> {ok, Req, State}
- | {ok, Req, State, hibernate}
- | {ok, Req, State, Timeout}
- | {ok, Req, State, Timeout, hibernate}
- | {shutdown, Req}
-
-Types:
-
-* TransportName = tcp | ssl | atom()
-* Req = cowboy_req:req()
-* Opts = any()
-* State = any()
-* Timeout = timeout()
-
-Initialize the state for this session.
-
-This function is called before the upgrade to Websocket occurs.
-It can be used to negotiate Websocket protocol extensions
-with the client. It will typically be used to register this process
-to an event manager or a message queue in order to receive
-the messages the handler wants to process.
-
-The connection will stay up for a duration of up to `Timeout`
-milliseconds after it last received data from the socket,
-at which point it will stop and close the connection.
-By default this value is set to `infinity`. It is recommended
-to either set this value or ensure by any other mechanism
-that the handler will be closed after a certain period of
-inactivity.
-
-The `hibernate` option will hibernate the process until it
-starts receiving either data from the Websocket connection
-or Erlang messages.
-
-The `shutdown` return value can be used to close the connection
-before upgrading to Websocket.
-
-: websocket_handle(InFrame, Req, State)
- -> {ok, Req, State}
- | {ok, Req, State, hibernate}
- | {reply, OutFrame | [OutFrame], Req, State}
- | {reply, OutFrame | [OutFrame], Req, State, hibernate}
- | {shutdown, Req, State}
-
-Types:
-
-* InFrame = {text | binary | ping | pong, binary()}
-* Req = cowboy_req:req()
-* State = any()
-* OutFrame = cowboy_websocket:frame()
-
-Handle the data received from the Websocket connection.
-
-This function will be called every time data is received
-from the Websocket connection.
-
-The `shutdown` return value can be used to close the
-connection. A close reply will also result in the connection
-being closed.
-
-The `hibernate` option will hibernate the process until
-it receives new data from the Websocket connection or an
-Erlang message.
-
-: websocket_info(Info, Req, State)
- -> {ok, Req, State}
- | {ok, Req, State, hibernate}
- | {reply, OutFrame | [OutFrame], Req, State}
- | {reply, OutFrame | [OutFrame], Req, State, hibernate}
- | {shutdown, Req, State}
-
-Types:
-
-* Info = any()
-* Req = cowboy_req:req()
-* State = any()
-* OutFrame = cowboy_websocket:frame()
-
-Handle the Erlang message received.
-
-This function will be called every time an Erlang message
-has been received. The message can be any Erlang term.
-
-The `shutdown` return value can be used to close the
-connection. A close reply will also result in the connection
-being closed.
-
-The `hibernate` option will hibernate the process until
-it receives another message or new data from the Websocket
-connection.
-
-: websocket_terminate(Reason, Req, State) -> ok
-
-Types:
-
-* Reason = {normal, shutdown | timeout} | {remote, closed} | {remote, cowboy_websocket:close_code(), binary()} | {error, badencoding | badframe | closed | atom()}
-* Req = cowboy_req:req()
-* State = any()
-
-Perform any necessary cleanup of the state.
-
-The connection will be closed and the process stopped right
-after this call.
diff --git a/doc/src/manual/index.ezdoc b/doc/src/manual/index.ezdoc
index e364e90..133a341 100644
--- a/doc/src/manual/index.ezdoc
+++ b/doc/src/manual/index.ezdoc
@@ -5,8 +5,7 @@ The function reference documents the public interface of Cowboy.
* ^"The Cowboy Application^cowboy_app
* ^cowboy
* ^cowboy_handler
-* ^cowboy_http_handler
-* ^cowboy_loop_handler
+* ^cowboy_loop
* ^cowboy_middleware
* ^cowboy_protocol
* ^cowboy_req
@@ -16,5 +15,4 @@ The function reference documents the public interface of Cowboy.
* ^cowboy_static
* ^cowboy_sub_protocol
* ^cowboy_websocket
-* ^cowboy_websocket_handler
* ^"HTTP status codes^http_status_codes