1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
= cowboy_loop(3)
== Name
cowboy_loop - Loop handlers
== Description
The module `cowboy_loop` defines a callback interface for
long running HTTP connections.
You should switch to this behavior for long polling,
server-sent events and similar long-running requests.
There are generally two usage patterns:
* Loop until receiving a specific message, then send
a response and stop execution (for example long polling);
* Or initiate a response in `init/2` and stream the
body in `info/3` as necessary (for example server-sent events).
== Callbacks
Loop handlers implement the following interface:
[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}
info(Info, Req, State)
-> {ok, Req, State}
| {ok, Req, State, hibernate}
| {stop, Req, State}
terminate(Reason, Req, State) -> ok %% optional
Req :: cowboy_req:req()
State :: any()
Info :: any()
Reason :: stop | timeout
| {crash, error | exit | throw, any()}
----
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)]
|
