resp.asciidoc 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368
  1. [[resp]]
  2. == Sending a response
  3. The response must be sent using the Req object.
  4. Cowboy provides two different ways of sending responses:
  5. either directly or by streaming the body. Response headers
  6. and body may be set in advance. The response is sent as
  7. soon as one of the reply or stream reply function is
  8. called.
  9. Cowboy also provides a simplified interface for sending
  10. files. It can also send only specific parts of a file.
  11. While only one response is allowed for every request,
  12. HTTP/2 introduced a mechanism that allows the server
  13. to push additional resources related to the response.
  14. This chapter also describes how this feature works in
  15. Cowboy.
  16. === Reply
  17. Cowboy provides three functions for sending the entire reply,
  18. depending on whether you need to set headers and body. In all
  19. cases, Cowboy will add any headers required by the protocol
  20. (for example the date header will always be sent).
  21. When you need to set only the status code,
  22. use `cowboy_req:reply/2`:
  23. [source,erlang]
  24. Req = cowboy_req:reply(200, Req0).
  25. When you need to set response headers at the same time,
  26. use `cowboy_req:reply/3`:
  27. [source,erlang]
  28. ----
  29. Req = cowboy_req:reply(303, #{
  30. <<"location">> => <<"https://ninenines.eu">>
  31. }, Req0).
  32. ----
  33. Note that the header name must always be a lowercase
  34. binary.
  35. When you also need to set the response body,
  36. use `cowboy_req:reply/4`:
  37. [source,erlang]
  38. ----
  39. Req = cowboy_req:reply(200, #{
  40. <<"content-type">> => <<"text/plain">>
  41. }, "Hello world!", Req0).
  42. ----
  43. You should always set the content-type header when the
  44. response has a body. There is however no need to set
  45. the content-length header; Cowboy does it automatically.
  46. The response body and the header values must be either
  47. a binary or an iolist. An iolist is a list containing
  48. binaries, characters, strings or other iolists. This
  49. allows you to build a response from different parts
  50. without having to do any concatenation:
  51. [source,erlang]
  52. ----
  53. Title = "Hello world!",
  54. Body = <<"Hats off!">>,
  55. Req = cowboy_req:reply(200, #{
  56. <<"content-type">> => <<"text/html">>
  57. }, ["<html><head><title>", Title, "</title></head>",
  58. "<body><p>", Body, "</p></body></html>"], Req0).
  59. ----
  60. This method of building responses is more efficient than
  61. concatenating. Behind the scenes, each element of the list
  62. is simply a pointer, and those pointers are used directly
  63. when writing to the socket.
  64. === Stream reply
  65. Cowboy provides two functions for initiating a response,
  66. and an additional function for streaming the response body.
  67. Cowboy will add any required headers to the response.
  68. // @todo For HTTP/1.1 Cowboy should probably not use chunked transfer-encoding if the content-length is set.
  69. When you need to set only the status code,
  70. use `cowboy_req:stream_reply/2`:
  71. [source,erlang]
  72. ----
  73. Req = cowboy_req:stream_reply(200, Req0),
  74. cowboy_req:stream_body("Hello...", nofin, Req),
  75. cowboy_req:stream_body("chunked...", nofin, Req),
  76. cowboy_req:stream_body("world!!", fin, Req).
  77. ----
  78. The second argument to `cowboy_req:stream_body/3` indicates
  79. whether this data terminates the body. Use `fin` for the
  80. final flag, and `nofin` otherwise.
  81. This snippet does not set a content-type header. This is
  82. not recommended. All responses with a body should have
  83. a content-type. The header can be set beforehand, or
  84. using the `cowboy_req:stream_reply/3`:
  85. [source,erlang]
  86. ----
  87. Req = cowboy_req:stream_reply(200, #{
  88. <<"content-type">> => <<"text/html">>
  89. }, Req0),
  90. cowboy_req:stream_body("<html><head>Hello world!</head>", nofin, Req),
  91. cowboy_req:stream_body("<body><p>Hats off!</p></body></html>", fin, Req).
  92. ----
  93. HTTP provides a few different ways to stream response bodies.
  94. Cowboy will select the most appropriate one based on the HTTP
  95. version and the request and response headers.
  96. While not required by any means, it is recommended that you
  97. set the content-length header in the response if you know it
  98. in advance. This will ensure that the best response method
  99. is selected and help clients understand when the response
  100. is fully received.
  101. Cowboy also provides a function to send response trailers.
  102. Response trailers are semantically equivalent to the headers
  103. you send in the response, only they are sent at the end.
  104. This is especially useful to attach information to the
  105. response that could not be generated until the response
  106. body was fully generated.
  107. Trailer fields must be listed in the trailer header. Any
  108. field not listed might be dropped by the client or an intermediary.
  109. [source,erlang]
  110. ----
  111. Req = cowboy_req:stream_reply(200, #{
  112. <<"content-type">> => <<"text/html">>,
  113. <<"trailer">> => <<"expires, content-md5">>
  114. }, Req0),
  115. cowboy_req:stream_body("<html><head>Hello world!</head>", nofin, Req),
  116. cowboy_req:stream_body("<body><p>Hats off!</p></body></html>", nofin, Req),
  117. cowboy_req:stream_trailers(#{
  118. <<"expires">> => <<"Sun, 10 Dec 2017 19:13:47 GMT">>,
  119. <<"content-md5">> => <<"c6081d20ff41a42ce17048ed1c0345e2">>
  120. }, Req).
  121. ----
  122. The stream ends with trailers. It is no longer possible to
  123. send data after sending trailers. You cannot send trailers
  124. after setting the `fin` flag when streaming the body.
  125. === Preset response headers
  126. Cowboy provides functions to set response headers without
  127. immediately sending them. They are stored in the Req object
  128. and sent as part of the response when a reply function is
  129. called.
  130. To set response headers:
  131. [source,erlang]
  132. Req = cowboy_req:set_resp_header(<<"allow">>, "GET", Req0).
  133. Header names must be a lowercase binary.
  134. Do not use this function for setting cookies. Refer to
  135. the xref:cookies[Cookies] chapter for more information.
  136. To check if a response header has already been set:
  137. [source,erlang]
  138. cowboy_req:has_resp_header(<<"allow">>, Req).
  139. It returns `true` if the header was set, `false` otherwise.
  140. To delete a response header that was set previously:
  141. [source,erlang]
  142. Req = cowboy_req:delete_resp_header(<<"allow">>, Req0).
  143. === Overriding headers
  144. As Cowboy provides different ways of setting response
  145. headers and body, clashes may occur, so it's important
  146. to understand what happens when a header is set twice.
  147. Headers come from five different origins:
  148. * Protocol-specific headers (for example HTTP/1.1's connection header)
  149. * Other required headers (for example the date header)
  150. * Preset headers
  151. * Headers given to the reply function
  152. * Set-cookie headers
  153. Cowboy does not allow overriding protocol-specific headers.
  154. Set-cookie headers will always be appended at the end of
  155. the list of headers before sending the response.
  156. Headers given to the reply function will always override
  157. preset headers and required headers. If a header is found
  158. in two or three of these, then the one in the reply function
  159. is picked and the others are dropped.
  160. Similarly, preset headers will always override required
  161. headers.
  162. To illustrate, look at the following snippet. Cowboy by
  163. default sends the server header with the value "Cowboy".
  164. We can override it:
  165. [source,erlang]
  166. ----
  167. Req = cowboy_req:reply(200, #{
  168. <<"server">> => <<"yaws">>
  169. }, Req0).
  170. ----
  171. === Preset response body
  172. Cowboy provides functions to set the response body without
  173. immediately sending it. It is stored in the Req object and
  174. sent when the reply function is called.
  175. To set the response body:
  176. [source,erlang]
  177. Req = cowboy_req:set_resp_body("Hello world!", Req0).
  178. // @todo Yeah we probably should add that function that
  179. // also sets the content-type at the same time...
  180. To check if a response body has already been set:
  181. [source,erlang]
  182. cowboy_req:has_resp_body(Req).
  183. It returns `true` if the body was set and is non-empty,
  184. `false` otherwise.
  185. // @todo We probably should also have a function that
  186. // properly removes the response body, including any
  187. // content-* headers.
  188. The preset response body is only sent if the reply function
  189. used is `cowboy_req:reply/2` or `cowboy_req:reply/3`.
  190. === Sending files
  191. Cowboy provides a shortcut for sending files. When
  192. using `cowboy_req:reply/4`, or when presetting the
  193. response header, you can give a `sendfile` tuple to
  194. Cowboy:
  195. [source,erlang]
  196. {sendfile, Offset, Length, Filename}
  197. Depending on the values for `Offset` or `Length`, the
  198. entire file may be sent, or just a part of it.
  199. The length is required even for sending the entire file.
  200. Cowboy sends it in the content-length header.
  201. To send a file while replying:
  202. [source,erlang]
  203. ----
  204. Req = cowboy_req:reply(200, #{
  205. <<"content-type">> => "image/png"
  206. }, {sendfile, 0, 12345, "path/to/logo.png"}, Req0).
  207. ----
  208. // @todo An example of presetting a file would be useful,
  209. // but let's wait for the function that can set the
  210. // content-type at the same time.
  211. // @todo What about streaming many files? For example
  212. // it should be possible to build a tar file on the fly
  213. // while still using sendfile. Another example could be
  214. // proper support for multipart byte ranges. Yet another
  215. // example would be automatic concatenation of CSS or JS
  216. // files.
  217. === Informational responses
  218. Cowboy allows you to send informational responses.
  219. Informational responses are responses that have a status
  220. code between 100 and 199. Any number can be sent before
  221. the proper response. Sending an informational response
  222. does not change the behavior of the proper response, and
  223. clients are expected to ignore any informational response
  224. they do not understand.
  225. The following snippet sends a 103 informational response
  226. with some headers that are expected to be in the final
  227. response.
  228. [source,erlang]
  229. ----
  230. Req = cowboy_req:inform(103, #{
  231. <<"link">> => <<"</style.css>; rel=preload; as=style, </script.js>; rel=preload; as=script">>
  232. }, Req0).
  233. ----
  234. === Push
  235. The HTTP/2 protocol introduced the ability to push resources
  236. related to the one sent in the response. Cowboy provides two
  237. functions for that purpose: `cowboy_req:push/3,4`.
  238. Push is only available for HTTP/2. Cowboy will automatically
  239. ignore push requests if the protocol doesn't support it.
  240. The push function must be called before any of the reply
  241. functions. Doing otherwise will result in a crash.
  242. To push a resource, you need to provide the same information
  243. as a client performing a request would. This includes the
  244. HTTP method, the URI and any necessary request headers.
  245. Cowboy by default only requires you to give the path to
  246. the resource and the request headers. The rest of the URI
  247. is taken from the current request (excluding the query
  248. string, set to empty) and the method is GET by default.
  249. The following snippet pushes a CSS file that is linked to
  250. in the response:
  251. [source,erlang]
  252. ----
  253. cowboy_req:push("/static/style.css", #{
  254. <<"accept">> => <<"text/css">>
  255. }, Req0),
  256. Req = cowboy_req:reply(200, #{
  257. <<"content-type">> => <<"text/html">>
  258. }, ["<html><head><title>My web page</title>",
  259. "<link rel='stylesheet' type='text/css' href='/static/style.css'>",
  260. "<body><p>Welcome to Erlang!</p></body></html>"], Req0).
  261. ----
  262. To override the method, scheme, host, port or query string,
  263. simply pass in a fourth argument. The following snippet
  264. uses a different host name:
  265. [source,erlang]
  266. ----
  267. cowboy_req:push("/static/style.css", #{
  268. <<"accept">> => <<"text/css">>
  269. }, #{host => <<"cdn.example.org">>}, Req),
  270. ----
  271. Pushed resources don't have to be files. As long as the push
  272. request is cacheable, safe and does not include a body, the
  273. resource can be pushed.
  274. Under the hood, Cowboy handles pushed requests the same as
  275. normal requests: a different process is created which will
  276. ultimately send a response to the client.