handlers.asciidoc 2.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105
  1. [[handlers]]
  2. == Handlers
  3. Handlers are Erlang modules that handle HTTP requests.
  4. === Plain HTTP handlers
  5. The most basic handler in Cowboy implements the mandatory
  6. `init/2` callback, manipulates the request, optionally
  7. sends a response and then returns.
  8. This callback receives the xref:req[Req object] and the options
  9. defined during the xref:routing[router configuration].
  10. A handler that does nothing would look like this:
  11. [source,erlang]
  12. ----
  13. init(Req, _Opts) ->
  14. {ok, Req, #state{}}.
  15. ----
  16. Despite sending no reply, a `204 No Content` reply will be
  17. sent to the client, as Cowboy makes sure that a reply is
  18. sent for every request.
  19. We need to use the Req object for sending a reply.
  20. [source,erlang]
  21. ----
  22. init(Req, _Opts) ->
  23. Req2 = cowboy_req:reply(200, [
  24. {<<"content-type">>, <<"text/plain">>}
  25. ], <<"Hello World!">>, Req),
  26. {ok, Req2, #state{}}.
  27. ----
  28. As you can see we return a 3-tuple. `ok` means that the
  29. handler ran successfully. The Req object is returned as
  30. it may have been modified as is the case here: replying
  31. returns a modified Req object that you need to return
  32. back to Cowboy for proper operations.
  33. The last value of the tuple is a state that will be used
  34. in every subsequent callbacks to this handler. Plain HTTP
  35. handlers only have one additional callback, the optional
  36. `terminate/3`.
  37. === Other handlers
  38. The `init/2` callback can also be used to inform Cowboy
  39. that this is a different kind of handler and that Cowboy
  40. should switch to it. To do this you simply need to return
  41. the module name of the handler type you want to switch to.
  42. Cowboy comes with three handler types you can switch to:
  43. xref:rest_handlers[cowboy_rest], xref:ws_handlers[cowboy_websocket]
  44. and xref:loop_handlers[cowboy_loop]. In addition to those you
  45. can define your own handler types.
  46. Switching is simple. Instead of returning `ok`, you simply
  47. return the name of the handler type you want to use. The
  48. following snippet switches to a Websocket handler:
  49. [source,erlang]
  50. ----
  51. init(Req, _Opts) ->
  52. {cowboy_websocket, Req, #state{}}.
  53. ----
  54. You can also switch to your own custom handler type:
  55. [source,erlang]
  56. ----
  57. init(Req, _Opts) ->
  58. {my_handler_type, Req, #state{}}.
  59. ----
  60. How to implement a custom handler type is described in the
  61. xref:sub_protocols[Sub protocols] chapter.
  62. === Cleaning up
  63. All handlers coming with Cowboy allow the use of the optional
  64. `terminate/3` callback.
  65. [source,erlang]
  66. ----
  67. terminate(_Reason, Req, State) ->
  68. ok.
  69. ----
  70. This callback is strictly reserved for any required cleanup.
  71. You cannot send a response from this function. There is no
  72. other return value.
  73. If you used the process dictionary, timers, monitors or may
  74. be receiving messages, then you can use this function to clean
  75. them up, as Cowboy might reuse the process for the next
  76. keep-alive request.
  77. Note that while this function may be called in a Websocket
  78. handler, it is generally not useful to do any clean up as
  79. the process terminates immediately after calling this callback
  80. when using Websocket.