mirror of
https://github.com/ninenines/cowboy.git
synced 2025-07-14 20:30:23 +00:00
Update cowboy_loop manual
This commit is contained in:
parent
b13c07932d
commit
5da7d1ef05
3 changed files with 90 additions and 71 deletions
|
@ -28,10 +28,10 @@ init(Req, State) -> {ok, Req, State}
|
|||
|
||||
terminate(Reason, Req, State) -> ok %% optional
|
||||
|
||||
Req :: cowboy_req:req()
|
||||
State :: any()
|
||||
Reason :: normal
|
||||
| {crash, error | exit | throw, any()}
|
||||
Req :: cowboy_req:req()
|
||||
State :: any()
|
||||
Reason :: normal
|
||||
| {crash, error | exit | throw, any()}
|
||||
----
|
||||
|
||||
These two callbacks are common to all handlers.
|
||||
|
|
|
@ -2,85 +2,103 @@
|
|||
|
||||
== Name
|
||||
|
||||
cowboy_loop - loop handlers
|
||||
cowboy_loop - Loop handlers
|
||||
|
||||
== Description
|
||||
|
||||
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.
|
||||
The module `cowboy_loop` defines a callback interface for
|
||||
long running HTTP connections.
|
||||
|
||||
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 link:cowboy_handler.asciidoc[cowboy_handler] module.
|
||||
You should switch to this behavior for long polling,
|
||||
server-sent events and similar long-running requests.
|
||||
|
||||
The `info/3` callback is specific to loop handlers and will be
|
||||
called as many times as necessary until a reply is sent.
|
||||
There are generally two usage patterns:
|
||||
|
||||
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.
|
||||
* Loop until receiving a specific message, then send
|
||||
a response and stop execution (for example long polling);
|
||||
|
||||
== 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.
|
||||
|
||||
stop::
|
||||
The handler requested to close the connection by returning
|
||||
a `stop` 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.
|
||||
* Or initiate a response in `init/2` and stream the
|
||||
body in `info/3` as necessary (for example server-sent events).
|
||||
|
||||
== Callbacks
|
||||
|
||||
=== info(Info, Req, State) -> {ok, Req, State} | {ok, Req, State, hibernate} | {stop, Req, State}
|
||||
Loop handlers implement the following interface:
|
||||
|
||||
Info = any():: Message received by the process.
|
||||
Req = cowboy_req:req():: The Req object.
|
||||
State = any():: Handler state.
|
||||
[source,erlang]
|
||||
----
|
||||
init(Req, State)
|
||||
-> {cowboy_loop, Req, State}
|
||||
| {cowboy_loop, Req, State, hibernate}
|
||||
| {cowboy_loop, Req, State, timeout()}
|
||||
| {cowboy_loop, Req, State, timeout(), hibernate}
|
||||
|
||||
Handle the Erlang message received.
|
||||
info(Info, Req, State)
|
||||
-> {ok, Req, State}
|
||||
| {ok, Req, State, hibernate}
|
||||
| {stop, Req, State}
|
||||
|
||||
This function will be called every time an Erlang message
|
||||
has been received. The message can be any Erlang term.
|
||||
terminate(Reason, Req, State) -> ok %% optional
|
||||
|
||||
The `stop` return value can be used to stop the receive loop,
|
||||
typically because a response has been sent.
|
||||
Req :: cowboy_req:req()
|
||||
State :: any()
|
||||
Info :: any()
|
||||
Reason :: stop | timeout
|
||||
| {crash, error | exit | throw, any()}
|
||||
----
|
||||
|
||||
The `hibernate` option will hibernate the process until
|
||||
it receives another message.
|
||||
The `init/2` callback is common to all handlers. To switch
|
||||
to the loop behavior, it must return `cowboy_loop` as the
|
||||
first element of the tuple.
|
||||
|
||||
The `info/3` callback will be called for every Erlang message
|
||||
received. It may choose to continue the receive loop or stop
|
||||
it.
|
||||
|
||||
The optional `terminate/3` callback will ultimately be called
|
||||
with the reason for the termination of the handler.
|
||||
Cowboy will terminate the process right after this. There
|
||||
is no need to perform any cleanup in this callback.
|
||||
|
||||
The following terminate reasons are defined for loop handlers:
|
||||
|
||||
stop::
|
||||
The handler requested to close the connection by returning
|
||||
a `stop` 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.
|
||||
|
||||
== Changelog
|
||||
|
||||
* *2.0*: Cowboy temporarily no longer checks the socket for data with HTTP/1.1.
|
||||
* *1.0*: Behavior introduced.
|
||||
|
||||
== See also
|
||||
|
||||
link:man:cowboy(7)[cowboy(7)],
|
||||
link:man:cowboy_handler(3)[cowboy_handler(3)]
|
||||
|
|
|
@ -161,5 +161,6 @@ timeout::
|
|||
== See also
|
||||
|
||||
link:man:cowboy(7)[cowboy(7)],
|
||||
link:man:cowboy_handler(3)[cowboy_handler(3)],
|
||||
link:man:cowboy_http(3)[cowboy_http(3)],
|
||||
link:man:cowboy_http2(3)[cowboy_http2(3)]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue