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
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
|
[[resp]]
== Sending a response
The response must be sent using the Req object.
Cowboy provides two different ways of sending responses:
either directly or by streaming the body. Response headers
and body may be set in advance. The response is sent as
soon as one of the reply or stream reply function is
called.
Cowboy also provides a simplified interface for sending
files. It can also send only specific parts of a file.
While only one response is allowed for every request,
HTTP/2 introduced a mechanism that allows the server
to push additional resources related to the response.
This chapter also describes how this feature works in
Cowboy.
=== Reply
Cowboy provides three functions for sending the entire reply,
depending on whether you need to set headers and body. In all
cases, Cowboy will add any headers required by the protocol
(for example the date header will always be sent).
When you need to set only the status code,
use `cowboy_req:reply/2`:
[source,erlang]
Req = cowboy_req:reply(200, Req0).
When you need to set response headers at the same time,
use `cowboy_req:reply/3`:
[source,erlang]
----
Req = cowboy_req:reply(303, #{
<<"location">> => <<"https://ninenines.eu">>
}, Req0).
----
Note that the header name must always be a lowercase
binary.
When you also need to set the response body,
use `cowboy_req:reply/4`:
[source,erlang]
----
Req = cowboy_req:reply(200, #{
<<"content-type">> => <<"text/plain">>
}, "Hello world!", Req0).
----
You should always set the content-type header when the
response has a body. There is however no need to set
the content-length header; Cowboy does it automatically.
The response body and the header values must be either
a binary or an iolist. An iolist is a list containing
binaries, characters, strings or other iolists. This
allows you to build a response from different parts
without having to do any concatenation:
[source,erlang]
----
Title = "Hello world!",
Body = <<"Hats off!">>,
Req = cowboy_req:reply(200, #{
<<"content-type">> => <<"text/html">>
}, ["<html><head><title>", Title, "</title></head>",
"<body><p>", Body, "</p></body></html>"], Req0).
----
This method of building responses is more efficient than
concatenating. Behind the scenes, each element of the list
is simply a pointer, and those pointers are used directly
when writing to the socket.
=== Stream reply
Cowboy provides two functions for initiating a response,
and an additional function for streaming the response body.
Cowboy will add any required headers to the response.
// @todo For HTTP/1.1 Cowboy should probably not use chunked transfer-encoding if the content-length is set.
When you need to set only the status code,
use `cowboy_req:stream_reply/2`:
[source,erlang]
----
Req = cowboy_req:stream_reply(200, Req0),
cowboy_req:stream_body("Hello...", nofin, Req),
cowboy_req:stream_body("chunked...", nofin, Req),
cowboy_req:stream_body("world!!", fin, Req).
----
The second argument to `cowboy_req:stream_body/3` indicates
whether this data terminates the body. Use `fin` for the
final flag, and `nofin` otherwise.
This snippet does not set a content-type header. This is
not recommended. All responses with a body should have
a content-type. The header can be set beforehand, or
using the `cowboy_req:stream_reply/3`:
[source,erlang]
----
Req = cowboy_req:stream_reply(200, #{
<<"content-type">> => <<"text/html">>
}, Req0),
cowboy_req:stream_body("<html><head>Hello world!</head>", nofin, Req),
cowboy_req:stream_body("<body><p>Hats off!</p></body></html>", fin, Req).
----
HTTP provides a few different ways to stream response bodies.
Cowboy will select the most appropriate one based on the HTTP
version and the request and response headers.
While not required by any means, it is recommended that you
set the content-length header in the response if you know it
in advance. This will ensure that the best response method
is selected and help clients understand when the response
is fully received.
Cowboy also provides a function to send response trailers.
Response trailers are semantically equivalent to the headers
you send in the response, only they are sent at the end.
This is especially useful to attach information to the
response that could not be generated until the response
body was fully generated.
Trailer fields must be listed in the trailer header. Any
field not listed might be dropped by the client or an intermediary.
[source,erlang]
----
Req = cowboy_req:stream_reply(200, #{
<<"content-type">> => <<"text/html">>,
<<"trailer">> => <<"expires, content-md5">>
}, Req0),
cowboy_req:stream_body("<html><head>Hello world!</head>", nofin, Req),
cowboy_req:stream_body("<body><p>Hats off!</p></body></html>", nofin, Req),
cowboy_req:stream_trailers(#{
<<"expires">> => <<"Sun, 10 Dec 2017 19:13:47 GMT">>,
<<"content-md5">> => <<"c6081d20ff41a42ce17048ed1c0345e2">>
}, Req).
----
The stream ends with trailers. It is no longer possible to
send data after sending trailers. You cannot send trailers
after setting the `fin` flag when streaming the body.
=== Preset response headers
Cowboy provides functions to set response headers without
immediately sending them. They are stored in the Req object
and sent as part of the response when a reply function is
called.
To set response headers:
[source,erlang]
Req = cowboy_req:set_resp_header(<<"allow">>, "GET", Req0).
Header names must be a lowercase binary.
Do not use this function for setting cookies. Refer to
the xref:cookies[Cookies] chapter for more information.
To check if a response header has already been set:
[source,erlang]
cowboy_req:has_resp_header(<<"allow">>, Req).
It returns `true` if the header was set, `false` otherwise.
To delete a response header that was set previously:
[source,erlang]
Req = cowboy_req:delete_resp_header(<<"allow">>, Req0).
=== Overriding headers
As Cowboy provides different ways of setting response
headers and body, clashes may occur, so it's important
to understand what happens when a header is set twice.
Headers come from five different origins:
* Protocol-specific headers (for example HTTP/1.1's connection header)
* Other required headers (for example the date header)
* Preset headers
* Headers given to the reply function
* Set-cookie headers
Cowboy does not allow overriding protocol-specific headers.
Set-cookie headers will always be appended at the end of
the list of headers before sending the response.
Headers given to the reply function will always override
preset headers and required headers. If a header is found
in two or three of these, then the one in the reply function
is picked and the others are dropped.
Similarly, preset headers will always override required
headers.
To illustrate, look at the following snippet. Cowboy by
default sends the server header with the value "Cowboy".
We can override it:
[source,erlang]
----
Req = cowboy_req:reply(200, #{
<<"server">> => <<"yaws">>
}, Req0).
----
=== Preset response body
Cowboy provides functions to set the response body without
immediately sending it. It is stored in the Req object and
sent when the reply function is called.
To set the response body:
[source,erlang]
Req = cowboy_req:set_resp_body("Hello world!", Req0).
// @todo Yeah we probably should add that function that
// also sets the content-type at the same time...
To check if a response body has already been set:
[source,erlang]
cowboy_req:has_resp_body(Req).
It returns `true` if the body was set and is non-empty,
`false` otherwise.
// @todo We probably should also have a function that
// properly removes the response body, including any
// content-* headers.
The preset response body is only sent if the reply function
used is `cowboy_req:reply/2` or `cowboy_req:reply/3`.
=== Sending files
Cowboy provides a shortcut for sending files. When
using `cowboy_req:reply/4`, or when presetting the
response header, you can give a `sendfile` tuple to
Cowboy:
[source,erlang]
{sendfile, Offset, Length, Filename}
Depending on the values for `Offset` or `Length`, the
entire file may be sent, or just a part of it.
The length is required even for sending the entire file.
Cowboy sends it in the content-length header.
To send a file while replying:
[source,erlang]
----
Req = cowboy_req:reply(200, #{
<<"content-type">> => "image/png"
}, {sendfile, 0, 12345, "path/to/logo.png"}, Req0).
----
// @todo An example of presetting a file would be useful,
// but let's wait for the function that can set the
// content-type at the same time.
// @todo What about streaming many files? For example
// it should be possible to build a tar file on the fly
// while still using sendfile. Another example could be
// proper support for multipart byte ranges. Yet another
// example would be automatic concatenation of CSS or JS
// files.
=== Informational responses
Cowboy allows you to send informational responses.
Informational responses are responses that have a status
code between 100 and 199. Any number can be sent before
the proper response. Sending an informational response
does not change the behavior of the proper response, and
clients are expected to ignore any informational response
they do not understand.
The following snippet sends a 103 informational response
with some headers that are expected to be in the final
response.
[source,erlang]
----
Req = cowboy_req:inform(103, #{
<<"link">> => <<"</style.css>; rel=preload; as=style, </script.js>; rel=preload; as=script">>
}, Req0).
----
=== Push
The HTTP/2 protocol introduced the ability to push resources
related to the one sent in the response. Cowboy provides two
functions for that purpose: `cowboy_req:push/3,4`.
Push is only available for HTTP/2. Cowboy will automatically
ignore push requests if the protocol doesn't support it.
The push function must be called before any of the reply
functions. Doing otherwise will result in a crash.
To push a resource, you need to provide the same information
as a client performing a request would. This includes the
HTTP method, the URI and any necessary request headers.
Cowboy by default only requires you to give the path to
the resource and the request headers. The rest of the URI
is taken from the current request (excluding the query
string, set to empty) and the method is GET by default.
The following snippet pushes a CSS file that is linked to
in the response:
[source,erlang]
----
cowboy_req:push("/static/style.css", #{
<<"accept">> => <<"text/css">>
}, Req0),
Req = cowboy_req:reply(200, #{
<<"content-type">> => <<"text/html">>
}, ["<html><head><title>My web page</title>",
"<link rel='stylesheet' type='text/css' href='/static/style.css'>",
"<body><p>Welcome to Erlang!</p></body></html>"], Req0).
----
To override the method, scheme, host, port or query string,
simply pass in a fourth argument. The following snippet
uses a different host name:
[source,erlang]
----
cowboy_req:push("/static/style.css", #{
<<"accept">> => <<"text/css">>
}, #{host => <<"cdn.example.org">>}, Req),
----
Pushed resources don't have to be files. As long as the push
request is cacheable, safe and does not include a body, the
resource can be pushed.
Under the hood, Cowboy handles pushed requests the same as
normal requests: a different process is created which will
ultimately send a response to the client.
|
