From 28b5bf18a3be3b933a76f8b8912c8ee55238cdc6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Thu, 9 Nov 2017 12:46:23 +0000 Subject: Update documentation for Cowboy 2.1 --- docs/en/cowboy/2.0/guide/constraints/index.html | 4 +- docs/en/cowboy/2.0/guide/cookies/index.html | 4 +- docs/en/cowboy/2.0/guide/erlang_web/index.html | 4 +- docs/en/cowboy/2.0/guide/flow_diagram/index.html | 4 +- .../en/cowboy/2.0/guide/getting_started/index.html | 4 +- docs/en/cowboy/2.0/guide/handlers/index.html | 4 +- docs/en/cowboy/2.0/guide/index.html | 4 +- docs/en/cowboy/2.0/guide/introduction/index.html | 4 +- docs/en/cowboy/2.0/guide/listeners/index.html | 4 +- docs/en/cowboy/2.0/guide/loop_handlers/index.html | 4 +- docs/en/cowboy/2.0/guide/middlewares/index.html | 4 +- .../cowboy/2.0/guide/migrating_from_1.0/index.html | 4 +- docs/en/cowboy/2.0/guide/modern_web/index.html | 4 +- docs/en/cowboy/2.0/guide/multipart/index.html | 4 +- docs/en/cowboy/2.0/guide/req/index.html | 4 +- docs/en/cowboy/2.0/guide/req_body/index.html | 4 +- docs/en/cowboy/2.0/guide/resource_design.asciidoc | 4 +- .../en/cowboy/2.0/guide/resource_design/index.html | 8 +- docs/en/cowboy/2.0/guide/resp/index.html | 4 +- .../en/cowboy/2.0/guide/rest_flowcharts/index.html | 4 +- docs/en/cowboy/2.0/guide/rest_handlers/index.html | 4 +- .../en/cowboy/2.0/guide/rest_principles/index.html | 4 +- docs/en/cowboy/2.0/guide/routing/index.html | 4 +- docs/en/cowboy/2.0/guide/specs/index.html | 4 +- docs/en/cowboy/2.0/guide/static_files/index.html | 4 +- docs/en/cowboy/2.0/guide/streams/index.html | 4 +- docs/en/cowboy/2.0/guide/ws_handlers.asciidoc | 15 +- docs/en/cowboy/2.0/guide/ws_handlers/index.html | 19 +- docs/en/cowboy/2.0/guide/ws_protocol/index.html | 4 +- .../en/cowboy/2.0/manual/cowboy.set_env/index.html | 4 +- .../2.0/manual/cowboy.start_clear/index.html | 4 +- .../cowboy/2.0/manual/cowboy.start_tls/index.html | 4 +- .../2.0/manual/cowboy.stop_listener/index.html | 4 +- docs/en/cowboy/2.0/manual/cowboy/index.html | 4 +- docs/en/cowboy/2.0/manual/cowboy_app/index.html | 4 +- .../2.0/manual/cowboy_constraints.int/index.html | 4 +- .../manual/cowboy_constraints.nonempty/index.html | 4 +- .../2.0/manual/cowboy_constraints/index.html | 4 +- .../2.0/manual/cowboy_handler.terminate/index.html | 4 +- .../en/cowboy/2.0/manual/cowboy_handler/index.html | 4 +- docs/en/cowboy/2.0/manual/cowboy_http/index.html | 4 +- docs/en/cowboy/2.0/manual/cowboy_http2/index.html | 4 +- docs/en/cowboy/2.0/manual/cowboy_loop/index.html | 4 +- .../cowboy/2.0/manual/cowboy_middleware/index.html | 4 +- .../2.0/manual/cowboy_req.binding/index.html | 4 +- .../2.0/manual/cowboy_req.bindings/index.html | 4 +- .../2.0/manual/cowboy_req.body_length/index.html | 4 +- .../cowboy_req.delete_resp_header/index.html | 4 +- .../2.0/manual/cowboy_req.has_body/index.html | 4 +- .../2.0/manual/cowboy_req.has_resp_body/index.html | 4 +- .../manual/cowboy_req.has_resp_header/index.html | 4 +- .../cowboy/2.0/manual/cowboy_req.header/index.html | 4 +- .../2.0/manual/cowboy_req.headers/index.html | 4 +- .../cowboy/2.0/manual/cowboy_req.host/index.html | 4 +- .../2.0/manual/cowboy_req.host_info/index.html | 4 +- .../2.0/manual/cowboy_req.match_cookies/index.html | 4 +- .../2.0/manual/cowboy_req.match_qs/index.html | 4 +- .../cowboy/2.0/manual/cowboy_req.method/index.html | 4 +- .../2.0/manual/cowboy_req.parse_cookies/index.html | 4 +- .../2.0/manual/cowboy_req.parse_header/index.html | 4 +- .../2.0/manual/cowboy_req.parse_qs/index.html | 4 +- .../cowboy/2.0/manual/cowboy_req.path/index.html | 4 +- .../2.0/manual/cowboy_req.path_info/index.html | 4 +- .../cowboy/2.0/manual/cowboy_req.peer/index.html | 4 +- .../cowboy/2.0/manual/cowboy_req.port/index.html | 4 +- .../cowboy/2.0/manual/cowboy_req.push/index.html | 4 +- docs/en/cowboy/2.0/manual/cowboy_req.qs/index.html | 4 +- .../2.0/manual/cowboy_req.read_body/index.html | 4 +- .../2.0/manual/cowboy_req.read_part/index.html | 4 +- .../manual/cowboy_req.read_part_body/index.html | 4 +- .../cowboy_req.read_urlencoded_body/index.html | 4 +- .../cowboy/2.0/manual/cowboy_req.reply/index.html | 4 +- .../2.0/manual/cowboy_req.resp_header/index.html | 4 +- .../2.0/manual/cowboy_req.resp_headers/index.html | 4 +- .../cowboy/2.0/manual/cowboy_req.scheme/index.html | 4 +- .../2.0/manual/cowboy_req.set_resp_body/index.html | 4 +- .../manual/cowboy_req.set_resp_cookie/index.html | 4 +- .../manual/cowboy_req.set_resp_header/index.html | 4 +- .../manual/cowboy_req.set_resp_headers/index.html | 4 +- .../2.0/manual/cowboy_req.stream_body/index.html | 4 +- .../2.0/manual/cowboy_req.stream_reply/index.html | 4 +- .../en/cowboy/2.0/manual/cowboy_req.uri/index.html | 4 +- .../2.0/manual/cowboy_req.version/index.html | 4 +- docs/en/cowboy/2.0/manual/cowboy_req/index.html | 4 +- docs/en/cowboy/2.0/manual/cowboy_rest/index.html | 4 +- .../2.0/manual/cowboy_router.compile/index.html | 4 +- docs/en/cowboy/2.0/manual/cowboy_router/index.html | 4 +- docs/en/cowboy/2.0/manual/cowboy_static/index.html | 4 +- docs/en/cowboy/2.0/manual/cowboy_stream/index.html | 4 +- .../cowboy/2.0/manual/cowboy_websocket/index.html | 4 +- .../cowboy/2.0/manual/http_status_codes/index.html | 4 +- docs/en/cowboy/2.0/manual/index.html | 4 +- docs/en/cowboy/2.1/guide/constraints.asciidoc | 123 + docs/en/cowboy/2.1/guide/constraints/index.html | 298 ++ docs/en/cowboy/2.1/guide/cookies.asciidoc | 139 + docs/en/cowboy/2.1/guide/cookies/index.html | 301 +++ docs/en/cowboy/2.1/guide/cowboy.sty | 8 + docs/en/cowboy/2.1/guide/erlang_web.asciidoc | 209 ++ docs/en/cowboy/2.1/guide/erlang_web/index.html | 351 +++ docs/en/cowboy/2.1/guide/flow_diagram.asciidoc | 109 + docs/en/cowboy/2.1/guide/flow_diagram/index.html | 270 ++ docs/en/cowboy/2.1/guide/getting_started.asciidoc | 147 + .../en/cowboy/2.1/guide/getting_started/index.html | 318 +++ docs/en/cowboy/2.1/guide/handlers.asciidoc | 90 + docs/en/cowboy/2.1/guide/handlers/index.html | 248 ++ docs/en/cowboy/2.1/guide/http_req_resp.png | Bin 0 -> 20713 bytes docs/en/cowboy/2.1/guide/http_req_resp.svg | 543 ++++ docs/en/cowboy/2.1/guide/index.html | 339 +++ docs/en/cowboy/2.1/guide/introduction.asciidoc | 75 + docs/en/cowboy/2.1/guide/introduction/index.html | 236 ++ docs/en/cowboy/2.1/guide/listeners.asciidoc | 115 + docs/en/cowboy/2.1/guide/listeners/index.html | 266 ++ docs/en/cowboy/2.1/guide/loop_handlers.asciidoc | 128 + docs/en/cowboy/2.1/guide/loop_handlers/index.html | 288 ++ docs/en/cowboy/2.1/guide/middlewares.asciidoc | 69 + docs/en/cowboy/2.1/guide/middlewares/index.html | 249 ++ .../cowboy/2.1/guide/migrating_from_1.0.asciidoc | 214 ++ .../cowboy/2.1/guide/migrating_from_1.0/index.html | 545 ++++ .../cowboy/2.1/guide/migrating_from_2.0.asciidoc | 107 + .../cowboy/2.1/guide/migrating_from_2.0/index.html | 345 +++ docs/en/cowboy/2.1/guide/modern_web.asciidoc | 122 + docs/en/cowboy/2.1/guide/modern_web/index.html | 268 ++ docs/en/cowboy/2.1/guide/multipart.asciidoc | 169 ++ docs/en/cowboy/2.1/guide/multipart/index.html | 326 +++ docs/en/cowboy/2.1/guide/req.asciidoc | 366 +++ docs/en/cowboy/2.1/guide/req/index.html | 564 ++++ docs/en/cowboy/2.1/guide/req_body.asciidoc | 130 + docs/en/cowboy/2.1/guide/req_body/index.html | 301 +++ docs/en/cowboy/2.1/guide/resource_design.asciidoc | 220 ++ .../en/cowboy/2.1/guide/resource_design/index.html | 370 +++ docs/en/cowboy/2.1/guide/resp.asciidoc | 341 +++ docs/en/cowboy/2.1/guide/resp/index.html | 503 ++++ docs/en/cowboy/2.1/guide/rest_cond.png | Bin 0 -> 111628 bytes docs/en/cowboy/2.1/guide/rest_cond.svg | 1656 ++++++++++++ docs/en/cowboy/2.1/guide/rest_conneg.png | Bin 0 -> 78133 bytes docs/en/cowboy/2.1/guide/rest_conneg.svg | 1135 ++++++++ docs/en/cowboy/2.1/guide/rest_delete.png | Bin 0 -> 122185 bytes docs/en/cowboy/2.1/guide/rest_delete.svg | 1718 ++++++++++++ docs/en/cowboy/2.1/guide/rest_flowcharts.asciidoc | 248 ++ .../en/cowboy/2.1/guide/rest_flowcharts/index.html | 401 +++ docs/en/cowboy/2.1/guide/rest_get_head.png | Bin 0 -> 94321 bytes docs/en/cowboy/2.1/guide/rest_get_head.svg | 1523 +++++++++++ docs/en/cowboy/2.1/guide/rest_handlers.asciidoc | 138 + docs/en/cowboy/2.1/guide/rest_handlers/index.html | 444 +++ docs/en/cowboy/2.1/guide/rest_options.png | Bin 0 -> 8539 bytes docs/en/cowboy/2.1/guide/rest_options.svg | 387 +++ docs/en/cowboy/2.1/guide/rest_principles.asciidoc | 160 ++ .../en/cowboy/2.1/guide/rest_principles/index.html | 310 +++ docs/en/cowboy/2.1/guide/rest_put_post_patch.png | Bin 0 -> 206747 bytes docs/en/cowboy/2.1/guide/rest_put_post_patch.svg | 2856 ++++++++++++++++++++ docs/en/cowboy/2.1/guide/rest_start.png | Bin 0 -> 105640 bytes docs/en/cowboy/2.1/guide/rest_start.svg | 1356 ++++++++++ docs/en/cowboy/2.1/guide/routing.asciidoc | 222 ++ docs/en/cowboy/2.1/guide/routing/index.html | 418 +++ docs/en/cowboy/2.1/guide/specs.asciidoc | 189 ++ docs/en/cowboy/2.1/guide/specs/index.html | 992 +++++++ docs/en/cowboy/2.1/guide/static_files.asciidoc | 163 ++ docs/en/cowboy/2.1/guide/static_files/index.html | 330 +++ docs/en/cowboy/2.1/guide/streams.asciidoc | 65 + docs/en/cowboy/2.1/guide/streams/index.html | 218 ++ docs/en/cowboy/2.1/guide/ws_handlers.asciidoc | 269 ++ docs/en/cowboy/2.1/guide/ws_handlers/index.html | 428 +++ docs/en/cowboy/2.1/guide/ws_protocol.asciidoc | 69 + docs/en/cowboy/2.1/guide/ws_protocol/index.html | 227 ++ .../en/cowboy/2.1/manual/cowboy.set_env/index.html | 252 ++ .../2.1/manual/cowboy.start_clear/index.html | 283 ++ .../cowboy/2.1/manual/cowboy.start_tls/index.html | 288 ++ .../2.1/manual/cowboy.stop_listener/index.html | 222 ++ docs/en/cowboy/2.1/manual/cowboy/index.html | 264 ++ docs/en/cowboy/2.1/manual/cowboy_app/index.html | 306 +++ .../2.1/manual/cowboy_constraints.int/index.html | 227 ++ .../manual/cowboy_constraints.nonempty/index.html | 226 ++ .../2.1/manual/cowboy_constraints/index.html | 219 ++ .../2.1/manual/cowboy_handler.terminate/index.html | 244 ++ .../en/cowboy/2.1/manual/cowboy_handler/index.html | 231 ++ docs/en/cowboy/2.1/manual/cowboy_http/index.html | 375 +++ docs/en/cowboy/2.1/manual/cowboy_http2/index.html | 258 ++ docs/en/cowboy/2.1/manual/cowboy_loop/index.html | 255 ++ .../cowboy/2.1/manual/cowboy_middleware/index.html | 250 ++ .../2.1/manual/cowboy_req.binding/index.html | 251 ++ .../2.1/manual/cowboy_req.bindings/index.html | 221 ++ .../2.1/manual/cowboy_req.body_length/index.html | 224 ++ .../cowboy/2.1/manual/cowboy_req.cert/index.html | 239 ++ .../cowboy_req.delete_resp_header/index.html | 230 ++ .../2.1/manual/cowboy_req.has_body/index.html | 215 ++ .../2.1/manual/cowboy_req.has_resp_body/index.html | 217 ++ .../manual/cowboy_req.has_resp_header/index.html | 230 ++ .../cowboy/2.1/manual/cowboy_req.header/index.html | 257 ++ .../2.1/manual/cowboy_req.headers/index.html | 225 ++ .../cowboy/2.1/manual/cowboy_req.host/index.html | 226 ++ .../2.1/manual/cowboy_req.host_info/index.html | 222 ++ .../cowboy/2.1/manual/cowboy_req.inform/index.html | 260 ++ .../2.1/manual/cowboy_req.match_cookies/index.html | 258 ++ .../2.1/manual/cowboy_req.match_qs/index.html | 258 ++ .../cowboy/2.1/manual/cowboy_req.method/index.html | 235 ++ .../2.1/manual/cowboy_req.parse_cookies/index.html | 226 ++ .../2.1/manual/cowboy_req.parse_header/index.html | 418 +++ .../2.1/manual/cowboy_req.parse_qs/index.html | 252 ++ .../cowboy/2.1/manual/cowboy_req.path/index.html | 225 ++ .../2.1/manual/cowboy_req.path_info/index.html | 222 ++ .../cowboy/2.1/manual/cowboy_req.peer/index.html | 233 ++ .../cowboy/2.1/manual/cowboy_req.port/index.html | 225 ++ .../cowboy/2.1/manual/cowboy_req.push/index.html | 277 ++ docs/en/cowboy/2.1/manual/cowboy_req.qs/index.html | 224 ++ .../2.1/manual/cowboy_req.read_body/index.html | 278 ++ .../2.1/manual/cowboy_req.read_part/index.html | 297 ++ .../manual/cowboy_req.read_part_body/index.html | 265 ++ .../cowboy_req.read_urlencoded_body/index.html | 261 ++ .../cowboy/2.1/manual/cowboy_req.reply/index.html | 300 ++ .../2.1/manual/cowboy_req.resp_header/index.html | 248 ++ .../2.1/manual/cowboy_req.resp_headers/index.html | 214 ++ .../cowboy/2.1/manual/cowboy_req.scheme/index.html | 224 ++ .../2.1/manual/cowboy_req.set_resp_body/index.html | 273 ++ .../manual/cowboy_req.set_resp_cookie/index.html | 302 +++ .../manual/cowboy_req.set_resp_header/index.html | 256 ++ .../manual/cowboy_req.set_resp_headers/index.html | 244 ++ .../cowboy/2.1/manual/cowboy_req.sock/index.html | 221 ++ .../2.1/manual/cowboy_req.stream_body/index.html | 251 ++ .../2.1/manual/cowboy_req.stream_reply/index.html | 284 ++ .../en/cowboy/2.1/manual/cowboy_req.uri/index.html | 312 +++ .../2.1/manual/cowboy_req.version/index.html | 223 ++ docs/en/cowboy/2.1/manual/cowboy_req/index.html | 544 ++++ docs/en/cowboy/2.1/manual/cowboy_rest/index.html | 786 ++++++ .../2.1/manual/cowboy_router.compile/index.html | 222 ++ docs/en/cowboy/2.1/manual/cowboy_router/index.html | 245 ++ docs/en/cowboy/2.1/manual/cowboy_static/index.html | 310 +++ docs/en/cowboy/2.1/manual/cowboy_stream/index.html | 546 ++++ .../cowboy/2.1/manual/cowboy_websocket/index.html | 430 +++ .../cowboy/2.1/manual/http_status_codes/index.html | 406 +++ docs/en/cowboy/2.1/manual/index.html | 306 +++ docs/en/erlang.mk/1/guide/app/index.html | 2 +- docs/en/erlang.mk/1/guide/asciidoc/index.html | 2 +- docs/en/erlang.mk/1/guide/ci/index.html | 2 +- docs/en/erlang.mk/1/guide/common_test/index.html | 2 +- docs/en/erlang.mk/1/guide/compat/index.html | 2 +- docs/en/erlang.mk/1/guide/contributing/index.html | 2 +- docs/en/erlang.mk/1/guide/coverage/index.html | 2 +- docs/en/erlang.mk/1/guide/deps/index.html | 2 +- docs/en/erlang.mk/1/guide/dialyzer/index.html | 2 +- docs/en/erlang.mk/1/guide/edoc/index.html | 2 +- docs/en/erlang.mk/1/guide/escripts/index.html | 2 +- docs/en/erlang.mk/1/guide/eunit/index.html | 2 +- .../erlang.mk/1/guide/external_plugins/index.html | 2 +- .../1/guide/external_plugins_list/index.html | 2 +- .../erlang.mk/1/guide/getting_started/index.html | 2 +- docs/en/erlang.mk/1/guide/history/index.html | 2 +- docs/en/erlang.mk/1/guide/index.html | 2 +- docs/en/erlang.mk/1/guide/installation/index.html | 2 +- docs/en/erlang.mk/1/guide/kerl/index.html | 2 +- docs/en/erlang.mk/1/guide/limitations/index.html | 2 +- docs/en/erlang.mk/1/guide/overview/index.html | 2 +- docs/en/erlang.mk/1/guide/ports/index.html | 2 +- docs/en/erlang.mk/1/guide/releases/index.html | 2 +- docs/en/erlang.mk/1/guide/sfx/index.html | 2 +- docs/en/erlang.mk/1/guide/shell/index.html | 2 +- docs/en/erlang.mk/1/guide/updating/index.html | 2 +- docs/en/erlang.mk/1/guide/why/index.html | 2 +- docs/en/erlang.mk/1/guide/xref/index.html | 2 +- docs/en/gun/1.0/guide/connect/index.html | 2 +- docs/en/gun/1.0/guide/http/index.html | 2 +- docs/en/gun/1.0/guide/index.html | 2 +- docs/en/gun/1.0/guide/introduction/index.html | 2 +- docs/en/gun/1.0/guide/protocols/index.html | 2 +- docs/en/gun/1.0/guide/start/index.html | 2 +- docs/en/gun/1.0/guide/websocket/index.html | 2 +- docs/en/gun/1.0/manual/gun/index.html | 2 +- docs/en/gun/1.0/manual/gun_app/index.html | 2 +- docs/en/gun/1.0/manual/index.html | 2 +- docs/en/ranch/1.2/guide/embedded/index.html | 2 +- docs/en/ranch/1.2/guide/index.html | 2 +- docs/en/ranch/1.2/guide/internals/index.html | 2 +- docs/en/ranch/1.2/guide/introduction/index.html | 2 +- docs/en/ranch/1.2/guide/listeners/index.html | 2 +- docs/en/ranch/1.2/guide/parsers/index.html | 2 +- docs/en/ranch/1.2/guide/protocols/index.html | 2 +- docs/en/ranch/1.2/guide/ssl_auth/index.html | 2 +- docs/en/ranch/1.2/guide/transports/index.html | 2 +- docs/en/ranch/1.2/manual/index.html | 2 +- docs/en/ranch/1.2/manual/ranch/index.html | 2 +- docs/en/ranch/1.2/manual/ranch_app/index.html | 2 +- docs/en/ranch/1.2/manual/ranch_protocol/index.html | 2 +- docs/en/ranch/1.2/manual/ranch_ssl/index.html | 2 +- docs/en/ranch/1.2/manual/ranch_tcp/index.html | 2 +- .../en/ranch/1.2/manual/ranch_transport/index.html | 2 +- docs/en/ranch/1.3/guide/embedded/index.html | 2 +- docs/en/ranch/1.3/guide/index.html | 2 +- docs/en/ranch/1.3/guide/internals/index.html | 2 +- docs/en/ranch/1.3/guide/introduction/index.html | 2 +- docs/en/ranch/1.3/guide/listeners/index.html | 2 +- docs/en/ranch/1.3/guide/parsers/index.html | 2 +- docs/en/ranch/1.3/guide/protocols/index.html | 2 +- docs/en/ranch/1.3/guide/ssl_auth/index.html | 2 +- docs/en/ranch/1.3/guide/transports/index.html | 2 +- docs/en/ranch/1.3/manual/index.html | 2 +- docs/en/ranch/1.3/manual/ranch/index.html | 2 +- docs/en/ranch/1.3/manual/ranch_app/index.html | 2 +- docs/en/ranch/1.3/manual/ranch_protocol/index.html | 2 +- docs/en/ranch/1.3/manual/ranch_ssl/index.html | 2 +- docs/en/ranch/1.3/manual/ranch_tcp/index.html | 2 +- .../en/ranch/1.3/manual/ranch_transport/index.html | 2 +- docs/en/ranch/1.4/guide/embedded/index.html | 2 +- docs/en/ranch/1.4/guide/index.html | 2 +- docs/en/ranch/1.4/guide/internals/index.html | 2 +- docs/en/ranch/1.4/guide/introduction/index.html | 2 +- docs/en/ranch/1.4/guide/listeners/index.html | 2 +- docs/en/ranch/1.4/guide/parsers/index.html | 2 +- docs/en/ranch/1.4/guide/protocols/index.html | 2 +- docs/en/ranch/1.4/guide/ssl_auth/index.html | 2 +- docs/en/ranch/1.4/guide/transports/index.html | 2 +- docs/en/ranch/1.4/manual/index.html | 2 +- docs/en/ranch/1.4/manual/ranch/index.html | 2 +- docs/en/ranch/1.4/manual/ranch_app/index.html | 2 +- docs/en/ranch/1.4/manual/ranch_protocol/index.html | 2 +- docs/en/ranch/1.4/manual/ranch_ssl/index.html | 2 +- docs/en/ranch/1.4/manual/ranch_tcp/index.html | 2 +- .../en/ranch/1.4/manual/ranch_transport/index.html | 2 +- 316 files changed, 44324 insertions(+), 196 deletions(-) create mode 100644 docs/en/cowboy/2.1/guide/constraints.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/constraints/index.html create mode 100644 docs/en/cowboy/2.1/guide/cookies.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/cookies/index.html create mode 100644 docs/en/cowboy/2.1/guide/cowboy.sty create mode 100644 docs/en/cowboy/2.1/guide/erlang_web.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/erlang_web/index.html create mode 100644 docs/en/cowboy/2.1/guide/flow_diagram.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/flow_diagram/index.html create mode 100644 docs/en/cowboy/2.1/guide/getting_started.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/getting_started/index.html create mode 100644 docs/en/cowboy/2.1/guide/handlers.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/handlers/index.html create mode 100644 docs/en/cowboy/2.1/guide/http_req_resp.png create mode 100644 docs/en/cowboy/2.1/guide/http_req_resp.svg create mode 100644 docs/en/cowboy/2.1/guide/index.html create mode 100644 docs/en/cowboy/2.1/guide/introduction.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/introduction/index.html create mode 100644 docs/en/cowboy/2.1/guide/listeners.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/listeners/index.html create mode 100644 docs/en/cowboy/2.1/guide/loop_handlers.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/loop_handlers/index.html create mode 100644 docs/en/cowboy/2.1/guide/middlewares.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/middlewares/index.html create mode 100644 docs/en/cowboy/2.1/guide/migrating_from_1.0.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/migrating_from_1.0/index.html create mode 100644 docs/en/cowboy/2.1/guide/migrating_from_2.0.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/migrating_from_2.0/index.html create mode 100644 docs/en/cowboy/2.1/guide/modern_web.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/modern_web/index.html create mode 100644 docs/en/cowboy/2.1/guide/multipart.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/multipart/index.html create mode 100644 docs/en/cowboy/2.1/guide/req.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/req/index.html create mode 100644 docs/en/cowboy/2.1/guide/req_body.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/req_body/index.html create mode 100644 docs/en/cowboy/2.1/guide/resource_design.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/resource_design/index.html create mode 100644 docs/en/cowboy/2.1/guide/resp.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/resp/index.html create mode 100644 docs/en/cowboy/2.1/guide/rest_cond.png create mode 100644 docs/en/cowboy/2.1/guide/rest_cond.svg create mode 100644 docs/en/cowboy/2.1/guide/rest_conneg.png create mode 100644 docs/en/cowboy/2.1/guide/rest_conneg.svg create mode 100644 docs/en/cowboy/2.1/guide/rest_delete.png create mode 100644 docs/en/cowboy/2.1/guide/rest_delete.svg create mode 100644 docs/en/cowboy/2.1/guide/rest_flowcharts.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/rest_flowcharts/index.html create mode 100644 docs/en/cowboy/2.1/guide/rest_get_head.png create mode 100644 docs/en/cowboy/2.1/guide/rest_get_head.svg create mode 100644 docs/en/cowboy/2.1/guide/rest_handlers.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/rest_handlers/index.html create mode 100644 docs/en/cowboy/2.1/guide/rest_options.png create mode 100644 docs/en/cowboy/2.1/guide/rest_options.svg create mode 100644 docs/en/cowboy/2.1/guide/rest_principles.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/rest_principles/index.html create mode 100644 docs/en/cowboy/2.1/guide/rest_put_post_patch.png create mode 100644 docs/en/cowboy/2.1/guide/rest_put_post_patch.svg create mode 100644 docs/en/cowboy/2.1/guide/rest_start.png create mode 100644 docs/en/cowboy/2.1/guide/rest_start.svg create mode 100644 docs/en/cowboy/2.1/guide/routing.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/routing/index.html create mode 100644 docs/en/cowboy/2.1/guide/specs.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/specs/index.html create mode 100644 docs/en/cowboy/2.1/guide/static_files.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/static_files/index.html create mode 100644 docs/en/cowboy/2.1/guide/streams.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/streams/index.html create mode 100644 docs/en/cowboy/2.1/guide/ws_handlers.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/ws_handlers/index.html create mode 100644 docs/en/cowboy/2.1/guide/ws_protocol.asciidoc create mode 100644 docs/en/cowboy/2.1/guide/ws_protocol/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy.set_env/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy.start_clear/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy.start_tls/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy.stop_listener/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_app/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_constraints.int/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_constraints.nonempty/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_constraints/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_handler.terminate/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_handler/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_http/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_http2/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_loop/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_middleware/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.binding/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.bindings/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.body_length/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.cert/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.delete_resp_header/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.has_body/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.has_resp_body/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.has_resp_header/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.header/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.headers/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.host/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.host_info/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.inform/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.match_cookies/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.match_qs/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.method/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.parse_cookies/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.parse_header/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.parse_qs/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.path/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.path_info/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.peer/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.port/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.push/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.qs/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.read_body/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.read_part/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.read_part_body/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.read_urlencoded_body/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.reply/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.resp_header/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.resp_headers/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.scheme/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.set_resp_body/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.set_resp_cookie/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.set_resp_header/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.set_resp_headers/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.sock/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.stream_body/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.stream_reply/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.uri/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req.version/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_req/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_rest/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_router.compile/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_router/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_static/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_stream/index.html create mode 100644 docs/en/cowboy/2.1/manual/cowboy_websocket/index.html create mode 100644 docs/en/cowboy/2.1/manual/http_status_codes/index.html create mode 100644 docs/en/cowboy/2.1/manual/index.html (limited to 'docs/en') diff --git a/docs/en/cowboy/2.0/guide/constraints/index.html b/docs/en/cowboy/2.0/guide/constraints/index.html index 570f49fe..d73b061d 100644 --- a/docs/en/cowboy/2.0/guide/constraints/index.html +++ b/docs/en/cowboy/2.0/guide/constraints/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Constraints @@ -258,6 +258,8 @@ functions. They should be written to not emit any exceptions.

+
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/cookies/index.html b/docs/en/cowboy/2.0/guide/cookies/index.html index fe40ca87..5d56bfaf 100644 --- a/docs/en/cowboy/2.0/guide/cookies/index.html +++ b/docs/en/cowboy/2.0/guide/cookies/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Using cookies @@ -261,6 +261,8 @@ exception is thrown.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/erlang_web/index.html b/docs/en/cowboy/2.0/guide/erlang_web/index.html index 33ceb1e6..f8e72f14 100644 --- a/docs/en/cowboy/2.0/guide/erlang_web/index.html +++ b/docs/en/cowboy/2.0/guide/erlang_web/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Erlang and the Web @@ -311,6 +311,8 @@ ebook version.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/flow_diagram/index.html b/docs/en/cowboy/2.0/guide/flow_diagram/index.html index 679ee0b1..abdec8b9 100644 --- a/docs/en/cowboy/2.0/guide/flow_diagram/index.html +++ b/docs/en/cowboy/2.0/guide/flow_diagram/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Flow diagram @@ -230,6 +230,8 @@ be the cause.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/getting_started/index.html b/docs/en/cowboy/2.0/guide/getting_started/index.html index 9ec1da90..8e80530b 100644 --- a/docs/en/cowboy/2.0/guide/getting_started/index.html +++ b/docs/en/cowboy/2.0/guide/getting_started/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Getting started @@ -278,6 +278,8 @@ in your browser, you should get a nice Hello Erlang! displayed!

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/handlers/index.html b/docs/en/cowboy/2.0/guide/handlers/index.html index 33cd53e2..f1fa61d0 100644 --- a/docs/en/cowboy/2.0/guide/handlers/index.html +++ b/docs/en/cowboy/2.0/guide/handlers/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Handlers @@ -208,6 +208,8 @@ process will terminate soon after this call returns.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/index.html b/docs/en/cowboy/2.0/guide/index.html index 533d8db1..e908b5b0 100644 --- a/docs/en/cowboy/2.0/guide/index.html +++ b/docs/en/cowboy/2.0/guide/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Cowboy User Guide @@ -294,6 +294,8 @@ +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/introduction/index.html b/docs/en/cowboy/2.0/guide/introduction/index.html index 63b07c4e..f1402b5a 100644 --- a/docs/en/cowboy/2.0/guide/introduction/index.html +++ b/docs/en/cowboy/2.0/guide/introduction/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Introduction @@ -196,6 +196,8 @@ when sending responses.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/listeners/index.html b/docs/en/cowboy/2.0/guide/listeners/index.html index ee7a86f9..c8efbf0d 100644 --- a/docs/en/cowboy/2.0/guide/listeners/index.html +++ b/docs/en/cowboy/2.0/guide/listeners/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Listeners @@ -226,6 +226,8 @@ shared.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/loop_handlers/index.html b/docs/en/cowboy/2.0/guide/loop_handlers/index.html index 0b0b50b5..ce390b41 100644 --- a/docs/en/cowboy/2.0/guide/loop_handlers/index.html +++ b/docs/en/cowboy/2.0/guide/loop_handlers/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Loop handlers @@ -248,6 +248,8 @@ accordingly.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/middlewares/index.html b/docs/en/cowboy/2.0/guide/middlewares/index.html index 5569e6f5..fc4f822b 100644 --- a/docs/en/cowboy/2.0/guide/middlewares/index.html +++ b/docs/en/cowboy/2.0/guide/middlewares/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Middlewares @@ -209,6 +209,8 @@ values. It puts the result of the request handling into result.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.0/guide/migrating_from_1.0/index.html index f7f9492b..f66b424e 100644 --- a/docs/en/cowboy/2.0/guide/migrating_from_1.0/index.html +++ b/docs/en/cowboy/2.0/guide/migrating_from_1.0/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Migrating from Cowboy 1.0 to 2.0 @@ -495,6 +495,8 @@ The static file handler has been improved to handle more special +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/modern_web/index.html b/docs/en/cowboy/2.0/guide/modern_web/index.html index 2bbf1072..ec2d3a7e 100644 --- a/docs/en/cowboy/2.0/guide/modern_web/index.html +++ b/docs/en/cowboy/2.0/guide/modern_web/index.html @@ -7,7 +7,7 @@ - + Nine Nines: The modern Web @@ -228,6 +228,8 @@ the HTTP protocol.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/multipart/index.html b/docs/en/cowboy/2.0/guide/multipart/index.html index 4f173126..7f6cc95b 100644 --- a/docs/en/cowboy/2.0/guide/multipart/index.html +++ b/docs/en/cowboy/2.0/guide/multipart/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Multipart requests @@ -286,6 +286,8 @@ reading as soon as you find the data you need.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/req/index.html b/docs/en/cowboy/2.0/guide/req/index.html index bdf6b6b9..b9198024 100644 --- a/docs/en/cowboy/2.0/guide/req/index.html +++ b/docs/en/cowboy/2.0/guide/req/index.html @@ -7,7 +7,7 @@ - + Nine Nines: The Req object @@ -524,6 +524,8 @@ client itself. It may also be a proxy or a gateway.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/req_body/index.html b/docs/en/cowboy/2.0/guide/req_body/index.html index 4fce0fd5..53d396e2 100644 --- a/docs/en/cowboy/2.0/guide/req_body/index.html +++ b/docs/en/cowboy/2.0/guide/req_body/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Reading the request body @@ -261,6 +261,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/resource_design.asciidoc b/docs/en/cowboy/2.0/guide/resource_design.asciidoc index fa0c6122..2325b9f2 100644 --- a/docs/en/cowboy/2.0/guide/resource_design.asciidoc +++ b/docs/en/cowboy/2.0/guide/resource_design.asciidoc @@ -193,8 +193,8 @@ callback. If you implement the methods PUT, POST and/or PATCH, you must implement the `content_types_accepted` callback, -and one `AcceptCallback` callback for each content-type -it returns. Prefix the `AcceptCallback` callback names +and one `AcceptResource` callback for each content-type +it returns. Prefix the `AcceptResource` callback names with `from_` for clarity. For example, `from_html` or `from_json`. diff --git a/docs/en/cowboy/2.0/guide/resource_design/index.html b/docs/en/cowboy/2.0/guide/resource_design/index.html index c2331de4..688a5f04 100644 --- a/docs/en/cowboy/2.0/guide/resource_design/index.html +++ b/docs/en/cowboy/2.0/guide/resource_design/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Designing a resource handler @@ -248,8 +248,8 @@ callback.

    If you implement the methods PUT, POST and/or PATCH, you must implement the content_types_accepted callback, -and one AcceptCallback callback for each content-type -it returns. Prefix the AcceptCallback callback names +and one AcceptResource callback for each content-type +it returns. Prefix the AcceptResource callback names with from_ for clarity. For example, from_html or from_json.

    Do we want to allow the POST method to create individual @@ -330,6 +330,8 @@ no way of knowing it has been completed yet, implement the +

  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/resp/index.html b/docs/en/cowboy/2.0/guide/resp/index.html index 6ecdd801..ef32be65 100644 --- a/docs/en/cowboy/2.0/guide/resp/index.html +++ b/docs/en/cowboy/2.0/guide/resp/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Sending a response @@ -439,6 +439,8 @@ ultimately send a response to the client.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.0/guide/rest_flowcharts/index.html index 88241cbf..fa510cf4 100644 --- a/docs/en/cowboy/2.0/guide/rest_flowcharts/index.html +++ b/docs/en/cowboy/2.0/guide/rest_flowcharts/index.html @@ -7,7 +7,7 @@ - + Nine Nines: REST flowcharts @@ -361,6 +361,8 @@ the results for subsequent use.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/rest_handlers/index.html b/docs/en/cowboy/2.0/guide/rest_handlers/index.html index 93a311d0..aa0be7ff 100644 --- a/docs/en/cowboy/2.0/guide/rest_handlers/index.html +++ b/docs/en/cowboy/2.0/guide/rest_handlers/index.html @@ -7,7 +7,7 @@ - + Nine Nines: REST handlers @@ -400,6 +400,8 @@ cellspacing="0" cellpadding="4"> +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/rest_principles/index.html b/docs/en/cowboy/2.0/guide/rest_principles/index.html index c221d123..c26bf839 100644 --- a/docs/en/cowboy/2.0/guide/rest_principles/index.html +++ b/docs/en/cowboy/2.0/guide/rest_principles/index.html @@ -7,7 +7,7 @@ - + Nine Nines: REST principles @@ -270,6 +270,8 @@ anything specific to the service to operate on it.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/routing/index.html b/docs/en/cowboy/2.0/guide/routing/index.html index 24f5ca46..891daf94 100644 --- a/docs/en/cowboy/2.0/guide/routing/index.html +++ b/docs/en/cowboy/2.0/guide/routing/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Routing @@ -378,6 +378,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/specs/index.html b/docs/en/cowboy/2.0/guide/specs/index.html index b0511164..bd6f8456 100644 --- a/docs/en/cowboy/2.0/guide/specs/index.html +++ b/docs/en/cowboy/2.0/guide/specs/index.html @@ -7,7 +7,7 @@ - + Nine Nines: HTTP and other specifications @@ -952,6 +952,8 @@ for or related to HTTP.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/static_files/index.html b/docs/en/cowboy/2.0/guide/static_files/index.html index f7a5c7f9..2d2e53c8 100644 --- a/docs/en/cowboy/2.0/guide/static_files/index.html +++ b/docs/en/cowboy/2.0/guide/static_files/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Static files @@ -290,6 +290,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/streams/index.html b/docs/en/cowboy/2.0/guide/streams/index.html index e7c82dd1..22100f9c 100644 --- a/docs/en/cowboy/2.0/guide/streams/index.html +++ b/docs/en/cowboy/2.0/guide/streams/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Streams @@ -178,6 +178,8 @@ that will modify responses.

    +
  • 2.1
    • +
  • 2.0
  • 1.0
    • diff --git a/docs/en/cowboy/2.0/guide/ws_handlers.asciidoc b/docs/en/cowboy/2.0/guide/ws_handlers.asciidoc index a79d7e29..84dfb9bc 100644 --- a/docs/en/cowboy/2.0/guide/ws_handlers.asciidoc +++ b/docs/en/cowboy/2.0/guide/ws_handlers.asciidoc @@ -57,19 +57,18 @@ be: [source,erlang] ---- -init(Req0, State) -> - case cowboy_req:parse_header(<<"sec-websocket-protocol">>, Req0) of +init(Req, State) -> + case cowboy_req:parse_header(<<"sec-websocket-protocol">>, Req) of undefined -> - {cowboy_websocket, Req0, State}; + {cowboy_websocket, Req, State}; Subprotocols -> case lists:keymember(<<"mqtt">>, 1, Subprotocols) of true -> - Req = cowboy_req:set_resp_header(<<"sec-websocket-protocol">>, - <<"mqtt">>, Req0), - {cowboy_websocket, Req, State}; + Req2 = cowboy_req:set_resp_header(<<"sec-websocket-protocol">>, + <<"mqtt">>, Req), + {cowboy_websocket, Req2, State}; false -> - Req = cowboy_req:reply(400, Req0), - {ok, Req, State} + {stop, Req, State} end end. ---- diff --git a/docs/en/cowboy/2.0/guide/ws_handlers/index.html b/docs/en/cowboy/2.0/guide/ws_handlers/index.html index f17b1093..8e867c6f 100644 --- a/docs/en/cowboy/2.0/guide/ws_handlers/index.html +++ b/docs/en/cowboy/2.0/guide/ws_handlers/index.html @@ -7,7 +7,7 @@ - + Nine Nines: Websocket handlers @@ -122,19 +122,18 @@ be:

    by Lorenzo Bettini http://www.lorenzobettini.it http://www.gnu.org/software/src-highlite --> -
    init(Req0, State) ->
-    case cowboy_req:parse_header(<<"sec-websocket-protocol">>, Req0) of
+
    init(Req, State) ->
+    case cowboy_req:parse_header(<<"sec-websocket-protocol">>, Req) of
         undefined ->
-            {cowboy_websocket, Req0, State};
+            {cowboy_websocket, Req, State};
         Subprotocols ->
             case lists:keymember(<<"mqtt">>, 1, Subprotocols) of
                 true ->
-                    Req = cowboy_req:set_resp_header(<<"sec-websocket-protocol">>,
-                        <<"mqtt">>, Req0),
-                    {cowboy_websocket, Req, State};
+                    Req2 = cowboy_req:set_resp_header(<<"sec-websocket-protocol">>,
+                        <<"mqtt">>, Req),
+                    {cowboy_websocket, Req2, State};
                 false ->
-                    Req = cowboy_req:reply(400, Req0),
-                    {ok, Req, State}
+                    {stop, Req, State}
             end
     end.
    
 
@@ -388,6 +387,8 @@ close frame will not be sent.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/guide/ws_protocol/index.html b/docs/en/cowboy/2.0/guide/ws_protocol/index.html
index d70fe10d..3b1b1cf4 100644
--- a/docs/en/cowboy/2.0/guide/ws_protocol/index.html
+++ b/docs/en/cowboy/2.0/guide/ws_protocol/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: The Websocket protocol
 
@@ -187,6 +187,8 @@ extensions.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.0/manual/cowboy.set_env/index.html
index 914b466c..3f186eea 100644
--- a/docs/en/cowboy/2.0/manual/cowboy.set_env/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy.set_env/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy:set_env(3)
 
@@ -212,6 +212,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.0/manual/cowboy.start_clear/index.html
index a544cc71..d5ae565f 100644
--- a/docs/en/cowboy/2.0/manual/cowboy.start_clear/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy.start_clear/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy:start_clear(3)
 
@@ -243,6 +243,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.0/manual/cowboy.start_tls/index.html
index 7b660e07..b5b3c4dc 100644
--- a/docs/en/cowboy/2.0/manual/cowboy.start_tls/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy.start_tls/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy:start_tls(3)
 
@@ -248,6 +248,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.0/manual/cowboy.stop_listener/index.html
index b3d736f9..3b4763b8 100644
--- a/docs/en/cowboy/2.0/manual/cowboy.stop_listener/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy.stop_listener/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy:stop_listener(3)
 
@@ -182,6 +182,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy/index.html b/docs/en/cowboy/2.0/manual/cowboy/index.html
index 8f2bc031..1e6edce9 100644
--- a/docs/en/cowboy/2.0/manual/cowboy/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy(3)
 
@@ -224,6 +224,8 @@ and the HTTP/2 options in
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_app/index.html b/docs/en/cowboy/2.0/manual/cowboy_app/index.html
index 0c92cf86..93eb3277 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_app/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_app/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy(7)
 
@@ -266,6 +266,8 @@ environment configuration parameters.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.0/manual/cowboy_constraints.int/index.html
index 70c8969e..ae991fd2 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_constraints.int/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_constraints.int/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_constraints:int(3)
 
@@ -187,6 +187,8 @@ and the value as second argument.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.0/manual/cowboy_constraints.nonempty/index.html
index b833f1b1..93f483c4 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_constraints.nonempty/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_constraints.nonempty/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_constraints:nonempty(3)
 
@@ -186,6 +186,8 @@ and the value as second argument.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.0/manual/cowboy_constraints/index.html
index ae5340eb..b171793c 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_constraints/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_constraints/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_constraints(3)
 
@@ -179,6 +179,8 @@ made the constraint fail.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.0/manual/cowboy_handler.terminate/index.html
index c12945ed..657eac26 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_handler.terminate/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_handler.terminate/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_handler:terminate(3)
 
@@ -204,6 +204,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_handler/index.html b/docs/en/cowboy/2.0/manual/cowboy_handler/index.html
index 6c60377a..8a9ea6f2 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_handler/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_handler/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_handler(3)
 
@@ -191,6 +191,8 @@ custom handlers to execute the optional terminate callback:
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_http/index.html b/docs/en/cowboy/2.0/manual/cowboy_http/index.html
index 414880a1..7212815d 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_http/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_http/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_http(3)
 
@@ -335,6 +335,8 @@ stream_handlers ([cowboy_stream_h])
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_http2/index.html b/docs/en/cowboy/2.0/manual/cowboy_http2/index.html
index cac697fa..e381f250 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_http2/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_http2/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_http2(3)
 
@@ -218,6 +218,8 @@ stream_handlers ([cowboy_stream_h])
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_loop/index.html b/docs/en/cowboy/2.0/manual/cowboy_loop/index.html
index a1f0a289..51d99a75 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_loop/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_loop/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_loop(3)
 
@@ -215,6 +215,8 @@ stop
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.0/manual/cowboy_middleware/index.html
index dbf5b412..df724703 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_middleware/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_middleware/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_middleware(3)
 
@@ -210,6 +210,8 @@ contains the name of the listener for this connection.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.binding/index.html
index 94112847..05367e32 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.binding/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.binding/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:binding(3)
 
@@ -211,6 +211,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.bindings/index.html
index 29c994f8..b1e82ffb 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.bindings/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.bindings/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:bindings(3)
 
@@ -181,6 +181,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.body_length/index.html
index 3a360235..57ba60cf 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.body_length/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.body_length/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:body_length(3)
 
@@ -184,6 +184,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.delete_resp_header/index.html
index 09e4f66f..33d13534 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.delete_resp_header/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.delete_resp_header/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:delete_resp_header(3)
 
@@ -190,6 +190,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.has_body/index.html
index 3a8d97ce..3203db5d 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.has_body/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.has_body/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:has_body(3)
 
@@ -175,6 +175,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_body/index.html
index 9d6b92fe..405fd209 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_body/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_body/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:has_resp_body(3)
 
@@ -177,6 +177,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_header/index.html
index 1fc629eb..7d8d98f6 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_header/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_header/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:has_resp_header(3)
 
@@ -190,6 +190,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.header/index.html
index 4680b487..f81ff4f5 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.header/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.header/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:header(3)
 
@@ -217,6 +217,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.headers/index.html
index 28fc85cf..86ecae98 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.headers/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.headers/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:headers(3)
 
@@ -185,6 +185,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.host/index.html
index a5c28fc8..8df8dbc2 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.host/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.host/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:host(3)
 
@@ -186,6 +186,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.host_info/index.html
index a423256f..2c7c38ff 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.host_info/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.host_info/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:host_info(3)
 
@@ -182,6 +182,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.match_cookies/index.html
index d07ea532..6d1e6e6f 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.match_cookies/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.match_cookies/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:match_cookies(3)
 
@@ -218,6 +218,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.match_qs/index.html
index bfbc7496..27372935 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.match_qs/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.match_qs/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:match_qs(3)
 
@@ -218,6 +218,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.method/index.html
index 1beab4a6..df1d0f74 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.method/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.method/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:method(3)
 
@@ -195,6 +195,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.parse_cookies/index.html
index f5949f9f..927c3d0c 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.parse_cookies/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.parse_cookies/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:parse_cookies(3)
 
@@ -186,6 +186,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.parse_header/index.html
index 7e22192a..bb926a82 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.parse_header/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.parse_header/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:parse_header(3)
 
@@ -378,6 +378,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.parse_qs/index.html
index 3b9970cc..0e6ad1ff 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.parse_qs/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.parse_qs/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:parse_qs(3)
 
@@ -212,6 +212,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.path/index.html
index 0836001b..939b10fc 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.path/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.path/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:path(3)
 
@@ -185,6 +185,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.path_info/index.html
index 03649d9b..4ea06181 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.path_info/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.path_info/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:path_info(3)
 
@@ -182,6 +182,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.peer/index.html
index 634b8e08..528e85c6 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.peer/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.peer/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:peer(3)
 
@@ -191,6 +191,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.port/index.html
index 5864d84a..3415e1ba 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.port/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.port/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:port(3)
 
@@ -185,6 +185,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.push/index.html
index bc56d006..8ed8ad68 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.push/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.push/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:push(3)
 
@@ -236,6 +236,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.qs/index.html
index 62407766..b83daa81 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.qs/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.qs/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:qs(3)
 
@@ -184,6 +184,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.read_body/index.html
index 08b506f0..afe62497 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.read_body/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.read_body/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:read_body(3)
 
@@ -238,6 +238,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.read_part/index.html
index c5b548d3..93f82820 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.read_part/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.read_part/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:read_part(3)
 
@@ -257,6 +257,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.read_part_body/index.html
index 28fe5e6e..afebd5f0 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.read_part_body/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.read_part_body/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:read_part_body(3)
 
@@ -225,6 +225,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.read_urlencoded_body/index.html
index 2fbe784d..87e67a1b 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.read_urlencoded_body/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.read_urlencoded_body/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:read_urlencoded_body(3)
 
@@ -221,6 +221,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.reply/index.html
index 7f1fe714..b8a30a0d 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.reply/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.reply/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:reply(3)
 
@@ -259,6 +259,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.resp_header/index.html
index 0154a3e9..1d651aa0 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.resp_header/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.resp_header/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:resp_header(3)
 
@@ -208,6 +208,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.resp_headers/index.html
index 731ef078..1c9ad4ae 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.resp_headers/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.resp_headers/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:resp_headers(3)
 
@@ -174,6 +174,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.scheme/index.html
index cb8ea3b9..fad56494 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.scheme/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.scheme/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:scheme(3)
 
@@ -184,6 +184,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_body/index.html
index 25b53626..70ddf9d9 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_body/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_body/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:set_resp_body(3)
 
@@ -233,6 +233,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_cookie/index.html
index f77c91e3..8745207c 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_cookie/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_cookie/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:set_resp_cookie(3)
 
@@ -262,6 +262,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_header/index.html
index 6f9d80cf..cc452f4a 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_header/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_header/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:set_resp_header(3)
 
@@ -216,6 +216,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_headers/index.html
index 5a60c156..ebb1b8f6 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_headers/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_headers/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:set_resp_headers(3)
 
@@ -204,6 +204,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.stream_body/index.html
index 1753c362..27db384e 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.stream_body/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.stream_body/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:stream_body(3)
 
@@ -211,6 +211,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.stream_reply/index.html
index a2b9bef1..65fa44c3 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.stream_reply/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.stream_reply/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:stream_reply(3)
 
@@ -243,6 +243,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.uri/index.html
index 98e3e2b2..bc96f18a 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.uri/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.uri/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:uri(3)
 
@@ -272,6 +272,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.version/index.html
index 313b06af..21a6a49e 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req.version/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req.version/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req:version(3)
 
@@ -183,6 +183,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_req/index.html b/docs/en/cowboy/2.0/manual/cowboy_req/index.html
index b04c65d5..0d09edb7 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_req/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_req/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_req(3)
 
@@ -484,6 +484,8 @@ is zero.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_rest/index.html b/docs/en/cowboy/2.0/manual/cowboy_rest/index.html
index cca510c5..3ffa1cd4 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_rest/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_rest/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_rest(3)
 
@@ -736,6 +736,8 @@ accept-language headers when necessary.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.0/manual/cowboy_router.compile/index.html
index 7987500b..808cc716 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_router.compile/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_router.compile/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_router:compile(3)
 
@@ -182,6 +182,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_router/index.html b/docs/en/cowboy/2.0/manual/cowboy_router/index.html
index 3ebdb9e7..1be8f8e7 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_router/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_router/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_router(3)
 
@@ -205,6 +205,8 @@ using the ... syntax.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_static/index.html b/docs/en/cowboy/2.0/manual/cowboy_static/index.html
index 4630aa10..15648c2d 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_static/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_static/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_static(3)
 
@@ -270,6 +270,8 @@ http://www.gnu.org/software/src-highlite -->
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_stream/index.html b/docs/en/cowboy/2.0/manual/cowboy_stream/index.html
index 40d11bcb..6527c30b 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_stream/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_stream/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_stream(3)
 
@@ -506,6 +506,8 @@ tuple.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.0/manual/cowboy_websocket/index.html
index 8903a079..2b8ada8b 100644
--- a/docs/en/cowboy/2.0/manual/cowboy_websocket/index.html
+++ b/docs/en/cowboy/2.0/manual/cowboy_websocket/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: cowboy_websocket(3)
 
@@ -390,6 +390,8 @@ req_filter
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/http_status_codes/index.html b/docs/en/cowboy/2.0/manual/http_status_codes/index.html
index 31b3296d..f2fbc270 100644
--- a/docs/en/cowboy/2.0/manual/http_status_codes/index.html
+++ b/docs/en/cowboy/2.0/manual/http_status_codes/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: HTTP status codes(7)
 
@@ -366,6 +366,8 @@ client and the connection is closed.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.0/manual/index.html b/docs/en/cowboy/2.0/manual/index.html
index d3466672..58588de9 100644
--- a/docs/en/cowboy/2.0/manual/index.html
+++ b/docs/en/cowboy/2.0/manual/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Cowboy Function Reference
 
@@ -266,6 +266,8 @@ environment configuration parameters.
    
 	
 	
 	
+		
  • 2.1
    • 
+	
 		
  • 2.0
    • 
 	
 		
  • 1.0
    • 
diff --git a/docs/en/cowboy/2.1/guide/constraints.asciidoc b/docs/en/cowboy/2.1/guide/constraints.asciidoc
new file mode 100644
index 00000000..6cc10752
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/constraints.asciidoc
@@ -0,0 +1,123 @@
+[[constraints]]
+== Constraints
+
+Constraints are validation and conversion functions applied
+to user input.
+
+They are used in various places in Cowboy, including the
+router and the `cowboy_req` match functions.
+
+=== Syntax
+
+Constraints are provided as a list of fields. For each field
+in the list, specific constraints can be applied, as well as
+a default value if the field is missing.
+
+A field can take the form of an atom `field`, a tuple with
+constraints `{field, Constraints}` or a tuple with constraints
+and a default value `{field, Constraints, Default}`.
+The `field` form indicates the field is mandatory.
+
+Note that when used with the router, only the second form
+makes sense, as it does not use the default and the field
+is always defined.
+
+Constraints for each field are provided as an ordered list
+of atoms or funs to apply. Built-in constraints are provided
+as atoms, while custom constraints are provided as funs.
+
+When multiple constraints are provided, they are applied in
+the order given. If the value has been modified by a constraint
+then the next one receives the new value.
+
+For example, the following constraints will first validate
+and convert the field `my_value` to an integer, and then
+check that the integer is positive:
+
+[source,erlang]
+----
+PositiveFun = fun
+    (_, V) when V > 0 ->
+        {ok, V};
+    (_, _) ->
+        {error, not_positive}
+end,
+{my_value, [int, PositiveFun]}.
+----
+
+We ignore the first fun argument in this snippet. We shouldn't.
+We will simply learn what it is later in this chapter.
+
+When there's only one constraint, it can be provided directly
+without wrapping it into a list:
+
+[source,erlang]
+----
+{my_value, int}
+----
+
+=== Built-in constraints
+
+Built-in constraints are specified as an atom:
+
+[cols="<,<",options="header"]
+|===
+| Constraint | Description
+| int        | Converts binary value to integer.
+| nonempty   | Ensures the binary value is non-empty.
+|===
+
+=== Custom constraints
+
+Custom constraints are specified as a fun. This fun takes
+two arguments. The first argument indicates the operation
+to be performed, and the second is the value. What the
+value is and what must be returned depends on the operation.
+
+Cowboy currently defines three operations. The operation
+used for validating and converting user input is the `forward`
+operation.
+
+[source,erlang]
+----
+int(forward, Value) ->
+    try
+        {ok, binary_to_integer(Value)}
+    catch _:_ ->
+        {error, not_an_integer}
+    end;
+----
+
+The value must be returned even if it is not converted
+by the constraint.
+
+The `reverse` operation does the opposite: it
+takes a converted value and changes it back to what the
+user input would have been.
+
+[source,erlang]
+----
+int(reverse, Value) ->
+	try
+		{ok, integer_to_binary(Value)}
+	catch _:_ ->
+		{error, not_an_integer}
+	end;
+----
+
+Finally, the `format_error` operation takes an error
+returned by any other operation and returns a formatted
+human-readable error message.
+
+[source,erlang]
+----
+int(format_error, {not_an_integer, Value}) ->
+	io_lib:format("The value ~p is not an integer.", [Value]).
+----
+
+Notice that for this case you get both the error and
+the value that was given to the constraint that produced
+this error.
+
+Cowboy will not catch exceptions coming from constraint
+functions. They should be written to not emit any exceptions.
diff --git a/docs/en/cowboy/2.1/guide/constraints/index.html b/docs/en/cowboy/2.1/guide/constraints/index.html
new file mode 100644
index 00000000..a86962fe
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/constraints/index.html
@@ -0,0 +1,298 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Constraints
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Constraints
    
+
+
    Constraints are validation and conversion functions applied
+to user input.
    
+
    They are used in various places in Cowboy, including the
+router and the cowboy_req match functions.
    
+
    
+
    Syntax
    
+
    
+
    Constraints are provided as a list of fields. For each field
+in the list, specific constraints can be applied, as well as
+a default value if the field is missing.
    
+
    A field can take the form of an atom field, a tuple with
+constraints {field, Constraints} or a tuple with constraints
+and a default value {field, Constraints, Default}.
+The field form indicates the field is mandatory.
    
+
    Note that when used with the router, only the second form
+makes sense, as it does not use the default and the field
+is always defined.
    
+
    Constraints for each field are provided as an ordered list
+of atoms or funs to apply. Built-in constraints are provided
+as atoms, while custom constraints are provided as funs.
    
+
    When multiple constraints are provided, they are applied in
+the order given. If the value has been modified by a constraint
+then the next one receives the new value.
    
+
    For example, the following constraints will first validate
+and convert the field my_value to an integer, and then
+check that the integer is positive:
    
+
    
+
    
+
    PositiveFun = fun
+    (_, V) when V > 0 ->
+        {ok, V};
+    (_, _) ->
+        {error, not_positive}
+end,
+{my_value, [int, PositiveFun]}.
    
+
    We ignore the first fun argument in this snippet. We shouldn’t.
+We will simply learn what it is later in this chapter.
    
+
    When there’s only one constraint, it can be provided directly
+without wrapping it into a list:
    
+
    
+
    
+
    {my_value, int}
    
+
    
+
    
+
    
+
    Built-in constraints
    
+
    
+
    Built-in constraints are specified as an atom:
    
+
    
+
+++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    


     Constraint  Description
    int
    Converts binary value to integer.
    nonempty
    Ensures the binary value is non-empty.
    
+
    
+
    
+
    
+
    
+
    Custom constraints
    
+
    
+
    Custom constraints are specified as a fun. This fun takes
+two arguments. The first argument indicates the operation
+to be performed, and the second is the value. What the
+value is and what must be returned depends on the operation.
    
+
    Cowboy currently defines three operations. The operation
+used for validating and converting user input is the forward
+operation.
    
+
    
+
    
+
    int(forward, Value) ->
+    try
+        {ok, binary_to_integer(Value)}
+    catch _:_ ->
+        {error, not_an_integer}
+    end;
    
+
    The value must be returned even if it is not converted
+by the constraint.
    
+
    The reverse operation does the opposite: it
+takes a converted value and changes it back to what the
+user input would have been.
    
+
    
+
    
+
    int(reverse, Value) ->
+        try
+                {ok, integer_to_binary(Value)}
+        catch _:_ ->
+                {error, not_an_integer}
+        end;
    
+
    Finally, the format_error operation takes an error
+returned by any other operation and returns a formatted
+human-readable error message.
    
+
    
+
    
+
    int(format_error, {not_an_integer, Value}) ->
+        io_lib:format("The value ~p is not an integer.", [Value]).
    
+
    Notice that for this case you get both the error and
+the value that was given to the constraint that produced
+this error.
    
+
    Cowboy will not catch exceptions coming from constraint
+functions. They should be written to not emit any exceptions.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/cookies.asciidoc b/docs/en/cowboy/2.1/guide/cookies.asciidoc
new file mode 100644
index 00000000..4825031b
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/cookies.asciidoc
@@ -0,0 +1,139 @@
+[[cookies]]
+== Using cookies
+
+Cookies are a mechanism allowing applications to maintain
+state on top of the stateless HTTP protocol.
+
+Cookies are a name/value store where the names and values are
+stored in plain text. They expire either after a delay
+or when the browser closes. They can be configured on a
+specific domain name or path, and restricted to secure
+resources (sent or downloaded over HTTPS), or restricted
+to the server (disallowing access from client-side scripts).
+
+Cookie names are de facto case sensitive.
+
+Cookies are stored client-side and sent with every subsequent
+request that matches the domain and path for which they were
+stored, until they expire. This can create a non-negligible
+cost.
+
+Cookies should not be considered secure. They are stored on
+the user's computer in plain text, and can be read by any
+program. They can also be read by proxies when using clear
+connections. Always validate the value before using it,
+and never store any sensitive information inside it.
+
+Cookies set by the server are only available in requests
+following the client reception of the response containing
+them.
+
+Cookies may be sent repeatedly. This is often useful to
+update the expiration time and avoid losing a cookie.
+
+=== Setting cookies
+
+By default cookies are defined for the duration of the session:
+
+[source,erlang]
+----
+SessionID = generate_session_id(),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID, Req0).
+----
+
+They can also be set for a duration in seconds:
+
+[source,erlang]
+----
+SessionID = generate_session_id(),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID, Req0,
+    #{max_age => 3600}).
+----
+
+To delete cookies, set `max_age` to 0:
+
+[source,erlang]
+----
+SessionID = generate_session_id(),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID, Req0,
+    #{max_age => 0}).
+----
+
+To restrict cookies to a specific domain and path, the options
+of the same name can be used:
+
+[source,erlang]
+----
+Req = cowboy_req:set_resp_cookie(<<"inaccount">>, <<"1">>, Req0,
+    #{domain => "my.example.org", path => "/account"}).
+----
+
+Cookies will be sent with requests to this domain and all
+its subdomains, and to resources on this path or deeper
+in the path hierarchy.
+
+To restrict cookies to secure channels (typically resources
+available over HTTPS):
+
+[source,erlang]
+----
+SessionID = generate_session_id(),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID, Req0,
+    #{secure => true}).
+----
+
+To prevent client-side scripts from accessing a cookie:
+
+[source,erlang]
+----
+SessionID = generate_session_id(),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID, Req0,
+    #{http_only => true}).
+----
+
+Cookies may also be set client-side, for example using
+Javascript.
+
+=== Reading cookies
+
+The client only ever sends back the cookie name and value.
+All other options that can be set are never sent back.
+
+Cowboy provides two functions for reading cookies. Both
+involve parsing the cookie header(s) and so should not
+be called repeatedly.
+
+You can get all cookies as a key/value list:
+
+[source,erlang]
+Cookies = cowboy_req:parse_cookies(Req),
+{_, Lang} = lists:keyfind(<<"lang">>, 1, Cookies).
+
+Or you can perform a match against cookies and retrieve
+only the ones you need, while at the same time doing
+any required post processing using xref:constraints[constraints].
+This function returns a map:
+
+[source,erlang]
+#{id := ID, lang := Lang} = cowboy_req:match_cookies([id, lang], Req).
+
+You can use constraints to validate the values while matching
+them. The following snippet will crash if the `id` cookie is
+not an integer number or if the `lang` cookie is empty. Additionally
+the `id` cookie value will be converted to an integer term:
+
+[source,erlang]
+CookiesMap = cowboy_req:match_cookies([{id, int}, {lang, nonempty}], Req).
+
+Note that if two cookies share the same name, then the map value
+will be a list of the two cookie values.
+
+A default value can be provided. The default will be used
+if the `lang` cookie is not found. It will not be used if
+the cookie is found but has an empty value:
+
+[source,erlang]
+#{lang := Lang} = cowboy_req:match_cookies([{lang, [], <<"en-US">>}], Req).
+
+If no default is provided and the value is missing, an
+exception is thrown.
diff --git a/docs/en/cowboy/2.1/guide/cookies/index.html b/docs/en/cowboy/2.1/guide/cookies/index.html
new file mode 100644
index 00000000..546e5c57
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/cookies/index.html
@@ -0,0 +1,301 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Using cookies
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Using cookies
    
+
+
    Cookies are a mechanism allowing applications to maintain
+state on top of the stateless HTTP protocol.
    
+
    Cookies are a name/value store where the names and values are
+stored in plain text. They expire either after a delay
+or when the browser closes. They can be configured on a
+specific domain name or path, and restricted to secure
+resources (sent or downloaded over HTTPS), or restricted
+to the server (disallowing access from client-side scripts).
    
+
    Cookie names are de facto case sensitive.
    
+
    Cookies are stored client-side and sent with every subsequent
+request that matches the domain and path for which they were
+stored, until they expire. This can create a non-negligible
+cost.
    
+
    Cookies should not be considered secure. They are stored on
+the user’s computer in plain text, and can be read by any
+program. They can also be read by proxies when using clear
+connections. Always validate the value before using it,
+and never store any sensitive information inside it.
    
+
    Cookies set by the server are only available in requests
+following the client reception of the response containing
+them.
    
+
    Cookies may be sent repeatedly. This is often useful to
+update the expiration time and avoid losing a cookie.
    
+
    
+
    Setting cookies
    
+
    
+
    By default cookies are defined for the duration of the session:
    
+
    
+
    
+
    SessionID = generate_session_id(),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID, Req0).
    
+
    They can also be set for a duration in seconds:
    
+
    
+
    
+
    SessionID = generate_session_id(),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID, Req0,
+    #{max_age => 3600}).
    
+
    To delete cookies, set max_age to 0:
    
+
    
+
    
+
    SessionID = generate_session_id(),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID, Req0,
+    #{max_age => 0}).
    
+
    To restrict cookies to a specific domain and path, the options
+of the same name can be used:
    
+
    
+
    
+
    Req = cowboy_req:set_resp_cookie(<<"inaccount">>, <<"1">>, Req0,
+    #{domain => "my.example.org", path => "/account"}).
    
+
    Cookies will be sent with requests to this domain and all
+its subdomains, and to resources on this path or deeper
+in the path hierarchy.
    
+
    To restrict cookies to secure channels (typically resources
+available over HTTPS):
    
+
    
+
    
+
    SessionID = generate_session_id(),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID, Req0,
+    #{secure => true}).
    
+
    To prevent client-side scripts from accessing a cookie:
    
+
    
+
    
+
    SessionID = generate_session_id(),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID, Req0,
+    #{http_only => true}).
    
+
    Cookies may also be set client-side, for example using
+Javascript.
    
+
    
+
    
+
    
+
    Reading cookies
    
+
    
+
    The client only ever sends back the cookie name and value.
+All other options that can be set are never sent back.
    
+
    Cowboy provides two functions for reading cookies. Both
+involve parsing the cookie header(s) and so should not
+be called repeatedly.
    
+
    You can get all cookies as a key/value list:
    
+
    
+
    
+
    Cookies = cowboy_req:parse_cookies(Req),
+{_, Lang} = lists:keyfind(<<"lang">>, 1, Cookies).
    
+
    Or you can perform a match against cookies and retrieve
+only the ones you need, while at the same time doing
+any required post processing using constraints.
+This function returns a map:
    
+
    
+
    
+
    #{id := ID, lang := Lang} = cowboy_req:match_cookies([id, lang], Req).
    
+
    You can use constraints to validate the values while matching
+them. The following snippet will crash if the id cookie is
+not an integer number or if the lang cookie is empty. Additionally
+the id cookie value will be converted to an integer term:
    
+
    
+
    
+
    CookiesMap = cowboy_req:match_cookies([{id, int}, {lang, nonempty}], Req).
    
+
    Note that if two cookies share the same name, then the map value
+will be a list of the two cookie values.
    
+
    A default value can be provided. The default will be used
+if the lang cookie is not found. It will not be used if
+the cookie is found but has an empty value:
    
+
    
+
    
+
    #{lang := Lang} = cowboy_req:match_cookies([{lang, [], <<"en-US">>}], Req).
    
+
    If no default is provided and the value is missing, an
+exception is thrown.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/cowboy.sty b/docs/en/cowboy/2.1/guide/cowboy.sty
new file mode 100644
index 00000000..d5e0d3be
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/cowboy.sty
@@ -0,0 +1,8 @@
+\NeedsTeXFormat{LaTeX2e}
+\ProvidesPackage{asciidoc-dblatex}[2012/10/24 AsciiDoc DocBook Style]
+
+%% Just use the original package and pass the options.
+\RequirePackageWithOptions{docbook}
+
+%% Define an alias for make snippets to be compatible with source-highlighter.
+\lstalias{makefile}{make}
diff --git a/docs/en/cowboy/2.1/guide/erlang_web.asciidoc b/docs/en/cowboy/2.1/guide/erlang_web.asciidoc
new file mode 100644
index 00000000..f528adc3
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/erlang_web.asciidoc
@@ -0,0 +1,209 @@
+[[erlang_web]]
+== Erlang and the Web
+
+Erlang is the ideal platform for writing Web applications.
+Its features are a perfect match for the requirements of
+modern Web applications.
+
+=== The Web is concurrent
+
+When you access a website there is little concurrency
+involved. A few connections are opened and requests
+are sent through these connections. Then the web page
+is displayed on your screen. Your browser will only
+open up to 4 or 8 connections to the server, depending
+on your settings. This isn't much.
+
+But think about it. You are not the only one accessing
+the server at the same time. There can be hundreds, if
+not thousands, if not millions of connections to the
+same server at the same time.
+
+Even today a lot of systems used in production haven't
+solved the C10K problem (ten thousand concurrent connections).
+And the ones who did are trying hard to get to the next
+step, C100K, and are pretty far from it.
+
+Erlang meanwhile has no problem handling millions of
+connections. At the time of writing there are application
+servers written in Erlang that can handle more than two
+million connections on a single server in a real production
+application, with spare memory and CPU!
+
+The Web is concurrent, and Erlang is a language designed
+for concurrency, so it is a perfect match.
+
+Of course, various platforms need to scale beyond a few
+million connections. This is where Erlang's built-in
+distribution mechanisms come in. If one server isn't
+enough, add more! Erlang allows you to use the same code
+for talking to local processes or to processes in other
+parts of your cluster, which means you can scale very
+quickly if the need arises.
+
+The Web has large userbases, and the Erlang platform was
+designed to work in a distributed setting, so it is a
+perfect match.
+
+Or is it? Surely you can find solutions to handle that many
+concurrent connections with your favorite language... But all
+these solutions will break down in the next few years. Why?
+Firstly because servers don't get any more powerful, they
+instead get a lot more cores and memory. This is only useful
+if your application can use them properly, and Erlang is
+light-years away from anything else in that area. Secondly,
+today your computer and your phone are online, tomorrow your
+watch, goggles, bike, car, fridge and tons of other devices
+will also connect to various applications on the Internet.
+
+Only Erlang is prepared to deal with what's coming.
+
+=== The Web is soft real time
+
+What does soft real time mean, you ask? It means we want the
+operations done as quickly as possible, and in the case of
+web applications, it means we want the data propagated fast.
+
+In comparison, hard real time has a similar meaning, but also
+has a hard time constraint, for example an operation needs to
+be done in under N milliseconds otherwise the system fails
+entirely.
+
+Users aren't that needy yet, they just want to get access
+to their content in a reasonable delay, and they want the
+actions they make to register at most a few seconds after
+they submitted them, otherwise they'll start worrying about
+whether it successfully went through.
+
+The Web is soft real time because taking longer to perform an
+operation would be seen as bad quality of service.
+
+Erlang is a soft real time system. It will always run
+processes fairly, a little at a time, switching to another
+process after a while and preventing a single process to
+steal resources from all others. This means that Erlang
+can guarantee stable low latency of operations.
+
+Erlang provides the guarantees that the soft real time Web
+requires.
+
+=== The Web is asynchronous
+
+Long ago, the Web was synchronous because HTTP was synchronous.
+You fired a request, and then waited for a response. Not anymore.
+It all began when XmlHttpRequest started being used. It allowed
+the client to perform asynchronous calls to the server.
+
+Then Websocket appeared and allowed both the server and the client
+to send data to the other endpoint completely asynchronously. The
+data is contained within frames and no response is necessary.
+
+Erlang processes work the same. They send each other data contained
+within messages and then continue running without needing a response.
+They tend to spend most of their time inactive, waiting for a new
+message, and the Erlang VM happily activate them when one is received.
+
+It is therefore quite easy to imagine Erlang being good at receiving
+Websocket frames, which may come in at unpredictable times, pass the
+data to the responsible processes which are always ready waiting for
+new messages, and perform the operations required by only activating
+the required parts of the system.
+
+The more recent Web technologies, like Websocket of course, but also
+HTTP/2.0, are all fully asynchronous protocols. The concept
+of requests and responses is retained of course, but anything could
+be sent in between, by both the client or the browser, and the
+responses could also be received in a completely different order.
+
+Erlang is by nature asynchronous and really good at it thanks to the
+great engineering that has been done in the VM over the years. It's
+only natural that it's so good at dealing with the asynchronous Web.
+
+=== The Web is omnipresent
+
+The Web has taken a very important part of our lives. We're
+connected at all times, when we're on our phone, using our computer,
+passing time using a tablet while in the bathroom... And this
+isn't going to slow down, every single device at home or on us
+will be connected.
+
+All these devices are always connected. And with the number of
+alternatives to give you access to the content you seek, users
+tend to not stick around when problems arise. Users today want
+their applications to be always available and if it's having
+too many issues they just move on.
+
+Despite this, when developers choose a product to use for building
+web applications, their only concern seems to be "Is it fast?",
+and they look around for synthetic benchmarks showing which one
+is the fastest at sending "Hello world" with only a handful
+concurrent connections. Web benchmarks haven't been representative
+of reality in a long time, and are drifting further away as
+time goes on.
+
+What developers should really ask themselves is "Can I service
+all my users with no interruption?" and they'd find that they have
+two choices. They can either hope for the best, or they can use
+Erlang.
+
+Erlang is built for fault tolerance. When writing code in any other
+language, you have to check all the return values and act accordingly
+to avoid any unforeseen issues. If you're lucky, you won't miss
+anything important. When writing Erlang code, you can just check
+the success condition and ignore all errors. If an error happens,
+the Erlang process crashes and is then restarted by a special
+process called a supervisor.
+
+Erlang developers thus have no need to fear unhandled
+errors, and can focus on handling only the errors that should
+give some feedback to the user and let the system take care of
+the rest. This also has the advantage of allowing them to write
+a lot less code, and let them sleep at night.
+
+Erlang's fault tolerance oriented design is the first piece of
+what makes it the best choice for the omnipresent, always available
+Web.
+
+The second piece is Erlang's built-in distribution. Distribution
+is a key part of building a fault tolerant system, because it
+allows you to handle bigger failures, like a whole server going
+down, or even a data center entirely.
+
+Fault tolerance and distribution are important today, and will be
+vital in the future of the Web. Erlang is ready.
+
+=== Learn Erlang
+
+If you are new to Erlang, you may want to grab a book or
+two to get started. Those are my recommendations as the
+author of Cowboy.
+
+==== The Erlanger Playbook
+
+The Erlanger Playbook is an ebook I am currently writing,
+which covers a number of different topics from code to
+documentation to testing Erlang applications. It also has
+an Erlang section where it covers directly the building
+blocks and patterns, rather than details like the syntax.
+
+You can most likely read it as a complete beginner, but
+you will need a companion book to make the most of it.
+Buy it from the https://ninenines.eu[Nine Nines website].
+
+==== Programming Erlang
+
+This book is from one of the creator of Erlang, Joe
+Armstrong. It provides a very good explanation of what
+Erlang is and why it is so. It serves as a very good
+introduction to the language and platform.
+
+The book is http://pragprog.com/book/jaerlang2/programming-erlang[Programming Erlang],
+and it also features a chapter on Cowboy.
+
+==== Learn You Some Erlang for Great Good!
+
+http://learnyousomeerlang.com[LYSE] is a much more complete
+book covering many aspects of Erlang, while also providing
+stories and humor. Be warned: it's pretty verbose. It comes
+with a free online version and a more refined paper and
+ebook version.
diff --git a/docs/en/cowboy/2.1/guide/erlang_web/index.html b/docs/en/cowboy/2.1/guide/erlang_web/index.html
new file mode 100644
index 00000000..b9200713
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/erlang_web/index.html
@@ -0,0 +1,351 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Erlang and the Web
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Erlang and the Web
    
+
+
    Erlang is the ideal platform for writing Web applications.
+Its features are a perfect match for the requirements of
+modern Web applications.
    
+
    
+
    The Web is concurrent
    
+
    
+
    When you access a website there is little concurrency
+involved. A few connections are opened and requests
+are sent through these connections. Then the web page
+is displayed on your screen. Your browser will only
+open up to 4 or 8 connections to the server, depending
+on your settings. This isn’t much.
    
+
    But think about it. You are not the only one accessing
+the server at the same time. There can be hundreds, if
+not thousands, if not millions of connections to the
+same server at the same time.
    
+
    Even today a lot of systems used in production haven’t
+solved the C10K problem (ten thousand concurrent connections).
+And the ones who did are trying hard to get to the next
+step, C100K, and are pretty far from it.
    
+
    Erlang meanwhile has no problem handling millions of
+connections. At the time of writing there are application
+servers written in Erlang that can handle more than two
+million connections on a single server in a real production
+application, with spare memory and CPU!
    
+
    The Web is concurrent, and Erlang is a language designed
+for concurrency, so it is a perfect match.
    
+
    Of course, various platforms need to scale beyond a few
+million connections. This is where Erlang’s built-in
+distribution mechanisms come in. If one server isn’t
+enough, add more! Erlang allows you to use the same code
+for talking to local processes or to processes in other
+parts of your cluster, which means you can scale very
+quickly if the need arises.
    
+
    The Web has large userbases, and the Erlang platform was
+designed to work in a distributed setting, so it is a
+perfect match.
    
+
    Or is it? Surely you can find solutions to handle that many
+concurrent connections with your favorite language… But all
+these solutions will break down in the next few years. Why?
+Firstly because servers don’t get any more powerful, they
+instead get a lot more cores and memory. This is only useful
+if your application can use them properly, and Erlang is
+light-years away from anything else in that area. Secondly,
+today your computer and your phone are online, tomorrow your
+watch, goggles, bike, car, fridge and tons of other devices
+will also connect to various applications on the Internet.
    
+
    Only Erlang is prepared to deal with what’s coming.
    
+
    
+
    
+
    
+
    The Web is soft real time
    
+
    
+
    What does soft real time mean, you ask? It means we want the
+operations done as quickly as possible, and in the case of
+web applications, it means we want the data propagated fast.
    
+
    In comparison, hard real time has a similar meaning, but also
+has a hard time constraint, for example an operation needs to
+be done in under N milliseconds otherwise the system fails
+entirely.
    
+
    Users aren’t that needy yet, they just want to get access
+to their content in a reasonable delay, and they want the
+actions they make to register at most a few seconds after
+they submitted them, otherwise they’ll start worrying about
+whether it successfully went through.
    
+
    The Web is soft real time because taking longer to perform an
+operation would be seen as bad quality of service.
    
+
    Erlang is a soft real time system. It will always run
+processes fairly, a little at a time, switching to another
+process after a while and preventing a single process to
+steal resources from all others. This means that Erlang
+can guarantee stable low latency of operations.
    
+
    Erlang provides the guarantees that the soft real time Web
+requires.
    
+
    
+
    
+
    
+
    The Web is asynchronous
    
+
    
+
    Long ago, the Web was synchronous because HTTP was synchronous.
+You fired a request, and then waited for a response. Not anymore.
+It all began when XmlHttpRequest started being used. It allowed
+the client to perform asynchronous calls to the server.
    
+
    Then Websocket appeared and allowed both the server and the client
+to send data to the other endpoint completely asynchronously. The
+data is contained within frames and no response is necessary.
    
+
    Erlang processes work the same. They send each other data contained
+within messages and then continue running without needing a response.
+They tend to spend most of their time inactive, waiting for a new
+message, and the Erlang VM happily activate them when one is received.
    
+
    It is therefore quite easy to imagine Erlang being good at receiving
+Websocket frames, which may come in at unpredictable times, pass the
+data to the responsible processes which are always ready waiting for
+new messages, and perform the operations required by only activating
+the required parts of the system.
    
+
    The more recent Web technologies, like Websocket of course, but also
+HTTP/2.0, are all fully asynchronous protocols. The concept
+of requests and responses is retained of course, but anything could
+be sent in between, by both the client or the browser, and the
+responses could also be received in a completely different order.
    
+
    Erlang is by nature asynchronous and really good at it thanks to the
+great engineering that has been done in the VM over the years. It’s
+only natural that it’s so good at dealing with the asynchronous Web.
    
+
    
+
    
+
    
+
    The Web is omnipresent
    
+
    
+
    The Web has taken a very important part of our lives. We’re
+connected at all times, when we’re on our phone, using our computer,
+passing time using a tablet while in the bathroom… And this
+isn’t going to slow down, every single device at home or on us
+will be connected.
    
+
    All these devices are always connected. And with the number of
+alternatives to give you access to the content you seek, users
+tend to not stick around when problems arise. Users today want
+their applications to be always available and if it’s having
+too many issues they just move on.
    
+
    Despite this, when developers choose a product to use for building
+web applications, their only concern seems to be "Is it fast?",
+and they look around for synthetic benchmarks showing which one
+is the fastest at sending "Hello world" with only a handful
+concurrent connections. Web benchmarks haven’t been representative
+of reality in a long time, and are drifting further away as
+time goes on.
    
+
    What developers should really ask themselves is "Can I service
+all my users with no interruption?" and they’d find that they have
+two choices. They can either hope for the best, or they can use
+Erlang.
    
+
    Erlang is built for fault tolerance. When writing code in any other
+language, you have to check all the return values and act accordingly
+to avoid any unforeseen issues. If you’re lucky, you won’t miss
+anything important. When writing Erlang code, you can just check
+the success condition and ignore all errors. If an error happens,
+the Erlang process crashes and is then restarted by a special
+process called a supervisor.
    
+
    Erlang developers thus have no need to fear unhandled
+errors, and can focus on handling only the errors that should
+give some feedback to the user and let the system take care of
+the rest. This also has the advantage of allowing them to write
+a lot less code, and let them sleep at night.
    
+
    Erlang’s fault tolerance oriented design is the first piece of
+what makes it the best choice for the omnipresent, always available
+Web.
    
+
    The second piece is Erlang’s built-in distribution. Distribution
+is a key part of building a fault tolerant system, because it
+allows you to handle bigger failures, like a whole server going
+down, or even a data center entirely.
    
+
    Fault tolerance and distribution are important today, and will be
+vital in the future of the Web. Erlang is ready.
    
+
    
+
    
+
    
+
    Learn Erlang
    
+
    
+
    If you are new to Erlang, you may want to grab a book or
+two to get started. Those are my recommendations as the
+author of Cowboy.
    
+
    
+
    The Erlanger Playbook
    
+
    The Erlanger Playbook is an ebook I am currently writing,
+which covers a number of different topics from code to
+documentation to testing Erlang applications. It also has
+an Erlang section where it covers directly the building
+blocks and patterns, rather than details like the syntax.
    
+
    You can most likely read it as a complete beginner, but
+you will need a companion book to make the most of it.
+Buy it from the Nine Nines website.
    
+
    
+
    
+
    Programming Erlang
    
+
    This book is from one of the creator of Erlang, Joe
+Armstrong. It provides a very good explanation of what
+Erlang is and why it is so. It serves as a very good
+introduction to the language and platform.
    
+
    The book is Programming Erlang,
+and it also features a chapter on Cowboy.
    
+
    
+
    
+
    Learn You Some Erlang for Great Good!
    
+
    LYSE is a much more complete
+book covering many aspects of Erlang, while also providing
+stories and humor. Be warned: it’s pretty verbose. It comes
+with a free online version and a more refined paper and
+ebook version.
    
+
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/flow_diagram.asciidoc b/docs/en/cowboy/2.1/guide/flow_diagram.asciidoc
new file mode 100644
index 00000000..2d35d4d6
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/flow_diagram.asciidoc
@@ -0,0 +1,109 @@
+[[flow_diagram]]
+== Flow diagram
+
+Cowboy is a lightweight HTTP server with support for HTTP/1.1,
+HTTP/2 and Websocket.
+
+It is built on top of Ranch. Please see the Ranch guide for more
+information about how the network connections are handled.
+
+=== Overview
+
+image::http_req_resp.png[HTTP request/response flowchart]
+
+As you can see on the diagram, the client
+begins by connecting to the server. This step is handled
+by a Ranch acceptor, which is a process dedicated to
+accepting new connections.
+
+After Ranch accepts a new connection, whether it is an
+HTTP/1.1 or HTTP/2 connection, Cowboy starts receiving
+requests and handling them.
+
+In HTTP/1.1 all requests come sequentially. In HTTP/2
+the requests may arrive and be processed concurrently.
+
+When a request comes in, Cowboy creates a stream, which
+is a set of request/response and all the events associated
+with them. The protocol code in Cowboy defers the handling
+of these streams to stream handler modules. When you
+configure Cowboy you may define one or more module that
+will receive all events associated with a stream, including
+the request, response, bodies, Erlang messages and more.
+
+By default Cowboy comes configured with a stream handler
+called `cowboy_stream_h`. This stream handler will create
+a new process for every request coming in, and then
+communicate with this process to read the body or send
+a response back. The request process executes middlewares
+which, by default, including the router and then the
+execution of handlers. Like stream handlers, middlewares
+may also be customized.
+
+A response may be sent at almost any point in this
+diagram. If the response must be sent before the stream
+is initialized (because an error occurred early, for
+example) then stream handlers receive a special event
+indicating this error.
+
+=== Protocol-specific headers
+
+Cowboy takes care of protocol-specific headers and prevents
+you from sending them manually. For HTTP/1.1 this includes
+the `transfer-encoding` and `connection` headers. For HTTP/2
+this includes the colon headers like `:status`.
+
+Cowboy will also remove protocol-specific headers from
+requests before passing them to stream handlers. Cowboy
+tries to hide the implementation details of all protocols
+as well as possible.
+
+=== Number of processes per connection
+
+By default, Cowboy will use one process per connection,
+plus one process per set of request/response (called a
+stream, internally).
+
+The reason it creates a new process for every request is due
+to the requirements of HTTP/2 where requests are executed
+concurrently and independently from the connection. The
+frames from the different requests end up interleaved on
+the single TCP connection.
+
+The request processes are never reused. There is therefore
+no need to perform any cleanup after the response has been
+sent. The process will terminate and Erlang/OTP will reclaim
+all memory at once.
+
+Cowboy ultimately does not require more than one process
+per connection. It is possible to interact with the connection
+directly from a stream handler, a low level interface to Cowboy.
+They are executed from within the connection process, and can
+handle the incoming requests and send responses. This is however
+not recommended in normal circumstances, as a stream handler
+taking too long to execute could have a negative impact on
+concurrent requests or the state of the connection itself.
+
+=== Date header
+
+Because querying for the current date and time can be expensive,
+Cowboy generates one 'Date' header value every second, shares it
+to all other processes, which then simply copy it in the response.
+This allows compliance with HTTP/1.1 with no actual performance loss.
+
+=== Binaries
+
+Cowboy makes extensive use of binaries.
+
+Binaries are more efficient than lists for representing
+strings because they take less memory space. Processing
+performance can vary depending on the operation. Binaries
+are known for generally getting a great boost if the code
+is compiled natively. Please see the HiPE documentation
+for more details.
+
+Binaries may end up being shared between processes. This
+can lead to some large memory usage when one process keeps
+the binary data around forever without freeing it. If you
+see some weird memory usage in your application, this might
+be the cause.
diff --git a/docs/en/cowboy/2.1/guide/flow_diagram/index.html b/docs/en/cowboy/2.1/guide/flow_diagram/index.html
new file mode 100644
index 00000000..8e2f5522
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/flow_diagram/index.html
@@ -0,0 +1,270 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Flow diagram
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Flow diagram
    
+
+
    Cowboy is a lightweight HTTP server with support for HTTP/1.1,
+HTTP/2 and Websocket.
    
+
    It is built on top of Ranch. Please see the Ranch guide for more
+information about how the network connections are handled.
    
+
    
+
    Overview
    
+
    
+
    
+
    
+HTTP request/response flowchart
+
    
+
    
+
    As you can see on the diagram, the client
+begins by connecting to the server. This step is handled
+by a Ranch acceptor, which is a process dedicated to
+accepting new connections.
    
+
    After Ranch accepts a new connection, whether it is an
+HTTP/1.1 or HTTP/2 connection, Cowboy starts receiving
+requests and handling them.
    
+
    In HTTP/1.1 all requests come sequentially. In HTTP/2
+the requests may arrive and be processed concurrently.
    
+
    When a request comes in, Cowboy creates a stream, which
+is a set of request/response and all the events associated
+with them. The protocol code in Cowboy defers the handling
+of these streams to stream handler modules. When you
+configure Cowboy you may define one or more module that
+will receive all events associated with a stream, including
+the request, response, bodies, Erlang messages and more.
    
+
    By default Cowboy comes configured with a stream handler
+called cowboy_stream_h. This stream handler will create
+a new process for every request coming in, and then
+communicate with this process to read the body or send
+a response back. The request process executes middlewares
+which, by default, including the router and then the
+execution of handlers. Like stream handlers, middlewares
+may also be customized.
    
+
    A response may be sent at almost any point in this
+diagram. If the response must be sent before the stream
+is initialized (because an error occurred early, for
+example) then stream handlers receive a special event
+indicating this error.
    
+
    
+
    
+
    
+
    Protocol-specific headers
    
+
    
+
    Cowboy takes care of protocol-specific headers and prevents
+you from sending them manually. For HTTP/1.1 this includes
+the transfer-encoding and connection headers. For HTTP/2
+this includes the colon headers like :status.
    
+
    Cowboy will also remove protocol-specific headers from
+requests before passing them to stream handlers. Cowboy
+tries to hide the implementation details of all protocols
+as well as possible.
    
+
    
+
    
+
    
+
    Number of processes per connection
    
+
    
+
    By default, Cowboy will use one process per connection,
+plus one process per set of request/response (called a
+stream, internally).
    
+
    The reason it creates a new process for every request is due
+to the requirements of HTTP/2 where requests are executed
+concurrently and independently from the connection. The
+frames from the different requests end up interleaved on
+the single TCP connection.
    
+
    The request processes are never reused. There is therefore
+no need to perform any cleanup after the response has been
+sent. The process will terminate and Erlang/OTP will reclaim
+all memory at once.
    
+
    Cowboy ultimately does not require more than one process
+per connection. It is possible to interact with the connection
+directly from a stream handler, a low level interface to Cowboy.
+They are executed from within the connection process, and can
+handle the incoming requests and send responses. This is however
+not recommended in normal circumstances, as a stream handler
+taking too long to execute could have a negative impact on
+concurrent requests or the state of the connection itself.
    
+
    
+
    
+
    
+
    Date header
    
+
    
+
    Because querying for the current date and time can be expensive,
+Cowboy generates one Date header value every second, shares it
+to all other processes, which then simply copy it in the response.
+This allows compliance with HTTP/1.1 with no actual performance loss.
    
+
    
+
    
+
    
+
    Binaries
    
+
    
+
    Cowboy makes extensive use of binaries.
    
+
    Binaries are more efficient than lists for representing
+strings because they take less memory space. Processing
+performance can vary depending on the operation. Binaries
+are known for generally getting a great boost if the code
+is compiled natively. Please see the HiPE documentation
+for more details.
    
+
    Binaries may end up being shared between processes. This
+can lead to some large memory usage when one process keeps
+the binary data around forever without freeing it. If you
+see some weird memory usage in your application, this might
+be the cause.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/getting_started.asciidoc b/docs/en/cowboy/2.1/guide/getting_started.asciidoc
new file mode 100644
index 00000000..3f145bb8
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/getting_started.asciidoc
@@ -0,0 +1,147 @@
+[[getting_started]]
+== Getting started
+
+Erlang is more than a language, it is also an operating system
+for your applications. Erlang developers rarely write standalone
+modules, they write libraries or applications, and then bundle
+those into what is called a release. A release contains the
+Erlang VM plus all applications required to run the node, so
+it can be pushed to production directly.
+
+This chapter walks you through all the steps of setting up
+Cowboy, writing your first application and generating your first
+release. At the end of this chapter you should know everything
+you need to push your first Cowboy application to production.
+
+=== Prerequisites
+
+We are going to use the https://github.com/ninenines/erlang.mk[Erlang.mk]
+build system. If you are using Windows, please check the
+http://erlang.mk/guide/installation.html[Installation instructions]
+to get your environment setup before you continue.
+
+=== Bootstrap
+
+First, let's create the directory for our application.
+
+[source,bash]
+$ mkdir hello_erlang
+$ cd hello_erlang
+
+Then we need to download Erlang.mk. Either use the following
+command or download it manually.
+
+[source,bash]
+$ wget https://erlang.mk/erlang.mk
+
+We can now bootstrap our application. Since we are going to generate
+a release, we will also bootstrap it at the same time.
+
+[source,bash]
+$ make -f erlang.mk bootstrap bootstrap-rel
+
+This creates a Makefile, a base application, and the release files
+necessary for creating the release. We can already build and start
+this release.
+
+[source,bash]
+----
+$ make run
+...
+(hello_erlang@127.0.0.1)1>
+----
+
+Entering the command `i().` will show the running processes, including
+one called `hello_erlang_sup`. This is the supervisor for our
+application.
+
+The release currently does nothing. In the rest of this chapter we
+will add Cowboy as a dependency and write a simple "Hello world!"
+handler.
+
+=== Cowboy setup
+
+We will modify the 'Makefile' to tell the build system it needs to
+fetch and compile Cowboy:
+
+[source,makefile]
+----
+PROJECT = hello_erlang
+
+DEPS = cowboy
+dep_cowboy_commit = 2.1.0
+
+DEP_PLUGINS = cowboy
+
+include erlang.mk
+----
+
+We also tell the build system to load the plugins Cowboy provides.
+These include predefined templates that we will use soon.
+
+If you do `make run` now, Cowboy will be included in the release
+and started automatically. This is not enough however, as Cowboy
+doesn't do anything by default. We still need to tell Cowboy to
+listen for connections.
+
+=== Listening for connections
+
+First we define the routes that Cowboy will use to map requests
+to handler modules, and then we start the listener. This is best
+done at application startup.
+
+Open the 'src/hello_erlang_app.erl' file and add the necessary
+code to the `start/2` function to make it look like this:
+
+[source,erlang]
+----
+start(_Type, _Args) ->
+    Dispatch = cowboy_router:compile([
+        {'_', [{"/", hello_handler, []}]}
+    ]),
+    {ok, _} = cowboy:start_clear(my_http_listener,
+        [{port, 8080}],
+        #{env => #{dispatch => Dispatch}}
+    ),
+    hello_erlang_sup:start_link().
+----
+
+Routes are explained in details in the xref:routing[Routing]
+chapter. For this tutorial we map the path `/` to the handler
+module `hello_handler`. This module doesn't exist yet.
+
+Build and start the release, then open http://localhost:8080
+in your browser. You will get a 500 error because the module is missing.
+Any other URL, like http://localhost:8080/test, will result in a
+404 error.
+
+=== Handling requests
+
+Cowboy features different kinds of handlers, including REST
+and Websocket handlers. For this tutorial we will use a plain
+HTTP handler.
+
+Generate a handler from a template:
+
+[source,bash]
+$ make new t=cowboy.http n=hello_handler
+
+Then, open the 'src/hello_handler.erl' file and modify
+the `init/2` function like this to send a reply.
+
+[source,erlang]
+----
+init(Req0, State) ->
+    Req = cowboy_req:reply(200,
+        #{<<"content-type">> => <<"text/plain">>},
+        <<"Hello Erlang!">>,
+        Req0),
+    {ok, Req, State}.
+----
+
+What the above code does is send a 200 OK reply, with the
+Content-type header set to `text/plain` and the response
+body set to `Hello Erlang!`.
+
+If you run the release and open http://localhost:8080
+in your browser, you should get a nice `Hello Erlang!` displayed!
diff --git a/docs/en/cowboy/2.1/guide/getting_started/index.html b/docs/en/cowboy/2.1/guide/getting_started/index.html
new file mode 100644
index 00000000..8ebd8629
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/getting_started/index.html
@@ -0,0 +1,318 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Getting started
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Getting started
    
+
+
    Erlang is more than a language, it is also an operating system
+for your applications. Erlang developers rarely write standalone
+modules, they write libraries or applications, and then bundle
+those into what is called a release. A release contains the
+Erlang VM plus all applications required to run the node, so
+it can be pushed to production directly.
    
+
    This chapter walks you through all the steps of setting up
+Cowboy, writing your first application and generating your first
+release. At the end of this chapter you should know everything
+you need to push your first Cowboy application to production.
    
+
    
+
    Prerequisites
    
+
    
+
    We are going to use the Erlang.mk
+build system. If you are using Windows, please check the
+Installation instructions
+to get your environment setup before you continue.
    
+
    
+
    
+
    
+
    Bootstrap
    
+
    
+
    First, let’s create the directory for our application.
    
+
    
+
    
+
    $ mkdir hello_erlang
+$ cd hello_erlang
    
+
    Then we need to download Erlang.mk. Either use the following
+command or download it manually.
    
+
    
+
    
+
    $ wget https://erlang.mk/erlang.mk
    
+
    We can now bootstrap our application. Since we are going to generate
+a release, we will also bootstrap it at the same time.
    
+
    
+
    
+
    $ make -f erlang.mk bootstrap bootstrap-rel
    
+
    This creates a Makefile, a base application, and the release files
+necessary for creating the release. We can already build and start
+this release.
    
+
    
+
    
+
    $ make run
+...
+(hello_erlang@127.0.0.1)1>
    
+
    Entering the command i(). will show the running processes, including
+one called hello_erlang_sup. This is the supervisor for our
+application.
    
+
    The release currently does nothing. In the rest of this chapter we
+will add Cowboy as a dependency and write a simple "Hello world!"
+handler.
    
+
    
+
    
+
    
+
    Cowboy setup
    
+
    
+
    We will modify the Makefile to tell the build system it needs to
+fetch and compile Cowboy:
    
+
    
+
    
+
    PROJECT = hello_erlang
+
+DEPS = cowboy
+dep_cowboy_commit = 2.1.0
+
+DEP_PLUGINS = cowboy
+
+include erlang.mk
    
+
    We also tell the build system to load the plugins Cowboy provides.
+These include predefined templates that we will use soon.
    
+
    If you do make run now, Cowboy will be included in the release
+and started automatically. This is not enough however, as Cowboy
+doesn’t do anything by default. We still need to tell Cowboy to
+listen for connections.
    
+
    
+
    
+
    
+
    Listening for connections
    
+
    
+
    First we define the routes that Cowboy will use to map requests
+to handler modules, and then we start the listener. This is best
+done at application startup.
    
+
    Open the src/hello_erlang_app.erl file and add the necessary
+code to the start/2 function to make it look like this:
    
+
    
+
    
+
    start(_Type, _Args) ->
+    Dispatch = cowboy_router:compile([
+        {'_', [{"/", hello_handler, []}]}
+    ]),
+    {ok, _} = cowboy:start_clear(my_http_listener,
+        [{port, 8080}],
+        #{env => #{dispatch => Dispatch}}
+    ),
+    hello_erlang_sup:start_link().
    
+
    Routes are explained in details in the Routing
+chapter. For this tutorial we map the path / to the handler
+module hello_handler. This module doesn’t exist yet.
    
+
    Build and start the release, then open http://localhost:8080
+in your browser. You will get a 500 error because the module is missing.
+Any other URL, like http://localhost:8080/test, will result in a
+404 error.
    
+
    
+
    
+
    
+
    Handling requests
    
+
    
+
    Cowboy features different kinds of handlers, including REST
+and Websocket handlers. For this tutorial we will use a plain
+HTTP handler.
    
+
    Generate a handler from a template:
    
+
    
+
    
+
    $ make new t=cowboy.http n=hello_handler
    
+
    Then, open the src/hello_handler.erl file and modify
+the init/2 function like this to send a reply.
    
+
    
+
    
+
    init(Req0, State) ->
+    Req = cowboy_req:reply(200,
+        #{<<"content-type">> => <<"text/plain">>},
+        <<"Hello Erlang!">>,
+        Req0),
+    {ok, Req, State}.
    
+
    What the above code does is send a 200 OK reply, with the
+Content-type header set to text/plain and the response
+body set to Hello Erlang!.
    
+
    If you run the release and open http://localhost:8080
+in your browser, you should get a nice Hello Erlang! displayed!
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/handlers.asciidoc b/docs/en/cowboy/2.1/guide/handlers.asciidoc
new file mode 100644
index 00000000..fe6f4623
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/handlers.asciidoc
@@ -0,0 +1,90 @@
+[[handlers]]
+== Handlers
+
+Handlers are Erlang modules that handle HTTP requests.
+
+=== Plain HTTP handlers
+
+The most basic handler in Cowboy implements the mandatory
+`init/2` callback, manipulates the request, optionally
+sends a response and then returns.
+
+This callback receives the xref:req[Req object] and the initial
+state defined in the xref:routing[router configuration].
+
+A handler that does nothing would look like this:
+
+[source,erlang]
+----
+init(Req, State) ->
+    {ok, Req, State}.
+----
+
+Despite sending no reply, a `204 No Content` response will be
+sent to the client, as Cowboy makes sure that a response is
+sent for every request.
+
+We need to use the Req object to reply.
+
+[source,erlang]
+----
+init(Req0, State) ->
+    Req = cowboy_req:reply(200, #{
+        <<"content-type">> => <<"text/plain">>
+    }, <<"Hello World!">>, Req0),
+    {ok, Req, State}.
+----
+
+Cowboy will immediately send a response when `cowboy:reply/4`
+is called.
+
+We then return a 3-tuple. `ok` means that the handler ran
+successfully. We also give the modified Req back to Cowboy.
+
+The last value of the tuple is a state that will be used
+in every subsequent callbacks to this handler. Plain HTTP
+handlers only have one additional callback, the optional
+and rarely used `terminate/3`.
+
+=== Other handlers
+
+The `init/2` callback can also be used to inform Cowboy
+that this is a different kind of handler and that Cowboy
+should switch to it. To do this you simply need to return
+the module name of the handler type you want to switch to.
+
+Cowboy comes with three handler types you can switch to:
+xref:rest_handlers[cowboy_rest], xref:ws_handlers[cowboy_websocket]
+and xref:loop_handlers[cowboy_loop]. In addition to those you
+can define your own handler types.
+
+Switching is simple. Instead of returning `ok`, you simply
+return the name of the handler type you want to use. The
+following snippet switches to a Websocket handler:
+
+[source,erlang]
+----
+init(Req, State) ->
+    {cowboy_websocket, Req, State}.
+----
+
+=== Cleaning up
+
+All handler types provide the optional `terminate/3` callback.
+
+[source,erlang]
+----
+terminate(_Reason, _Req, _State) ->
+    ok.
+----
+
+This callback is strictly reserved for any required cleanup.
+You cannot send a response from this function. There is no
+other return value.
+
+This callback is optional because it is rarely necessary.
+Cleanup should be done in separate processes directly (by
+monitoring the handler process to detect when it exits).
+
+Cowboy does not reuse processes for different requests. The
+process will terminate soon after this call returns.
diff --git a/docs/en/cowboy/2.1/guide/handlers/index.html b/docs/en/cowboy/2.1/guide/handlers/index.html
new file mode 100644
index 00000000..9d4b1bf3
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/handlers/index.html
@@ -0,0 +1,248 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Handlers
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Handlers
    
+
+
    Handlers are Erlang modules that handle HTTP requests.
    
+
    
+
    Plain HTTP handlers
    
+
    
+
    The most basic handler in Cowboy implements the mandatory
+init/2 callback, manipulates the request, optionally
+sends a response and then returns.
    
+
    This callback receives the Req object and the initial
+state defined in the router configuration.
    
+
    A handler that does nothing would look like this:
    
+
    
+
    
+
    init(Req, State) ->
+    {ok, Req, State}.
    
+
    Despite sending no reply, a 204 No Content response will be
+sent to the client, as Cowboy makes sure that a response is
+sent for every request.
    
+
    We need to use the Req object to reply.
    
+
    
+
    
+
    init(Req0, State) ->
+    Req = cowboy_req:reply(200, #{
+        <<"content-type">> => <<"text/plain">>
+    }, <<"Hello World!">>, Req0),
+    {ok, Req, State}.
    
+
    Cowboy will immediately send a response when cowboy:reply/4
+is called.
    
+
    We then return a 3-tuple. ok means that the handler ran
+successfully. We also give the modified Req back to Cowboy.
    
+
    The last value of the tuple is a state that will be used
+in every subsequent callbacks to this handler. Plain HTTP
+handlers only have one additional callback, the optional
+and rarely used terminate/3.
    
+
    
+
    
+
    
+
    Other handlers
    
+
    
+
    The init/2 callback can also be used to inform Cowboy
+that this is a different kind of handler and that Cowboy
+should switch to it. To do this you simply need to return
+the module name of the handler type you want to switch to.
    
+
    Cowboy comes with three handler types you can switch to:
+cowboy_rest, cowboy_websocket
+and cowboy_loop. In addition to those you
+can define your own handler types.
    
+
    Switching is simple. Instead of returning ok, you simply
+return the name of the handler type you want to use. The
+following snippet switches to a Websocket handler:
    
+
    
+
    
+
    init(Req, State) ->
+    {cowboy_websocket, Req, State}.
    
+
    
+
    
+
    
+
    Cleaning up
    
+
    
+
    All handler types provide the optional terminate/3 callback.
    
+
    
+
    
+
    terminate(_Reason, _Req, _State) ->
+    ok.
    
+
    This callback is strictly reserved for any required cleanup.
+You cannot send a response from this function. There is no
+other return value.
    
+
    This callback is optional because it is rarely necessary.
+Cleanup should be done in separate processes directly (by
+monitoring the handler process to detect when it exits).
    
+
    Cowboy does not reuse processes for different requests. The
+process will terminate soon after this call returns.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/http_req_resp.png b/docs/en/cowboy/2.1/guide/http_req_resp.png
new file mode 100644
index 00000000..41c17c8a
Binary files /dev/null and b/docs/en/cowboy/2.1/guide/http_req_resp.png differ
diff --git a/docs/en/cowboy/2.1/guide/http_req_resp.svg b/docs/en/cowboy/2.1/guide/http_req_resp.svg
new file mode 100644
index 00000000..acedb152
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/http_req_resp.svg
@@ -0,0 +1,543 @@
+
+
+
+
+  
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+    
+  
+  
+    
+  
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    some text
+    
+      
+      
+        acceptor
+      
+    
+    
+      
+      protocol
+    
+    
+      
+      router
+    
+    some text
+    
+      
+      handler
+    
+    middlewares
+    some text
+    
+      
+      client
+    
+    
+      
+      stream
+    
+  
+
diff --git a/docs/en/cowboy/2.1/guide/index.html b/docs/en/cowboy/2.1/guide/index.html
new file mode 100644
index 00000000..b5af3291
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/index.html
@@ -0,0 +1,339 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Cowboy User Guide
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Cowboy User Guide
    
+
+
    
+
    Rationale
    
+
    
+
    
+
    
+
    
+
    
+
    Introduction
    
+
    
+
    
+
    
+
    
+
    
+
    Configuration
    
+
    
+
    
+
    
+
    
+
    
+
    Handlers
    
+
    
+
    
+
    
+
    
+
    
+
    Request and response
    
+
    
+
    
+
    
+
    
+
    
+
    REST
    
+
    
+
    
+
    
+
    
+
    
+
    Websocket
    
+
    
+
    
+
    
+
    
+
    
+
    Advanced
    
+
    
+
    
+
    
+
    
+
    
+
    Additional information
    
+
    
+
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/introduction.asciidoc b/docs/en/cowboy/2.1/guide/introduction.asciidoc
new file mode 100644
index 00000000..1f9b52e4
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/introduction.asciidoc
@@ -0,0 +1,75 @@
+[[introduction]]
+== Introduction
+
+Cowboy is a small, fast and modern HTTP server for Erlang/OTP.
+
+Cowboy aims to provide a complete xref:modern_web[modern Web stack].
+This includes HTTP/1.1, HTTP/2, Websocket, Server-Sent Events and
+Webmachine-based REST.
+
+Cowboy comes with functions for introspection and tracing, enabling
+developers to know precisely what is happening at any time. Its modular
+design also easily enable developers to add instrumentation.
+
+Cowboy is a high quality project. It has a small code base, is very
+efficient (both in latency and memory use) and can easily be embedded
+in another application.
+
+Cowboy is clean Erlang code. It includes hundreds of tests and its code
+is fully compliant with the Dialyzer. It is also well documented and
+features a Function Reference, a User Guide and numerous Tutorials.
+
+=== Prerequisites
+
+Beginner Erlang knowledge is recommended for reading this guide.
+
+Knowledge of the HTTP protocol is recommended but not required, as it
+will be detailed throughout the guide.
+
+=== Supported platforms
+
+Cowboy is tested and supported on Linux, FreeBSD, Windows and OSX.
+
+Cowboy has been reported to work on other platforms, but we make no
+guarantee that the experience will be safe and smooth. You are advised
+to perform the necessary testing and security audits prior to deploying
+on other platforms.
+
+Cowboy is developed for Erlang/OTP 19.0 and newer.
+
+=== License
+
+Cowboy uses the ISC License.
+
+----
+Copyright (c) 2011-2017, Loïc Hoguin 
+
+Permission to use, copy, modify, and/or distribute this software for any
+purpose with or without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+----
+
+=== Versioning
+
+Cowboy uses http://semver.org/[Semantic Versioning 2.0.0].
+
+=== Conventions
+
+In the HTTP protocol, the method name is case sensitive. All standard
+method names are uppercase.
+
+Header names are case insensitive. When using HTTP/1.1, Cowboy converts
+all the request header names to lowercase. HTTP/2 requires clients to
+send them as lowercase. Any other header name is expected to be provided
+lowercased, including when querying information about the request or
+when sending responses.
+
+The same applies to any other case insensitive value.
diff --git a/docs/en/cowboy/2.1/guide/introduction/index.html b/docs/en/cowboy/2.1/guide/introduction/index.html
new file mode 100644
index 00000000..fa633e57
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/introduction/index.html
@@ -0,0 +1,236 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Introduction
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Introduction
    
+
+
    Cowboy is a small, fast and modern HTTP server for Erlang/OTP.
    
+
    Cowboy aims to provide a complete modern Web stack.
+This includes HTTP/1.1, HTTP/2, Websocket, Server-Sent Events and
+Webmachine-based REST.
    
+
    Cowboy comes with functions for introspection and tracing, enabling
+developers to know precisely what is happening at any time. Its modular
+design also easily enable developers to add instrumentation.
    
+
    Cowboy is a high quality project. It has a small code base, is very
+efficient (both in latency and memory use) and can easily be embedded
+in another application.
    
+
    Cowboy is clean Erlang code. It includes hundreds of tests and its code
+is fully compliant with the Dialyzer. It is also well documented and
+features a Function Reference, a User Guide and numerous Tutorials.
    
+
    
+
    Prerequisites
    
+
    
+
    Beginner Erlang knowledge is recommended for reading this guide.
    
+
    Knowledge of the HTTP protocol is recommended but not required, as it
+will be detailed throughout the guide.
    
+
    
+
    
+
    
+
    Supported platforms
    
+
    
+
    Cowboy is tested and supported on Linux, FreeBSD, Windows and OSX.
    
+
    Cowboy has been reported to work on other platforms, but we make no
+guarantee that the experience will be safe and smooth. You are advised
+to perform the necessary testing and security audits prior to deploying
+on other platforms.
    
+
    Cowboy is developed for Erlang/OTP 19.0 and newer.
    
+
    
+
    
+
    
+
    License
    
+
    
+
    Cowboy uses the ISC License.
    
+
    
+
    
+
    Copyright (c) 2011-2017, Loïc Hoguin <essen@ninenines.eu>
+
+Permission to use, copy, modify, and/or distribute this software for any
+purpose with or without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
    
+
    
+
    
+
    
+
    
+
    Versioning
    
+
    
+
    Cowboy uses Semantic Versioning 2.0.0.
    
+
    
+
    
+
    
+
    Conventions
    
+
    
+
    In the HTTP protocol, the method name is case sensitive. All standard
+method names are uppercase.
    
+
    Header names are case insensitive. When using HTTP/1.1, Cowboy converts
+all the request header names to lowercase. HTTP/2 requires clients to
+send them as lowercase. Any other header name is expected to be provided
+lowercased, including when querying information about the request or
+when sending responses.
    
+
    The same applies to any other case insensitive value.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/listeners.asciidoc b/docs/en/cowboy/2.1/guide/listeners.asciidoc
new file mode 100644
index 00000000..10ac4aad
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/listeners.asciidoc
@@ -0,0 +1,115 @@
+[[listeners]]
+== Listeners
+
+A listener is a set of processes that listens on a port for
+new connections. Incoming connections get handled by Cowboy.
+Depending on the connection handshake, one or another protocol
+may be used.
+
+This chapter is specific to Cowboy. Please refer to the
+https://ninenines.eu/docs/en/ranch/1.3/guide/listeners/[Ranch User Guide]
+for more information about listeners.
+
+Cowboy provides two types of listeners: one listening for
+clear TCP connections, and one listening for secure TLS
+connections. Both of them support the HTTP/1.1 and HTTP/2
+protocols.
+
+=== Clear TCP listener
+
+The clear TCP listener will accept connections on the
+given port. A typical HTTP server would listen on port 80.
+Port 80 requires special permissions on most platforms
+however so a common alternative is port 8080.
+
+The following snippet starts listening for connections
+on port 8080:
+
+[source,erlang]
+----
+start(_Type, _Args) ->
+    Dispatch = cowboy_router:compile([
+        {'_', [{"/", hello_handler, []}]}
+    ]),
+    {ok, _} = cowboy:start_clear(my_http_listener,
+        [{port, 8080}],
+        #{env => #{dispatch => Dispatch}}
+    ),
+    hello_erlang_sup:start_link().
+----
+
+The xref:getting_started[Getting Started] chapter uses a
+clear TCP listener.
+
+Clients connecting to Cowboy on the clear listener port are
+expected to use either HTTP/1.1 or HTTP/2.
+
+Cowboy supports both methods of initiating a clear
+HTTP/2 connection: through the Upgrade mechanism
+(https://tools.ietf.org/html/rfc7540#section-3.2[RFC 7540 3.2])
+or by sending the preface directly
+(https://tools.ietf.org/html/rfc7540#section-3.4[RFC 7540 3.4]).
+
+Compatibility with HTTP/1.0 is provided by Cowboy's HTTP/1.1
+implementation.
+
+=== Secure TLS listener
+
+The secure TLS listener will accept connections on the
+given port. A typical HTTPS server would listen on port 443.
+Port 443 requires special permissions on most platforms
+however so a common alternative is port 8443.
+
+// @todo Make a complete list of restrictions.
+
+The function provided by Cowboy will ensure that the TLS
+options given are following the HTTP/2 RFC with regards
+to security. For example some TLS extensions or ciphers
+may be disabled. This also applies to HTTP/1.1 connections
+on this listener. If this is not desirable, Ranch can be
+used directly to setup a custom listener.
+
+[source,erlang]
+----
+start(_Type, _Args) ->
+    Dispatch = cowboy_router:compile([
+        {'_', [{"/", hello_handler, []}]}
+    ]),
+    {ok, _} = cowboy:start_tls(my_http_listener,
+        [
+            {port, 8443},
+            {certfile, "/path/to/certfile"},
+            {keyfile, "/path/to/keyfile"}
+        ],
+        #{env => #{dispatch => Dispatch}}
+    ),
+    hello_erlang_sup:start_link().
+----
+
+Clients connecting to Cowboy on the secure listener are
+expected to use the ALPN TLS extension to indicate what
+protocols they understand. Cowboy always prefers HTTP/2
+over HTTP/1.1 when both are supported. When neither are
+supported by the client, or when the ALPN extension was
+missing, Cowboy expects HTTP/1.1 to be used.
+
+Cowboy also advertises HTTP/2 support through the older
+NPN TLS extension for compatibility. Note however that
+this support will likely not be enabled by default when
+Cowboy 2.0 gets released.
+
+Compatibility with HTTP/1.0 is provided by Cowboy's HTTP/1.1
+implementation.
+
+=== Protocol configuration
+
+The HTTP/1.1 and HTTP/2 protocols share the same semantics;
+only their framing differs. The first is a text protocol and
+the second a binary protocol.
+
+Cowboy doesn't separate the configuration for HTTP/1.1 and
+HTTP/2. Everything goes into the same map. Many options are
+shared.
+
+// @todo Describe good to know options for both protocols?
+// Maybe do that in separate chapters?
diff --git a/docs/en/cowboy/2.1/guide/listeners/index.html b/docs/en/cowboy/2.1/guide/listeners/index.html
new file mode 100644
index 00000000..f0a7d95f
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/listeners/index.html
@@ -0,0 +1,266 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Listeners
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Listeners
    
+
+
    A listener is a set of processes that listens on a port for
+new connections. Incoming connections get handled by Cowboy.
+Depending on the connection handshake, one or another protocol
+may be used.
    
+
    This chapter is specific to Cowboy. Please refer to the
+Ranch User Guide
+for more information about listeners.
    
+
    Cowboy provides two types of listeners: one listening for
+clear TCP connections, and one listening for secure TLS
+connections. Both of them support the HTTP/1.1 and HTTP/2
+protocols.
    
+
    
+
    Clear TCP listener
    
+
    
+
    The clear TCP listener will accept connections on the
+given port. A typical HTTP server would listen on port 80.
+Port 80 requires special permissions on most platforms
+however so a common alternative is port 8080.
    
+
    The following snippet starts listening for connections
+on port 8080:
    
+
    
+
    
+
    start(_Type, _Args) ->
+    Dispatch = cowboy_router:compile([
+        {'_', [{"/", hello_handler, []}]}
+    ]),
+    {ok, _} = cowboy:start_clear(my_http_listener,
+        [{port, 8080}],
+        #{env => #{dispatch => Dispatch}}
+    ),
+    hello_erlang_sup:start_link().
    
+
    The Getting Started chapter uses a
+clear TCP listener.
    
+
    Clients connecting to Cowboy on the clear listener port are
+expected to use either HTTP/1.1 or HTTP/2.
    
+
    Cowboy supports both methods of initiating a clear
+HTTP/2 connection: through the Upgrade mechanism
+(RFC 7540 3.2)
+or by sending the preface directly
+(RFC 7540 3.4).
    
+
    Compatibility with HTTP/1.0 is provided by Cowboy’s HTTP/1.1
+implementation.
    
+
    
+
    
+
    
+
    Secure TLS listener
    
+
    
+
    The secure TLS listener will accept connections on the
+given port. A typical HTTPS server would listen on port 443.
+Port 443 requires special permissions on most platforms
+however so a common alternative is port 8443.
    
+
    The function provided by Cowboy will ensure that the TLS
+options given are following the HTTP/2 RFC with regards
+to security. For example some TLS extensions or ciphers
+may be disabled. This also applies to HTTP/1.1 connections
+on this listener. If this is not desirable, Ranch can be
+used directly to setup a custom listener.
    
+
    
+
    
+
    start(_Type, _Args) ->
+    Dispatch = cowboy_router:compile([
+        {'_', [{"/", hello_handler, []}]}
+    ]),
+    {ok, _} = cowboy:start_tls(my_http_listener,
+        [
+            {port, 8443},
+            {certfile, "/path/to/certfile"},
+            {keyfile, "/path/to/keyfile"}
+        ],
+        #{env => #{dispatch => Dispatch}}
+    ),
+    hello_erlang_sup:start_link().
    
+
    Clients connecting to Cowboy on the secure listener are
+expected to use the ALPN TLS extension to indicate what
+protocols they understand. Cowboy always prefers HTTP/2
+over HTTP/1.1 when both are supported. When neither are
+supported by the client, or when the ALPN extension was
+missing, Cowboy expects HTTP/1.1 to be used.
    
+
    Cowboy also advertises HTTP/2 support through the older
+NPN TLS extension for compatibility. Note however that
+this support will likely not be enabled by default when
+Cowboy 2.0 gets released.
    
+
    Compatibility with HTTP/1.0 is provided by Cowboy’s HTTP/1.1
+implementation.
    
+
    
+
    
+
    
+
    Protocol configuration
    
+
    
+
    The HTTP/1.1 and HTTP/2 protocols share the same semantics;
+only their framing differs. The first is a text protocol and
+the second a binary protocol.
    
+
    Cowboy doesn’t separate the configuration for HTTP/1.1 and
+HTTP/2. Everything goes into the same map. Many options are
+shared.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/loop_handlers.asciidoc b/docs/en/cowboy/2.1/guide/loop_handlers.asciidoc
new file mode 100644
index 00000000..21bf8424
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/loop_handlers.asciidoc
@@ -0,0 +1,128 @@
+[[loop_handlers]]
+== Loop handlers
+
+Loop handlers are a special kind of HTTP handlers used when the
+response can not be sent right away. The handler enters instead
+a receive loop waiting for the right message before it can send
+a response.
+
+Loop handlers are used for requests where a response might not
+be immediately available, but where you would like to keep the
+connection open for a while in case the response arrives. The
+most known example of such practice is known as long polling.
+
+Loop handlers can also be used for requests where a response is
+partially available and you need to stream the response body
+while the connection is open. The most known example of such
+practice is server-sent events.
+
+While the same can be accomplished using plain HTTP handlers,
+it is recommended to use loop handlers because they are well-tested
+and allow using built-in features like hibernation and timeouts.
+
+Loop handlers essentially wait for one or more Erlang messages
+and feed these messages to the `info/3` callback. It also features
+the `init/2` and `terminate/3` callbacks which work the same as
+for plain HTTP handlers.
+
+=== Initialization
+
+The `init/2` function must return a `cowboy_loop` tuple to enable
+loop handler behavior. This tuple may optionally contain
+a timeout value and/or the atom `hibernate` to make the
+process enter hibernation until a message is received.
+
+This snippet enables the loop handler:
+
+[source,erlang]
+----
+init(Req, State) ->
+    {cowboy_loop, Req, State}.
+----
+
+This also makes the process hibernate:
+
+[source,erlang]
+----
+init(Req, State) ->
+    {cowboy_loop, Req, State, hibernate}.
+----
+
+=== Receive loop
+
+Once initialized, Cowboy will wait for messages to arrive
+in the process' mailbox. When a message arrives, Cowboy
+calls the `info/3` function with the message, the Req object
+and the handler's state.
+
+The following snippet sends a reply when it receives a
+`reply` message from another process, or waits for another
+message otherwise.
+
+[source,erlang]
+----
+info({reply, Body}, Req, State) ->
+    cowboy_req:reply(200, #{}, Body, Req),
+    {stop, Req, State};
+info(_Msg, Req, State) ->
+    {ok, Req, State, hibernate}.
+----
+
+Do note that the `reply` tuple here may be any message
+and is simply an example.
+
+This callback may perform any necessary operation including
+sending all or parts of a reply, and will subsequently
+return a tuple indicating if more messages are to be expected.
+
+The callback may also choose to do nothing at all and just
+skip the message received.
+
+If a reply is sent, then the `stop` tuple should be returned.
+This will instruct Cowboy to end the request.
+
+Otherwise an `ok` tuple should be returned.
+
+=== Streaming loop
+
+Another common case well suited for loop handlers is
+streaming data received in the form of Erlang messages.
+This can be done by initiating a chunked reply in the
+`init/2` callback and then using `cowboy_req:chunk/2`
+every time a message is received.
+
+The following snippet does exactly that. As you can see
+a chunk is sent every time an `event` message is received,
+and the loop is stopped by sending an `eof` message.
+
+[source,erlang]
+----
+init(Req, State) ->
+    Req2 = cowboy_req:stream_reply(200, Req),
+    {cowboy_loop, Req2, State}.
+
+info(eof, Req, State) ->
+    {stop, Req, State};
+info({event, Data}, Req, State) ->
+    cowboy_req:stream_body(Data, nofin, Req),
+    {ok, Req, State};
+info(_Msg, Req, State) ->
+    {ok, Req, State}.
+----
+
+=== Cleaning up
+
+It is recommended that you set the connection header to
+`close` when replying, as this process may be reused for
+a subsequent request.
+
+Please refer to the xref:handlers[Handlers chapter]
+for general instructions about cleaning up.
+
+=== Hibernate
+
+To save memory, you may hibernate the process in between
+messages received. This is done by returning the atom
+`hibernate` as part of the `loop` tuple callbacks normally
+return. Just add the atom at the end and Cowboy will hibernate
+accordingly.
diff --git a/docs/en/cowboy/2.1/guide/loop_handlers/index.html b/docs/en/cowboy/2.1/guide/loop_handlers/index.html
new file mode 100644
index 00000000..31412c7b
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/loop_handlers/index.html
@@ -0,0 +1,288 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Loop handlers
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Loop handlers
    
+
+
    Loop handlers are a special kind of HTTP handlers used when the
+response can not be sent right away. The handler enters instead
+a receive loop waiting for the right message before it can send
+a response.
    
+
    Loop handlers are used for requests where a response might not
+be immediately available, but where you would like to keep the
+connection open for a while in case the response arrives. The
+most known example of such practice is known as long polling.
    
+
    Loop handlers can also be used for requests where a response is
+partially available and you need to stream the response body
+while the connection is open. The most known example of such
+practice is server-sent events.
    
+
    While the same can be accomplished using plain HTTP handlers,
+it is recommended to use loop handlers because they are well-tested
+and allow using built-in features like hibernation and timeouts.
    
+
    Loop handlers essentially wait for one or more Erlang messages
+and feed these messages to the info/3 callback. It also features
+the init/2 and terminate/3 callbacks which work the same as
+for plain HTTP handlers.
    
+
    
+
    Initialization
    
+
    
+
    The init/2 function must return a cowboy_loop tuple to enable
+loop handler behavior. This tuple may optionally contain
+a timeout value and/or the atom hibernate to make the
+process enter hibernation until a message is received.
    
+
    This snippet enables the loop handler:
    
+
    
+
    
+
    init(Req, State) ->
+    {cowboy_loop, Req, State}.
    
+
    This also makes the process hibernate:
    
+
    
+
    
+
    init(Req, State) ->
+    {cowboy_loop, Req, State, hibernate}.
    
+
    
+
    
+
    
+
    Receive loop
    
+
    
+
    Once initialized, Cowboy will wait for messages to arrive
+in the process' mailbox. When a message arrives, Cowboy
+calls the info/3 function with the message, the Req object
+and the handler’s state.
    
+
    The following snippet sends a reply when it receives a
+reply message from another process, or waits for another
+message otherwise.
    
+
    
+
    
+
    info({reply, Body}, Req, State) ->
+    cowboy_req:reply(200, #{}, Body, Req),
+    {stop, Req, State};
+info(_Msg, Req, State) ->
+    {ok, Req, State, hibernate}.
    
+
    Do note that the reply tuple here may be any message
+and is simply an example.
    
+
    This callback may perform any necessary operation including
+sending all or parts of a reply, and will subsequently
+return a tuple indicating if more messages are to be expected.
    
+
    The callback may also choose to do nothing at all and just
+skip the message received.
    
+
    If a reply is sent, then the stop tuple should be returned.
+This will instruct Cowboy to end the request.
    
+
    Otherwise an ok tuple should be returned.
    
+
    
+
    
+
    
+
    Streaming loop
    
+
    
+
    Another common case well suited for loop handlers is
+streaming data received in the form of Erlang messages.
+This can be done by initiating a chunked reply in the
+init/2 callback and then using cowboy_req:chunk/2
+every time a message is received.
    
+
    The following snippet does exactly that. As you can see
+a chunk is sent every time an event message is received,
+and the loop is stopped by sending an eof message.
    
+
    
+
    
+
    init(Req, State) ->
+    Req2 = cowboy_req:stream_reply(200, Req),
+    {cowboy_loop, Req2, State}.
+
+info(eof, Req, State) ->
+    {stop, Req, State};
+info({event, Data}, Req, State) ->
+    cowboy_req:stream_body(Data, nofin, Req),
+    {ok, Req, State};
+info(_Msg, Req, State) ->
+    {ok, Req, State}.
    
+
    
+
    
+
    
+
    Cleaning up
    
+
    
+
    It is recommended that you set the connection header to
+close when replying, as this process may be reused for
+a subsequent request.
    
+
    Please refer to the Handlers chapter
+for general instructions about cleaning up.
    
+
    
+
    
+
    
+
    Hibernate
    
+
    
+
    To save memory, you may hibernate the process in between
+messages received. This is done by returning the atom
+hibernate as part of the loop tuple callbacks normally
+return. Just add the atom at the end and Cowboy will hibernate
+accordingly.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/middlewares.asciidoc b/docs/en/cowboy/2.1/guide/middlewares.asciidoc
new file mode 100644
index 00000000..e6be30dd
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/middlewares.asciidoc
@@ -0,0 +1,69 @@
+[[middlewares]]
+== Middlewares
+
+Cowboy delegates the request processing to middleware components.
+By default, two middlewares are defined, for the routing and handling
+of the request, as is detailed in most of this guide.
+
+Middlewares give you complete control over how requests are to be
+processed. You can add your own middlewares to the mix or completely
+change the chain of middlewares as needed.
+
+Cowboy will execute all middlewares in the given order, unless one
+of them decides to stop processing.
+
+=== Usage
+
+Middlewares only need to implement a single callback: `execute/2`.
+It is defined in the `cowboy_middleware` behavior.
+
+This callback has two arguments. The first is the `Req` object.
+The second is the environment.
+
+Middlewares can return one of three different values:
+
+* `{ok, Req, Env}` to continue the request processing
+* `{suspend, Module, Function, Args}` to hibernate
+* `{stop, Req}` to stop processing and move on to the next request
+
+Of note is that when hibernating, processing will resume on the given
+MFA, discarding all previous stacktrace. Make sure you keep the `Req`
+and `Env` in the arguments of this MFA for later use.
+
+If an error happens during middleware processing, Cowboy will not try
+to send an error back to the socket, the process will just crash. It
+is up to the middleware to make sure that a reply is sent if something
+goes wrong.
+
+=== Configuration
+
+The middleware environment is defined as the `env` protocol option.
+In the previous chapters we saw it briefly when we needed to pass
+the routing information. It is a list of tuples with the first
+element being an atom and the second any Erlang term.
+
+Two values in the environment are reserved:
+
+* `listener` contains the name of the listener
+* `result` contains the result of the processing
+
+The `listener` value is always defined. The `result` value can be
+set by any middleware. If set to anything other than `ok`, Cowboy
+will not process any subsequent requests on this connection.
+
+The middlewares that come with Cowboy may define or require other
+environment values to perform.
+
+You can update the environment by calling the `cowboy:set_env/3`
+convenience function, adding or replacing a value in the environment.
+
+=== Routing middleware
+
+The routing middleware requires the `dispatch` value. If routing
+succeeds, it will put the handler name and options in the `handler`
+and `handler_opts` values of the environment, respectively.
+
+=== Handler middleware
+
+The handler middleware requires the `handler` and `handler_opts`
+values. It puts the result of the request handling into `result`.
diff --git a/docs/en/cowboy/2.1/guide/middlewares/index.html b/docs/en/cowboy/2.1/guide/middlewares/index.html
new file mode 100644
index 00000000..8dc24be9
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/middlewares/index.html
@@ -0,0 +1,249 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Middlewares
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Middlewares
    
+
+
    Cowboy delegates the request processing to middleware components.
+By default, two middlewares are defined, for the routing and handling
+of the request, as is detailed in most of this guide.
    
+
    Middlewares give you complete control over how requests are to be
+processed. You can add your own middlewares to the mix or completely
+change the chain of middlewares as needed.
    
+
    Cowboy will execute all middlewares in the given order, unless one
+of them decides to stop processing.
    
+
    
+
    Usage
    
+
    
+
    Middlewares only need to implement a single callback: execute/2.
+It is defined in the cowboy_middleware behavior.
    
+
    This callback has two arguments. The first is the Req object.
+The second is the environment.
    
+
    Middlewares can return one of three different values:
    
+
      
+
    • 
+
      
+{ok, Req, Env} to continue the request processing
+
      
+
      • 
+
    • 
+
      
+{suspend, Module, Function, Args} to hibernate
+
      
+
      • 
+
    • 
+
      
+{stop, Req} to stop processing and move on to the next request
+
      
+
      • 
+
    
+
    Of note is that when hibernating, processing will resume on the given
+MFA, discarding all previous stacktrace. Make sure you keep the Req
+and Env in the arguments of this MFA for later use.
    
+
    If an error happens during middleware processing, Cowboy will not try
+to send an error back to the socket, the process will just crash. It
+is up to the middleware to make sure that a reply is sent if something
+goes wrong.
    
+
    
+
    
+
    
+
    Configuration
    
+
    
+
    The middleware environment is defined as the env protocol option.
+In the previous chapters we saw it briefly when we needed to pass
+the routing information. It is a list of tuples with the first
+element being an atom and the second any Erlang term.
    
+
    Two values in the environment are reserved:
    
+
      
+
    • 
+
      
+listener contains the name of the listener
+
      
+
      • 
+
    • 
+
      
+result contains the result of the processing
+
      
+
      • 
+
    
+
    The listener value is always defined. The result value can be
+set by any middleware. If set to anything other than ok, Cowboy
+will not process any subsequent requests on this connection.
    
+
    The middlewares that come with Cowboy may define or require other
+environment values to perform.
    
+
    You can update the environment by calling the cowboy:set_env/3
+convenience function, adding or replacing a value in the environment.
    
+
    
+
    
+
    
+
    Routing middleware
    
+
    
+
    The routing middleware requires the dispatch value. If routing
+succeeds, it will put the handler name and options in the handler
+and handler_opts values of the environment, respectively.
    
+
    
+
    
+
    
+
    Handler middleware
    
+
    
+
    The handler middleware requires the handler and handler_opts
+values. It puts the result of the request handling into result.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/migrating_from_1.0.asciidoc b/docs/en/cowboy/2.1/guide/migrating_from_1.0.asciidoc
new file mode 100644
index 00000000..4f4ea5bf
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/migrating_from_1.0.asciidoc
@@ -0,0 +1,214 @@
+[appendix]
+== Migrating from Cowboy 1.0 to 2.0
+
+A lot has changed between Cowboy 1.0 and 2.0. The `cowboy_req`
+interface in particular has seen a massive revamp. Hooks are
+gone, their functionality can now be achieved via stream
+handlers.
+
+The documentation has seen great work, in particular the
+manual. Each module and each function now has its own dedicated
+manual page with full details and examples.
+
+=== Compatibility
+
+Compatibility with Erlang/OTP R16, 17 and 18 has been dropped.
+Erlang/OTP 19.0 or above is required. It is non-trivial to
+make Cowboy 2.0 work with older Erlang/OTP versions.
+
+Cowboy 2.0 is not compatible with Cowlib versions older than
+2.0. It should be compatible with Ranch 1.0 or above, however
+it has not been tested with Ranch versions older than 1.4.
+
+Cowboy 2.0 is tested on Arch Linux, Ubuntu, FreeBSD, Windows
+and OSX. It is tested with every point release (latest patch
+release) and also with HiPE on the most recent release.
+
+Cowboy 2.0 now comes with Erlang.mk templates.
+
+=== Features added
+
+* The HTTP/2 protocol is now supported.
+
+* Cowboy no longer uses only one process per connection.
+  It now uses one process per connection plus one process
+  per request by default. This is necessary for HTTP/2.
+  There might be a slight drop in performance for HTTP/1.1
+  connections due to this change.
+
+* Cowboy internals have largely been reworked in order to
+  support HTTP/2. This opened the way to stream handlers,
+  which are a chain of modules that are called whenever
+  something happens relating to a request/response.
+
+* The `cowboy_stream_h` stream handler has been added.
+  It provides most of Cowboy's default behavior.
+
+* The `cowboy_compress_h` stream handler has been added.
+  It compresses responses when possible. It's worth noting
+  that it compresses in more cases than Cowboy 1.0 ever did.
+
+* Because of the many changes in the internals of Cowboy,
+  many options have been added or modified. Of note is that
+  the Websocket options are now given per handler rather
+  than for the entire listener.
+
+* Websocket permessage-deflate compression is now supported
+  via the `compress` option.
+
+* Static file handlers will now correctly find files found
+  in '.ez' archives.
+
+* Constraints have been generalized and are now used not only
+  in the router but also in some `cowboy_req` functions. Their
+  interface has also been modified to allow for reverse
+  operations and formatting of errors.
+
+=== Features removed
+
+* SPDY support has been removed. Use HTTP/2 instead.
+
+* Hooks have been removed. Use xref:streams[stream handlers] instead.
+
+* The undocumented `waiting_stream` hack has been removed.
+  It allowed disabling chunked transfer-encoding for HTTP/1.1.
+  It has no equivalent in Cowboy 2.0. Open a ticket if necessary.
+
+* Sub protocols still exist, but their interface has largely changed
+  and they are no longer documented for the time being.
+
+=== Changed behaviors
+
+* The handler behaviors have been renamed and are now `cowboy_handler`,
+  `cowboy_loop`, `cowboy_rest` and `cowboy_websocket`.
+
+* Plain HTTP, loop, REST and Websocket handlers have had their
+  init and terminate callbacks unified. They now all use the
+  `init/2` and `terminate/3` callbacks. The latter is now optional.
+  The terminate reason has now been documented for all handlers.
+
+* The tuple returned to switch to a different handler type has
+  changed. It now takes the form `{Module, Req, State}` or
+  `{Module, Req, State, Opts}`, where `Opts` is a map of options
+  to configure the handler. The timeout and hibernate options
+  must now be specified using this map, where applicable.
+
+* All behaviors that used to accept `halt` or `shutdown` tuples
+  as a return value no longer do so. The return value is now
+  a `stop` tuple, consistent across Cowboy.
+
+* Middlewares can no longer return an `error` tuple. They have
+  to send the response and return a `stop` tuple instead.
+
+* The `known_content_type` REST handler callback has been removed
+  as it was found unnecessary.
+
+* Websocket handlers have both the normal `init/2` and
+  an optional `websocket_init/1` function. The reason for
+  that exception is that the `websocket_*` callbacks execute
+  in a separate process from the `init/2` callback, and it
+  was therefore not obvious how timers or monitors should
+  be setup properly. They are effectively initializing the
+  handler before and after the HTTP/1.1 upgrade.
+
+* Websocket handlers can now send frames directly from
+  `websocket_init/1`. The frames will be sent immediately
+  after the handshake.
+
+* Websocket handler callbacks no longer receive the Req
+  argument. The `init/2` callback still receives it and
+  can be used to extract relevant information. The `terminate/3`
+  callback, if implemented, may still receive the Req
+  (see next bullet point).
+
+* Websocket handlers have a new `req_filter` option that
+  can be used to customize how much information should be
+  discarded from the Req object after the handshake. Note
+  that the Req object is only available in `terminate/3`
+  past that point.
+
+* Websocket handlers have their timeout default changed
+  from infinity to 60 seconds.
+
+=== New functions
+
+* The `cowboy_req:scheme/1` function has been added.
+
+* The `cowboy_req:uri/1,2` function has been added, replacing the
+  less powerful functions `cowboy_req:url/1` and `cowboy_req:host_url/1`.
+
+* The functions `cowboy_req:match_qs/2` and `cowboy_req:match_cookies/2`
+  allow matching query string and cookies against constraints.
+
+* The function `cowboy_req:set_resp_cookie/3` has been added to
+  complement `cowboy_req:set_resp_cookie/4`.
+
+* The functions `cowboy_req:resp_header/2,3` and `cowboy_req:resp_headers/1`
+  have been added. They can be used to retrieve response headers
+  that were previously set.
+
+* The function `cowboy_req:set_resp_headers/2` has been added. It
+  allows setting many response headers at once.
+
+* The functions `cowboy_req:push/3,4` can be used to push resources
+  for protocols that support it (by default only HTTP/2).
+
+=== Changed functions
+
+* The `cowboy:start_http/4` function was renamed to `cowboy:start_clear/3`.
+
+* The `cowboy:start_https/4` function was renamed to `cowboy:start_tls/3`.
+
+* Most, if not all, functions in the `cowboy_req` module have been modified.
+  Please consult the changelog of each individual functions. The changes
+  are mainly about simplifying and clarifying the interface. The Req is no
+  longer returned when not necessary, maps are used wherever possible,
+  and some functions have been renamed.
+
+* The position of the `Opts` argument for `cowboy_req:set_resp_cookie/4`
+  has changed to improve consistency. It is now the last argument.
+
+=== Removed functions
+
+* The functions `cowboy_req:url/1` and `cowboy_req:host_url/1` have been
+  removed in favor of the new function `cowboy_req:uri/1,2`.
+
+* The functions `cowboy_req:meta/2,3` and `cowboy_req:set_meta/3` have
+  been removed. The Req object is now a public map, therefore they became
+  unnecessary.
+
+* The functions `cowboy_req:set_resp_body_fun/2,3` have been removed.
+  For sending files, the function `cowboy_req:set_resp_body/2` can now
+  take a sendfile tuple.
+
+* Remove many undocumented functions from `cowboy_req`, including the
+  functions `cowboy_req:get/2` and `cowboy_req:set/3`.
+
+=== Other changes
+
+* The correct percent-decoding algorithm is now used for path elements
+  during routing. It will no longer decode `+` characters.
+
+* The router will now properly handle path segments `.` and `..`.
+
+* Routing behavior has changed for URIs containing latin1 characters.
+  They are no longer allowed. URIs are expected to be in UTF-8 once
+  they are percent-decoded.
+
+* Clients that send multiple headers of the same name
+  will have the values of those headers concatenated into a
+  comma-separated list. This is of special importance in the
+  case of the content-type header, as previously only the
+  first value was used in the `content_types_accepted/2` step
+  in REST handlers.
+
+* Etag comparison in REST handlers has been fixed. Some requests may
+  now fail when they succeeded in the past.
+
+* The `If-*-Since` headers are now ignored in REST handlers if
+  the corresponding `If*-Match` header exist. The former is
+  largely a backward compatible header and this shouldn't create
+  any issue. The new behavior follows the current RFCs more closely.
+
+* The static file handler has been improved to handle more special
+  characters on systems that accept them.
diff --git a/docs/en/cowboy/2.1/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.1/guide/migrating_from_1.0/index.html
new file mode 100644
index 00000000..c9f1c628
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/migrating_from_1.0/index.html
@@ -0,0 +1,545 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Migrating from Cowboy 1.0 to 2.0
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Migrating from Cowboy 1.0 to 2.0
    
+
+
    A lot has changed between Cowboy 1.0 and 2.0. The cowboy_req
+interface in particular has seen a massive revamp. Hooks are
+gone, their functionality can now be achieved via stream
+handlers.
    
+
    The documentation has seen great work, in particular the
+manual. Each module and each function now has its own dedicated
+manual page with full details and examples.
    
+
    
+
    Compatibility
    
+
    
+
    Compatibility with Erlang/OTP R16, 17 and 18 has been dropped.
+Erlang/OTP 19.0 or above is required. It is non-trivial to
+make Cowboy 2.0 work with older Erlang/OTP versions.
    
+
    Cowboy 2.0 is not compatible with Cowlib versions older than
+2.0. It should be compatible with Ranch 1.0 or above, however
+it has not been tested with Ranch versions older than 1.4.
    
+
    Cowboy 2.0 is tested on Arch Linux, Ubuntu, FreeBSD, Windows
+and OSX. It is tested with every point release (latest patch
+release) and also with HiPE on the most recent release.
    
+
    Cowboy 2.0 now comes with Erlang.mk templates.
    
+
    
+
    
+
    
+
    Features added
    
+
    
+
      
+
    • 
+
      
+The HTTP/2 protocol is now supported.
+
      
+
      • 
+
    • 
+
      
+Cowboy no longer uses only one process per connection.
+  It now uses one process per connection plus one process
+  per request by default. This is necessary for HTTP/2.
+  There might be a slight drop in performance for HTTP/1.1
+  connections due to this change.
+
      
+
      • 
+
    • 
+
      
+Cowboy internals have largely been reworked in order to
+  support HTTP/2. This opened the way to stream handlers,
+  which are a chain of modules that are called whenever
+  something happens relating to a request/response.
+
      
+
      • 
+
    • 
+
      
+The cowboy_stream_h stream handler has been added.
+  It provides most of Cowboy’s default behavior.
+
      
+
      • 
+
    • 
+
      
+The cowboy_compress_h stream handler has been added.
+  It compresses responses when possible. It’s worth noting
+  that it compresses in more cases than Cowboy 1.0 ever did.
+
      
+
      • 
+
    • 
+
      
+Because of the many changes in the internals of Cowboy,
+  many options have been added or modified. Of note is that
+  the Websocket options are now given per handler rather
+  than for the entire listener.
+
      
+
      • 
+
    • 
+
      
+Websocket permessage-deflate compression is now supported
+  via the compress option.
+
      
+
      • 
+
    • 
+
      
+Static file handlers will now correctly find files found
+  in .ez archives.
+
      
+
      • 
+
    • 
+
      
+Constraints have been generalized and are now used not only
+  in the router but also in some cowboy_req functions. Their
+  interface has also been modified to allow for reverse
+  operations and formatting of errors.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Features removed
    
+
    
+
      
+
    • 
+
      
+SPDY support has been removed. Use HTTP/2 instead.
+
      
+
      • 
+
    • 
+
      
+Hooks have been removed. Use stream handlers instead.
+
      
+
      • 
+
    • 
+
      
+The undocumented waiting_stream hack has been removed.
+  It allowed disabling chunked transfer-encoding for HTTP/1.1.
+  It has no equivalent in Cowboy 2.0. Open a ticket if necessary.
+
      
+
      • 
+
    • 
+
      
+Sub protocols still exist, but their interface has largely changed
+  and they are no longer documented for the time being.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Changed behaviors
    
+
    
+
      
+
    • 
+
      
+The handler behaviors have been renamed and are now cowboy_handler,
+  cowboy_loop, cowboy_rest and cowboy_websocket.
+
      
+
      • 
+
    • 
+
      
+Plain HTTP, loop, REST and Websocket handlers have had their
+  init and terminate callbacks unified. They now all use the
+  init/2 and terminate/3 callbacks. The latter is now optional.
+  The terminate reason has now been documented for all handlers.
+
      
+
      • 
+
    • 
+
      
+The tuple returned to switch to a different handler type has
+  changed. It now takes the form {Module, Req, State} or
+  {Module, Req, State, Opts}, where Opts is a map of options
+  to configure the handler. The timeout and hibernate options
+  must now be specified using this map, where applicable.
+
      
+
      • 
+
    • 
+
      
+All behaviors that used to accept halt or shutdown tuples
+  as a return value no longer do so. The return value is now
+  a stop tuple, consistent across Cowboy.
+
      
+
      • 
+
    • 
+
      
+Middlewares can no longer return an error tuple. They have
+  to send the response and return a stop tuple instead.
+
      
+
      • 
+
    • 
+
      
+The known_content_type REST handler callback has been removed
+  as it was found unnecessary.
+
      
+
      • 
+
    • 
+
      
+Websocket handlers have both the normal init/2 and
+  an optional websocket_init/1 function. The reason for
+  that exception is that the websocket_* callbacks execute
+  in a separate process from the init/2 callback, and it
+  was therefore not obvious how timers or monitors should
+  be setup properly. They are effectively initializing the
+  handler before and after the HTTP/1.1 upgrade.
+
      
+
      • 
+
    • 
+
      
+Websocket handlers can now send frames directly from
+  websocket_init/1. The frames will be sent immediately
+  after the handshake.
+
      
+
      • 
+
    • 
+
      
+Websocket handler callbacks no longer receive the Req
+  argument. The init/2 callback still receives it and
+  can be used to extract relevant information. The terminate/3
+  callback, if implemented, may still receive the Req
+  (see next bullet point).
+
      
+
      • 
+
    • 
+
      
+Websocket handlers have a new req_filter option that
+  can be used to customize how much information should be
+  discarded from the Req object after the handshake. Note
+  that the Req object is only available in terminate/3
+  past that point.
+
      
+
      • 
+
    • 
+
      
+Websocket handlers have their timeout default changed
+  from infinity to 60 seconds.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    New functions
    
+
    
+
      
+
    • 
+
      
+The cowboy_req:scheme/1 function has been added.
+
      
+
      • 
+
    • 
+
      
+The cowboy_req:uri/1,2 function has been added, replacing the
+  less powerful functions cowboy_req:url/1 and cowboy_req:host_url/1.
+
      
+
      • 
+
    • 
+
      
+The functions cowboy_req:match_qs/2 and cowboy_req:match_cookies/2
+  allow matching query string and cookies against constraints.
+
      
+
      • 
+
    • 
+
      
+The function cowboy_req:set_resp_cookie/3 has been added to
+  complement cowboy_req:set_resp_cookie/4.
+
      
+
      • 
+
    • 
+
      
+The functions cowboy_req:resp_header/2,3 and cowboy_req:resp_headers/1
+  have been added. They can be used to retrieve response headers
+  that were previously set.
+
      
+
      • 
+
    • 
+
      
+The function cowboy_req:set_resp_headers/2 has been added. It
+  allows setting many response headers at once.
+
      
+
      • 
+
    • 
+
      
+The functions cowboy_req:push/3,4 can be used to push resources
+  for protocols that support it (by default only HTTP/2).
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Changed functions
    
+
    
+
      
+
    • 
+
      
+The cowboy:start_http/4 function was renamed to cowboy:start_clear/3.
+
      
+
      • 
+
    • 
+
      
+The cowboy:start_https/4 function was renamed to cowboy:start_tls/3.
+
      
+
      • 
+
    • 
+
      
+Most, if not all, functions in the cowboy_req module have been modified.
+  Please consult the changelog of each individual functions. The changes
+  are mainly about simplifying and clarifying the interface. The Req is no
+  longer returned when not necessary, maps are used wherever possible,
+  and some functions have been renamed.
+
      
+
      • 
+
    • 
+
      
+The position of the Opts argument for cowboy_req:set_resp_cookie/4
+  has changed to improve consistency. It is now the last argument.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Removed functions
    
+
    
+
      
+
    • 
+
      
+The functions cowboy_req:url/1 and cowboy_req:host_url/1 have been
+  removed in favor of the new function cowboy_req:uri/1,2.
+
      
+
      • 
+
    • 
+
      
+The functions cowboy_req:meta/2,3 and cowboy_req:set_meta/3 have
+  been removed. The Req object is now a public map, therefore they became
+  unnecessary.
+
      
+
      • 
+
    • 
+
      
+The functions cowboy_req:set_resp_body_fun/2,3 have been removed.
+  For sending files, the function cowboy_req:set_resp_body/2 can now
+  take a sendfile tuple.
+
      
+
      • 
+
    • 
+
      
+Remove many undocumented functions from cowboy_req, including the
+  functions cowboy_req:get/2 and cowboy_req:set/3.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Other changes
    
+
    
+
      
+
    • 
+
      
+The correct percent-decoding algorithm is now used for path elements
+  during routing. It will no longer decode + characters.
+
      
+
      • 
+
    • 
+
      
+The router will now properly handle path segments . and ...
+
      
+
      • 
+
    • 
+
      
+Routing behavior has changed for URIs containing latin1 characters.
+  They are no longer allowed. URIs are expected to be in UTF-8 once
+  they are percent-decoded.
+
      
+
      • 
+
    • 
+
      
+Clients that send multiple headers of the same name
+  will have the values of those headers concatenated into a
+  comma-separated list. This is of special importance in the
+  case of the content-type header, as previously only the
+  first value was used in the content_types_accepted/2 step
+  in REST handlers.
+
      
+
      • 
+
    • 
+
      
+Etag comparison in REST handlers has been fixed. Some requests may
+  now fail when they succeeded in the past.
+
      
+
      • 
+
    • 
+
      
+The If-*-Since headers are now ignored in REST handlers if
+  the corresponding If*-Match header exist. The former is
+  largely a backward compatible header and this shouldn’t create
+  any issue. The new behavior follows the current RFCs more closely.
+
      
+
      • 
+
    • 
+
      
+The static file handler has been improved to handle more special
+  characters on systems that accept them.
+
      
+
      • 
+
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/migrating_from_2.0.asciidoc b/docs/en/cowboy/2.1/guide/migrating_from_2.0.asciidoc
new file mode 100644
index 00000000..c76430c2
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/migrating_from_2.0.asciidoc
@@ -0,0 +1,107 @@
+[appendix]
+== Migrating from Cowboy 2.0 to 2.1
+
+Cowboy 2.1 focused on adding features that were temporarily
+removed in Cowboy 2.0. A number of bugs found in the 2.0
+release were also fixed.
+
+=== Features added
+
+* It is now possible to obtain the client TLS certificate
+  and the local IP/port for the connection from the Req object.
+
+* Informational responses (1XX responses) can now be sent.
+  They must be sent before initiating the final response.
+
+* The `expect: 100-continue` header is now handled
+  automatically. The 100 response will be sent on the
+  first `cowboy_req:read_body/2,3,4` call. This only applies
+  when using the default `cowboy_stream_h` stream handler.
+
+=== Experimental features added
+
+Experimental features are previews of features that will be
+added in a future release. They are not documented and their
+interface may change at any time. You are welcome to try them
+and provide feedback.
+
+* The `cowboy_metrics_h` stream handler can be used to
+  extract metrics out of Cowboy. It must be used first in
+  the list of stream handlers, and will record all events
+  related to requests, responses and spawned processes.
+  When the stream terminates it will pass this information
+  to a user-defined callback.
+
+* The `cowboy_tracer_h` stream handler can be used to setup
+  automatic tracing of specific requests. You can conditionally
+  enable tracing based on a function, header, path or any other
+  element from the request and the trace will apply to the
+  entire connection and any processes created by it. This is
+  meant to be used for debugging both in tests and production.
+
+=== Changed behaviors
+
+* The `cowboy_rest` handler now implements a mechanism for
+  switching to a different type of handler from any callback
+  where `stop` is also allowed. Switch by returning
+  `{switch_handler, Module}` or `{switch_handler, Module, Opts}`.
+  This is especially useful for switching to `cowboy_loop`
+  for streaming the request or response body.
+
+* REST callbacks that do not allow `stop` as a return value
+  are now explicitly listed in the documentation.
+
+=== New functions
+
+* The function `cowboy_req:sock/1` returns the IP/port
+  of the local socket.
+
+* The function `cowboy_req:cert/1` returns the client
+  TLS certificate or `undefined` if it isn't available.
+
+* The function `cowboy_req:inform/2,3` sends an
+  informational response.
+
+=== Bugs fixed
+
+* Ensure HTTP/2 connections are not closed prematurely
+  when the user code does not read the request body.
+
+* Ensure HTTP/1.1 streams are not terminated too early.
+  Their behavior is now consistent with the HTTP/2 code
+  where the stream handler is only terminated when the
+  `stop` command is returned.
+
+* Sending zero-sized data from stream handlers or from
+  `cowboy_req:stream_body/3` could lead to issues with
+  HTTP/1.1. This has been fixed.
+
+* The final chunk sent by Cowboy when it terminates a
+  chunked body after the handler process exits was not
+  passed through stream handlers, which could lead to
+  issues when `cowboy_compress_h` was being used. This
+  is now corrected.
+
+* The stream handler state was discarded in some cases
+  where Cowboy had to send a response or response data
+  automatically when ending a stream. This has now
+  been corrected.
+
+* The stream handler callback `terminate/3` will now be
+  called when switching to another protocol using the
+  command `switch_protocol`. This doesn't apply when
+  doing upgrades to HTTP/2 as those occur before the
+  stream is initialized.
+
+* Cowlib has been updated to 2.0.1 to fix an issue with
+  Websocket compression when using Erlang/OTP 20.1. Note
+  that at the time of writing all 20.1 versions (from
+  20.1 to 20.1.4) have issues when compression is enabled.
+  It is expected to work properly from 20.1.5 onward. In
+  the meantime it is recommended to run the plain 20.1
+  release and disable Websocket compression, or use a
+  release before 20.1.
+
+* Cowboy will no longer crash when the `cowboy_clock`
+  process is not running. This can happen when Cowboy
+  is being restarted during upgrades, for example.
diff --git a/docs/en/cowboy/2.1/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.1/guide/migrating_from_2.0/index.html
new file mode 100644
index 00000000..2e4a1d66
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/migrating_from_2.0/index.html
@@ -0,0 +1,345 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Migrating from Cowboy 2.0 to 2.1
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Migrating from Cowboy 2.0 to 2.1
    
+
+
    Cowboy 2.1 focused on adding features that were temporarily
+removed in Cowboy 2.0. A number of bugs found in the 2.0
+release were also fixed.
    
+
    
+
    Features added
    
+
    
+
      
+
    • 
+
      
+It is now possible to obtain the client TLS certificate
+  and the local IP/port for the connection from the Req object.
+
      
+
      • 
+
    • 
+
      
+Informational responses (1XX responses) can now be sent.
+  They must be sent before initiating the final response.
+
      
+
      • 
+
    • 
+
      
+The expect: 100-continue header is now handled
+  automatically. The 100 response will be sent on the
+  first cowboy_req:read_body/2,3,4 call. This only applies
+  when using the default cowboy_stream_h stream handler.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Experimental features added
    
+
    
+
    Experimental features are previews of features that will be
+added in a future release. They are not documented and their
+interface may change at any time. You are welcome to try them
+and provide feedback.
    
+
      
+
    • 
+
      
+The cowboy_metrics_h stream handler can be used to
+  extract metrics out of Cowboy. It must be used first in
+  the list of stream handlers, and will record all events
+  related to requests, responses and spawned processes.
+  When the stream terminates it will pass this information
+  to a user-defined callback.
+
      
+
      • 
+
    • 
+
      
+The cowboy_tracer_h stream handler can be used to setup
+  automatic tracing of specific requests. You can conditionally
+  enable tracing based on a function, header, path or any other
+  element from the request and the trace will apply to the
+  entire connection and any processes created by it. This is
+  meant to be used for debugging both in tests and production.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Changed behaviors
    
+
    
+
      
+
    • 
+
      
+The cowboy_rest handler now implements a mechanism for
+  switching to a different type of handler from any callback
+  where stop is also allowed. Switch by returning
+  {switch_handler, Module} or {switch_handler, Module, Opts}.
+  This is especially useful for switching to cowboy_loop
+  for streaming the request or response body.
+
      
+
      • 
+
    • 
+
      
+REST callbacks that do not allow stop as a return value
+  are now explicitly listed in the documentation.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    New functions
    
+
    
+
      
+
    • 
+
      
+The function cowboy_req:sock/1 returns the IP/port
+  of the local socket.
+
      
+
      • 
+
    • 
+
      
+The function cowboy_req:cert/1 returns the client
+  TLS certificate or undefined if it isn’t available.
+
      
+
      • 
+
    • 
+
      
+The function cowboy_req:inform/2,3 sends an
+  informational response.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Bugs fixed
    
+
    
+
      
+
    • 
+
      
+Ensure HTTP/2 connections are not closed prematurely
+  when the user code does not read the request body.
+
      
+
      • 
+
    • 
+
      
+Ensure HTTP/1.1 streams are not terminated too early.
+  Their behavior is now consistent with the HTTP/2 code
+  where the stream handler is only terminated when the
+  stop command is returned.
+
      
+
      • 
+
    • 
+
      
+Sending zero-sized data from stream handlers or from
+  cowboy_req:stream_body/3 could lead to issues with
+  HTTP/1.1. This has been fixed.
+
      
+
      • 
+
    • 
+
      
+The final chunk sent by Cowboy when it terminates a
+  chunked body after the handler process exits was not
+  passed through stream handlers, which could lead to
+  issues when cowboy_compress_h was being used. This
+  is now corrected.
+
      
+
      • 
+
    • 
+
      
+The stream handler state was discarded in some cases
+  where Cowboy had to send a response or response data
+  automatically when ending a stream. This has now
+  been corrected.
+
      
+
      • 
+
    • 
+
      
+The stream handler callback terminate/3 will now be
+  called when switching to another protocol using the
+  command switch_protocol. This doesn’t apply when
+  doing upgrades to HTTP/2 as those occur before the
+  stream is initialized.
+
      
+
      • 
+
    • 
+
      
+Cowlib has been updated to 2.0.1 to fix an issue with
+  Websocket compression when using Erlang/OTP 20.1. Note
+  that at the time of writing all 20.1 versions (from
+  20.1 to 20.1.4) have issues when compression is enabled.
+  It is expected to work properly from 20.1.5 onward. In
+  the meantime it is recommended to run the plain 20.1
+  release and disable Websocket compression, or use a
+  release before 20.1.
+
      
+
      • 
+
    • 
+
      
+Cowboy will no longer crash when the cowboy_clock
+  process is not running. This can happen when Cowboy
+  is being restarted during upgrades, for example.
+
      
+
      • 
+
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/modern_web.asciidoc b/docs/en/cowboy/2.1/guide/modern_web.asciidoc
new file mode 100644
index 00000000..48525732
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/modern_web.asciidoc
@@ -0,0 +1,122 @@
+[[modern_web]]
+== The modern Web
+
+Cowboy is a server for the modern Web. This chapter explains
+what it means and details all the standards involved.
+
+Cowboy supports all the standards listed in this document.
+
+=== HTTP/2
+
+HTTP/2 is the most efficient protocol for consuming Web
+services. It enables clients to keep a connection open
+for long periods of time; to send requests concurrently;
+to reduce the size of requests through HTTP headers
+compression; and more. The protocol is binary, greatly
+reducing the resources needed to parse it.
+
+HTTP/2 also enables the server to push messages to the
+client. This can be used for various purposes, including
+the sending of related resources before the client requests
+them, in an effort to reduce latency. This can also be used
+to enable bidirectional communication.
+
+Cowboy provides transparent support for HTTP/2. Clients
+that know it can use it; others fall back to HTTP/1.1
+automatically.
+
+HTTP/2 is compatible with the HTTP/1.1 semantics.
+
+HTTP/2 is defined by RFC 7540 and RFC 7541.
+
+=== HTTP/1.1
+
+HTTP/1.1 is the previous version of the HTTP protocol.
+The protocol itself is text-based and suffers from numerous
+issues and limitations. In particular it is not possible
+to execute requests concurrently (though pipelining is
+sometimes possible), and it's also sometimes difficult
+to detect that a client disconnected.
+
+HTTP/1.1 does provide very good semantics for interacting
+with Web services. It defines the standard methods, headers
+and status codes used by HTTP/1.1 and HTTP/2 clients and
+servers.
+
+HTTP/1.1 also defines compatibility with an older version
+of the protocol, HTTP/1.0, which was never really standardized
+across implementations.
+
+The core of HTTP/1.1 is defined by RFC 7230, RFC 7231,
+RFC 7232, RFC 7233, RFC 7234 and RFC 7235. Numerous RFCs
+and other specifications exist defining additional HTTP
+methods, status codes, headers or semantics.
+
+=== Websocket
+
+xref:ws_protocol[Websocket] is a protocol built on top of HTTP/1.1
+that provides a two-ways communication channel between the client and
+the server. Communication is asynchronous and can occur concurrently.
+
+It consists of a Javascript object allowing setting up a
+Websocket connection to the server, and a binary based
+protocol for sending data to the server or the client.
+
+Websocket connections can transfer either UTF-8 encoded text
+data or binary data. The protocol also includes support for
+implementing a ping/pong mechanism, allowing the server and
+the client to have more confidence that the connection is still
+alive.
+
+A Websocket connection can be used to transfer any kind of data,
+small or big, text or binary. Because of this Websocket is
+sometimes used for communication between systems.
+
+Websocket messages have no semantics on their own. Websocket
+is closer to TCP in that aspect, and requires you to design
+and implement your own protocol on top of it; or adapt an
+existing protocol to Websocket.
+
+Cowboy provides an interface known as xref:ws_handlers[Websocket handlers]
+that gives complete control over a Websocket connection.
+
+The Websocket protocol is defined by RFC 6455.
+
+=== Long-lived requests
+
+Cowboy provides an interface that can be used to support
+long-polling or to stream large amounts of data reliably,
+including using Server-Sent Events.
+
+Long-polling is a mechanism in which the client performs
+a request which may not be immediately answered by the
+server. It allows clients to request resources that may
+not currently exist, but are expected to be created soon,
+and which will be returned as soon as they are.
+
+Long-polling is essentially a hack, but it is widely used
+to overcome limitations on older clients and servers.
+
+Server-Sent Events is a small protocol defined as a media
+type, `text/event-stream`, along with a new HTTP header,
+`Last-Event-ID`. It is defined in the EventSource W3C
+specification.
+
+Cowboy provides an interface known as xref:loop_handlers[loop handlers]
+that facilitates the implementation of long-polling or stream
+mechanisms. It works regardless of the underlying protocol.
+
+=== REST
+
+xref:rest_principles[REST, or REpresentational State Transfer],
+is a style of architecture for loosely connected distributed
+systems. It can easily be implemented on top of HTTP.
+
+REST is essentially a set of constraints to be followed.
+Many of these constraints are purely architectural and
+solved by simply using HTTP. Some constraints must be
+explicitly followed by the developer.
+
+Cowboy provides an interface known as xref:rest_handlers[REST handlers]
+that simplifies the implementation of a REST API on top of
+the HTTP protocol.
diff --git a/docs/en/cowboy/2.1/guide/modern_web/index.html b/docs/en/cowboy/2.1/guide/modern_web/index.html
new file mode 100644
index 00000000..4fd014d2
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/modern_web/index.html
@@ -0,0 +1,268 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: The modern Web
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    The modern Web
    
+
+
    Cowboy is a server for the modern Web. This chapter explains
+what it means and details all the standards involved.
    
+
    Cowboy supports all the standards listed in this document.
    
+
    
+
    HTTP/2
    
+
    
+
    HTTP/2 is the most efficient protocol for consuming Web
+services. It enables clients to keep a connection open
+for long periods of time; to send requests concurrently;
+to reduce the size of requests through HTTP headers
+compression; and more. The protocol is binary, greatly
+reducing the resources needed to parse it.
    
+
    HTTP/2 also enables the server to push messages to the
+client. This can be used for various purposes, including
+the sending of related resources before the client requests
+them, in an effort to reduce latency. This can also be used
+to enable bidirectional communication.
    
+
    Cowboy provides transparent support for HTTP/2. Clients
+that know it can use it; others fall back to HTTP/1.1
+automatically.
    
+
    HTTP/2 is compatible with the HTTP/1.1 semantics.
    
+
    HTTP/2 is defined by RFC 7540 and RFC 7541.
    
+
    
+
    
+
    
+
    HTTP/1.1
    
+
    
+
    HTTP/1.1 is the previous version of the HTTP protocol.
+The protocol itself is text-based and suffers from numerous
+issues and limitations. In particular it is not possible
+to execute requests concurrently (though pipelining is
+sometimes possible), and it’s also sometimes difficult
+to detect that a client disconnected.
    
+
    HTTP/1.1 does provide very good semantics for interacting
+with Web services. It defines the standard methods, headers
+and status codes used by HTTP/1.1 and HTTP/2 clients and
+servers.
    
+
    HTTP/1.1 also defines compatibility with an older version
+of the protocol, HTTP/1.0, which was never really standardized
+across implementations.
    
+
    The core of HTTP/1.1 is defined by RFC 7230, RFC 7231,
+RFC 7232, RFC 7233, RFC 7234 and RFC 7235. Numerous RFCs
+and other specifications exist defining additional HTTP
+methods, status codes, headers or semantics.
    
+
    
+
    
+
    
+
    Websocket
    
+
    
+
    Websocket is a protocol built on top of HTTP/1.1
+that provides a two-ways communication channel between the client and
+the server. Communication is asynchronous and can occur concurrently.
    
+
    It consists of a Javascript object allowing setting up a
+Websocket connection to the server, and a binary based
+protocol for sending data to the server or the client.
    
+
    Websocket connections can transfer either UTF-8 encoded text
+data or binary data. The protocol also includes support for
+implementing a ping/pong mechanism, allowing the server and
+the client to have more confidence that the connection is still
+alive.
    
+
    A Websocket connection can be used to transfer any kind of data,
+small or big, text or binary. Because of this Websocket is
+sometimes used for communication between systems.
    
+
    Websocket messages have no semantics on their own. Websocket
+is closer to TCP in that aspect, and requires you to design
+and implement your own protocol on top of it; or adapt an
+existing protocol to Websocket.
    
+
    Cowboy provides an interface known as Websocket handlers
+that gives complete control over a Websocket connection.
    
+
    The Websocket protocol is defined by RFC 6455.
    
+
    
+
    
+
    
+
    Long-lived requests
    
+
    
+
    Cowboy provides an interface that can be used to support
+long-polling or to stream large amounts of data reliably,
+including using Server-Sent Events.
    
+
    Long-polling is a mechanism in which the client performs
+a request which may not be immediately answered by the
+server. It allows clients to request resources that may
+not currently exist, but are expected to be created soon,
+and which will be returned as soon as they are.
    
+
    Long-polling is essentially a hack, but it is widely used
+to overcome limitations on older clients and servers.
    
+
    Server-Sent Events is a small protocol defined as a media
+type, text/event-stream, along with a new HTTP header,
+Last-Event-ID. It is defined in the EventSource W3C
+specification.
    
+
    Cowboy provides an interface known as loop handlers
+that facilitates the implementation of long-polling or stream
+mechanisms. It works regardless of the underlying protocol.
    
+
    
+
    
+
    
+
    REST
    
+
    
+
    REST, or REpresentational State Transfer,
+is a style of architecture for loosely connected distributed
+systems. It can easily be implemented on top of HTTP.
    
+
    REST is essentially a set of constraints to be followed.
+Many of these constraints are purely architectural and
+solved by simply using HTTP. Some constraints must be
+explicitly followed by the developer.
    
+
    Cowboy provides an interface known as REST handlers
+that simplifies the implementation of a REST API on top of
+the HTTP protocol.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/multipart.asciidoc b/docs/en/cowboy/2.1/guide/multipart.asciidoc
new file mode 100644
index 00000000..0825244c
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/multipart.asciidoc
@@ -0,0 +1,169 @@
+[[multipart]]
+== Multipart requests
+
+Multipart originates from MIME, an Internet standard that
+extends the format of emails.
+
+A multipart message is a list of parts. A part contains
+headers and a body. The body of the parts may be
+of any media type, and contain text or binary data.
+It is possible for parts to contain a multipart media
+type.
+
+In the context of HTTP, multipart is most often used
+with the `multipart/form-data` media type. It is what
+browsers use to upload files through HTML forms.
+
+The `multipart/byteranges` is also common. It is the
+media type used to send arbitrary bytes from a resource,
+enabling clients to resume downloads.
+
+=== Form-data
+
+In the normal case, when a form is submitted, the
+browser will use the `application/x-www-form-urlencoded`
+content-type. This type is just a list of keys and
+values and is therefore not fit for uploading files.
+
+That's where the `multipart/form-data` content-type
+comes in. When the form is configured to use this
+content-type, the browser will create a multipart
+message where each part corresponds to a field on
+the form. For files, it also adds some metadata in
+the part headers, like the file name.
+
+A form with a text input, a file input and a select
+choice box will result in a multipart message with
+three parts, one for each field.
+
+The browser does its best to determine the media type
+of the files it sends this way, but you should not
+rely on it for determining the contents of the file.
+Proper investigation of the contents is recommended.
+
+=== Checking for multipart messages
+
+The content-type header indicates the presence of
+a multipart message:
+
+[source,erlang]
+----
+{<<"multipart">>, <<"form-data">>, _}
+    = cowboy_req:parse_header(<<"content-type">>, Req).
+----
+
+=== Reading a multipart message
+
+Cowboy provides two sets of functions for reading
+request bodies as multipart messages.
+
+The `cowboy_req:read_part/1,2` functions return the
+next part's headers, if any.
+
+The `cowboy_req:read_part_body/1,2` functions return
+the current part's body. For large bodies you may
+need to call the function multiple times.
+
+To read a multipart message you need to iterate over
+all its parts:
+
+[source,erlang]
+----
+multipart(Req0) ->
+    case cowboy_req:read_part(Req0) of
+        {ok, _Headers, Req1} ->
+            {ok, _Body, Req} = cowboy_req:read_part_body(Req1),
+            multipart(Req);
+        {done, Req} ->
+            Req
+    end.
+----
+
+When part bodies are too large, Cowboy will return
+a `more` tuple, and allow you to loop until the part
+body has been fully read.
+
+The function `cow_multipart:form_data/1` can be used
+to quickly obtain information about a part from a
+`multipart/form-data` message. The function returns
+a `data` or a `file` tuple depending on whether this
+is a normal field or a file being uploaded.
+
+The following snippet will use this function and
+use different strategies depending on whether the
+part is a file:
+
+[source,erlang]
+----
+multipart(Req0) ->
+    case cowboy_req:read_part(Req0) of
+        {ok, Headers, Req1} ->
+            Req = case cow_multipart:form_data(Headers) of
+                {data, _FieldName} ->
+                    {ok, _Body, Req2} = cowboy_req:read_part_body(Req1),
+                    Req2;
+                {file, _FieldName, _Filename, _CType} ->
+                    stream_file(Req1)
+            end,
+            multipart(Req);
+        {done, Req} ->
+            Req
+    end.
+
+stream_file(Req0) ->
+    case cowboy_req:read_part_body(Req0) of
+        {ok, _LastBodyChunk, Req} ->
+            Req;
+        {more, _BodyChunk, Req} ->
+            stream_file(Req)
+    end.
+----
+
+Both the part header and body reading functions can take
+options that will be given to the request body reading
+functions. By default, `cowboy_req:read_part/1` reads
+up to 64KB for up to 5 seconds. `cowboy_req:read_part_body/1`
+has the same defaults as `cowboy_req:read_body/1`.
+
+To change the defaults for part headers:
+
+[source,erlang]
+cowboy_req:read_part(Req, #{length => 128000}).
+
+And for part bodies:
+
+[source,erlang]
+cowboy_req:read_part_body(Req, #{length => 1000000, period => 7000}).
+
+=== Skipping unwanted parts
+
+Part bodies do not have to be read. Cowboy will automatically
+skip it when you request the next part's body.
+
+The following snippet reads all part headers and skips
+all bodies:
+
+[source,erlang]
+----
+multipart(Req0) ->
+    case cowboy_req:read_part(Req0) of
+        {ok, _Headers, Req} ->
+            multipart(Req);
+        {done, Req} ->
+            Req
+    end.
+----
+
+Similarly, if you start reading the body and it ends up
+being too big, you can simply continue with the next part.
+Cowboy will automatically skip what remains.
+
+While Cowboy can skip part bodies automatically, the read
+rate is not configurable. Depending on your application
+you may want to skip manually, in particular if you observe
+poor performance while skipping.
+
+You do not have to read all parts either. You can stop
+reading as soon as you find the data you need.
+
+// @todo Cover the building of multipart messages.
diff --git a/docs/en/cowboy/2.1/guide/multipart/index.html b/docs/en/cowboy/2.1/guide/multipart/index.html
new file mode 100644
index 00000000..509462c6
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/multipart/index.html
@@ -0,0 +1,326 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Multipart requests
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Multipart requests
    
+
+
    Multipart originates from MIME, an Internet standard that
+extends the format of emails.
    
+
    A multipart message is a list of parts. A part contains
+headers and a body. The body of the parts may be
+of any media type, and contain text or binary data.
+It is possible for parts to contain a multipart media
+type.
    
+
    In the context of HTTP, multipart is most often used
+with the multipart/form-data media type. It is what
+browsers use to upload files through HTML forms.
    
+
    The multipart/byteranges is also common. It is the
+media type used to send arbitrary bytes from a resource,
+enabling clients to resume downloads.
    
+
    
+
    Form-data
    
+
    
+
    In the normal case, when a form is submitted, the
+browser will use the application/x-www-form-urlencoded
+content-type. This type is just a list of keys and
+values and is therefore not fit for uploading files.
    
+
    That’s where the multipart/form-data content-type
+comes in. When the form is configured to use this
+content-type, the browser will create a multipart
+message where each part corresponds to a field on
+the form. For files, it also adds some metadata in
+the part headers, like the file name.
    
+
    A form with a text input, a file input and a select
+choice box will result in a multipart message with
+three parts, one for each field.
    
+
    The browser does its best to determine the media type
+of the files it sends this way, but you should not
+rely on it for determining the contents of the file.
+Proper investigation of the contents is recommended.
    
+
    
+
    
+
    
+
    Checking for multipart messages
    
+
    
+
    The content-type header indicates the presence of
+a multipart message:
    
+
    
+
    
+
    {<<"multipart">>, <<"form-data">>, _}
+    = cowboy_req:parse_header(<<"content-type">>, Req).
    
+
    
+
    
+
    
+
    Reading a multipart message
    
+
    
+
    Cowboy provides two sets of functions for reading
+request bodies as multipart messages.
    
+
    The cowboy_req:read_part/1,2 functions return the
+next part’s headers, if any.
    
+
    The cowboy_req:read_part_body/1,2 functions return
+the current part’s body. For large bodies you may
+need to call the function multiple times.
    
+
    To read a multipart message you need to iterate over
+all its parts:
    
+
    
+
    
+
    multipart(Req0) ->
+    case cowboy_req:read_part(Req0) of
+        {ok, _Headers, Req1} ->
+            {ok, _Body, Req} = cowboy_req:read_part_body(Req1),
+            multipart(Req);
+        {done, Req} ->
+            Req
+    end.
    
+
    When part bodies are too large, Cowboy will return
+a more tuple, and allow you to loop until the part
+body has been fully read.
    
+
    The function cow_multipart:form_data/1 can be used
+to quickly obtain information about a part from a
+multipart/form-data message. The function returns
+a data or a file tuple depending on whether this
+is a normal field or a file being uploaded.
    
+
    The following snippet will use this function and
+use different strategies depending on whether the
+part is a file:
    
+
    
+
    
+
    multipart(Req0) ->
+    case cowboy_req:read_part(Req0) of
+        {ok, Headers, Req1} ->
+            Req = case cow_multipart:form_data(Headers) of
+                {data, _FieldName} ->
+                    {ok, _Body, Req2} = cowboy_req:read_part_body(Req1),
+                    Req2;
+                {file, _FieldName, _Filename, _CType} ->
+                    stream_file(Req1)
+            end,
+            multipart(Req);
+        {done, Req} ->
+            Req
+    end.
+
+stream_file(Req0) ->
+    case cowboy_req:read_part_body(Req0) of
+        {ok, _LastBodyChunk, Req} ->
+            Req;
+        {more, _BodyChunk, Req} ->
+            stream_file(Req)
+    end.
    
+
    Both the part header and body reading functions can take
+options that will be given to the request body reading
+functions. By default, cowboy_req:read_part/1 reads
+up to 64KB for up to 5 seconds. cowboy_req:read_part_body/1
+has the same defaults as cowboy_req:read_body/1.
    
+
    To change the defaults for part headers:
    
+
    
+
    
+
    cowboy_req:read_part(Req, #{length => 128000}).
    
+
    And for part bodies:
    
+
    
+
    
+
    cowboy_req:read_part_body(Req, #{length => 1000000, period => 7000}).
    
+
    
+
    
+
    
+
    Skipping unwanted parts
    
+
    
+
    Part bodies do not have to be read. Cowboy will automatically
+skip it when you request the next part’s body.
    
+
    The following snippet reads all part headers and skips
+all bodies:
    
+
    
+
    
+
    multipart(Req0) ->
+    case cowboy_req:read_part(Req0) of
+        {ok, _Headers, Req} ->
+            multipart(Req);
+        {done, Req} ->
+            Req
+    end.
    
+
    Similarly, if you start reading the body and it ends up
+being too big, you can simply continue with the next part.
+Cowboy will automatically skip what remains.
    
+
    While Cowboy can skip part bodies automatically, the read
+rate is not configurable. Depending on your application
+you may want to skip manually, in particular if you observe
+poor performance while skipping.
    
+
    You do not have to read all parts either. You can stop
+reading as soon as you find the data you need.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/req.asciidoc b/docs/en/cowboy/2.1/guide/req.asciidoc
new file mode 100644
index 00000000..b879fa3d
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/req.asciidoc
@@ -0,0 +1,366 @@
+[[req]]
+== The Req object
+
+The Req object is a variable used for obtaining information
+about a request, read its body or send a response.
+
+It is not really an object in the object-oriented sense.
+It is a simple map that can be directly accessed or
+used when calling functions from the `cowboy_req` module.
+
+The Req object is the subject of a few different chapters.
+In this chapter we will learn about the Req object and
+look at how to retrieve information about the request.
+
+=== Direct access
+
+The Req map contains a number of fields which are documented
+and can be accessed directly. They are the fields that have
+a direct mapping to HTTP: the request `method`; the HTTP
+`version` used; the effective URI components `scheme`,
+`host`, `port`, `path` and `qs`; the request `headers`;
+and the connection `peer` address and port.
+
+Note that the `version` field can be used to determine
+whether a connection is using HTTP/2.
+
+To access a field, you can simply match in the function
+head. The following example sends a simple "Hello world!"
+response when the `method` is GET, and a 405 error
+otherwise.
+
+[source,erlang]
+----
+init(Req0=#{method := <<"GET">>}, State) ->
+    Req = cowboy_req:reply(200, #{
+        <<"content-type">> => <<"text/plain">>
+    }, <<"Hello world!">>, Req0),
+    {ok, Req, State};
+init(Req0, State) ->
+    Req = cowboy_req:reply(405, #{
+        <<"allow">> => <<"GET">>
+    }, Req0),
+    {ok, Req, State}.
+----
+
+Any other field is internal and should not be accessed.
+They may change in future releases, including maintenance
+releases, without notice.
+
+Modifying the Req object, while allowed, is not recommended
+unless strictly necessary. If adding new fields, make sure
+to namespace the field names so that no conflict can occur
+with future Cowboy updates or third party projects.
+
+// @todo There are currently no tests for direct access.
+
+=== Introduction to the cowboy_req interface
+
+// @todo Link to cowboy_req manual
+
+Functions in the `cowboy_req` module provide access to
+the request information but also various operations that
+are common when dealing with HTTP requests.
+
+All the functions that begin with a verb indicate an action.
+Other functions simply return the corresponding value
+(sometimes that value does need to be built, but the
+cost of the operation is equivalent to retrieving a value).
+
+Some of the `cowboy_req` functions return an updated Req
+object. They are the read, reply, set and delete functions.
+While ignoring the returned Req will not cause incorrect
+behavior for some of them, it is highly recommended to
+always keep and use the last returned Req object. The
+manual for `cowboy_req` details these functions and what
+modifications are done to the Req object.
+
+Some of the calls to `cowboy_req` have side effects. This
+is the case of the read and reply functions. Cowboy reads
+the request body or replies immediately when the function
+is called.
+
+All functions will crash if something goes wrong. There
+is usually no need to catch these errors, Cowboy will
+send the appropriate 4xx or 5xx response depending on
+where the crash occurred.
+
+=== Request method
+
+The request method can be retrieved directly:
+
+[source, erlang]
+#{method := Method} = Req.
+
+Or using a function:
+
+[source,erlang]
+Method = cowboy_req:method(Req).
+
+The method is a case sensitive binary string. Standard
+methods include GET, HEAD, OPTIONS, PATCH, POST, PUT
+or DELETE.
+
+=== HTTP version
+
+The HTTP version is informational. It does not indicate that
+the client implements the protocol well or fully.
+
+There is typically no need to change behavior based on the
+HTTP version: Cowboy already does it for you.
+
+It can be useful in some cases, though. For example, one may
+want to redirect HTTP/1.1 clients to use Websocket, while HTTP/2
+clients keep using HTTP/2.
+
+The HTTP version can be retrieved directly:
+
+[source,erlang]
+#{version := Version} = Req.
+
+Or using a function:
+
+[source,erlang]
+Version = cowboy_req:version(Req).
+
+Cowboy defines the `'HTTP/1.0'`, `'HTTP/1.1'` and `'HTTP/2'`
+versions. Custom protocols can define their own values as
+atoms.
+
+=== Effective request URI
+
+The scheme, host, port, path and query string components
+of the effective request URI can all be retrieved directly:
+
+[source,erlang]
+----
+#{
+    scheme := Scheme,
+    host := Host,
+    port := Port,
+    path := Path,
+    qs := Qs
+} = Req.
+----
+
+Or using the related functions:
+
+[source,erlang]
+Scheme = cowboy_req:scheme(Req),
+Host = cowboy_req:host(Req),
+Port = cowboy_req:port(Req),
+Path = cowboy_req:path(Req).
+Qs = cowboy_req:qs(Req).
+
+The scheme and host are lowercased case insensitive binary
+strings. The port is an integer representing the port number.
+The path and query string are case sensitive binary strings.
+
+Cowboy defines only the `<<"http">>` and `<<"https">>` schemes.
+They are chosen so that the scheme will only be `<<"https">>`
+for requests on secure HTTP/1.1 or HTTP/2 connections.
+// @todo Is that tested well?
+
+The effective request URI itself can be reconstructed with
+the `cowboy_req:uri/1,2` function. By default, an absolute
+URI is returned:
+
+[source,erlang]
+%% scheme://host[:port]/path[?qs]
+URI = cowboy_req:uri(Req).
+
+Options are available to either disable or replace some
+or all of the components. Various URIs or URI formats can
+be generated this way, including the origin form:
+
+[source,erlang]
+%% /path[?qs]
+URI = cowboy_req:uri(Req, #{host => undefined}).
+
+The protocol relative form:
+
+[source,erlang]
+%% //host[:port]/path[?qs]
+URI = cowboy_req:uri(Req, #{scheme => undefined}).
+
+The absolute URI without a query string:
+
+[source,erlang]
+URI = cowboy_req:uri(Req, #{qs => undefined}).
+
+A different host:
+
+[source,erlang]
+URI = cowboy_req:uri(Req, #{host => <<"example.org">>}).
+
+And any other combination.
+
+=== Bindings
+
+Bindings are the host and path components that you chose
+to extract when defining the routes of your application.
+They are only available after the routing.
+
+Cowboy provides functions to retrieve one or all bindings.
+
+To retrieve a single value:
+
+[source,erlang]
+Value = cowboy_req:binding(userid, Req).
+
+When attempting to retrieve a value that was not bound,
+`undefined` will be returned. A different default value
+can be provided:
+
+[source,erlang]
+Value = cowboy_req:binding(userid, Req, 42).
+
+To retrieve everything that was bound:
+
+[source,erlang]
+Bindings = cowboy_req:bindings(Req).
+
+They are returned as a map, with keys being atoms.
+
+The Cowboy router also allows you to capture many host
+or path segments at once using the `...` qualifier.
+
+To retrieve the segments captured from the host name:
+
+[source,erlang]
+HostInfo = cowboy_req:host_info(Req).
+
+And the path segments:
+
+[source,erlang]
+PathInfo = cowboy_req:path_info(Req).
+
+Cowboy will return `undefined` if `...` was not used
+in the route.
+
+=== Query parameters
+
+Cowboy provides two functions to access query parameters.
+You can use the first to get the entire list of parameters.
+
+[source,erlang]
+QsVals = cowboy_req:parse_qs(Req),
+{_, Lang} = lists:keyfind(<<"lang">>, 1, QsVals).
+
+Cowboy will only parse the query string, and not do any
+transformation. This function may therefore return duplicates,
+or parameter names without an associated value. The order of
+the list returned is undefined.
+
+When a query string is `key=1&key=2`, the list returned will
+contain two parameters of name `key`.
+
+The same is true when trying to use the PHP-style suffix `[]`.
+When a query string is `key[]=1&key[]=2`, the list returned will
+contain two parameters of name `key[]`.
+
+When a query string is simply `key`, Cowboy will return the
+list `[{<<"key">>, true}]`, using `true` to indicate that the
+parameter `key` was defined, but with no value.
+
+The second function Cowboy provides allows you to match out
+only the parameters you are interested in, and at the same
+time do any post processing you require using xref:constraints[constraints].
+This function returns a map.
+
+[source,erlang]
+#{id := ID, lang := Lang} = cowboy_req:match_qs([id, lang], Req).
+
+Constraints can be applied automatically. The following
+snippet will crash when the `id` parameter is not an integer,
+or when the `lang` parameter is empty. At the same time, the
+value for `id` will be converted to an integer term:
+
+[source,erlang]
+QsMap = cowboy_req:match_qs([{id, int}, {lang, nonempty}], Req).
+
+A default value may also be provided. The default will be used
+if the `lang` key is not found. It will not be used if
+the key is found but has an empty value.
+
+[source,erlang]
+#{lang := Lang} = cowboy_req:match_qs([{lang, [], <<"en-US">>}], Req).
+
+If no default is provided and the value is missing, the
+query string is deemed invalid and the process will crash.
+
+When the query string is `key=1&key=2`, the value for `key`
+will be the list `[1, 2]`. Parameter names do not need to
+include the PHP-style suffix. Constraints may be used to
+ensure that only one value was passed through.
+
+=== Headers
+
+Header values can be retrieved either as a binary string
+or parsed into a more meaningful representation.
+
+The get the raw value:
+
+[source,erlang]
+HeaderVal = cowboy_req:header(<<"content-type">>, Req).
+
+Cowboy expects all header names to be provided as lowercase
+binary strings. This is true for both requests and responses,
+regardless of the underlying protocol.
+
+When the header is missing from the request, `undefined`
+will be returned. A different default can be provided:
+
+[source,erlang]
+HeaderVal = cowboy_req:header(<<"content-type">>, Req, <<"text/plain">>).
+
+All headers can be retrieved at once, either directly:
+
+[source,erlang]
+#{headers := AllHeaders} = Req.
+
+Or using a function:
+
+[source,erlang]
+AllHeaders = cowboy_req:headers(Req).
+
+Cowboy provides equivalent functions to parse individual
+headers. There is no function to parse all headers at once.
+
+To parse a specific header:
+
+[source,erlang]
+ParsedVal = cowboy_req:parse_header(<<"content-type">>, Req).
+
+An exception will be thrown if it doesn't know how to parse the
+given header, or if the value is invalid. The list of known headers
+and default values can be found in the manual.
+
+When the header is missing, `undefined` is returned. You can
+change the default value. Note that it should be the parsed value
+directly:
+
+[source,erlang]
+----
+ParsedVal = cowboy_req:parse_header(<<"content-type">>, Req,
+    {<<"text">>, <<"plain">>, []}).
+----
+
+=== Peer
+
+The peer address and port number for the connection can be
+retrieved either directly or using a function.
+
+To retrieve the peer directly:
+
+[source,erlang]
+#{peer := {IP, Port}} = Req.
+
+And using a function:
+
+[source,erlang]
+{IP, Port} = cowboy_req:peer(Req).
+
+Note that the peer corresponds to the remote end of the
+connection to the server, which may or may not be the
+client itself. It may also be a proxy or a gateway.
diff --git a/docs/en/cowboy/2.1/guide/req/index.html b/docs/en/cowboy/2.1/guide/req/index.html
new file mode 100644
index 00000000..cfc7b97e
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/req/index.html
@@ -0,0 +1,564 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: The Req object
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    The Req object
    
+
+
    The Req object is a variable used for obtaining information
+about a request, read its body or send a response.
    
+
    It is not really an object in the object-oriented sense.
+It is a simple map that can be directly accessed or
+used when calling functions from the cowboy_req module.
    
+
    The Req object is the subject of a few different chapters.
+In this chapter we will learn about the Req object and
+look at how to retrieve information about the request.
    
+
    
+
    Direct access
    
+
    
+
    The Req map contains a number of fields which are documented
+and can be accessed directly. They are the fields that have
+a direct mapping to HTTP: the request method; the HTTP
+version used; the effective URI components scheme,
+host, port, path and qs; the request headers;
+and the connection peer address and port.
    
+
    Note that the version field can be used to determine
+whether a connection is using HTTP/2.
    
+
    To access a field, you can simply match in the function
+head. The following example sends a simple "Hello world!"
+response when the method is GET, and a 405 error
+otherwise.
    
+
    
+
    
+
    init(Req0=#{method := <<"GET">>}, State) ->
+    Req = cowboy_req:reply(200, #{
+        <<"content-type">> => <<"text/plain">>
+    }, <<"Hello world!">>, Req0),
+    {ok, Req, State};
+init(Req0, State) ->
+    Req = cowboy_req:reply(405, #{
+        <<"allow">> => <<"GET">>
+    }, Req0),
+    {ok, Req, State}.
    
+
    Any other field is internal and should not be accessed.
+They may change in future releases, including maintenance
+releases, without notice.
    
+
    Modifying the Req object, while allowed, is not recommended
+unless strictly necessary. If adding new fields, make sure
+to namespace the field names so that no conflict can occur
+with future Cowboy updates or third party projects.
    
+
    
+
    
+
    
+
    Introduction to the cowboy_req interface
    
+
    
+
    Functions in the cowboy_req module provide access to
+the request information but also various operations that
+are common when dealing with HTTP requests.
    
+
    All the functions that begin with a verb indicate an action.
+Other functions simply return the corresponding value
+(sometimes that value does need to be built, but the
+cost of the operation is equivalent to retrieving a value).
    
+
    Some of the cowboy_req functions return an updated Req
+object. They are the read, reply, set and delete functions.
+While ignoring the returned Req will not cause incorrect
+behavior for some of them, it is highly recommended to
+always keep and use the last returned Req object. The
+manual for cowboy_req details these functions and what
+modifications are done to the Req object.
    
+
    Some of the calls to cowboy_req have side effects. This
+is the case of the read and reply functions. Cowboy reads
+the request body or replies immediately when the function
+is called.
    
+
    All functions will crash if something goes wrong. There
+is usually no need to catch these errors, Cowboy will
+send the appropriate 4xx or 5xx response depending on
+where the crash occurred.
    
+
    
+
    
+
    
+
    Request method
    
+
    
+
    The request method can be retrieved directly:
    
+
    
+
    
+
    #{method := Method} = Req.
    
+
    Or using a function:
    
+
    
+
    
+
    Method = cowboy_req:method(Req).
    
+
    The method is a case sensitive binary string. Standard
+methods include GET, HEAD, OPTIONS, PATCH, POST, PUT
+or DELETE.
    
+
    
+
    
+
    
+
    HTTP version
    
+
    
+
    The HTTP version is informational. It does not indicate that
+the client implements the protocol well or fully.
    
+
    There is typically no need to change behavior based on the
+HTTP version: Cowboy already does it for you.
    
+
    It can be useful in some cases, though. For example, one may
+want to redirect HTTP/1.1 clients to use Websocket, while HTTP/2
+clients keep using HTTP/2.
    
+
    The HTTP version can be retrieved directly:
    
+
    
+
    
+
    #{version := Version} = Req.
    
+
    Or using a function:
    
+
    
+
    
+
    Version = cowboy_req:version(Req).
    
+
    Cowboy defines the 'HTTP/1.0', 'HTTP/1.1' and 'HTTP/2'
+versions. Custom protocols can define their own values as
+atoms.
    
+
    
+
    
+
    
+
    Effective request URI
    
+
    
+
    The scheme, host, port, path and query string components
+of the effective request URI can all be retrieved directly:
    
+
    
+
    
+
    #{
+    scheme := Scheme,
+    host := Host,
+    port := Port,
+    path := Path,
+    qs := Qs
+} = Req.
    
+
    Or using the related functions:
    
+
    
+
    
+
    Scheme = cowboy_req:scheme(Req),
+Host = cowboy_req:host(Req),
+Port = cowboy_req:port(Req),
+Path = cowboy_req:path(Req).
+Qs = cowboy_req:qs(Req).
    
+
    The scheme and host are lowercased case insensitive binary
+strings. The port is an integer representing the port number.
+The path and query string are case sensitive binary strings.
    
+
    Cowboy defines only the <<"http">> and <<"https">> schemes.
+They are chosen so that the scheme will only be <<"https">>
+for requests on secure HTTP/1.1 or HTTP/2 connections.
    
+
    The effective request URI itself can be reconstructed with
+the cowboy_req:uri/1,2 function. By default, an absolute
+URI is returned:
    
+
    
+
    
+
    %% scheme://host[:port]/path[?qs]
+URI = cowboy_req:uri(Req).
    
+
    Options are available to either disable or replace some
+or all of the components. Various URIs or URI formats can
+be generated this way, including the origin form:
    
+
    
+
    
+
    %% /path[?qs]
+URI = cowboy_req:uri(Req, #{host => undefined}).
    
+
    The protocol relative form:
    
+
    
+
    
+
    %% //host[:port]/path[?qs]
+URI = cowboy_req:uri(Req, #{scheme => undefined}).
    
+
    The absolute URI without a query string:
    
+
    
+
    
+
    URI = cowboy_req:uri(Req, #{qs => undefined}).
    
+
    A different host:
    
+
    
+
    
+
    URI = cowboy_req:uri(Req, #{host => <<"example.org">>}).
    
+
    And any other combination.
    
+
    
+
    
+
    
+
    Bindings
    
+
    
+
    Bindings are the host and path components that you chose
+to extract when defining the routes of your application.
+They are only available after the routing.
    
+
    Cowboy provides functions to retrieve one or all bindings.
    
+
    To retrieve a single value:
    
+
    
+
    
+
    Value = cowboy_req:binding(userid, Req).
    
+
    When attempting to retrieve a value that was not bound,
+undefined will be returned. A different default value
+can be provided:
    
+
    
+
    
+
    Value = cowboy_req:binding(userid, Req, 42).
    
+
    To retrieve everything that was bound:
    
+
    
+
    
+
    Bindings = cowboy_req:bindings(Req).
    
+
    They are returned as a map, with keys being atoms.
    
+
    The Cowboy router also allows you to capture many host
+or path segments at once using the ... qualifier.
    
+
    To retrieve the segments captured from the host name:
    
+
    
+
    
+
    HostInfo = cowboy_req:host_info(Req).
    
+
    And the path segments:
    
+
    
+
    
+
    PathInfo = cowboy_req:path_info(Req).
    
+
    Cowboy will return undefined if ... was not used
+in the route.
    
+
    
+
    
+
    
+
    Query parameters
    
+
    
+
    Cowboy provides two functions to access query parameters.
+You can use the first to get the entire list of parameters.
    
+
    
+
    
+
    QsVals = cowboy_req:parse_qs(Req),
+{_, Lang} = lists:keyfind(<<"lang">>, 1, QsVals).
    
+
    Cowboy will only parse the query string, and not do any
+transformation. This function may therefore return duplicates,
+or parameter names without an associated value. The order of
+the list returned is undefined.
    
+
    When a query string is key=1&key=2, the list returned will
+contain two parameters of name key.
    
+
    The same is true when trying to use the PHP-style suffix [].
+When a query string is key[]=1&key[]=2, the list returned will
+contain two parameters of name key[].
    
+
    When a query string is simply key, Cowboy will return the
+list [{<<"key">>, true}], using true to indicate that the
+parameter key was defined, but with no value.
    
+
    The second function Cowboy provides allows you to match out
+only the parameters you are interested in, and at the same
+time do any post processing you require using constraints.
+This function returns a map.
    
+
    
+
    
+
    #{id := ID, lang := Lang} = cowboy_req:match_qs([id, lang], Req).
    
+
    Constraints can be applied automatically. The following
+snippet will crash when the id parameter is not an integer,
+or when the lang parameter is empty. At the same time, the
+value for id will be converted to an integer term:
    
+
    
+
    
+
    QsMap = cowboy_req:match_qs([{id, int}, {lang, nonempty}], Req).
    
+
    A default value may also be provided. The default will be used
+if the lang key is not found. It will not be used if
+the key is found but has an empty value.
    
+
    
+
    
+
    #{lang := Lang} = cowboy_req:match_qs([{lang, [], <<"en-US">>}], Req).
    
+
    If no default is provided and the value is missing, the
+query string is deemed invalid and the process will crash.
    
+
    When the query string is key=1&key=2, the value for key
+will be the list [1, 2]. Parameter names do not need to
+include the PHP-style suffix. Constraints may be used to
+ensure that only one value was passed through.
    
+
    
+
    
+
    
+
    Headers
    
+
    
+
    Header values can be retrieved either as a binary string
+or parsed into a more meaningful representation.
    
+
    The get the raw value:
    
+
    
+
    
+
    HeaderVal = cowboy_req:header(<<"content-type">>, Req).
    
+
    Cowboy expects all header names to be provided as lowercase
+binary strings. This is true for both requests and responses,
+regardless of the underlying protocol.
    
+
    When the header is missing from the request, undefined
+will be returned. A different default can be provided:
    
+
    
+
    
+
    HeaderVal = cowboy_req:header(<<"content-type">>, Req, <<"text/plain">>).
    
+
    All headers can be retrieved at once, either directly:
    
+
    
+
    
+
    #{headers := AllHeaders} = Req.
    
+
    Or using a function:
    
+
    
+
    
+
    AllHeaders = cowboy_req:headers(Req).
    
+
    Cowboy provides equivalent functions to parse individual
+headers. There is no function to parse all headers at once.
    
+
    To parse a specific header:
    
+
    
+
    
+
    ParsedVal = cowboy_req:parse_header(<<"content-type">>, Req).
    
+
    An exception will be thrown if it doesn’t know how to parse the
+given header, or if the value is invalid. The list of known headers
+and default values can be found in the manual.
    
+
    When the header is missing, undefined is returned. You can
+change the default value. Note that it should be the parsed value
+directly:
    
+
    
+
    
+
    ParsedVal = cowboy_req:parse_header(<<"content-type">>, Req,
+    {<<"text">>, <<"plain">>, []}).
    
+
    
+
    
+
    
+
    Peer
    
+
    
+
    The peer address and port number for the connection can be
+retrieved either directly or using a function.
    
+
    To retrieve the peer directly:
    
+
    
+
    
+
    #{peer := {IP, Port}} = Req.
    
+
    And using a function:
    
+
    
+
    
+
    {IP, Port} = cowboy_req:peer(Req).
    
+
    Note that the peer corresponds to the remote end of the
+connection to the server, which may or may not be the
+client itself. It may also be a proxy or a gateway.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/req_body.asciidoc b/docs/en/cowboy/2.1/guide/req_body.asciidoc
new file mode 100644
index 00000000..4906811e
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/req_body.asciidoc
@@ -0,0 +1,130 @@
+[[req_body]]
+== Reading the request body
+
+The request body can be read using the Req object.
+
+Cowboy will not attempt to read the body until requested.
+You need to call the body reading functions in order to
+retrieve it.
+
+Cowboy will not cache the body, it is therefore only
+possible to read it once.
+
+You are not required to read it, however. If a body is
+present and was not read, Cowboy will either cancel or
+skip its download, depending on the protocol.
+
+Cowboy provides functions for reading the body raw,
+and read and parse form urlencoded or xref:multipart[multipart bodies].
+The latter is covered in its own chapter.
+
+=== Request body presence
+
+Not all requests come with a body. You can check for
+the presence of a request body with this function:
+
+[source,erlang]
+cowboy_req:has_body(Req).
+
+It returns `true` if there is a body; `false` otherwise.
+
+In practice, this function is rarely used. When the
+method is `POST`, `PUT` or `PATCH`, the request body
+is often required by the application, which should
+just attempt to read it directly.
+
+=== Request body length
+
+You can obtain the length of the body:
+
+[source,erlang]
+Length = cowboy_req:body_length(Req).
+
+Note that the length may not be known in advance. In
+that case `undefined` will be returned. This can happen
+with HTTP/1.1's chunked transfer-encoding, or HTTP/2
+when no content-length was provided.
+
+Cowboy will update the body length in the Req object
+once the body has been read completely. A length will
+always be returned when attempting to call this function
+after reading the body completely.
+
+=== Reading the body
+
+You can read the entire body with one function call:
+
+[source,erlang]
+{ok, Data, Req} = cowboy_req:read_body(Req0).
+
+Cowboy returns an `ok` tuple when the body has been
+read fully.
+
+By default, Cowboy will attempt to read up to 8MB
+of data, for up to 15 seconds. The call will return
+once Cowboy has read at least 8MB of data, or at
+the end of the 15 seconds period.
+
+These values can be customized. For example, to read
+only up to 1MB for up to 5 seconds:
+
+[source,erlang]
+----
+{ok, Data, Req} = cowboy_req:read_body(Req0,
+    #{length => 1000000, period => 5000}).
+----
+
+You may also disable the length limit:
+
+[source,erlang]
+{ok, Data, Req} = cowboy_req:read_body(Req0, #{length => infinity}).
+
+This makes the function wait 15 seconds and return with
+whatever arrived during that period. This is not
+recommended for public facing applications.
+
+These two options can effectively be used to control
+the rate of transmission of the request body.
+
+=== Streaming the body
+
+When the body is too large, the first call will return
+a `more` tuple instead of `ok`. You can call the
+function again to read more of the body, reading
+it one chunk at a time.
+
+[source,erlang]
+----
+read_body_to_console(Req0) ->
+    case cowboy_req:read_body(Req0) of
+        {ok, Data, Req} ->
+            io:format("~s", [Data]),
+            Req;
+        {more, Data, Req} ->
+            io:format("~s", [Data]),
+            read_body_to_console(Req)
+    end.
+----
+
+The `length` and `period` options can also be used.
+They need to be passed for every call.
+
+=== Reading a form urlencoded body
+
+Cowboy provides a convenient function for reading and
+parsing bodies sent as application/x-www-form-urlencoded.
+
+[source,erlang]
+{ok, KeyValues, Req} = cowboy_req:read_urlencoded_body(Req0).
+
+This function returns a list of key/values, exactly like
+the function `cowboy_req:parse_qs/1`.
+
+The defaults for this function are different. Cowboy will
+read for up to 64KB and up to 5 seconds. They can be modified:
+
+[source,erlang]
+----
+{ok, KeyValues, Req} = cowboy_req:read_urlencoded_body(Req0,
+    #{length => 4096, period => 3000}).
+----
diff --git a/docs/en/cowboy/2.1/guide/req_body/index.html b/docs/en/cowboy/2.1/guide/req_body/index.html
new file mode 100644
index 00000000..724d2f6a
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/req_body/index.html
@@ -0,0 +1,301 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Reading the request body
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Reading the request body
    
+
+
    The request body can be read using the Req object.
    
+
    Cowboy will not attempt to read the body until requested.
+You need to call the body reading functions in order to
+retrieve it.
    
+
    Cowboy will not cache the body, it is therefore only
+possible to read it once.
    
+
    You are not required to read it, however. If a body is
+present and was not read, Cowboy will either cancel or
+skip its download, depending on the protocol.
    
+
    Cowboy provides functions for reading the body raw,
+and read and parse form urlencoded or multipart bodies.
+The latter is covered in its own chapter.
    
+
    
+
    Request body presence
    
+
    
+
    Not all requests come with a body. You can check for
+the presence of a request body with this function:
    
+
    
+
    
+
    cowboy_req:has_body(Req).
    
+
    It returns true if there is a body; false otherwise.
    
+
    In practice, this function is rarely used. When the
+method is POST, PUT or PATCH, the request body
+is often required by the application, which should
+just attempt to read it directly.
    
+
    
+
    
+
    
+
    Request body length
    
+
    
+
    You can obtain the length of the body:
    
+
    
+
    
+
    Length = cowboy_req:body_length(Req).
    
+
    Note that the length may not be known in advance. In
+that case undefined will be returned. This can happen
+with HTTP/1.1’s chunked transfer-encoding, or HTTP/2
+when no content-length was provided.
    
+
    Cowboy will update the body length in the Req object
+once the body has been read completely. A length will
+always be returned when attempting to call this function
+after reading the body completely.
    
+
    
+
    
+
    
+
    Reading the body
    
+
    
+
    You can read the entire body with one function call:
    
+
    
+
    
+
    {ok, Data, Req} = cowboy_req:read_body(Req0).
    
+
    Cowboy returns an ok tuple when the body has been
+read fully.
    
+
    By default, Cowboy will attempt to read up to 8MB
+of data, for up to 15 seconds. The call will return
+once Cowboy has read at least 8MB of data, or at
+the end of the 15 seconds period.
    
+
    These values can be customized. For example, to read
+only up to 1MB for up to 5 seconds:
    
+
    
+
    
+
    {ok, Data, Req} = cowboy_req:read_body(Req0,
+    #{length => 1000000, period => 5000}).
    
+
    You may also disable the length limit:
    
+
    
+
    
+
    {ok, Data, Req} = cowboy_req:read_body(Req0, #{length => infinity}).
    
+
    This makes the function wait 15 seconds and return with
+whatever arrived during that period. This is not
+recommended for public facing applications.
    
+
    These two options can effectively be used to control
+the rate of transmission of the request body.
    
+
    
+
    
+
    
+
    Streaming the body
    
+
    
+
    When the body is too large, the first call will return
+a more tuple instead of ok. You can call the
+function again to read more of the body, reading
+it one chunk at a time.
    
+
    
+
    
+
    read_body_to_console(Req0) ->
+    case cowboy_req:read_body(Req0) of
+        {ok, Data, Req} ->
+            io:format("~s", [Data]),
+            Req;
+        {more, Data, Req} ->
+            io:format("~s", [Data]),
+            read_body_to_console(Req)
+    end.
    
+
    The length and period options can also be used.
+They need to be passed for every call.
    
+
    
+
    
+
    
+
    Reading a form urlencoded body
    
+
    
+
    Cowboy provides a convenient function for reading and
+parsing bodies sent as application/x-www-form-urlencoded.
    
+
    
+
    
+
    {ok, KeyValues, Req} = cowboy_req:read_urlencoded_body(Req0).
    
+
    This function returns a list of key/values, exactly like
+the function cowboy_req:parse_qs/1.
    
+
    The defaults for this function are different. Cowboy will
+read for up to 64KB and up to 5 seconds. They can be modified:
    
+
    
+
    
+
    {ok, KeyValues, Req} = cowboy_req:read_urlencoded_body(Req0,
+    #{length => 4096, period => 3000}).
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/resource_design.asciidoc b/docs/en/cowboy/2.1/guide/resource_design.asciidoc
new file mode 100644
index 00000000..fa0c6122
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/resource_design.asciidoc
@@ -0,0 +1,220 @@
+[[resource_design]]
+== Designing a resource handler
+
+This chapter aims to provide you with a list of questions
+you must answer in order to write a good resource handler.
+It is meant to be usable as a step by step guide.
+
+=== The service
+
+Can the service become unavailable, and when it does, can
+we detect it? For example, database connectivity problems
+may be detected early. We may also have planned outages
+of all or parts of the system. Implement the
+`service_available` callback.
+
+What HTTP methods does the service implement? Do we need
+more than the standard OPTIONS, HEAD, GET, PUT, POST,
+PATCH and DELETE? Are we not using one of those at all?
+Implement the `known_methods` callback.
+
+=== Type of resource handler
+
+Am I writing a handler for a collection of resources,
+or for a single resource?
+
+The semantics for each of these are quite different.
+You should not mix collection and single resource in
+the same handler.
+
+=== Collection handler
+
+Skip this section if you are not doing a collection.
+
+Is the collection hardcoded or dynamic? For example,
+if you use the route `/users` for the collection of
+users then the collection is hardcoded; if you use
+`/forums/:category` for the collection of threads
+then it isn't. When the collection is hardcoded you
+can safely assume the resource always exists.
+
+What methods should I implement?
+
+OPTIONS is used to get some information about the
+collection. It is recommended to allow it even if you
+do not implement it, as Cowboy has a default
+implementation built-in.
+
+HEAD and GET are used to retrieve the collection.
+If you allow GET, also allow HEAD as there's no extra
+work required to make it work.
+
+POST is used to create a new resource inside the
+collection. Creating a resource by using POST on
+the collection is useful when resources may be
+created before knowing their URI, usually because
+parts of it are generated dynamically. A common
+case is some kind of auto incremented integer
+identifier.
+
+The next methods are more rarely allowed.
+
+PUT is used to create a new collection (when
+the collection isn't hardcoded), or replace
+the entire collection.
+
+DELETE is used to delete the entire collection.
+
+PATCH is used to modify the collection using
+instructions given in the request body. A PATCH
+operation is atomic. The PATCH operation may
+be used for such things as reordering; adding,
+modifying or deleting parts of the collection.
+
+=== Single resource handler
+
+Skip this section if you are doing a collection.
+
+What methods should I implement?
+
+OPTIONS is used to get some information about the
+resource. It is recommended to allow it even if you
+do not implement it, as Cowboy has a default
+implementation built-in.
+
+HEAD and GET are used to retrieve the resource.
+If you allow GET, also allow HEAD as there's no extra
+work required to make it work.
+
+POST is used to update the resource.
+
+PUT is used to create a new resource (when it doesn't
+already exist) or replace the resource.
+
+DELETE is used to delete the resource.
+
+PATCH is used to modify the resource using
+instructions given in the request body. A PATCH
+operation is atomic. The PATCH operation may
+be used for adding, removing or modifying specific
+values in the resource.
+
+=== The resource
+
+Following the above discussion, implement the
+`allowed_methods` callback.
+
+Does the resource always exist? If it may not, implement
+the `resource_exists` callback.
+
+Do I need to authenticate the client before they can
+access the resource? What authentication mechanisms
+should I provide? This may include form-based, token-based
+(in the URL or a cookie), HTTP basic, HTTP digest,
+SSL certificate or any other form of authentication.
+Implement the `is_authorized` callback.
+
+Do I need fine-grained access control? How do I determine
+that they are authorized access? Handle that in your
+`is_authorized` callback.
+
+Can access to a resource be forbidden regardless of access
+being authorized? A simple example of that is censorship
+of a resource. Implement the `forbidden` callback.
+
+Are there any constraints on the length of the resource URI?
+For example, the URI may be used as a key in storage and may
+have a limit in length. Implement `uri_too_long`.
+
+=== Representations
+
+What media types do I provide? If text based, what charsets
+are provided? What languages do I provide?
+
+Implement the mandatory `content_types_provided`. Prefix
+the callbacks with `to_` for clarity. For example, `to_html`
+or `to_text`.
+
+Implement the `languages_provided` or `charsets_provided`
+callbacks if applicable.
+
+Is there any other header that may make the representation
+of the resource vary? Implement the `variances` callback.
+
+Depending on your choices for caching content, you may
+want to implement one or more of the `generate_etag`,
+`last_modified` and `expires` callbacks.
+
+Do I want the user or user agent to actively choose a
+representation available? Send a list of available
+representations in the response body and implement
+the `multiple_choices` callback.
+
+=== Redirections
+
+Do I need to keep track of what resources were deleted?
+For example, you may have a mechanism where moving a
+resource leaves a redirect link to its new location.
+Implement the `previously_existed` callback.
+
+Was the resource moved, and is the move temporary? If
+it is explicitly temporary, for example due to maintenance,
+implement the `moved_temporarily` callback. Otherwise,
+implement the `moved_permanently` callback.
+
+=== The request
+
+Do you need to read the query string? Individual headers?
+Implement `malformed_request` and do all the parsing and
+validation in this function. Note that the body should not
+be read at this point.
+
+May there be a request body? Will I know its size?
+What's the maximum size of the request body I'm willing
+to accept? Implement `valid_entity_length`.
+
+Finally, take a look at the sections corresponding to the
+methods you are implementing.
+
+=== OPTIONS method
+
+Cowboy by default will send back a list of allowed methods.
+Do I need to add more information to the response? Implement
+the `options` method.
+
+=== GET and HEAD methods
+
+If you implement the methods GET and/or HEAD, you must
+implement one `ProvideResource` callback for each
+content-type returned by the `content_types_provided`
+callback.
+
+=== PUT, POST and PATCH methods
+
+If you implement the methods PUT, POST and/or PATCH,
+you must implement the `content_types_accepted` callback,
+and one `AcceptCallback` callback for each content-type
+it returns. Prefix the `AcceptCallback` callback names
+with `from_` for clarity. For example, `from_html` or
+`from_json`.
+
+Do we want to allow the POST method to create individual
+resources directly through their URI (like PUT)? Implement
+the `allow_missing_post` callback. It is recommended to
+explicitly use PUT in these cases instead.
+
+May there be conflicts when using PUT to create or replace
+a resource? Do we want to make sure that two updates around
+the same time are not cancelling one another? Implement the
+`is_conflict` callback.
+
+=== DELETE methods
+
+If you implement the method DELETE, you must implement
+the `delete_resource` callback.
+
+When `delete_resource` returns, is the resource completely
+removed from the server, including from any caching service?
+If not, and/or if the deletion is asynchronous and we have
+no way of knowing it has been completed yet, implement the
+`delete_completed` callback.
diff --git a/docs/en/cowboy/2.1/guide/resource_design/index.html b/docs/en/cowboy/2.1/guide/resource_design/index.html
new file mode 100644
index 00000000..42e31625
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/resource_design/index.html
@@ -0,0 +1,370 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Designing a resource handler
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Designing a resource handler
    
+
+
    This chapter aims to provide you with a list of questions
+you must answer in order to write a good resource handler.
+It is meant to be usable as a step by step guide.
    
+
    
+
    The service
    
+
    
+
    Can the service become unavailable, and when it does, can
+we detect it? For example, database connectivity problems
+may be detected early. We may also have planned outages
+of all or parts of the system. Implement the
+service_available callback.
    
+
    What HTTP methods does the service implement? Do we need
+more than the standard OPTIONS, HEAD, GET, PUT, POST,
+PATCH and DELETE? Are we not using one of those at all?
+Implement the known_methods callback.
    
+
    
+
    
+
    
+
    Type of resource handler
    
+
    
+
    Am I writing a handler for a collection of resources,
+or for a single resource?
    
+
    The semantics for each of these are quite different.
+You should not mix collection and single resource in
+the same handler.
    
+
    
+
    
+
    
+
    Collection handler
    
+
    
+
    Skip this section if you are not doing a collection.
    
+
    Is the collection hardcoded or dynamic? For example,
+if you use the route /users for the collection of
+users then the collection is hardcoded; if you use
+/forums/:category for the collection of threads
+then it isn’t. When the collection is hardcoded you
+can safely assume the resource always exists.
    
+
    What methods should I implement?
    
+
    OPTIONS is used to get some information about the
+collection. It is recommended to allow it even if you
+do not implement it, as Cowboy has a default
+implementation built-in.
    
+
    HEAD and GET are used to retrieve the collection.
+If you allow GET, also allow HEAD as there’s no extra
+work required to make it work.
    
+
    POST is used to create a new resource inside the
+collection. Creating a resource by using POST on
+the collection is useful when resources may be
+created before knowing their URI, usually because
+parts of it are generated dynamically. A common
+case is some kind of auto incremented integer
+identifier.
    
+
    The next methods are more rarely allowed.
    
+
    PUT is used to create a new collection (when
+the collection isn’t hardcoded), or replace
+the entire collection.
    
+
    DELETE is used to delete the entire collection.
    
+
    PATCH is used to modify the collection using
+instructions given in the request body. A PATCH
+operation is atomic. The PATCH operation may
+be used for such things as reordering; adding,
+modifying or deleting parts of the collection.
    
+
    
+
    
+
    
+
    Single resource handler
    
+
    
+
    Skip this section if you are doing a collection.
    
+
    What methods should I implement?
    
+
    OPTIONS is used to get some information about the
+resource. It is recommended to allow it even if you
+do not implement it, as Cowboy has a default
+implementation built-in.
    
+
    HEAD and GET are used to retrieve the resource.
+If you allow GET, also allow HEAD as there’s no extra
+work required to make it work.
    
+
    POST is used to update the resource.
    
+
    PUT is used to create a new resource (when it doesn’t
+already exist) or replace the resource.
    
+
    DELETE is used to delete the resource.
    
+
    PATCH is used to modify the resource using
+instructions given in the request body. A PATCH
+operation is atomic. The PATCH operation may
+be used for adding, removing or modifying specific
+values in the resource.
    
+
    
+
    
+
    
+
    The resource
    
+
    
+
    Following the above discussion, implement the
+allowed_methods callback.
    
+
    Does the resource always exist? If it may not, implement
+the resource_exists callback.
    
+
    Do I need to authenticate the client before they can
+access the resource? What authentication mechanisms
+should I provide? This may include form-based, token-based
+(in the URL or a cookie), HTTP basic, HTTP digest,
+SSL certificate or any other form of authentication.
+Implement the is_authorized callback.
    
+
    Do I need fine-grained access control? How do I determine
+that they are authorized access? Handle that in your
+is_authorized callback.
    
+
    Can access to a resource be forbidden regardless of access
+being authorized? A simple example of that is censorship
+of a resource. Implement the forbidden callback.
    
+
    Are there any constraints on the length of the resource URI?
+For example, the URI may be used as a key in storage and may
+have a limit in length. Implement uri_too_long.
    
+
    
+
    
+
    
+
    Representations
    
+
    
+
    What media types do I provide? If text based, what charsets
+are provided? What languages do I provide?
    
+
    Implement the mandatory content_types_provided. Prefix
+the callbacks with to_ for clarity. For example, to_html
+or to_text.
    
+
    Implement the languages_provided or charsets_provided
+callbacks if applicable.
    
+
    Is there any other header that may make the representation
+of the resource vary? Implement the variances callback.
    
+
    Depending on your choices for caching content, you may
+want to implement one or more of the generate_etag,
+last_modified and expires callbacks.
    
+
    Do I want the user or user agent to actively choose a
+representation available? Send a list of available
+representations in the response body and implement
+the multiple_choices callback.
    
+
    
+
    
+
    
+
    Redirections
    
+
    
+
    Do I need to keep track of what resources were deleted?
+For example, you may have a mechanism where moving a
+resource leaves a redirect link to its new location.
+Implement the previously_existed callback.
    
+
    Was the resource moved, and is the move temporary? If
+it is explicitly temporary, for example due to maintenance,
+implement the moved_temporarily callback. Otherwise,
+implement the moved_permanently callback.
    
+
    
+
    
+
    
+
    The request
    
+
    
+
    Do you need to read the query string? Individual headers?
+Implement malformed_request and do all the parsing and
+validation in this function. Note that the body should not
+be read at this point.
    
+
    May there be a request body? Will I know its size?
+What’s the maximum size of the request body I’m willing
+to accept? Implement valid_entity_length.
    
+
    Finally, take a look at the sections corresponding to the
+methods you are implementing.
    
+
    
+
    
+
    
+
    OPTIONS method
    
+
    
+
    Cowboy by default will send back a list of allowed methods.
+Do I need to add more information to the response? Implement
+the options method.
    
+
    
+
    
+
    
+
    GET and HEAD methods
    
+
    
+
    If you implement the methods GET and/or HEAD, you must
+implement one ProvideResource callback for each
+content-type returned by the content_types_provided
+callback.
    
+
    
+
    
+
    
+
    PUT, POST and PATCH methods
    
+
    
+
    If you implement the methods PUT, POST and/or PATCH,
+you must implement the content_types_accepted callback,
+and one AcceptCallback callback for each content-type
+it returns. Prefix the AcceptCallback callback names
+with from_ for clarity. For example, from_html or
+from_json.
    
+
    Do we want to allow the POST method to create individual
+resources directly through their URI (like PUT)? Implement
+the allow_missing_post callback. It is recommended to
+explicitly use PUT in these cases instead.
    
+
    May there be conflicts when using PUT to create or replace
+a resource? Do we want to make sure that two updates around
+the same time are not cancelling one another? Implement the
+is_conflict callback.
    
+
    
+
    
+
    
+
    DELETE methods
    
+
    
+
    If you implement the method DELETE, you must implement
+the delete_resource callback.
    
+
    When delete_resource returns, is the resource completely
+removed from the server, including from any caching service?
+If not, and/or if the deletion is asynchronous and we have
+no way of knowing it has been completed yet, implement the
+delete_completed callback.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/resp.asciidoc b/docs/en/cowboy/2.1/guide/resp.asciidoc
new file mode 100644
index 00000000..6d4967e0
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/resp.asciidoc
@@ -0,0 +1,341 @@
+[[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">>
+}, ["", Title, "",
+    "
    ", Body, "
    "], 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("Hello world!", nofin, Req),
+cowboy_req:stream_body("
    Hats off!
    ", 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.
+
+// @todo Document trailers here.
+
+=== 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">> => <<"; rel=preload; as=style">>,
+    <<"link">> => <<"; 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">>
+}, ["My web page",
+    "",
+    "
    Welcome to Erlang!
    "], 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.
diff --git a/docs/en/cowboy/2.1/guide/resp/index.html b/docs/en/cowboy/2.1/guide/resp/index.html
new file mode 100644
index 00000000..9caa66d8
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/resp/index.html
@@ -0,0 +1,503 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Sending a response
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    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:
    
+
    
+
    
+
    Req = cowboy_req:reply(200, Req0).
    
+
    When you need to set response headers at the same time,
+use cowboy_req:reply/3:
    
+
    
+
    
+
    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:
    
+
    
+
    
+
    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:
    
+
    
+
    
+
    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.
    
+
    When you need to set only the status code,
+use cowboy_req:stream_reply/2:
    
+
    
+
    
+
    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:
    
+
    
+
    
+
    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.
    
+
    
+
    
+
    
+
    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:
    
+
    
+
    
+
    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 Cookies chapter for more information.
    
+
    To check if a response header has already been set:
    
+
    
+
    
+
    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:
    
+
    
+
    
+
    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:
    
+
    
+
    
+
    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:
    
+
    
+
    
+
    Req = cowboy_req:set_resp_body("Hello world!", Req0).
    
+
    To check if a response body has already been set:
    
+
    
+
    
+
    cowboy_req:has_resp_body(Req).
    
+
    It returns true if the body was set and is non-empty,
+false otherwise.
    
+
    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:
    
+
    
+
    
+
    {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:
    
+
    
+
    
+
    Req = cowboy_req:reply(200, #{
+    <<"content-type">> => "image/png"
+}, {sendfile, 0, 12345, "path/to/logo.png"}, Req0).
    
+
    
+
    
+
    
+
    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.
    
+
    
+
    
+
    Req = cowboy_req:inform(103, #{
+    <<"link">> => <<"</style.css>; rel=preload; as=style">>,
+    <<"link">> => <<"</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:
    
+
    
+
    
+
    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:
    
+
    
+
    
+
    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.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/rest_cond.png b/docs/en/cowboy/2.1/guide/rest_cond.png
new file mode 100644
index 00000000..64cda347
Binary files /dev/null and b/docs/en/cowboy/2.1/guide/rest_cond.png differ
diff --git a/docs/en/cowboy/2.1/guide/rest_cond.svg b/docs/en/cowboy/2.1/guide/rest_cond.svg
new file mode 100644
index 00000000..542ae17d
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_cond.svg
@@ -0,0 +1,1656 @@
+
+
+
+
+  
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+    
+  
+  
+    
+  
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    some text
+    some text
+    has if-unmodified-since?
+    has if-none-match?
+    some text
+    ...
+    generate_etag
+    has if-modified-since?
+    has if-match?
+    generate_etag
+    last_modified
+    
+    true
+    match*
+    true
+    not modified*
+    true
+    no match*
+    
+      
+      
+    
+    false
+    false, orinvalid
+    modified*
+    false
+    
+      
+      
+    
+    
+    412 precondition failed
+    
+    middlewares
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    no match*
+    
+      
+      
+    
+    
+    date is in the future?
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    last_modified
+    
+      
+      
+    
+    
+    304 not modified
+    
+    ...
+    false, orinvalid
+    match*
+    
+    method is GET/HEAD?
+    true
+    false
+    true
+    false
+    true
+    modified*
+    not modified*
+    
+      
+      
+    
+    
+    generate_etag
+    
+      
+      
+    
+    
+    expires
+  
+
diff --git a/docs/en/cowboy/2.1/guide/rest_conneg.png b/docs/en/cowboy/2.1/guide/rest_conneg.png
new file mode 100644
index 00000000..65ecdcf3
Binary files /dev/null and b/docs/en/cowboy/2.1/guide/rest_conneg.png differ
diff --git a/docs/en/cowboy/2.1/guide/rest_conneg.svg b/docs/en/cowboy/2.1/guide/rest_conneg.svg
new file mode 100644
index 00000000..247567a0
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_conneg.svg
@@ -0,0 +1,1135 @@
+
+
+
+
+  
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+    
+  
+  
+    
+  
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    some text
+    some text
+    has accept-language?
+    has accept-charset?
+    some text
+    start
+    charsets_provided
+    variances
+    has accept?
+    content_types_provided
+    languages_provided
+    
+    true
+    provided*
+    true
+    provided*
+    true
+    provided*
+    
+      
+      
+    
+    false
+    false
+    not provided*
+    false
+    not provided*
+    
+    
+      
+      
+    
+    406 not acceptable
+    
+    middlewares
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    not provided*
+    
+    ...
+  
+
diff --git a/docs/en/cowboy/2.1/guide/rest_delete.png b/docs/en/cowboy/2.1/guide/rest_delete.png
new file mode 100644
index 00000000..56a861c0
Binary files /dev/null and b/docs/en/cowboy/2.1/guide/rest_delete.png differ
diff --git a/docs/en/cowboy/2.1/guide/rest_delete.svg b/docs/en/cowboy/2.1/guide/rest_delete.svg
new file mode 100644
index 00000000..2f5513cd
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_delete.svg
@@ -0,0 +1,1718 @@
+
+
+
+
+  
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+    
+  
+  
+    
+  
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    some text
+    some text
+    delete_completed
+    has response body?
+    some text
+    conneg
+    multiple_choices
+    resource_exists
+    delete_resource
+    
+    true
+    false
+    
+      
+      
+    
+    false
+    
+      
+      
+    
+    
+    middlewares
+    
+      
+      
+    
+    true
+    true
+    
+      
+      
+    
+    
+    cond
+    
+    300 multiple choices
+    
+    200 OK
+    
+      
+      
+    
+    
+    has if-match?
+    false
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    previously_existed
+    
+    404 not found
+    false
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    moved_permanently
+    
+      
+      
+    
+    
+    412 precondition failed
+    true
+    true*
+    false
+    
+    301 moved permanently
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    moved_temporarily
+    true*
+    false
+    
+    307 moved temporarily
+    
+    410 gone
+    
+      
+      
+    
+    false
+    
+    202 accepted
+    
+    204 no content
+    true
+    true
+    
+    500 internal server error
+    false
+    true
+    false
+  
+
diff --git a/docs/en/cowboy/2.1/guide/rest_flowcharts.asciidoc b/docs/en/cowboy/2.1/guide/rest_flowcharts.asciidoc
new file mode 100644
index 00000000..b5697825
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_flowcharts.asciidoc
@@ -0,0 +1,248 @@
+[[rest_flowcharts]]
+== REST flowcharts
+
+This chapter will explain the REST handler state machine through
+a number of different diagrams.
+
+There are four main paths that requests may follow. One for the
+method OPTIONS; one for the methods GET and HEAD; one for the
+methods PUT, POST and PATCH; and one for the method DELETE.
+
+All paths start with the "Start" diagram, and all paths excluding
+the OPTIONS path go through the "Content negotiation" diagram
+and optionally the "Conditional requests" diagram if the resource
+exists.
+
+The red squares refer to another diagram. The light green squares
+indicate a response. Other squares may be either a callback or a
+question answered by Cowboy itself. Green arrows tend to indicate
+the default behavior if the callback is undefined.
+
+=== Start
+
+All requests start from here.
+
+image::rest_start.png[REST starting flowchart]
+
+A series of callbacks are called in succession to perform
+a general checkup of the service, the request line and
+request headers.
+
+The request body, if any, is not expected to have been
+received for any of these steps. It is only processed
+at the end of the "PUT, POST and PATCH methods" diagram,
+when all conditions have been met.
+
+The `known_methods` and `allowed_methods` callbacks
+return a list of methods. Cowboy then checks if the request
+method is in the list, and stops otherwise.
+
+The `is_authorized` callback may be used to check that
+access to the resource is authorized. Authentication
+may also be performed as needed. When authorization is
+denied, the return value from the callback must include
+a challenge applicable to the requested resource, which
+will be sent back to the client in the www-authenticate
+header.
+
+This diagram is immediately followed by either the
+"OPTIONS method" diagram when the request method is
+OPTIONS, or the "Content negotiation" diagram otherwise.
+
+=== OPTIONS method
+
+This diagram only applies to OPTIONS requests.
+
+image::rest_options.png[REST OPTIONS method flowchart]
+
+The `options` callback may be used to add information
+about the resource, such as media types or languages
+provided; allowed methods; any extra information. A
+response body may also be set, although clients should
+not be expected to read it.
+
+If the `options` callback is not defined, Cowboy will
+send a response containing the list of allowed methods
+by default.
+
+=== Content negotiation
+
+This diagram applies to all request methods other than
+OPTIONS. It is executed right after the "Start" diagram
+is completed.
+
+image::rest_conneg.png[REST content negotiation flowchart]
+
+The purpose of these steps is to determine an appropriate
+representation to be sent back to the client.
+
+The request may contain any of the accept header; the
+accept-language header; or the accept-charset header.
+When present, Cowboy will parse the headers and then
+call the corresponding callback to obtain the list
+of provided content-type, language or charset for this
+resource. It then automatically select the best match
+based on the request.
+
+If a callback is not defined, Cowboy will select the
+content-type, language or charset that the client
+prefers.
+
+The `content_types_provided` also returns the name of
+a callback for every content-type it accepts. This
+callback will only be called at the end of the
+"GET and HEAD methods" diagram, when all conditions
+have been met.
+
+The selected content-type, language and charset are
+saved as meta values in the Req object. You *should*
+use the appropriate representation if you set a
+response body manually (alongside an error code,
+for example).
+
+This diagram is immediately followed by
+the "GET and HEAD methods" diagram,
+the "PUT, POST and PATCH methods" diagram,
+or the "DELETE method" diagram, depending on the
+method.
+
+=== GET and HEAD methods
+
+This diagram only applies to GET and HEAD requests.
+
+For a description of the `cond` step, please see
+the "Conditional requests" diagram.
+
+image::rest_get_head.png[REST GET/HEAD methods flowchart]
+
+When the resource exists, and the conditional steps
+succeed, the resource can be retrieved.
+
+Cowboy prepares the response by first retrieving
+metadata about the representation, then by calling
+the `ProvideResource` callback. This is the callback
+you defined for each content-types you returned from
+`content_types_provided`. This callback returns the body
+that will be sent back to the client, or a fun if the
+body must be streamed.
+
+When the resource does not exist, Cowboy will figure out
+whether the resource existed previously, and if so whether
+it was moved elsewhere in order to redirect the client to
+the new URI.
+
+The `moved_permanently` and `moved_temporarily` callbacks
+must return the new location of the resource if it was in
+fact moved.
+
+=== PUT, POST and PATCH methods
+
+This diagram only applies to PUT, POST and PATCH requests.
+
+For a description of the `cond` step, please see
+the "Conditional requests" diagram.
+
+image::rest_put_post_patch.png[REST PUT/POST/PATCH methods flowchart]
+
+When the resource exists, first the conditional steps
+are executed. When that succeeds, and the method is PUT,
+Cowboy will call the `is_conflict` callback. This function
+can be used to prevent potential race conditions, by locking
+the resource for example.
+
+Then all three methods reach the `content_types_accepted`
+step that we will describe in a few paragraphs.
+
+When the resource does not exist, and the method is PUT,
+Cowboy will check for conflicts and then move on to the
+`content_types_accepted` step. For other methods, Cowboy
+will figure out whether the resource existed previously,
+and if so whether it was moved elsewhere. If the resource
+is truly non-existent, the method is POST and the call
+for `allow_missing_post` returns `true`, then Cowboy will
+move on to the `content_types_accepted` step. Otherwise
+the request processing ends there.
+
+The `moved_permanently` and `moved_temporarily` callbacks
+must return the new location of the resource if it was in
+fact moved.
+
+The `content_types_accepted` returns a list of
+content-types it accepts, but also the name of a callback
+for each of them. Cowboy will select the appropriate
+callback for processing the request body and call it.
+
+This callback may return one of three different return
+values.
+
+If an error occurred while processing the request body,
+it must return `false` and Cowboy will send an
+appropriate error response.
+
+If the method is POST, then you may return `true` with
+an URI of where the resource has been created. This is
+especially useful for writing handlers for collections.
+
+Otherwise, return `true` to indicate success. Cowboy
+will select the appropriate response to be sent depending
+on whether a resource has been created, rather than
+modified, and on the availability of a location header
+or a body in the response.
+
+=== DELETE method
+
+This diagram only applies to DELETE requests.
+
+For a description of the `cond` step, please see
+the "Conditional requests" diagram.
+
+image::rest_delete.png[REST DELETE method flowchart]
+
+When the resource exists, and the conditional steps
+succeed, the resource can be deleted.
+
+Deleting the resource is a two steps process. First
+the callback `delete_resource` is executed. Use this
+callback to delete the resource.
+
+Because the resource may be cached, you must also
+delete all cached representations of this resource
+in the system. This operation may take a while though,
+so you may return before it finished.
+
+Cowboy will then call the `delete_completed` callback.
+If you know that the resource has been completely
+deleted from your system, including from caches, then
+you can return `true`. If any doubts persist, return
+`false`. Cowboy will assume `true` by default.
+
+To finish, Cowboy checks if you set a response body,
+and depending on that, sends the appropriate response.
+
+When the resource does not exist, Cowboy will figure out
+whether the resource existed previously, and if so whether
+it was moved elsewhere in order to redirect the client to
+the new URI.
+
+The `moved_permanently` and `moved_temporarily` callbacks
+must return the new location of the resource if it was in
+fact moved.
+
+=== Conditional requests
+
+This diagram applies to all request methods other than
+OPTIONS. It is executed right after the `resource_exists`
+callback, when the resource exists.
+
+image::rest_cond.png[REST conditional requests flowchart]
+
+A request becomes conditional when it includes either of
+the if-match header; the if-unmodified-since header; the
+if-none-match header; or the if-modified-since header.
+
+If the condition fails, the request ends immediately
+without any retrieval or modification of the resource.
+
+The `generate_etag` and `last_modified` are called as
+needed. Cowboy will only call them once and then cache
+the results for subsequent use.
diff --git a/docs/en/cowboy/2.1/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.1/guide/rest_flowcharts/index.html
new file mode 100644
index 00000000..eadfcc74
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_flowcharts/index.html
@@ -0,0 +1,401 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: REST flowcharts
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    REST flowcharts
    
+
+
    This chapter will explain the REST handler state machine through
+a number of different diagrams.
    
+
    There are four main paths that requests may follow. One for the
+method OPTIONS; one for the methods GET and HEAD; one for the
+methods PUT, POST and PATCH; and one for the method DELETE.
    
+
    All paths start with the "Start" diagram, and all paths excluding
+the OPTIONS path go through the "Content negotiation" diagram
+and optionally the "Conditional requests" diagram if the resource
+exists.
    
+
    The red squares refer to another diagram. The light green squares
+indicate a response. Other squares may be either a callback or a
+question answered by Cowboy itself. Green arrows tend to indicate
+the default behavior if the callback is undefined.
    
+
    
+
    Start
    
+
    
+
    All requests start from here.
    
+
    
+
    
+REST starting flowchart
+
    
+
    
+
    A series of callbacks are called in succession to perform
+a general checkup of the service, the request line and
+request headers.
    
+
    The request body, if any, is not expected to have been
+received for any of these steps. It is only processed
+at the end of the "PUT, POST and PATCH methods" diagram,
+when all conditions have been met.
    
+
    The known_methods and allowed_methods callbacks
+return a list of methods. Cowboy then checks if the request
+method is in the list, and stops otherwise.
    
+
    The is_authorized callback may be used to check that
+access to the resource is authorized. Authentication
+may also be performed as needed. When authorization is
+denied, the return value from the callback must include
+a challenge applicable to the requested resource, which
+will be sent back to the client in the www-authenticate
+header.
    
+
    This diagram is immediately followed by either the
+"OPTIONS method" diagram when the request method is
+OPTIONS, or the "Content negotiation" diagram otherwise.
    
+
    
+
    
+
    
+
    OPTIONS method
    
+
    
+
    This diagram only applies to OPTIONS requests.
    
+
    
+
    
+REST OPTIONS method flowchart
+
    
+
    
+
    The options callback may be used to add information
+about the resource, such as media types or languages
+provided; allowed methods; any extra information. A
+response body may also be set, although clients should
+not be expected to read it.
    
+
    If the options callback is not defined, Cowboy will
+send a response containing the list of allowed methods
+by default.
    
+
    
+
    
+
    
+
    Content negotiation
    
+
    
+
    This diagram applies to all request methods other than
+OPTIONS. It is executed right after the "Start" diagram
+is completed.
    
+
    
+
    
+REST content negotiation flowchart
+
    
+
    
+
    The purpose of these steps is to determine an appropriate
+representation to be sent back to the client.
    
+
    The request may contain any of the accept header; the
+accept-language header; or the accept-charset header.
+When present, Cowboy will parse the headers and then
+call the corresponding callback to obtain the list
+of provided content-type, language or charset for this
+resource. It then automatically select the best match
+based on the request.
    
+
    If a callback is not defined, Cowboy will select the
+content-type, language or charset that the client
+prefers.
    
+
    The content_types_provided also returns the name of
+a callback for every content-type it accepts. This
+callback will only be called at the end of the
+"GET and HEAD methods" diagram, when all conditions
+have been met.
    
+
    The selected content-type, language and charset are
+saved as meta values in the Req object. You should
+use the appropriate representation if you set a
+response body manually (alongside an error code,
+for example).
    
+
    This diagram is immediately followed by
+the "GET and HEAD methods" diagram,
+the "PUT, POST and PATCH methods" diagram,
+or the "DELETE method" diagram, depending on the
+method.
    
+
    
+
    
+
    
+
    GET and HEAD methods
    
+
    
+
    This diagram only applies to GET and HEAD requests.
    
+
    For a description of the cond step, please see
+the "Conditional requests" diagram.
    
+
    
+
    
+REST GET/HEAD methods flowchart
+
    
+
    
+
    When the resource exists, and the conditional steps
+succeed, the resource can be retrieved.
    
+
    Cowboy prepares the response by first retrieving
+metadata about the representation, then by calling
+the ProvideResource callback. This is the callback
+you defined for each content-types you returned from
+content_types_provided. This callback returns the body
+that will be sent back to the client, or a fun if the
+body must be streamed.
    
+
    When the resource does not exist, Cowboy will figure out
+whether the resource existed previously, and if so whether
+it was moved elsewhere in order to redirect the client to
+the new URI.
    
+
    The moved_permanently and moved_temporarily callbacks
+must return the new location of the resource if it was in
+fact moved.
    
+
    
+
    
+
    
+
    PUT, POST and PATCH methods
    
+
    
+
    This diagram only applies to PUT, POST and PATCH requests.
    
+
    For a description of the cond step, please see
+the "Conditional requests" diagram.
    
+
    
+
    
+REST PUT/POST/PATCH methods flowchart
+
    
+
    
+
    When the resource exists, first the conditional steps
+are executed. When that succeeds, and the method is PUT,
+Cowboy will call the is_conflict callback. This function
+can be used to prevent potential race conditions, by locking
+the resource for example.
    
+
    Then all three methods reach the content_types_accepted
+step that we will describe in a few paragraphs.
    
+
    When the resource does not exist, and the method is PUT,
+Cowboy will check for conflicts and then move on to the
+content_types_accepted step. For other methods, Cowboy
+will figure out whether the resource existed previously,
+and if so whether it was moved elsewhere. If the resource
+is truly non-existent, the method is POST and the call
+for allow_missing_post returns true, then Cowboy will
+move on to the content_types_accepted step. Otherwise
+the request processing ends there.
    
+
    The moved_permanently and moved_temporarily callbacks
+must return the new location of the resource if it was in
+fact moved.
    
+
    The content_types_accepted returns a list of
+content-types it accepts, but also the name of a callback
+for each of them. Cowboy will select the appropriate
+callback for processing the request body and call it.
    
+
    This callback may return one of three different return
+values.
    
+
    If an error occurred while processing the request body,
+it must return false and Cowboy will send an
+appropriate error response.
    
+
    If the method is POST, then you may return true with
+an URI of where the resource has been created. This is
+especially useful for writing handlers for collections.
    
+
    Otherwise, return true to indicate success. Cowboy
+will select the appropriate response to be sent depending
+on whether a resource has been created, rather than
+modified, and on the availability of a location header
+or a body in the response.
    
+
    
+
    
+
    
+
    DELETE method
    
+
    
+
    This diagram only applies to DELETE requests.
    
+
    For a description of the cond step, please see
+the "Conditional requests" diagram.
    
+
    
+
    
+REST DELETE method flowchart
+
    
+
    
+
    When the resource exists, and the conditional steps
+succeed, the resource can be deleted.
    
+
    Deleting the resource is a two steps process. First
+the callback delete_resource is executed. Use this
+callback to delete the resource.
    
+
    Because the resource may be cached, you must also
+delete all cached representations of this resource
+in the system. This operation may take a while though,
+so you may return before it finished.
    
+
    Cowboy will then call the delete_completed callback.
+If you know that the resource has been completely
+deleted from your system, including from caches, then
+you can return true. If any doubts persist, return
+false. Cowboy will assume true by default.
    
+
    To finish, Cowboy checks if you set a response body,
+and depending on that, sends the appropriate response.
    
+
    When the resource does not exist, Cowboy will figure out
+whether the resource existed previously, and if so whether
+it was moved elsewhere in order to redirect the client to
+the new URI.
    
+
    The moved_permanently and moved_temporarily callbacks
+must return the new location of the resource if it was in
+fact moved.
    
+
    
+
    
+
    
+
    Conditional requests
    
+
    
+
    This diagram applies to all request methods other than
+OPTIONS. It is executed right after the resource_exists
+callback, when the resource exists.
    
+
    
+
    
+REST conditional requests flowchart
+
    
+
    
+
    A request becomes conditional when it includes either of
+the if-match header; the if-unmodified-since header; the
+if-none-match header; or the if-modified-since header.
    
+
    If the condition fails, the request ends immediately
+without any retrieval or modification of the resource.
    
+
    The generate_etag and last_modified are called as
+needed. Cowboy will only call them once and then cache
+the results for subsequent use.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/rest_get_head.png b/docs/en/cowboy/2.1/guide/rest_get_head.png
new file mode 100644
index 00000000..211ab603
Binary files /dev/null and b/docs/en/cowboy/2.1/guide/rest_get_head.png differ
diff --git a/docs/en/cowboy/2.1/guide/rest_get_head.svg b/docs/en/cowboy/2.1/guide/rest_get_head.svg
new file mode 100644
index 00000000..92030cf3
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_get_head.svg
@@ -0,0 +1,1523 @@
+
+
+
+
+  
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+    
+  
+  
+    
+  
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    some text
+    some text
+    last_modified
+    ProvideCallback
+    some text
+    conneg
+    multiple_choices
+    resource_exists
+    generate_etag
+    expires
+    
+    true
+    false
+    
+      
+      
+    
+    false
+    
+      
+      
+    
+    
+    middlewares
+    
+      
+      
+    
+    true
+    true
+    
+      
+      
+    
+    
+    cond
+    
+    300 multiple choices
+    
+    200 OK
+    
+      
+      
+    
+    
+    has if-match?
+    false
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    previously_existed
+    
+    404 not found
+    false
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    moved_permanently
+    
+      
+      
+    
+    
+    412 precondition failed
+    true
+    true*
+    false
+    
+    301 moved permanently
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    moved_temporarily
+    true*
+    false
+    
+    307 moved temporarily
+    
+    410 gone
+    
+      
+      
+    
+  
+
diff --git a/docs/en/cowboy/2.1/guide/rest_handlers.asciidoc b/docs/en/cowboy/2.1/guide/rest_handlers.asciidoc
new file mode 100644
index 00000000..dab5bead
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_handlers.asciidoc
@@ -0,0 +1,138 @@
+[[rest_handlers]]
+== REST handlers
+
+REST is implemented in Cowboy as a sub protocol. The request
+is handled as a state machine with many optional callbacks
+describing the resource and modifying the machine's behavior.
+
+The REST handler is the recommended way to handle HTTP requests.
+
+=== Initialization
+
+First, the `init/2` callback is called. This callback is common
+to all handlers. To use REST for the current request, this function
+must return a `cowboy_rest` tuple.
+
+[source,erlang]
+----
+init(Req, State) ->
+    {cowboy_rest, Req, State}.
+----
+
+Cowboy will then switch to the REST protocol and start executing
+the state machine.
+
+After reaching the end of the flowchart, the `terminate/3` callback
+will be called if it is defined.
+
+=== Methods
+
+The REST component has code for handling the following HTTP methods:
+HEAD, GET, POST, PATCH, PUT, DELETE and OPTIONS.
+
+Other methods can be accepted, however they have no specific callback
+defined for them at this time.
+
+=== Callbacks
+
+All callbacks are optional. Some may become mandatory depending
+on what other defined callbacks return. The various flowcharts
+in the next chapter should be a useful to determine which callbacks
+you need.
+
+All callbacks take two arguments, the Req object and the State,
+and return a three-element tuple of the form `{Value, Req, State}`.
+
+Nearly all callbacks can also return `{stop, Req, State}` to
+stop execution of the request, and
+`{{switch_handler, Module}, Req, State}` or
+`{{switch_handler, Module, Opts}, Req, State}` to switch to
+a different handler type. The exceptions are `expires`
+`generate_etag`, `last_modified` and `variances`.
+
+The following table summarizes the callbacks and their default values.
+If the callback isn't defined, then the default value will be used.
+Please look at the flowcharts to find out the result of each return
+value.
+
+In the following table, "skip" means the callback is entirely skipped
+if it is undefined, moving directly to the next step. Similarly,
+"none" means there is no default value for this callback.
+
+[cols="<,^",options="header"]
+|===
+| Callback name          | Default value
+| allowed_methods        | `[<<"GET">>, <<"HEAD">>, <<"OPTIONS">>]`
+| allow_missing_post     | `true`
+| charsets_provided      | skip
+| content_types_accepted | none
+// @todo Space required for the time being: https://github.com/spf13/hugo/issues/2398
+| content_types_provided | `[{{ <<"text">>, <<"html">>, '*'}, to_html}]`
+| delete_completed       | `true`
+| delete_resource        | `false`
+| expires                | `undefined`
+| forbidden              | `false`
+| generate_etag          | `undefined`
+| is_authorized          | `true`
+| is_conflict            | `false`
+| known_methods          | `[<<"GET">>, <<"HEAD">>, <<"POST">>, <<"PUT">>, <<"PATCH">>, <<"DELETE">>, <<"OPTIONS">>]`
+| languages_provided     | skip
+| last_modified          | `undefined`
+| malformed_request      | `false`
+| moved_permanently      | `false`
+| moved_temporarily      | `false`
+| multiple_choices       | `false`
+| options                | `ok`
+| previously_existed     | `false`
+| resource_exists        | `true`
+| service_available      | `true`
+| uri_too_long           | `false`
+| valid_content_headers  | `true`
+| valid_entity_length    | `true`
+| variances              | `[]`
+|===
+
+As you can see, Cowboy tries to move on with the request whenever
+possible by using well thought out default values.
+
+In addition to these, there can be any number of user-defined
+callbacks that are specified through `content_types_accepted/2`
+and `content_types_provided/2`. They can take any name, however
+it is recommended to use a separate prefix for the callbacks of
+each function. For example, `from_html` and `to_html` indicate
+in the first case that we're accepting a resource given as HTML,
+and in the second case that we send one as HTML.
+
+=== Meta data
+
+Cowboy will set informative values to the Req object at various
+points of the execution. You can retrieve them by matching the
+Req object directly. The values are defined in the following table:
+
+[cols="<,<",options="header"]
+|===
+| Key        | Details
+| media_type | The content-type negotiated for the response entity.
+| language   | The language negotiated for the response entity.
+| charset    | The charset negotiated for the response entity.
+|===
+
+They can be used to send a proper body with the response to a
+request that used a method other than HEAD or GET.
+
+=== Response headers
+
+Cowboy will set response headers automatically over the execution
+of the REST code. They are listed in the following table.
+
+[cols="<,<",options="header"]
+|===
+| Header name      | Details
+| content-language | Language used in the response body
+| content-type     | Media type and charset of the response body
+| etag             | Etag of the resource
+| expires          | Expiration date of the resource
+| last-modified    | Last modification date for the resource
+| location         | Relative or absolute URI to the requested resource
+| vary             | List of headers that may change the representation of the resource
+|===
diff --git a/docs/en/cowboy/2.1/guide/rest_handlers/index.html b/docs/en/cowboy/2.1/guide/rest_handlers/index.html
new file mode 100644
index 00000000..beebdf4a
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_handlers/index.html
@@ -0,0 +1,444 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: REST handlers
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    REST handlers
    
+
+
    REST is implemented in Cowboy as a sub protocol. The request
+is handled as a state machine with many optional callbacks
+describing the resource and modifying the machine’s behavior.
    
+
    The REST handler is the recommended way to handle HTTP requests.
    
+
    
+
    Initialization
    
+
    
+
    First, the init/2 callback is called. This callback is common
+to all handlers. To use REST for the current request, this function
+must return a cowboy_rest tuple.
    
+
    
+
    
+
    init(Req, State) ->
+    {cowboy_rest, Req, State}.
    
+
    Cowboy will then switch to the REST protocol and start executing
+the state machine.
    
+
    After reaching the end of the flowchart, the terminate/3 callback
+will be called if it is defined.
    
+
    
+
    
+
    
+
    Methods
    
+
    
+
    The REST component has code for handling the following HTTP methods:
+HEAD, GET, POST, PATCH, PUT, DELETE and OPTIONS.
    
+
    Other methods can be accepted, however they have no specific callback
+defined for them at this time.
    
+
    
+
    
+
    
+
    Callbacks
    
+
    
+
    All callbacks are optional. Some may become mandatory depending
+on what other defined callbacks return. The various flowcharts
+in the next chapter should be a useful to determine which callbacks
+you need.
    
+
    All callbacks take two arguments, the Req object and the State,
+and return a three-element tuple of the form {Value, Req, State}.
    
+
    Nearly all callbacks can also return {stop, Req, State} to
+stop execution of the request, and
+{{switch_handler, Module}, Req, State} or
+{{switch_handler, Module, Opts}, Req, State} to switch to
+a different handler type. The exceptions are expires
+generate_etag, last_modified and variances.
    
+
    The following table summarizes the callbacks and their default values.
+If the callback isn’t defined, then the default value will be used.
+Please look at the flowcharts to find out the result of each return
+value.
    
+
    In the following table, "skip" means the callback is entirely skipped
+if it is undefined, moving directly to the next step. Similarly,
+"none" means there is no default value for this callback.
    
+
    
+
+++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    


     Callback name           Default value
    allowed_methods
    [<<"GET">>, <<"HEAD">>, <<"OPTIONS">>]
    allow_missing_post
    true
    charsets_provided
    skip
    content_types_accepted
    none
    content_types_provided
    [{{ <<"text">>, <<"html">>, '*'}, to_html}]
    delete_completed
    true
    delete_resource
    false
    expires
    undefined
    forbidden
    false
    generate_etag
    undefined
    is_authorized
    true
    is_conflict
    false
    known_methods
    [<<"GET">>, <<"HEAD">>, <<"POST">>, <<"PUT">>, <<"PATCH">>, <<"DELETE">>, <<"OPTIONS">>]
    languages_provided
    skip
    last_modified
    undefined
    malformed_request
    false
    moved_permanently
    false
    moved_temporarily
    false
    multiple_choices
    false
    options
    ok
    previously_existed
    false
    resource_exists
    true
    service_available
    true
    uri_too_long
    false
    valid_content_headers
    true
    valid_entity_length
    true
    variances
    []
    
+
    
+
    As you can see, Cowboy tries to move on with the request whenever
+possible by using well thought out default values.
    
+
    In addition to these, there can be any number of user-defined
+callbacks that are specified through content_types_accepted/2
+and content_types_provided/2. They can take any name, however
+it is recommended to use a separate prefix for the callbacks of
+each function. For example, from_html and to_html indicate
+in the first case that we’re accepting a resource given as HTML,
+and in the second case that we send one as HTML.
    
+
    
+
    
+
    
+
    Meta data
    
+
    
+
    Cowboy will set informative values to the Req object at various
+points of the execution. You can retrieve them by matching the
+Req object directly. The values are defined in the following table:
    
+
    
+
+++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    


     Key         Details
    media_type
    The content-type negotiated for the response entity.
    language
    The language negotiated for the response entity.
    charset
    The charset negotiated for the response entity.
    
+
    
+
    They can be used to send a proper body with the response to a
+request that used a method other than HEAD or GET.
    
+
    
+
    
+
    
+
    Response headers
    
+
    
+
    Cowboy will set response headers automatically over the execution
+of the REST code. They are listed in the following table.
    
+
    
+
+++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    


     Header name       Details
    content-language
    Language used in the response body
    content-type
    Media type and charset of the response body
    etag
    Etag of the resource
    expires
    Expiration date of the resource
    last-modified
    Last modification date for the resource
    location
    Relative or absolute URI to the requested resource
    vary
    List of headers that may change the representation of the resource
    
+
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/rest_options.png b/docs/en/cowboy/2.1/guide/rest_options.png
new file mode 100644
index 00000000..90fd6f06
Binary files /dev/null and b/docs/en/cowboy/2.1/guide/rest_options.png differ
diff --git a/docs/en/cowboy/2.1/guide/rest_options.svg b/docs/en/cowboy/2.1/guide/rest_options.svg
new file mode 100644
index 00000000..496c050c
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_options.svg
@@ -0,0 +1,387 @@
+
+
+
+
+  
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+    
+  
+  
+    
+  
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    some text
+    some text
+    some text
+    start
+    options
+    200 OK
+    
+    
+      
+      
+    
+    
+    middlewares
+  
+
diff --git a/docs/en/cowboy/2.1/guide/rest_principles.asciidoc b/docs/en/cowboy/2.1/guide/rest_principles.asciidoc
new file mode 100644
index 00000000..66939cb7
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_principles.asciidoc
@@ -0,0 +1,160 @@
+[[rest_principles]]
+== REST principles
+
+This chapter will attempt to define the concepts behind REST
+and explain what makes a service RESTful.
+
+REST is often confused with performing a distinct operation
+depending on the HTTP method, while using more than the GET
+and POST methods. That's highly misguided at best.
+
+We will first attempt to define REST and will look at what
+it means in the context of HTTP and the Web.
+For a more in-depth explanation of REST, you can read
+http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm[Roy T. Fielding's dissertation]
+as it does a great job explaining where it comes from and
+what it achieves.
+
+=== REST architecture
+
+REST is a *client-server* architecture. The client and the server
+both have a different set of concerns. The server stores and/or
+manipulates information and makes it available to the user in
+an efficient manner. The client takes that information and
+displays it to the user and/or uses it to perform subsequent
+requests for information. This separation of concerns allows both
+the client and the server to evolve independently as it only
+requires that the interface stays the same.
+
+REST is *stateless*. That means the communication between the
+client and the server always contains all the information needed
+to perform the request. There is no session state in the server,
+it is kept entirely on the client's side. If access to a resource
+requires authentication, then the client needs to authenticate
+itself with every request.
+
+REST is *cacheable*. The client, the server and any intermediary
+components can all cache resources in order to improve performance.
+
+REST provides a *uniform interface* between components. This
+simplifies the architecture, as all components follow the same
+rules to speak to one another. It also makes it easier to understand
+the interactions between the different components of the system.
+A number of constraints are required to achieve this. They are
+covered in the rest of the chapter.
+
+REST is a *layered system*. Individual components cannot see
+beyond the immediate layer with which they are interacting. This
+means that a client connecting to an intermediate component, like
+a proxy, has no knowledge of what lies beyond. This allows
+components to be independent and thus easily replaceable or
+extendable.
+
+REST optionally provides *code on demand*. Code may be downloaded
+to extend client functionality. This is optional however because
+the client may not be able to download or run this code, and so
+a REST component cannot rely on it being executed.
+
+=== Resources and resource identifiers
+
+A resource is an abstract concept. In a REST system, any information
+that can be named may be a resource. This includes documents, images,
+a collection of resources and any other information. Any information
+that can be the target of an hypertext link can be a resource.
+
+A resource is a conceptual mapping to a set of entities. The set of
+entities evolves over time; a resource doesn't. For example, a resource
+can map to "users who have logged in this past month" and another
+to "all users". At some point in time they may map to the same set of
+entities, because all users logged in this past month. But they are
+still different resources. Similarly, if nobody logged in recently,
+then the first resource may map to the empty set. This resource exists
+regardless of the information it maps to.
+
+Resources are identified by uniform resource identifiers, also known
+as URIs. Sometimes internationalized resource identifiers, or IRIs,
+may also be used, but these can be directly translated into a URI.
+
+In practice we will identify two kinds of resources. Individual
+resources map to a set of one element, for example "user Joe".
+Collection of resources map to a set of 0 to N elements,
+for example "all users".
+
+=== Resource representations
+
+The representation of a resource is a sequence of bytes associated
+with metadata.
+
+The metadata comes as a list of key-value pairs, where the name
+corresponds to a standard that defines the value's structure and
+semantics. With HTTP, the metadata comes in the form of request
+or response headers. The headers' structure and semantics are well
+defined in the HTTP standard. Metadata includes representation
+metadata, resource metadata and control data.
+
+The representation metadata gives information about the
+representation, such as its media type, the date of last
+modification, or even a checksum.
+
+Resource metadata could be link to related resources or
+information about additional representations of the resource.
+
+Control data allows parameterizing the request or response.
+For example, we may only want the representation returned if
+it is more recent than the one we have in cache. Similarly,
+we may want to instruct the client about how it should cache
+the representation. This isn't restricted to caching. We may,
+for example, want to store a new representation of a resource
+only if it wasn't modified since we first retrieved it.
+
+The data format of a representation is also known as the media
+type. Some media types are intended for direct rendering to the
+user, while others are intended for automated processing. The
+media type is a key component of the REST architecture.
+
+=== Self-descriptive messages
+
+Messages must be self-descriptive. That means that the data
+format of a representation must always come with its media
+type (and similarly requesting a resource involves choosing
+the media type of the representation returned). If you are
+sending HTML, then you must say it is HTML by sending the
+media type with the representation. In HTTP this is done
+using the content-type header.
+
+The media type is often an IANA registered media type, like
+`text/html` or `image/png`, but does not need to be. Exactly
+two things are important for respecting this constraint: that
+the media type is well specified, and that the sender and
+recipient agree about what the media type refers to.
+
+This means that you can create your own media types, like
+`application/x-mine`, and that as long as you write the
+specifications for it and that both endpoints agree about
+it then the constraint is respected.
+
+=== Hypermedia as the engine of application state
+
+The last constraint is generally where services that claim
+to be RESTful fail. Interactions with a server must be
+entirely driven by hypermedia. The client does not need
+any prior knowledge of the service in order to use it,
+other than an entry point and of course basic understanding
+of the media type of the representations, at the very least
+enough to find and identify hyperlinks and link relations.
+
+To give a simple example, if your service only works with
+the `application/json` media type then this constraint
+cannot be respected (as there are no concept of links in
+JSON) and thus your service isn't RESTful. This is the case
+for the majority of self-proclaimed REST services.
+
+On the other hand if you create a JSON based media type
+that has a concept of links and link relations, then
+your service might be RESTful.
+
+Respecting this constraint means that the entirety of the
+service becomes self-discoverable, not only the resources
+in it, but also the operations you can perform on it. This
+makes clients very thin as there is no need to implement
+anything specific to the service to operate on it.
diff --git a/docs/en/cowboy/2.1/guide/rest_principles/index.html b/docs/en/cowboy/2.1/guide/rest_principles/index.html
new file mode 100644
index 00000000..17ab197e
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_principles/index.html
@@ -0,0 +1,310 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: REST principles
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    REST principles
    
+
+
    This chapter will attempt to define the concepts behind REST
+and explain what makes a service RESTful.
    
+
    REST is often confused with performing a distinct operation
+depending on the HTTP method, while using more than the GET
+and POST methods. That’s highly misguided at best.
    
+
    We will first attempt to define REST and will look at what
+it means in the context of HTTP and the Web.
+For a more in-depth explanation of REST, you can read
+Roy T. Fielding’s dissertation
+as it does a great job explaining where it comes from and
+what it achieves.
    
+
    
+
    REST architecture
    
+
    
+
    REST is a client-server architecture. The client and the server
+both have a different set of concerns. The server stores and/or
+manipulates information and makes it available to the user in
+an efficient manner. The client takes that information and
+displays it to the user and/or uses it to perform subsequent
+requests for information. This separation of concerns allows both
+the client and the server to evolve independently as it only
+requires that the interface stays the same.
    
+
    REST is stateless. That means the communication between the
+client and the server always contains all the information needed
+to perform the request. There is no session state in the server,
+it is kept entirely on the client’s side. If access to a resource
+requires authentication, then the client needs to authenticate
+itself with every request.
    
+
    REST is cacheable. The client, the server and any intermediary
+components can all cache resources in order to improve performance.
    
+
    REST provides a uniform interface between components. This
+simplifies the architecture, as all components follow the same
+rules to speak to one another. It also makes it easier to understand
+the interactions between the different components of the system.
+A number of constraints are required to achieve this. They are
+covered in the rest of the chapter.
    
+
    REST is a layered system. Individual components cannot see
+beyond the immediate layer with which they are interacting. This
+means that a client connecting to an intermediate component, like
+a proxy, has no knowledge of what lies beyond. This allows
+components to be independent and thus easily replaceable or
+extendable.
    
+
    REST optionally provides code on demand. Code may be downloaded
+to extend client functionality. This is optional however because
+the client may not be able to download or run this code, and so
+a REST component cannot rely on it being executed.
    
+
    
+
    
+
    
+
    Resources and resource identifiers
    
+
    
+
    A resource is an abstract concept. In a REST system, any information
+that can be named may be a resource. This includes documents, images,
+a collection of resources and any other information. Any information
+that can be the target of an hypertext link can be a resource.
    
+
    A resource is a conceptual mapping to a set of entities. The set of
+entities evolves over time; a resource doesn’t. For example, a resource
+can map to "users who have logged in this past month" and another
+to "all users". At some point in time they may map to the same set of
+entities, because all users logged in this past month. But they are
+still different resources. Similarly, if nobody logged in recently,
+then the first resource may map to the empty set. This resource exists
+regardless of the information it maps to.
    
+
    Resources are identified by uniform resource identifiers, also known
+as URIs. Sometimes internationalized resource identifiers, or IRIs,
+may also be used, but these can be directly translated into a URI.
    
+
    In practice we will identify two kinds of resources. Individual
+resources map to a set of one element, for example "user Joe".
+Collection of resources map to a set of 0 to N elements,
+for example "all users".
    
+
    
+
    
+
    
+
    Resource representations
    
+
    
+
    The representation of a resource is a sequence of bytes associated
+with metadata.
    
+
    The metadata comes as a list of key-value pairs, where the name
+corresponds to a standard that defines the value’s structure and
+semantics. With HTTP, the metadata comes in the form of request
+or response headers. The headers' structure and semantics are well
+defined in the HTTP standard. Metadata includes representation
+metadata, resource metadata and control data.
    
+
    The representation metadata gives information about the
+representation, such as its media type, the date of last
+modification, or even a checksum.
    
+
    Resource metadata could be link to related resources or
+information about additional representations of the resource.
    
+
    Control data allows parameterizing the request or response.
+For example, we may only want the representation returned if
+it is more recent than the one we have in cache. Similarly,
+we may want to instruct the client about how it should cache
+the representation. This isn’t restricted to caching. We may,
+for example, want to store a new representation of a resource
+only if it wasn’t modified since we first retrieved it.
    
+
    The data format of a representation is also known as the media
+type. Some media types are intended for direct rendering to the
+user, while others are intended for automated processing. The
+media type is a key component of the REST architecture.
    
+
    
+
    
+
    
+
    Self-descriptive messages
    
+
    
+
    Messages must be self-descriptive. That means that the data
+format of a representation must always come with its media
+type (and similarly requesting a resource involves choosing
+the media type of the representation returned). If you are
+sending HTML, then you must say it is HTML by sending the
+media type with the representation. In HTTP this is done
+using the content-type header.
    
+
    The media type is often an IANA registered media type, like
+text/html or image/png, but does not need to be. Exactly
+two things are important for respecting this constraint: that
+the media type is well specified, and that the sender and
+recipient agree about what the media type refers to.
    
+
    This means that you can create your own media types, like
+application/x-mine, and that as long as you write the
+specifications for it and that both endpoints agree about
+it then the constraint is respected.
    
+
    
+
    
+
    
+
    Hypermedia as the engine of application state
    
+
    
+
    The last constraint is generally where services that claim
+to be RESTful fail. Interactions with a server must be
+entirely driven by hypermedia. The client does not need
+any prior knowledge of the service in order to use it,
+other than an entry point and of course basic understanding
+of the media type of the representations, at the very least
+enough to find and identify hyperlinks and link relations.
    
+
    To give a simple example, if your service only works with
+the application/json media type then this constraint
+cannot be respected (as there are no concept of links in
+JSON) and thus your service isn’t RESTful. This is the case
+for the majority of self-proclaimed REST services.
    
+
    On the other hand if you create a JSON based media type
+that has a concept of links and link relations, then
+your service might be RESTful.
    
+
    Respecting this constraint means that the entirety of the
+service becomes self-discoverable, not only the resources
+in it, but also the operations you can perform on it. This
+makes clients very thin as there is no need to implement
+anything specific to the service to operate on it.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/rest_put_post_patch.png b/docs/en/cowboy/2.1/guide/rest_put_post_patch.png
new file mode 100644
index 00000000..176650e9
Binary files /dev/null and b/docs/en/cowboy/2.1/guide/rest_put_post_patch.png differ
diff --git a/docs/en/cowboy/2.1/guide/rest_put_post_patch.svg b/docs/en/cowboy/2.1/guide/rest_put_post_patch.svg
new file mode 100644
index 00000000..06d55052
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_put_post_patch.svg
@@ -0,0 +1,2856 @@
+
+
+
+
+  
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+    
+  
+  
+    
+  
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    some text
+    some text
+    some text
+    conneg
+    resource_exists
+    
+    true
+    
+      
+      
+    
+    false
+    
+      
+      
+    
+    
+    middlewares
+    
+      
+      
+    
+    true
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    cond
+    
+      
+      
+    
+    
+    has if-match?
+    false
+    
+      
+      
+    
+    
+    method is POST/PATCH?
+    true
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+      
+      
+    
+    
+    method is POST?
+    
+    412 precondition failed
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    previously_existed
+    
+    
+      
+      
+    
+    404 not found
+    false
+    
+      
+      
+    
+    
+      
+      
+    
+    true*
+    false
+    
+    301 moved permanently
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    moved_temporarily
+    true*
+    false
+    
+    307 moved temporarily
+    
+    400 bad request
+    
+      
+      
+    
+    true
+    
+      
+      
+    
+    
+    allow_missing_post
+    
+    method is POST?
+    allow_missing_post
+    
+      
+      
+    
+    
+    method is PUT?
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    is_conflict
+    true
+    
+    409 conflict
+    
+      
+      
+    
+    
+    content_types_accepted
+    
+    AcceptCallback
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    new resource?
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    new resource?
+    
+    201 created
+    
+    303 see other
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    has resp location?
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    has resp body?
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    multiple_choices
+    false
+    
+    300 multiple choices
+    
+    200 OK
+    204 no content
+    true
+    
+      
+      
+    
+    true
+    
+    moved_permanently
+    
+    410 gone
+    false
+    true
+    false
+    false
+    false
+    false
+    
+      
+      
+    
+    true
+    
+      
+      
+    
+    true, URI*
+    
+      
+      
+    
+    true
+    false
+    true
+    true
+    false
+    true
+    false
+    true
+    false
+    false
+    false
+    
+    
+      
+        
+      
+      
+    
+    true
+    
+      
+      
+    
+    false
+    true
+  
+
diff --git a/docs/en/cowboy/2.1/guide/rest_start.png b/docs/en/cowboy/2.1/guide/rest_start.png
new file mode 100644
index 00000000..1f1e312e
Binary files /dev/null and b/docs/en/cowboy/2.1/guide/rest_start.png differ
diff --git a/docs/en/cowboy/2.1/guide/rest_start.svg b/docs/en/cowboy/2.1/guide/rest_start.svg
new file mode 100644
index 00000000..076c6195
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/rest_start.svg
@@ -0,0 +1,1356 @@
+
+
+
+
+  
+    
+      
+      
+    
+    
+      
+      
+      
+    
+    
+      
+    
+  
+  
+    
+  
+  
+    
+      
+        image/svg+xml
+        
+        
+      
+    
+  
+  
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+      
+      
+    
+    
+    
+    
+    
+    
+    
+    some text
+    some text
+    uri_too_long
+    malformed_request
+    some text
+    init
+    is_authorized
+    forbidden
+    valid_content_headers
+    valid_entity_length
+    ...
+    service_available
+    known_methods
+    allowed_methods
+    
+    true
+    known*
+    false
+    allowed*
+    false
+    true
+    false
+    true
+    true
+    
+      
+      
+    
+    false
+    unknown*
+    true
+    unallowed*
+    true
+    false*
+    true
+    false
+    false
+    
+    503 service unavailable
+    
+    
+    
+    
+    
+    
+    
+    
+    501 not implemented
+    414 request URI too long
+    405 method not allowed
+    400 bad request
+    401 unauthorized
+    403 forbidden
+    501 not implemented
+    413 request entity too large
+    
+    middlewares
+  
+
diff --git a/docs/en/cowboy/2.1/guide/routing.asciidoc b/docs/en/cowboy/2.1/guide/routing.asciidoc
new file mode 100644
index 00000000..47ef3c57
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/routing.asciidoc
@@ -0,0 +1,222 @@
+[[routing]]
+== Routing
+
+Cowboy does nothing by default.
+
+To make Cowboy useful, you need to map URIs to Erlang modules that will
+handle the requests. This is called routing.
+
+When Cowboy receives a request, it tries to match the requested host and
+path to the configured routes. When there's a match, the route's
+associated handler is executed.
+
+Routes need to be compiled before they can be used by Cowboy.
+The result of the compilation is the dispatch rules.
+
+=== Syntax
+
+The general structure for the routes is defined as follow.
+
+[source,erlang]
+Routes = [Host1, Host2, ... HostN].
+
+Each host contains matching rules for the host along with optional
+constraints, and a list of routes for the path component.
+
+[source,erlang]
+Host1 = {HostMatch, PathsList}.
+Host2 = {HostMatch, Constraints, PathsList}.
+
+The list of routes for the path component is defined similar to the
+list of hosts.
+
+[source,erlang]
+PathsList = [Path1, Path2, ... PathN].
+
+Finally, each path contains matching rules for the path along with
+optional constraints, and gives us the handler module to be used
+along with its initial state.
+
+[source,erlang]
+Path1 = {PathMatch, Handler, InitialState}.
+Path2 = {PathMatch, Constraints, Handler, InitialState}.
+
+Continue reading to learn more about the match syntax and the optional
+constraints.
+
+=== Match syntax
+
+The match syntax is used to associate host names and paths with their
+respective handlers.
+
+The match syntax is the same for host and path with a few subtleties.
+Indeed, the segments separator is different, and the host is matched
+starting from the last segment going to the first. All examples will
+feature both host and path match rules and explain the differences
+when encountered.
+
+Excluding special values that we will explain at the end of this section,
+the simplest match value is a host or a path. It can be given as either
+a `string()` or a `binary()`.
+
+[source,erlang]
+----
+PathMatch1 = "/".
+PathMatch2 = "/path/to/resource".
+
+HostMatch1 = "cowboy.example.org".
+----
+
+As you can see, all paths defined this way must start with a slash
+character. Note that these two paths are identical as far as routing
+is concerned.
+
+[source,erlang]
+PathMatch2 = "/path/to/resource".
+PathMatch3 = "/path/to/resource/".
+
+Hosts with and without a trailing dot are equivalent for routing.
+Similarly, hosts with and without a leading dot are also equivalent.
+
+[source,erlang]
+HostMatch1 = "cowboy.example.org".
+HostMatch2 = "cowboy.example.org.".
+HostMatch3 = ".cowboy.example.org".
+
+It is possible to extract segments of the host and path and to store
+the values in the `Req` object for later use. We call these kind of
+values bindings.
+
+The syntax for bindings is very simple. A segment that begins with
+the `:` character means that what follows until the end of the segment
+is the name of the binding in which the segment value will be stored.
+
+[source,erlang]
+PathMatch = "/hats/:name/prices".
+HostMatch = ":subdomain.example.org".
+
+If these two end up matching when routing, you will end up with two
+bindings defined, `subdomain` and `name`, each containing the
+segment value where they were defined. For example, the URL
+`http://test.example.org/hats/wild_cowboy_legendary/prices` will
+result in having the value `test` bound to the name `subdomain`
+and the value `wild_cowboy_legendary` bound to the name `name`.
+They can later be retrieved using `cowboy_req:binding/{2,3}`. The
+binding name must be given as an atom.
+
+There is a special binding name you can use to mimic the underscore
+variable in Erlang. Any match against the `_` binding will succeed
+but the data will be discarded. This is especially useful for
+matching against many domain names in one go.
+
+[source,erlang]
+HostMatch = "ninenines.:_".
+
+Similarly, it is possible to have optional segments. Anything
+between brackets is optional.
+
+[source,erlang]
+PathMatch = "/hats/[page/:number]".
+HostMatch = "[www.]ninenines.eu".
+
+You can also have imbricated optional segments.
+
+[source,erlang]
+PathMatch = "/hats/[page/[:number]]".
+
+You can retrieve the rest of the host or path using `[...]`.
+In the case of hosts it will match anything before, in the case
+of paths anything after the previously matched segments. It is
+a special case of optional segments, in that it can have
+zero, one or many segments. You can then find the segments using
+`cowboy_req:host_info/1` and `cowboy_req:path_info/1` respectively.
+They will be represented as a list of segments.
+
+[source,erlang]
+PathMatch = "/hats/[...]".
+HostMatch = "[...]ninenines.eu".
+
+If a binding appears twice in the routing rules, then the match
+will succeed only if they share the same value. This copies the
+Erlang pattern matching behavior.
+
+[source,erlang]
+PathMatch = "/hats/:name/:name".
+
+This is also true when an optional segment is present. In this
+case the two values must be identical only if the segment is
+available.
+
+[source,erlang]
+PathMatch = "/hats/:name/[:name]".
+
+If a binding is defined in both the host and path, then they must
+also share the same value.
+
+[source,erlang]
+PathMatch = "/:user/[...]".
+HostMatch = ":user.github.com".
+
+Finally, there are two special match values that can be used. The
+first is the atom `'_'` which will match any host or path.
+
+[source,erlang]
+PathMatch = '_'.
+HostMatch = '_'.
+
+The second is the special host match `"*"` which will match the
+wildcard path, generally used alongside the `OPTIONS` method.
+
+[source,erlang]
+HostMatch = "*".
+
+=== Constraints
+
+After the matching has completed, the resulting bindings can be tested
+against a set of constraints. Constraints are only tested when the
+binding is defined. They run in the order you defined them. The match
+will succeed only if they all succeed. If the match fails, then Cowboy
+tries the next route in the list.
+
+The format used for constraints is the same as match functions in
+`cowboy_req`: they are provided as a list of fields which may have
+one or more constraints. While the router accepts the same format,
+it will skip fields with no constraints and will also ignore default
+values, if any.
+
+Read more about xref:constraints[constraints].
+
+=== Compilation
+
+The routes must be compiled before Cowboy can use them. The compilation
+step normalizes the routes to simplify the code and speed up the
+execution, but the routes are still looked up one by one in the end.
+Faster compilation strategies could be to compile the routes directly
+to Erlang code, but would require heavier dependencies.
+
+To compile routes, just call the appropriate function:
+
+[source,erlang]
+----
+Dispatch = cowboy_router:compile([
+    %% {HostMatch, list({PathMatch, Handler, InitialState})}
+    {'_', [{'_', my_handler, #{}}]}
+]),
+%% Name, NbAcceptors, TransOpts, ProtoOpts
+cowboy:start_clear(my_http_listener,
+    [{port, 8080}],
+    #{env => #{dispatch => Dispatch}}
+).
+----
+
+=== Live update
+
+You can use the `cowboy:set_env/3` function for updating the dispatch
+list used by routing. This will apply to all new connections accepted
+by the listener:
+
+[source,erlang]
+Dispatch = cowboy_router:compile(Routes),
+cowboy:set_env(my_http_listener, dispatch, Dispatch).
+
+Note that you need to compile the routes again before updating.
diff --git a/docs/en/cowboy/2.1/guide/routing/index.html b/docs/en/cowboy/2.1/guide/routing/index.html
new file mode 100644
index 00000000..6b1a2748
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/routing/index.html
@@ -0,0 +1,418 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Routing
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Routing
    
+
+
    Cowboy does nothing by default.
    
+
    To make Cowboy useful, you need to map URIs to Erlang modules that will
+handle the requests. This is called routing.
    
+
    When Cowboy receives a request, it tries to match the requested host and
+path to the configured routes. When there’s a match, the route’s
+associated handler is executed.
    
+
    Routes need to be compiled before they can be used by Cowboy.
+The result of the compilation is the dispatch rules.
    
+
    
+
    Syntax
    
+
    
+
    The general structure for the routes is defined as follow.
    
+
    
+
    
+
    Routes = [Host1, Host2, ... HostN].
    
+
    Each host contains matching rules for the host along with optional
+constraints, and a list of routes for the path component.
    
+
    
+
    
+
    Host1 = {HostMatch, PathsList}.
+Host2 = {HostMatch, Constraints, PathsList}.
    
+
    The list of routes for the path component is defined similar to the
+list of hosts.
    
+
    
+
    
+
    PathsList = [Path1, Path2, ... PathN].
    
+
    Finally, each path contains matching rules for the path along with
+optional constraints, and gives us the handler module to be used
+along with its initial state.
    
+
    
+
    
+
    Path1 = {PathMatch, Handler, InitialState}.
+Path2 = {PathMatch, Constraints, Handler, InitialState}.
    
+
    Continue reading to learn more about the match syntax and the optional
+constraints.
    
+
    
+
    
+
    
+
    Match syntax
    
+
    
+
    The match syntax is used to associate host names and paths with their
+respective handlers.
    
+
    The match syntax is the same for host and path with a few subtleties.
+Indeed, the segments separator is different, and the host is matched
+starting from the last segment going to the first. All examples will
+feature both host and path match rules and explain the differences
+when encountered.
    
+
    Excluding special values that we will explain at the end of this section,
+the simplest match value is a host or a path. It can be given as either
+a string() or a binary().
    
+
    
+
    
+
    PathMatch1 = "/".
+PathMatch2 = "/path/to/resource".
+
+HostMatch1 = "cowboy.example.org".
    
+
    As you can see, all paths defined this way must start with a slash
+character. Note that these two paths are identical as far as routing
+is concerned.
    
+
    
+
    
+
    PathMatch2 = "/path/to/resource".
+PathMatch3 = "/path/to/resource/".
    
+
    Hosts with and without a trailing dot are equivalent for routing.
+Similarly, hosts with and without a leading dot are also equivalent.
    
+
    
+
    
+
    HostMatch1 = "cowboy.example.org".
+HostMatch2 = "cowboy.example.org.".
+HostMatch3 = ".cowboy.example.org".
    
+
    It is possible to extract segments of the host and path and to store
+the values in the Req object for later use. We call these kind of
+values bindings.
    
+
    The syntax for bindings is very simple. A segment that begins with
+the : character means that what follows until the end of the segment
+is the name of the binding in which the segment value will be stored.
    
+
    
+
    
+
    PathMatch = "/hats/:name/prices".
+HostMatch = ":subdomain.example.org".
    
+
    If these two end up matching when routing, you will end up with two
+bindings defined, subdomain and name, each containing the
+segment value where they were defined. For example, the URL
+http://test.example.org/hats/wild_cowboy_legendary/prices will
+result in having the value test bound to the name subdomain
+and the value wild_cowboy_legendary bound to the name name.
+They can later be retrieved using cowboy_req:binding/{2,3}. The
+binding name must be given as an atom.
    
+
    There is a special binding name you can use to mimic the underscore
+variable in Erlang. Any match against the _ binding will succeed
+but the data will be discarded. This is especially useful for
+matching against many domain names in one go.
    
+
    
+
    
+
    HostMatch = "ninenines.:_".
    
+
    Similarly, it is possible to have optional segments. Anything
+between brackets is optional.
    
+
    
+
    
+
    PathMatch = "/hats/[page/:number]".
+HostMatch = "[www.]ninenines.eu".
    
+
    You can also have imbricated optional segments.
    
+
    
+
    
+
    PathMatch = "/hats/[page/[:number]]".
    
+
    You can retrieve the rest of the host or path using [...].
+In the case of hosts it will match anything before, in the case
+of paths anything after the previously matched segments. It is
+a special case of optional segments, in that it can have
+zero, one or many segments. You can then find the segments using
+cowboy_req:host_info/1 and cowboy_req:path_info/1 respectively.
+They will be represented as a list of segments.
    
+
    
+
    
+
    PathMatch = "/hats/[...]".
+HostMatch = "[...]ninenines.eu".
    
+
    If a binding appears twice in the routing rules, then the match
+will succeed only if they share the same value. This copies the
+Erlang pattern matching behavior.
    
+
    
+
    
+
    PathMatch = "/hats/:name/:name".
    
+
    This is also true when an optional segment is present. In this
+case the two values must be identical only if the segment is
+available.
    
+
    
+
    
+
    PathMatch = "/hats/:name/[:name]".
    
+
    If a binding is defined in both the host and path, then they must
+also share the same value.
    
+
    
+
    
+
    PathMatch = "/:user/[...]".
+HostMatch = ":user.github.com".
    
+
    Finally, there are two special match values that can be used. The
+first is the atom '_' which will match any host or path.
    
+
    
+
    
+
    PathMatch = '_'.
+HostMatch = '_'.
    
+
    The second is the special host match "*" which will match the
+wildcard path, generally used alongside the OPTIONS method.
    
+
    
+
    
+
    HostMatch = "*".
    
+
    
+
    
+
    
+
    Constraints
    
+
    
+
    After the matching has completed, the resulting bindings can be tested
+against a set of constraints. Constraints are only tested when the
+binding is defined. They run in the order you defined them. The match
+will succeed only if they all succeed. If the match fails, then Cowboy
+tries the next route in the list.
    
+
    The format used for constraints is the same as match functions in
+cowboy_req: they are provided as a list of fields which may have
+one or more constraints. While the router accepts the same format,
+it will skip fields with no constraints and will also ignore default
+values, if any.
    
+
    Read more about constraints.
    
+
    
+
    
+
    
+
    Compilation
    
+
    
+
    The routes must be compiled before Cowboy can use them. The compilation
+step normalizes the routes to simplify the code and speed up the
+execution, but the routes are still looked up one by one in the end.
+Faster compilation strategies could be to compile the routes directly
+to Erlang code, but would require heavier dependencies.
    
+
    To compile routes, just call the appropriate function:
    
+
    
+
    
+
    Dispatch = cowboy_router:compile([
+    %% {HostMatch, list({PathMatch, Handler, InitialState})}
+    {'_', [{'_', my_handler, #{}}]}
+]),
+%% Name, NbAcceptors, TransOpts, ProtoOpts
+cowboy:start_clear(my_http_listener,
+    [{port, 8080}],
+    #{env => #{dispatch => Dispatch}}
+).
    
+
    
+
    
+
    
+
    Live update
    
+
    
+
    You can use the cowboy:set_env/3 function for updating the dispatch
+list used by routing. This will apply to all new connections accepted
+by the listener:
    
+
    
+
    
+
    Dispatch = cowboy_router:compile(Routes),
+cowboy:set_env(my_http_listener, dispatch, Dispatch).
    
+
    Note that you need to compile the routes again before updating.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/specs.asciidoc b/docs/en/cowboy/2.1/guide/specs.asciidoc
new file mode 100644
index 00000000..ec101fbd
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/specs.asciidoc
@@ -0,0 +1,189 @@
+[appendix]
+== HTTP and other specifications
+
+This chapter intends to list all the specification documents
+for or related to HTTP.
+
+=== HTTP
+
+==== IANA Registries
+
+* https://www.iana.org/assignments/http-methods/http-methods.xhtml[HTTP Method Registry]
+* https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml[HTTP Status Code Registry]
+* https://www.iana.org/assignments/message-headers/message-headers.xhtml[Message Headers]
+* https://www.iana.org/assignments/http-parameters/http-parameters.xhtml[HTTP Parameters]
+* https://www.iana.org/assignments/http-alt-svc-parameters/http-alt-svc-parameters.xhtml[HTTP Alt-Svc Parameter Registry]
+* https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml[HTTP Authentication Scheme Registry]
+* https://www.iana.org/assignments/http-cache-directives/http-cache-directives.xhtml[HTTP Cache Directive Registry]
+* https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml[HTTP Digest Algorithm Values]
+* https://www.iana.org/assignments/hoba-device-identifiers/hoba-device-identifiers.xhtml[HTTP Origin-Bound Authentication Device Identifier Types]
+* https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml[HTTP Upgrade Token Registry]
+* https://www.iana.org/assignments/http-warn-codes/http-warn-codes.xhtml[HTTP Warn Codes]
+* https://www.iana.org/assignments/http2-parameters/http2-parameters.xhtml[HTTP/2 Parameters]
+* https://www.ietf.org/assignments/websocket/websocket.xml[WebSocket Protocol Registries]
+
+==== Current
+
+* http://www.w3.org/TR/cors/[CORS]: Cross-Origin Resource Sharing
+* http://www.w3.org/TR/CSP2/[CSP2]: Content Security Policy Level 2
+* http://www.w3.org/TR/tracking-dnt/[DNT]: Tracking Preference Expression (DNT)
+* http://www.w3.org/TR/eventsource/[eventsource]: Server-Sent Events
+* https://www.w3.org/TR/html4/interact/forms.html#h-17.13.4[Form content types]: Form content types
+* https://www.w3.org/TR/preload/[Preload]: Preload
+* http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm[REST]: Fielding's Dissertation
+* https://tools.ietf.org/html/rfc1945[RFC 1945]: HTTP/1.0
+* https://tools.ietf.org/html/rfc1951[RFC 1951]: DEFLATE Compressed Data Format Specification version 1.3
+* https://tools.ietf.org/html/rfc1952[RFC 1952]: GZIP file format specification version 4.3
+* https://tools.ietf.org/html/rfc2046#section-5.1[RFC 2046]: Multipart media type (in MIME Part Two: Media Types)
+* https://tools.ietf.org/html/rfc2295[RFC 2295]: Transparent Content Negotiation in HTTP
+* https://tools.ietf.org/html/rfc2296[RFC 2296]: HTTP Remote Variant Selection Algorithm: RVSA/1.0
+* https://tools.ietf.org/html/rfc2817[RFC 2817]: Upgrading to TLS Within HTTP/1.1
+* https://tools.ietf.org/html/rfc2818[RFC 2818]: HTTP Over TLS
+* https://tools.ietf.org/html/rfc3230[RFC 3230]: Instance Digests in HTTP
+* https://tools.ietf.org/html/rfc4559[RFC 4559]: SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows
+* https://tools.ietf.org/html/rfc5789[RFC 5789]: PATCH Method for HTTP
+* https://tools.ietf.org/html/rfc5843[RFC 5843]: Additional Hash Algorithms for HTTP Instance Digests
+* https://tools.ietf.org/html/rfc5861[RFC 5861]: HTTP Cache-Control Extensions for Stale Content
+* https://tools.ietf.org/html/rfc5988[RFC 5988]: Web Linking
+* https://tools.ietf.org/html/rfc6265[RFC 6265]: HTTP State Management Mechanism
+* https://tools.ietf.org/html/rfc6266[RFC 6266]: Use of the Content-Disposition Header Field
+* https://tools.ietf.org/html/rfc6454[RFC 6454]: The Web Origin Concept
+* https://tools.ietf.org/html/rfc6455[RFC 6455]: The WebSocket Protocol
+* https://tools.ietf.org/html/rfc6585[RFC 6585]: Additional HTTP Status Codes
+* https://tools.ietf.org/html/rfc6750[RFC 6750]: The OAuth 2.0 Authorization Framework: Bearer Token Usage
+* https://tools.ietf.org/html/rfc6797[RFC 6797]: HTTP Strict Transport Security (HSTS)
+* https://tools.ietf.org/html/rfc6903[RFC 6903]: Additional Link Relation Types
+* https://tools.ietf.org/html/rfc7034[RFC 7034]: HTTP Header Field X-Frame-Options
+* https://tools.ietf.org/html/rfc7089[RFC 7089]: Time-Based Access to Resource States: Memento
+* https://tools.ietf.org/html/rfc7230[RFC 7230]: HTTP/1.1 Message Syntax and Routing
+* https://tools.ietf.org/html/rfc7231[RFC 7231]: HTTP/1.1 Semantics and Content
+* https://tools.ietf.org/html/rfc7232[RFC 7232]: HTTP/1.1 Conditional Requests
+* https://tools.ietf.org/html/rfc7233[RFC 7233]: HTTP/1.1 Range Requests
+* https://tools.ietf.org/html/rfc7234[RFC 7234]: HTTP/1.1 Caching
+* https://tools.ietf.org/html/rfc7235[RFC 7235]: HTTP/1.1 Authentication
+* https://tools.ietf.org/html/rfc7239[RFC 7239]: Forwarded HTTP Extension
+* https://tools.ietf.org/html/rfc7240[RFC 7240]: Prefer Header for HTTP
+* https://tools.ietf.org/html/rfc7469[RFC 7469]: Public Key Pinning Extension for HTTP
+* https://tools.ietf.org/html/rfc7486[RFC 7486]: HTTP Origin-Bound Authentication (HOBA)
+* https://tools.ietf.org/html/rfc7538[RFC 7538]: HTTP Status Code 308 (Permanent Redirect)
+* https://tools.ietf.org/html/rfc7540[RFC 7540]: Hypertext Transfer Protocol Version 2 (HTTP/2)
+* https://tools.ietf.org/html/rfc7541[RFC 7541]: HPACK: Header Compression for HTTP/2
+* https://tools.ietf.org/html/rfc7578[RFC 7578]: Returning Values from Forms: multipart/form-data
+* https://tools.ietf.org/html/rfc7615[RFC 7615]: HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields
+* https://tools.ietf.org/html/rfc7616[RFC 7616]: HTTP Digest Access Authentication
+* https://tools.ietf.org/html/rfc7617[RFC 7617]: The 'Basic' HTTP Authentication Scheme
+* https://tools.ietf.org/html/rfc7639[RFC 7639]: The ALPN HTTP Header Field
+* https://tools.ietf.org/html/rfc7692[RFC 7692]: Compression Extensions for WebSocket
+* https://tools.ietf.org/html/rfc7694[RFC 7694]: HTTP Client-Initiated Content-Encoding
+* https://tools.ietf.org/html/rfc7725[RFC 7725]: An HTTP Status Code to Report Legal Obstacles
+* https://tools.ietf.org/html/rfc7804[RFC 7804]: Salted Challenge Response HTTP Authentication Mechanism
+* https://tools.ietf.org/html/rfc7838[RFC 7838]: HTTP Alternative Services
+* https://tools.ietf.org/html/rfc7932[RFC 7932]: Brotli Compressed Data Format
+* https://tools.ietf.org/html/rfc7936[RFC 7936]: Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry
+* https://tools.ietf.org/html/rfc8053[RFC 8053]: HTTP Authentication Extensions for Interactive Clients
+* https://tools.ietf.org/html/rfc8164[RFC 8164]: Opportunistic Security for HTTP/2
+* https://tools.ietf.org/html/rfc8187[RFC 8187]: Indicating Character Encoding and Language for HTTP Header Field Parameters
+* https://tools.ietf.org/html/rfc8188[RFC 8188]: Encrypted Content-Encoding for HTTP
+* https://tools.ietf.org/html/rfc8246[RFC 8246]: HTTP Immutable Responses
+* https://www.w3.org/TR/webmention/[Webmention]: Webmention
+
+==== Upcoming
+
+* https://www.w3.org/TR/csp-cookies/[Content Security Policy: Cookie Controls]
+* https://www.w3.org/TR/csp-embedded-enforcement/[Content Security Policy: Embedded Enforcement]
+* https://www.w3.org/TR/CSP3/[Content Security Policy Level 3]
+* https://www.w3.org/TR/csp-pinning/[Content Security Policy Pinning]
+* http://www.w3.org/TR/referrer-policy/[Referrer Policy]
+* http://www.w3.org/TR/UISecurity/[User Interface Security Directives for Content Security Policy]
+
+==== Informative
+
+* http://www.w3.org/TR/webarch/[Architecture of the World Wide Web]
+* https://tools.ietf.org/html/rfc2936[RFC 2936]: HTTP MIME Type Handler Detection
+* https://tools.ietf.org/html/rfc2964[RFC 2964]: Use of HTTP State Management
+* https://tools.ietf.org/html/rfc3143[RFC 3143]: Known HTTP Proxy/Caching Problems
+* https://tools.ietf.org/html/rfc6202[RFC 6202]: Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP
+* https://tools.ietf.org/html/rfc6838[RFC 6838]: Media Type Specifications and Registration Procedures
+* https://tools.ietf.org/html/rfc7478[RFC 7478]: Web Real-Time Communication Use Cases and Requirements
+
+==== Related
+
+* http://www.w3.org/TR/app-uri/[app: URL Scheme]
+* http://www.w3.org/TR/beacon/[Beacon]
+* http://www.w3.org/TR/FileAPI/[File API]
+* https://tools.ietf.org/html/rfc8030[Generic Event Delivery Using HTTP Push]
+* http://www.w3.org/TR/capability-urls/[Good Practices for Capability URLs]
+* https://html.spec.whatwg.org/multipage/[HTML Living Standard]
+* https://developers.whatwg.org/[HTML Living Standard for Web developers]
+* http://www.w3.org/TR/html401/[HTML4.01]
+* http://www.w3.org/TR/html5/[HTML5]
+* http://www.w3.org/TR/html51/[HTML5.1]
+* https://www.w3.org/TR/html52/[HTML5.2]
+* http://www.w3.org/TR/media-frags/[Media Fragments URI 1.0]
+* https://tools.ietf.org/html/rfc6690[RFC 6690]: Constrained RESTful Environments (CoRE) Link Format
+* https://tools.ietf.org/html/rfc7807[RFC 7807]: Problem Details for HTTP APIs
+* https://tools.ietf.org/html/rfc6906[RFC 6906]: The 'profile' Link Relation Type
+* http://www.w3.org/TR/SRI/[Subresource Integrity]
+* http://www.w3.org/TR/tracking-compliance/[Tracking Compliance and Scope]
+* http://www.w3.org/TR/media-frags-reqs/[Use cases and requirements for Media Fragments]
+* http://www.w3.org/TR/webrtc/[WebRTC 1.0: Real-time Communication Between Browsers]
+* http://www.w3.org/TR/websockets/[Websocket API]
+* http://www.w3.org/TR/XMLHttpRequest/[XMLHttpRequest Level 1]
+* https://xhr.spec.whatwg.org/[XMLHttpRequest Living Standard]
+
+==== Seemingly obsolete
+
+* https://tools.ietf.org/html/rfc2227[RFC 2227]: Simple Hit-Metering and Usage-Limiting for HTTP
+* https://tools.ietf.org/html/rfc2310[RFC 2310]: The Safe Response Header Field
+* https://tools.ietf.org/html/rfc2324[RFC 2324]: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
+* https://tools.ietf.org/html/rfc2660[RFC 2660]: The Secure HyperText Transfer Protocol
+* https://tools.ietf.org/html/rfc2774[RFC 2774]: An HTTP Extension Framework
+* https://tools.ietf.org/html/rfc2965[RFC 2965]: HTTP State Management Mechanism (Cookie2)
+* https://tools.ietf.org/html/rfc3229[RFC 3229]: Delta encoding in HTTP
+* https://tools.ietf.org/html/rfc7168[RFC 7168]: The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)
+* http://dev.chromium.org/spdy/spdy-protocol[SPDY]: SPDY Protocol
+* https://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-06[x-webkit-deflate-frame]: Deprecated Websocket compression
+
+=== URL
+
+* https://tools.ietf.org/html/rfc3986[RFC 3986]: URI Generic Syntax
+* https://tools.ietf.org/html/rfc6570[RFC 6570]: URI Template
+* https://tools.ietf.org/html/rfc6874[RFC 6874]: Representing IPv6 Zone Identifiers in Address Literals and URIs
+* https://tools.ietf.org/html/rfc7320[RFC 7320]: URI Design and Ownership
+* http://www.w3.org/TR/url-1/[URL]
+* https://url.spec.whatwg.org/[URL Living Standard]
+
+=== WebDAV
+
+* https://tools.ietf.org/html/rfc3253[RFC 3253]: Versioning Extensions to WebDAV
+* https://tools.ietf.org/html/rfc3648[RFC 3648]: WebDAV Ordered Collections Protocol
+* https://tools.ietf.org/html/rfc3744[RFC 3744]: WebDAV Access Control Protocol
+* https://tools.ietf.org/html/rfc4316[RFC 4316]: Datatypes for WebDAV Properties
+* https://tools.ietf.org/html/rfc4331[RFC 4331]: Quota and Size Properties for DAV Collections
+* https://tools.ietf.org/html/rfc4437[RFC 4437]: WebDAV Redirect Reference Resources
+* https://tools.ietf.org/html/rfc4709[RFC 4709]: Mounting WebDAV Servers
+* https://tools.ietf.org/html/rfc4791[RFC 4791]: Calendaring Extensions to WebDAV (CalDAV)
+* https://tools.ietf.org/html/rfc4918[RFC 4918]: HTTP Extensions for WebDAV
+* https://tools.ietf.org/html/rfc5323[RFC 5323]: WebDAV SEARCH
+* https://tools.ietf.org/html/rfc5397[RFC 5397]: WebDAV Current Principal Extension
+* https://tools.ietf.org/html/rfc5689[RFC 5689]: Extended MKCOL for WebDAV
+* https://tools.ietf.org/html/rfc5842[RFC 5842]: Binding Extensions to WebDAV
+* https://tools.ietf.org/html/rfc5995[RFC 5995]: Using POST to Add Members to WebDAV Collections
+* https://tools.ietf.org/html/rfc6352[RFC 6352]: CardDAV: vCard Extensions to WebDAV
+* https://tools.ietf.org/html/rfc6578[RFC 6578]: Collection Synchronization for WebDAV
+* https://tools.ietf.org/html/rfc6638[RFC 6638]: Scheduling Extensions to CalDAV
+* https://tools.ietf.org/html/rfc6764[RFC 6764]: Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)
+* https://tools.ietf.org/html/rfc7809[RFC 7809]: Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference
+* https://tools.ietf.org/html/rfc7953[RFC 7953]: Calendar Availability
+* https://tools.ietf.org/html/rfc8144[RFC 8144]: Use of the Prefer Header Field in WebDAV
+
+=== CoAP
+
+* https://tools.ietf.org/html/rfc7252[RFC 7252]: The Constrained Application Protocol (CoAP)
+* https://tools.ietf.org/html/rfc7390[RFC 7390]: Group Communication for CoAP
+* https://tools.ietf.org/html/rfc7641[RFC 7641]: Observing Resources in CoAP
+* https://tools.ietf.org/html/rfc7650[RFC 7650]: A CoAP Usage for REsource LOcation And Discovery (RELOAD)
+* https://tools.ietf.org/html/rfc7959[RFC 7959]: Block-Wise Transfers in CoAP
+* https://tools.ietf.org/html/rfc7967[RFC 7967]: CoAP Option for No Server Response
+* https://tools.ietf.org/html/rfc8075[RFC 8075]: Guidelines for Mapping Implementations: HTTP to CoAP
+* https://tools.ietf.org/html/rfc8132[RFC 8132]: PATCH and FETCH Methods for CoAP
diff --git a/docs/en/cowboy/2.1/guide/specs/index.html b/docs/en/cowboy/2.1/guide/specs/index.html
new file mode 100644
index 00000000..3eb1f286
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/specs/index.html
@@ -0,0 +1,992 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: HTTP and other specifications
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    HTTP and other specifications
    
+
+
    This chapter intends to list all the specification documents
+for or related to HTTP.
    
+
    
+
    HTTP
    
+
    
+
    
+
    IANA Registries
    
+
    
+
    
+
    
+
    Current
    
+
      
+
    • 
+
      
+CORS: Cross-Origin Resource Sharing
+
      
+
      • 
+
    • 
+
      
+CSP2: Content Security Policy Level 2
+
      
+
      • 
+
    • 
+
      
+DNT: Tracking Preference Expression (DNT)
+
      
+
      • 
+
    • 
+
      
+eventsource: Server-Sent Events
+
      
+
      • 
+
    • 
+
      
+Form content types: Form content types
+
      
+
      • 
+
    • 
+
      
+Preload: Preload
+
      
+
      • 
+
    • 
+
      
+REST: Fielding’s Dissertation
+
      
+
      • 
+
    • 
+
      
+RFC 1945: HTTP/1.0
+
      
+
      • 
+
    • 
+
      
+RFC 1951: DEFLATE Compressed Data Format Specification version 1.3
+
      
+
      • 
+
    • 
+
      
+RFC 1952: GZIP file format specification version 4.3
+
      
+
      • 
+
    • 
+
      
+RFC 2046: Multipart media type (in MIME Part Two: Media Types)
+
      
+
      • 
+
    • 
+
      
+RFC 2295: Transparent Content Negotiation in HTTP
+
      
+
      • 
+
    • 
+
      
+RFC 2296: HTTP Remote Variant Selection Algorithm: RVSA/1.0
+
      
+
      • 
+
    • 
+
      
+RFC 2817: Upgrading to TLS Within HTTP/1.1
+
      
+
      • 
+
    • 
+
      
+RFC 2818: HTTP Over TLS
+
      
+
      • 
+
    • 
+
      
+RFC 3230: Instance Digests in HTTP
+
      
+
      • 
+
    • 
+
      
+RFC 4559: SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows
+
      
+
      • 
+
    • 
+
      
+RFC 5789: PATCH Method for HTTP
+
      
+
      • 
+
    • 
+
      
+RFC 5843: Additional Hash Algorithms for HTTP Instance Digests
+
      
+
      • 
+
    • 
+
      
+RFC 5861: HTTP Cache-Control Extensions for Stale Content
+
      
+
      • 
+
    • 
+
      
+RFC 5988: Web Linking
+
      
+
      • 
+
    • 
+
      
+RFC 6265: HTTP State Management Mechanism
+
      
+
      • 
+
    • 
+
      
+RFC 6266: Use of the Content-Disposition Header Field
+
      
+
      • 
+
    • 
+
      
+RFC 6454: The Web Origin Concept
+
      
+
      • 
+
    • 
+
      
+RFC 6455: The WebSocket Protocol
+
      
+
      • 
+
    • 
+
      
+RFC 6585: Additional HTTP Status Codes
+
      
+
      • 
+
    • 
+
      
+RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage
+
      
+
      • 
+
    • 
+
      
+RFC 6797: HTTP Strict Transport Security (HSTS)
+
      
+
      • 
+
    • 
+
      
+RFC 6903: Additional Link Relation Types
+
      
+
      • 
+
    • 
+
      
+RFC 7034: HTTP Header Field X-Frame-Options
+
      
+
      • 
+
    • 
+
      
+RFC 7089: Time-Based Access to Resource States: Memento
+
      
+
      • 
+
    • 
+
      
+RFC 7230: HTTP/1.1 Message Syntax and Routing
+
      
+
      • 
+
    • 
+
      
+RFC 7231: HTTP/1.1 Semantics and Content
+
      
+
      • 
+
    • 
+
      
+RFC 7232: HTTP/1.1 Conditional Requests
+
      
+
      • 
+
    • 
+
      
+RFC 7233: HTTP/1.1 Range Requests
+
      
+
      • 
+
    • 
+
      
+RFC 7234: HTTP/1.1 Caching
+
      
+
      • 
+
    • 
+
      
+RFC 7235: HTTP/1.1 Authentication
+
      
+
      • 
+
    • 
+
      
+RFC 7239: Forwarded HTTP Extension
+
      
+
      • 
+
    • 
+
      
+RFC 7240: Prefer Header for HTTP
+
      
+
      • 
+
    • 
+
      
+RFC 7469: Public Key Pinning Extension for HTTP
+
      
+
      • 
+
    • 
+
      
+RFC 7486: HTTP Origin-Bound Authentication (HOBA)
+
      
+
      • 
+
    • 
+
      
+RFC 7538: HTTP Status Code 308 (Permanent Redirect)
+
      
+
      • 
+
    • 
+
      
+RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2)
+
      
+
      • 
+
    • 
+
      
+RFC 7541: HPACK: Header Compression for HTTP/2
+
      
+
      • 
+
    • 
+
      
+RFC 7578: Returning Values from Forms: multipart/form-data
+
      
+
      • 
+
    • 
+
      
+RFC 7615: HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields
+
      
+
      • 
+
    • 
+
      
+RFC 7616: HTTP Digest Access Authentication
+
      
+
      • 
+
    • 
+
      
+RFC 7617: The Basic HTTP Authentication Scheme
+
      
+
      • 
+
    • 
+
      
+RFC 7639: The ALPN HTTP Header Field
+
      
+
      • 
+
    • 
+
      
+RFC 7692: Compression Extensions for WebSocket
+
      
+
      • 
+
    • 
+
      
+RFC 7694: HTTP Client-Initiated Content-Encoding
+
      
+
      • 
+
    • 
+
      
+RFC 7725: An HTTP Status Code to Report Legal Obstacles
+
      
+
      • 
+
    • 
+
      
+RFC 7804: Salted Challenge Response HTTP Authentication Mechanism
+
      
+
      • 
+
    • 
+
      
+RFC 7838: HTTP Alternative Services
+
      
+
      • 
+
    • 
+
      
+RFC 7932: Brotli Compressed Data Format
+
      
+
      • 
+
    • 
+
      
+RFC 7936: Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry
+
      
+
      • 
+
    • 
+
      
+RFC 8053: HTTP Authentication Extensions for Interactive Clients
+
      
+
      • 
+
    • 
+
      
+RFC 8164: Opportunistic Security for HTTP/2
+
      
+
      • 
+
    • 
+
      
+RFC 8187: Indicating Character Encoding and Language for HTTP Header Field Parameters
+
      
+
      • 
+
    • 
+
      
+RFC 8188: Encrypted Content-Encoding for HTTP
+
      
+
      • 
+
    • 
+
      
+RFC 8246: HTTP Immutable Responses
+
      
+
      • 
+
    • 
+
      
+Webmention: Webmention
+
      
+
      • 
+
    
+
    
+
    
+
    Upcoming
    
+
    
+
    
+
    
+
    Informative
    
+
      
+
    • 
+
      
+Architecture of the World Wide Web
+
      
+
      • 
+
    • 
+
      
+RFC 2936: HTTP MIME Type Handler Detection
+
      
+
      • 
+
    • 
+
      
+RFC 2964: Use of HTTP State Management
+
      
+
      • 
+
    • 
+
      
+RFC 3143: Known HTTP Proxy/Caching Problems
+
      
+
      • 
+
    • 
+
      
+RFC 6202: Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP
+
      
+
      • 
+
    • 
+
      
+RFC 6838: Media Type Specifications and Registration Procedures
+
      
+
      • 
+
    • 
+
      
+RFC 7478: Web Real-Time Communication Use Cases and Requirements
+
      
+
      • 
+
    
+
    
+
    
+
    Related
    
+
    
+
    
+
    
+
    Seemingly obsolete
    
+
      
+
    • 
+
      
+RFC 2227: Simple Hit-Metering and Usage-Limiting for HTTP
+
      
+
      • 
+
    • 
+
      
+RFC 2310: The Safe Response Header Field
+
      
+
      • 
+
    • 
+
      
+RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
+
      
+
      • 
+
    • 
+
      
+RFC 2660: The Secure HyperText Transfer Protocol
+
      
+
      • 
+
    • 
+
      
+RFC 2774: An HTTP Extension Framework
+
      
+
      • 
+
    • 
+
      
+RFC 2965: HTTP State Management Mechanism (Cookie2)
+
      
+
      • 
+
    • 
+
      
+RFC 3229: Delta encoding in HTTP
+
      
+
      • 
+
    • 
+
      
+RFC 7168: The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)
+
      
+
      • 
+
    • 
+
      
+SPDY: SPDY Protocol
+
      
+
      • 
+
    • 
+
      
+x-webkit-deflate-frame: Deprecated Websocket compression
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    
+
    URL
    
+
    
+
    
+
    
+
    
+
    
+
    WebDAV
    
+
    
+
      
+
    • 
+
      
+RFC 3253: Versioning Extensions to WebDAV
+
      
+
      • 
+
    • 
+
      
+RFC 3648: WebDAV Ordered Collections Protocol
+
      
+
      • 
+
    • 
+
      
+RFC 3744: WebDAV Access Control Protocol
+
      
+
      • 
+
    • 
+
      
+RFC 4316: Datatypes for WebDAV Properties
+
      
+
      • 
+
    • 
+
      
+RFC 4331: Quota and Size Properties for DAV Collections
+
      
+
      • 
+
    • 
+
      
+RFC 4437: WebDAV Redirect Reference Resources
+
      
+
      • 
+
    • 
+
      
+RFC 4709: Mounting WebDAV Servers
+
      
+
      • 
+
    • 
+
      
+RFC 4791: Calendaring Extensions to WebDAV (CalDAV)
+
      
+
      • 
+
    • 
+
      
+RFC 4918: HTTP Extensions for WebDAV
+
      
+
      • 
+
    • 
+
      
+RFC 5323: WebDAV SEARCH
+
      
+
      • 
+
    • 
+
      
+RFC 5397: WebDAV Current Principal Extension
+
      
+
      • 
+
    • 
+
      
+RFC 5689: Extended MKCOL for WebDAV
+
      
+
      • 
+
    • 
+
      
+RFC 5842: Binding Extensions to WebDAV
+
      
+
      • 
+
    • 
+
      
+RFC 5995: Using POST to Add Members to WebDAV Collections
+
      
+
      • 
+
    • 
+
      
+RFC 6352: CardDAV: vCard Extensions to WebDAV
+
      
+
      • 
+
    • 
+
      
+RFC 6578: Collection Synchronization for WebDAV
+
      
+
      • 
+
    • 
+
      
+RFC 6638: Scheduling Extensions to CalDAV
+
      
+
      • 
+
    • 
+
      
+RFC 6764: Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)
+
      
+
      • 
+
    • 
+
      
+RFC 7809: Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference
+
      
+
      • 
+
    • 
+
      
+RFC 7953: Calendar Availability
+
      
+
      • 
+
    • 
+
      
+RFC 8144: Use of the Prefer Header Field in WebDAV
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    CoAP
    
+
    
+
      
+
    • 
+
      
+RFC 7252: The Constrained Application Protocol (CoAP)
+
      
+
      • 
+
    • 
+
      
+RFC 7390: Group Communication for CoAP
+
      
+
      • 
+
    • 
+
      
+RFC 7641: Observing Resources in CoAP
+
      
+
      • 
+
    • 
+
      
+RFC 7650: A CoAP Usage for REsource LOcation And Discovery (RELOAD)
+
      
+
      • 
+
    • 
+
      
+RFC 7959: Block-Wise Transfers in CoAP
+
      
+
      • 
+
    • 
+
      
+RFC 7967: CoAP Option for No Server Response
+
      
+
      • 
+
    • 
+
      
+RFC 8075: Guidelines for Mapping Implementations: HTTP to CoAP
+
      
+
      • 
+
    • 
+
      
+RFC 8132: PATCH and FETCH Methods for CoAP
+
      
+
      • 
+
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/static_files.asciidoc b/docs/en/cowboy/2.1/guide/static_files.asciidoc
new file mode 100644
index 00000000..9d9b8cc2
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/static_files.asciidoc
@@ -0,0 +1,163 @@
+[[static_files]]
+== Static files
+
+Cowboy comes with a ready to use handler for serving static
+files. It is provided as a convenience for serving files
+during development.
+
+For systems in production, consider using one of the many
+Content Distribution Network (CDN) available on the market,
+as they are the best solution for serving files.
+
+The static handler can serve either one file or all files
+from a given directory. The etag generation and mime types
+can be configured.
+
+=== Serve one file
+
+You can use the static handler to serve one specific file
+from an application's private directory. This is particularly
+useful to serve an 'index.html' file when the client requests
+the `/` path, for example. The path configured is relative
+to the given application's private directory.
+
+The following rule will serve the file 'static/index.html'
+from the application `my_app`'s priv directory whenever the
+path `/` is accessed:
+
+[source,erlang]
+{"/", cowboy_static, {priv_file, my_app, "static/index.html"}}
+
+You can also specify the absolute path to a file, or the
+path to the file relative to the current directory:
+
+[source,erlang]
+{"/", cowboy_static, {file, "/var/www/index.html"}}
+
+=== Serve all files from a directory
+
+You can also use the static handler to serve all files that
+can be found in the configured directory. The handler will
+use the `path_info` information to resolve the file location,
+which means that your route must end with a `[...]` pattern
+for it to work. All files are served, including the ones that
+may be found in subfolders.
+
+You can specify the directory relative to an application's
+private directory.
+
+The following rule will serve any file found in the application
+`my_app`'s priv directory inside the `static/assets` folder
+whenever the requested path begins with `/assets/`:
+
+[source,erlang]
+{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets"}}
+
+You can also specify the absolute path to the directory or
+set it relative to the current directory:
+
+[source,erlang]
+{"/assets/[...]", cowboy_static, {dir, "/var/www/assets"}}
+
+=== Customize the mimetype detection
+
+By default, Cowboy will attempt to recognize the mimetype
+of your static files by looking at the extension.
+
+You can override the function that figures out the mimetype
+of the static files. It can be useful when Cowboy is missing
+a mimetype you need to handle, or when you want to reduce
+the list to make lookups faster. You can also give a
+hard-coded mimetype that will be used unconditionally.
+
+Cowboy comes with two functions built-in. The default
+function only handles common file types used when building
+Web applications. The other function is an extensive list
+of hundreds of mimetypes that should cover almost any need
+you may have. You can of course create your own function.
+
+To use the default function, you should not have to configure
+anything, as it is the default. If you insist, though, the
+following will do the job:
+
+[source,erlang]
+----
+{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets",
+    [{mimetypes, cow_mimetypes, web}]}}
+----
+
+As you can see, there is an optional field that may contain
+a list of less used options, like mimetypes or etag. All option
+types have this optional field.
+
+To use the function that will detect almost any mimetype,
+the following configuration will do:
+
+[source,erlang]
+----
+{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets",
+    [{mimetypes, cow_mimetypes, all}]}}
+----
+
+You probably noticed the pattern by now. The configuration
+expects a module and a function name, so you can use any
+of your own functions instead:
+
+[source,erlang]
+----
+{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets",
+    [{mimetypes, Module, Function}]}}
+----
+
+The function that performs the mimetype detection receives
+a single argument that is the path to the file on disk. It
+is recommended to return the mimetype in tuple form, although
+a binary string is also allowed (but will require extra
+processing). If the function can't figure out the mimetype,
+then it should return `{<<"application">>, <<"octet-stream">>, []}`.
+
+When the static handler fails to find the extension,
+it will send the file as `application/octet-stream`.
+A browser receiving such file will attempt to download it
+directly to disk.
+
+Finally, the mimetype can be hard-coded for all files.
+This is especially useful in combination with the `file`
+and `priv_file` options as it avoids needless computation:
+
+[source,erlang]
+----
+{"/", cowboy_static, {priv_file, my_app, "static/index.html",
+    [{mimetypes, {<<"text">>, <<"html">>, []}}]}}
+----
+
+=== Generate an etag
+
+By default, the static handler will generate an etag header
+value based on the size and modified time. This solution
+can not be applied to all systems though. It would perform
+rather poorly over a cluster of nodes, for example, as the
+file metadata will vary from server to server, giving a
+different etag on each server.
+
+You can however change the way the etag is calculated:
+
+[source,erlang]
+----
+{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets",
+    [{etag, Module, Function}]}}
+----
+
+This function will receive three arguments: the path to the
+file on disk, the size of the file and the last modification
+time. In a distributed setup, you would typically use the
+file path to retrieve an etag value that is identical across
+all your servers.
+
+You can also completely disable etag handling:
+
+[source,erlang]
+----
+{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets",
+    [{etag, false}]}}
+----
diff --git a/docs/en/cowboy/2.1/guide/static_files/index.html b/docs/en/cowboy/2.1/guide/static_files/index.html
new file mode 100644
index 00000000..f0740821
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/static_files/index.html
@@ -0,0 +1,330 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Static files
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Static files
    
+
+
    Cowboy comes with a ready to use handler for serving static
+files. It is provided as a convenience for serving files
+during development.
    
+
    For systems in production, consider using one of the many
+Content Distribution Network (CDN) available on the market,
+as they are the best solution for serving files.
    
+
    The static handler can serve either one file or all files
+from a given directory. The etag generation and mime types
+can be configured.
    
+
    
+
    Serve one file
    
+
    
+
    You can use the static handler to serve one specific file
+from an application’s private directory. This is particularly
+useful to serve an index.html file when the client requests
+the / path, for example. The path configured is relative
+to the given application’s private directory.
    
+
    The following rule will serve the file static/index.html
+from the application my_app's priv directory whenever the
+path / is accessed:
    
+
    
+
    
+
    {"/", cowboy_static, {priv_file, my_app, "static/index.html"}}
    
+
    You can also specify the absolute path to a file, or the
+path to the file relative to the current directory:
    
+
    
+
    
+
    {"/", cowboy_static, {file, "/var/www/index.html"}}
    
+
    
+
    
+
    
+
    Serve all files from a directory
    
+
    
+
    You can also use the static handler to serve all files that
+can be found in the configured directory. The handler will
+use the path_info information to resolve the file location,
+which means that your route must end with a [...] pattern
+for it to work. All files are served, including the ones that
+may be found in subfolders.
    
+
    You can specify the directory relative to an application’s
+private directory.
    
+
    The following rule will serve any file found in the application
+my_app's priv directory inside the static/assets folder
+whenever the requested path begins with /assets/:
    
+
    
+
    
+
    {"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets"}}
    
+
    You can also specify the absolute path to the directory or
+set it relative to the current directory:
    
+
    
+
    
+
    {"/assets/[...]", cowboy_static, {dir, "/var/www/assets"}}
    
+
    
+
    
+
    
+
    Customize the mimetype detection
    
+
    
+
    By default, Cowboy will attempt to recognize the mimetype
+of your static files by looking at the extension.
    
+
    You can override the function that figures out the mimetype
+of the static files. It can be useful when Cowboy is missing
+a mimetype you need to handle, or when you want to reduce
+the list to make lookups faster. You can also give a
+hard-coded mimetype that will be used unconditionally.
    
+
    Cowboy comes with two functions built-in. The default
+function only handles common file types used when building
+Web applications. The other function is an extensive list
+of hundreds of mimetypes that should cover almost any need
+you may have. You can of course create your own function.
    
+
    To use the default function, you should not have to configure
+anything, as it is the default. If you insist, though, the
+following will do the job:
    
+
    
+
    
+
    {"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets",
+    [{mimetypes, cow_mimetypes, web}]}}
    
+
    As you can see, there is an optional field that may contain
+a list of less used options, like mimetypes or etag. All option
+types have this optional field.
    
+
    To use the function that will detect almost any mimetype,
+the following configuration will do:
    
+
    
+
    
+
    {"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets",
+    [{mimetypes, cow_mimetypes, all}]}}
    
+
    You probably noticed the pattern by now. The configuration
+expects a module and a function name, so you can use any
+of your own functions instead:
    
+
    
+
    
+
    {"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets",
+    [{mimetypes, Module, Function}]}}
    
+
    The function that performs the mimetype detection receives
+a single argument that is the path to the file on disk. It
+is recommended to return the mimetype in tuple form, although
+a binary string is also allowed (but will require extra
+processing). If the function can’t figure out the mimetype,
+then it should return {<<"application">>, <<"octet-stream">>, []}.
    
+
    When the static handler fails to find the extension,
+it will send the file as application/octet-stream.
+A browser receiving such file will attempt to download it
+directly to disk.
    
+
    Finally, the mimetype can be hard-coded for all files.
+This is especially useful in combination with the file
+and priv_file options as it avoids needless computation:
    
+
    
+
    
+
    {"/", cowboy_static, {priv_file, my_app, "static/index.html",
+    [{mimetypes, {<<"text">>, <<"html">>, []}}]}}
    
+
    
+
    
+
    
+
    Generate an etag
    
+
    
+
    By default, the static handler will generate an etag header
+value based on the size and modified time. This solution
+can not be applied to all systems though. It would perform
+rather poorly over a cluster of nodes, for example, as the
+file metadata will vary from server to server, giving a
+different etag on each server.
    
+
    You can however change the way the etag is calculated:
    
+
    
+
    
+
    {"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets",
+    [{etag, Module, Function}]}}
    
+
    This function will receive three arguments: the path to the
+file on disk, the size of the file and the last modification
+time. In a distributed setup, you would typically use the
+file path to retrieve an etag value that is identical across
+all your servers.
    
+
    You can also completely disable etag handling:
    
+
    
+
    
+
    {"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets",
+    [{etag, false}]}}
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/streams.asciidoc b/docs/en/cowboy/2.1/guide/streams.asciidoc
new file mode 100644
index 00000000..841a9712
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/streams.asciidoc
@@ -0,0 +1,65 @@
+[[streams]]
+== Streams
+
+A stream is the set of messages that form an HTTP
+request/response pair.
+
+The term stream comes from HTTP/2. In Cowboy, it is
+also used when talking about HTTP/1.1 or HTTP/1.0.
+It should not be confused with streaming the request
+or response body.
+
+All versions of HTTP allow clients to initiate
+streams. HTTP/2 is the only one also allowing servers,
+through its server push feature. Both client and
+server-initiated streams go through the same process
+in Cowboy.
+
+=== Stream handlers
+
+Stream handlers must implement five different callbacks.
+Four of them are directly related; one is special.
+
+All callbacks receives the stream ID as first argument.
+
+Most of them can return a list of commands to be executed
+by Cowboy. When callbacks are chained, it is possible to
+intercept and modify these commands. This can be useful
+for modifying responses for example.
+
+The `init/3` callback is invoked when a new request
+comes in. It receives the Req object and the protocol options
+for this listener.
+
+The `data/4` callback is invoked when data from the request
+body is received. It receives both this data and a flag
+indicating whether more is to be expected.
+
+The `info/3` callback is invoked when an Erlang message is
+received for this stream. They will typically be messages
+sent by the request process.
+
+Finally the `terminate/3` callback is invoked with the
+terminate reason for the stream. The return value is ignored.
+Note that as with all terminate callbacks in Erlang, there
+is no strong guarantee that it will be called.
+
+The special callback `early_error/5` is called when an error
+occurs before the request headers were fully received and
+Cowboy is sending a response. It receives the partial Req
+object, the error reason, the protocol options and the response
+Cowboy will send. This response must be returned, possibly
+modified.
+
+=== Built-in handlers
+
+Cowboy comes with two handlers.
+
+`cowboy_stream_h` is the default stream handler.
+It is the core of much of the functionality of Cowboy.
+All chains of stream handlers should call it last.
+
+`cowboy_compress_h` will automatically compress
+responses when possible. It is not enabled by default.
+It is a good example for writing your own handlers
+that will modify responses.
diff --git a/docs/en/cowboy/2.1/guide/streams/index.html b/docs/en/cowboy/2.1/guide/streams/index.html
new file mode 100644
index 00000000..1efbb2e2
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/streams/index.html
@@ -0,0 +1,218 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Streams
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Streams
    
+
+
    A stream is the set of messages that form an HTTP
+request/response pair.
    
+
    The term stream comes from HTTP/2. In Cowboy, it is
+also used when talking about HTTP/1.1 or HTTP/1.0.
+It should not be confused with streaming the request
+or response body.
    
+
    All versions of HTTP allow clients to initiate
+streams. HTTP/2 is the only one also allowing servers,
+through its server push feature. Both client and
+server-initiated streams go through the same process
+in Cowboy.
    
+
    
+
    Stream handlers
    
+
    
+
    Stream handlers must implement five different callbacks.
+Four of them are directly related; one is special.
    
+
    All callbacks receives the stream ID as first argument.
    
+
    Most of them can return a list of commands to be executed
+by Cowboy. When callbacks are chained, it is possible to
+intercept and modify these commands. This can be useful
+for modifying responses for example.
    
+
    The init/3 callback is invoked when a new request
+comes in. It receives the Req object and the protocol options
+for this listener.
    
+
    The data/4 callback is invoked when data from the request
+body is received. It receives both this data and a flag
+indicating whether more is to be expected.
    
+
    The info/3 callback is invoked when an Erlang message is
+received for this stream. They will typically be messages
+sent by the request process.
    
+
    Finally the terminate/3 callback is invoked with the
+terminate reason for the stream. The return value is ignored.
+Note that as with all terminate callbacks in Erlang, there
+is no strong guarantee that it will be called.
    
+
    The special callback early_error/5 is called when an error
+occurs before the request headers were fully received and
+Cowboy is sending a response. It receives the partial Req
+object, the error reason, the protocol options and the response
+Cowboy will send. This response must be returned, possibly
+modified.
    
+
    
+
    
+
    
+
    Built-in handlers
    
+
    
+
    Cowboy comes with two handlers.
    
+
    cowboy_stream_h is the default stream handler.
+It is the core of much of the functionality of Cowboy.
+All chains of stream handlers should call it last.
    
+
    cowboy_compress_h will automatically compress
+responses when possible. It is not enabled by default.
+It is a good example for writing your own handlers
+that will modify responses.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/ws_handlers.asciidoc b/docs/en/cowboy/2.1/guide/ws_handlers.asciidoc
new file mode 100644
index 00000000..a79d7e29
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/ws_handlers.asciidoc
@@ -0,0 +1,269 @@
+[[ws_handlers]]
+== Websocket handlers
+
+Websocket handlers provide an interface for upgrading HTTP/1.1
+connections to Websocket and sending or receiving frames on
+the Websocket connection.
+
+As Websocket connections are established through the HTTP/1.1
+upgrade mechanism, Websocket handlers need to be able to first
+receive the HTTP request for the upgrade, before switching to
+Websocket and taking over the connection. They can then receive
+or send Websocket frames, handle incoming Erlang messages or
+close the connection.
+
+=== Upgrade
+
+The `init/2` callback is called when the request is received.
+To establish a Websocket connection, you must switch to the
+`cowboy_websocket` module:
+
+[source,erlang]
+----
+init(Req, State) ->
+    {cowboy_websocket, Req, State}.
+----
+
+Cowboy will perform the Websocket handshake immediately. Note
+that the handshake will fail if the client did not request an
+upgrade to Websocket.
+
+The Req object becomes unavailable after this function returns.
+Any information required for proper execution of the Websocket
+handler must be saved in the state.
+
+=== Subprotocol
+
+The client may provide a list of Websocket subprotocols it
+supports in the sec-websocket-protocol header. The server *must*
+select one of them and send it back to the client or the
+handshake will fail.
+
+For example, a client could understand both STOMP and MQTT over
+Websocket, and provide the header:
+
+----
+sec-websocket-protocol: v12.stomp, mqtt
+----
+
+If the server only understands MQTT it can return:
+
+----
+sec-websocket-protocol: mqtt
+----
+
+This selection must be done in `init/2`. An example usage could
+be:
+
+[source,erlang]
+----
+init(Req0, State) ->
+    case cowboy_req:parse_header(<<"sec-websocket-protocol">>, Req0) of
+        undefined ->
+            {cowboy_websocket, Req0, State};
+        Subprotocols ->
+            case lists:keymember(<<"mqtt">>, 1, Subprotocols) of
+                true ->
+                    Req = cowboy_req:set_resp_header(<<"sec-websocket-protocol">>,
+                        <<"mqtt">>, Req0),
+                    {cowboy_websocket, Req, State};
+                false ->
+                    Req = cowboy_req:reply(400, Req0),
+                    {ok, Req, State}
+            end
+    end.
+----
+
+=== Post-upgrade initialization
+
+Cowboy has separate processes for handling the connection
+and requests. Because Websocket takes over the connection,
+the Websocket protocol handling occurs in a different
+process than the request handling.
+
+This is reflected in the different callbacks Websocket
+handlers have. The `init/2` callback is called from the
+temporary request process and the `websocket_` callbacks
+from the connection process.
+
+This means that some initialization cannot be done from
+`init/2`. Anything that would require the current pid,
+or be tied to the current pid, will not work as intended.
+The optional `websocket_init/1` can be used instead:
+
+[source,erlang]
+----
+websocket_init(State) ->
+    erlang:start_timer(1000, self(), <<"Hello!">>),
+    {ok, State}.
+----
+
+All Websocket callbacks share the same return values. This
+means that we can send frames to the client right after
+the upgrade:
+
+[source,erlang]
+----
+websocket_init(State) ->
+    {reply, {text, <<"Hello!">>}, State}.
+----
+
+=== Receiving frames
+
+Cowboy will call `websocket_handle/2` whenever a text, binary,
+ping or pong frame arrives from the client.
+
+The handler can handle or ignore the frames. It can also
+send frames back to the client or stop the connection.
+
+The following snippet echoes back any text frame received and
+ignores all others:
+
+[source,erlang]
+----
+websocket_handle(Frame = {text, _}, State) ->
+    {reply, Frame, State};
+websocket_handle(_Frame, State) ->
+    {ok, State}.
+----
+
+Note that ping and pong frames require no action from the
+handler as Cowboy will automatically reply to ping frames.
+They are provided for informative purposes only.
+
+=== Receiving Erlang messages
+
+Cowboy will call `websocket_info/2` whenever an Erlang message
+arrives.
+
+The handler can handle or ignore the messages. It can also
+send frames to the client or stop the connection.
+
+The following snippet forwards log messages to the client
+and ignores all others:
+
+[source,erlang]
+----
+websocket_info({log, Text}, State) ->
+    {reply, {text, Text}, State};
+websocket_info(_Info, State) ->
+    {ok, State}.
+----
+
+=== Sending frames
+
+// @todo This will be deprecated and eventually replaced with a
+// {Commands, State} interface that allows providing more
+// functionality easily.
+
+All `websocket_` callbacks share return values. They may
+send zero, one or many frames to the client.
+
+To send nothing, just return an ok tuple:
+
+[source,erlang]
+----
+websocket_info(_Info, State) ->
+    {ok, State}.
+----
+
+To send one frame, return a reply tuple with the frame to send:
+
+[source,erlang]
+----
+websocket_info(_Info, State) ->
+    {reply, {text, <<"Hello!">>}, State}.
+----
+
+You can send frames of any type: text, binary, ping, pong
+or close frames.
+
+To send many frames at once, return a reply tuple with the
+list of frames to send:
+
+[source,erlang]
+----
+websocket_info(_Info, State) ->
+    {reply, [
+        {text, "Hello"},
+        {text, <<"world!">>},
+        {binary, <<0:8000>>}
+    ], State}.
+----
+
+They are sent in the given order.
+
+=== Keeping the connection alive
+
+Cowboy will automatically respond to ping frames sent by
+the client. They are still forwarded to the handler for
+informative purposes, but no further action is required.
+
+Cowboy does not send ping frames itself. The handler can
+do it if required. A better solution in most cases is to
+let the client handle pings. Doing it from the handler
+would imply having an additional timer per connection and
+this can be a considerable cost for servers that need to
+handle large numbers of connections.
+
+Cowboy can be configured to close idle connections
+automatically. It is highly recommended to configure
+a timeout here, to avoid having processes linger longer
+than needed.
+
+The `init/2` callback can set the timeout to be used
+for the connection. For example, this would make Cowboy
+close connections idle for more than 30 seconds:
+
+[source,erlang]
+----
+init(Req, State) ->
+    {cowboy_websocket, Req, State, #{
+        idle_timeout => 30000}}.
+----
+
+This value cannot be changed once it is set. It defaults to
+`60000`.
+
+=== Saving memory
+
+The Websocket connection process can be set to hibernate
+after the callback returns.
+
+Simply add an `hibernate` field to the ok or reply tuples:
+
+[source,erlang]
+----
+websocket_init(State) ->
+    {ok, State, hibernate}.
+
+websocket_handle(_Frame, State) ->
+    {ok, State, hibernate}.
+
+websocket_info(_Info, State) ->
+    {reply, {text, <<"Hello!">>}, State, hibernate}.
+----
+
+It is highly recommended to write your handlers with
+hibernate enabled, as this allows to greatly reduce the
+memory usage. Do note however that an increase in the
+CPU usage or latency can be observed instead, in particular
+for the more busy connections.
+
+=== Closing the connection
+
+The connection can be closed at any time, either by telling
+Cowboy to stop it or by sending a close frame.
+
+To tell Cowboy to close the connection, use a stop tuple:
+
+[source,erlang]
+----
+websocket_info(_Info, State) ->
+    {stop, State}.
+----
+
+Sending a `close` frame will immediately initiate the closing
+of the Websocket connection. Note that when sending a list of
+frames that include a close frame, any frame found after the
+close frame will not be sent.
diff --git a/docs/en/cowboy/2.1/guide/ws_handlers/index.html b/docs/en/cowboy/2.1/guide/ws_handlers/index.html
new file mode 100644
index 00000000..6e20b0ab
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/ws_handlers/index.html
@@ -0,0 +1,428 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Websocket handlers
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Websocket handlers
    
+
+
    Websocket handlers provide an interface for upgrading HTTP/1.1
+connections to Websocket and sending or receiving frames on
+the Websocket connection.
    
+
    As Websocket connections are established through the HTTP/1.1
+upgrade mechanism, Websocket handlers need to be able to first
+receive the HTTP request for the upgrade, before switching to
+Websocket and taking over the connection. They can then receive
+or send Websocket frames, handle incoming Erlang messages or
+close the connection.
    
+
    
+
    Upgrade
    
+
    
+
    The init/2 callback is called when the request is received.
+To establish a Websocket connection, you must switch to the
+cowboy_websocket module:
    
+
    
+
    
+
    init(Req, State) ->
+    {cowboy_websocket, Req, State}.
    
+
    Cowboy will perform the Websocket handshake immediately. Note
+that the handshake will fail if the client did not request an
+upgrade to Websocket.
    
+
    The Req object becomes unavailable after this function returns.
+Any information required for proper execution of the Websocket
+handler must be saved in the state.
    
+
    
+
    
+
    
+
    Subprotocol
    
+
    
+
    The client may provide a list of Websocket subprotocols it
+supports in the sec-websocket-protocol header. The server must
+select one of them and send it back to the client or the
+handshake will fail.
    
+
    For example, a client could understand both STOMP and MQTT over
+Websocket, and provide the header:
    
+
    
+
    
+
    sec-websocket-protocol: v12.stomp, mqtt
    
+
    
+
    If the server only understands MQTT it can return:
    
+
    
+
    
+
    sec-websocket-protocol: mqtt
    
+
    
+
    This selection must be done in init/2. An example usage could
+be:
    
+
    
+
    
+
    init(Req0, State) ->
+    case cowboy_req:parse_header(<<"sec-websocket-protocol">>, Req0) of
+        undefined ->
+            {cowboy_websocket, Req0, State};
+        Subprotocols ->
+            case lists:keymember(<<"mqtt">>, 1, Subprotocols) of
+                true ->
+                    Req = cowboy_req:set_resp_header(<<"sec-websocket-protocol">>,
+                        <<"mqtt">>, Req0),
+                    {cowboy_websocket, Req, State};
+                false ->
+                    Req = cowboy_req:reply(400, Req0),
+                    {ok, Req, State}
+            end
+    end.
    
+
    
+
    
+
    
+
    Post-upgrade initialization
    
+
    
+
    Cowboy has separate processes for handling the connection
+and requests. Because Websocket takes over the connection,
+the Websocket protocol handling occurs in a different
+process than the request handling.
    
+
    This is reflected in the different callbacks Websocket
+handlers have. The init/2 callback is called from the
+temporary request process and the websocket_ callbacks
+from the connection process.
    
+
    This means that some initialization cannot be done from
+init/2. Anything that would require the current pid,
+or be tied to the current pid, will not work as intended.
+The optional websocket_init/1 can be used instead:
    
+
    
+
    
+
    websocket_init(State) ->
+    erlang:start_timer(1000, self(), <<"Hello!">>),
+    {ok, State}.
    
+
    All Websocket callbacks share the same return values. This
+means that we can send frames to the client right after
+the upgrade:
    
+
    
+
    
+
    websocket_init(State) ->
+    {reply, {text, <<"Hello!">>}, State}.
    
+
    
+
    
+
    
+
    Receiving frames
    
+
    
+
    Cowboy will call websocket_handle/2 whenever a text, binary,
+ping or pong frame arrives from the client.
    
+
    The handler can handle or ignore the frames. It can also
+send frames back to the client or stop the connection.
    
+
    The following snippet echoes back any text frame received and
+ignores all others:
    
+
    
+
    
+
    websocket_handle(Frame = {text, _}, State) ->
+    {reply, Frame, State};
+websocket_handle(_Frame, State) ->
+    {ok, State}.
    
+
    Note that ping and pong frames require no action from the
+handler as Cowboy will automatically reply to ping frames.
+They are provided for informative purposes only.
    
+
    
+
    
+
    
+
    Receiving Erlang messages
    
+
    
+
    Cowboy will call websocket_info/2 whenever an Erlang message
+arrives.
    
+
    The handler can handle or ignore the messages. It can also
+send frames to the client or stop the connection.
    
+
    The following snippet forwards log messages to the client
+and ignores all others:
    
+
    
+
    
+
    websocket_info({log, Text}, State) ->
+    {reply, {text, Text}, State};
+websocket_info(_Info, State) ->
+    {ok, State}.
    
+
    
+
    
+
    
+
    Sending frames
    
+
    
+
    All websocket_ callbacks share return values. They may
+send zero, one or many frames to the client.
    
+
    To send nothing, just return an ok tuple:
    
+
    
+
    
+
    websocket_info(_Info, State) ->
+    {ok, State}.
    
+
    To send one frame, return a reply tuple with the frame to send:
    
+
    
+
    
+
    websocket_info(_Info, State) ->
+    {reply, {text, <<"Hello!">>}, State}.
    
+
    You can send frames of any type: text, binary, ping, pong
+or close frames.
    
+
    To send many frames at once, return a reply tuple with the
+list of frames to send:
    
+
    
+
    
+
    websocket_info(_Info, State) ->
+    {reply, [
+        {text, "Hello"},
+        {text, <<"world!">>},
+        {binary, <<0:8000>>}
+    ], State}.
    
+
    They are sent in the given order.
    
+
    
+
    
+
    
+
    Keeping the connection alive
    
+
    
+
    Cowboy will automatically respond to ping frames sent by
+the client. They are still forwarded to the handler for
+informative purposes, but no further action is required.
    
+
    Cowboy does not send ping frames itself. The handler can
+do it if required. A better solution in most cases is to
+let the client handle pings. Doing it from the handler
+would imply having an additional timer per connection and
+this can be a considerable cost for servers that need to
+handle large numbers of connections.
    
+
    Cowboy can be configured to close idle connections
+automatically. It is highly recommended to configure
+a timeout here, to avoid having processes linger longer
+than needed.
    
+
    The init/2 callback can set the timeout to be used
+for the connection. For example, this would make Cowboy
+close connections idle for more than 30 seconds:
    
+
    
+
    
+
    init(Req, State) ->
+    {cowboy_websocket, Req, State, #{
+        idle_timeout => 30000}}.
    
+
    This value cannot be changed once it is set. It defaults to
+60000.
    
+
    
+
    
+
    
+
    Saving memory
    
+
    
+
    The Websocket connection process can be set to hibernate
+after the callback returns.
    
+
    Simply add an hibernate field to the ok or reply tuples:
    
+
    
+
    
+
    websocket_init(State) ->
+    {ok, State, hibernate}.
+
+websocket_handle(_Frame, State) ->
+    {ok, State, hibernate}.
+
+websocket_info(_Info, State) ->
+    {reply, {text, <<"Hello!">>}, State, hibernate}.
    
+
    It is highly recommended to write your handlers with
+hibernate enabled, as this allows to greatly reduce the
+memory usage. Do note however that an increase in the
+CPU usage or latency can be observed instead, in particular
+for the more busy connections.
    
+
    
+
    
+
    
+
    Closing the connection
    
+
    
+
    The connection can be closed at any time, either by telling
+Cowboy to stop it or by sending a close frame.
    
+
    To tell Cowboy to close the connection, use a stop tuple:
    
+
    
+
    
+
    websocket_info(_Info, State) ->
+    {stop, State}.
    
+
    Sending a close frame will immediately initiate the closing
+of the Websocket connection. Note that when sending a list of
+frames that include a close frame, any frame found after the
+close frame will not be sent.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/guide/ws_protocol.asciidoc b/docs/en/cowboy/2.1/guide/ws_protocol.asciidoc
new file mode 100644
index 00000000..8fa0673d
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/ws_protocol.asciidoc
@@ -0,0 +1,69 @@
+[[ws_protocol]]
+== The Websocket protocol
+
+This chapter explains what Websocket is and why it is
+a vital component of soft realtime Web applications.
+
+=== Description
+
+Websocket is an extension to HTTP that emulates plain TCP
+connections between the client, typically a Web browser,
+and the server. It uses the HTTP Upgrade mechanism to
+establish the connection.
+
+Websocket connections are fully asynchronous, unlike
+HTTP/1.1 (synchronous) and HTTP/2 (asynchronous, but the
+server can only initiate streams in response to requests).
+With Websocket, the client and the server can both send
+frames at any time without any restriction. It is closer
+to TCP than any of the HTTP protocols.
+
+Websocket is an IETF standard. Cowboy supports the standard
+and all drafts that were previously implemented by browsers,
+excluding the initial flawed draft sometimes known as
+"version 0".
+
+=== Websocket vs HTTP/2
+
+For a few years Websocket was the only way to have a
+bidirectional asynchronous connection with the server.
+This changed when HTTP/2 was introduced. While HTTP/2
+requires the client to first perform a request before
+the server can push data, this is only a minor restriction
+as the client can do so just as it connects.
+
+Websocket was designed as a kind-of-TCP channel to a
+server. It only defines the framing and connection
+management and lets the developer implement a protocol
+on top of it. For example you could implement IRC over
+Websocket and use a Javascript IRC client to speak to
+the server.
+
+HTTP/2 on the other hand is just an improvement over
+the HTTP/1.1 connection and request/response mechanism.
+It has the same semantics as HTTP/1.1.
+
+If all you need is to access an HTTP API, then HTTP/2
+should be your first choice. On the other hand, if what
+you need is a different protocol, then you can use
+Websocket to implement it.
+
+=== Implementation
+
+Cowboy implements Websocket as a protocol upgrade. Once the
+upgrade is performed from the `init/2` callback, Cowboy
+switches to Websocket. Please consult the next chapter for
+more information on initiating and handling Websocket
+connections.
+
+The implementation of Websocket in Cowboy is validated using
+the Autobahn test suite, which is an extensive suite of tests
+covering all aspects of the protocol. Cowboy passes the
+suite with 100% success, including all optional tests.
+
+Cowboy's Websocket implementation also includes the
+permessage-deflate and x-webkit-deflate-frame compression
+extensions.
+
+Cowboy will automatically use compression when the
+`compress` option is returned from the `init/2` function.
diff --git a/docs/en/cowboy/2.1/guide/ws_protocol/index.html b/docs/en/cowboy/2.1/guide/ws_protocol/index.html
new file mode 100644
index 00000000..ff47904e
--- /dev/null
+++ b/docs/en/cowboy/2.1/guide/ws_protocol/index.html
@@ -0,0 +1,227 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: The Websocket protocol
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    The Websocket protocol
    
+
+
    This chapter explains what Websocket is and why it is
+a vital component of soft realtime Web applications.
    
+
    
+
    Description
    
+
    
+
    Websocket is an extension to HTTP that emulates plain TCP
+connections between the client, typically a Web browser,
+and the server. It uses the HTTP Upgrade mechanism to
+establish the connection.
    
+
    Websocket connections are fully asynchronous, unlike
+HTTP/1.1 (synchronous) and HTTP/2 (asynchronous, but the
+server can only initiate streams in response to requests).
+With Websocket, the client and the server can both send
+frames at any time without any restriction. It is closer
+to TCP than any of the HTTP protocols.
    
+
    Websocket is an IETF standard. Cowboy supports the standard
+and all drafts that were previously implemented by browsers,
+excluding the initial flawed draft sometimes known as
+"version 0".
    
+
    
+
    
+
    
+
    Websocket vs HTTP/2
    
+
    
+
    For a few years Websocket was the only way to have a
+bidirectional asynchronous connection with the server.
+This changed when HTTP/2 was introduced. While HTTP/2
+requires the client to first perform a request before
+the server can push data, this is only a minor restriction
+as the client can do so just as it connects.
    
+
    Websocket was designed as a kind-of-TCP channel to a
+server. It only defines the framing and connection
+management and lets the developer implement a protocol
+on top of it. For example you could implement IRC over
+Websocket and use a Javascript IRC client to speak to
+the server.
    
+
    HTTP/2 on the other hand is just an improvement over
+the HTTP/1.1 connection and request/response mechanism.
+It has the same semantics as HTTP/1.1.
    
+
    If all you need is to access an HTTP API, then HTTP/2
+should be your first choice. On the other hand, if what
+you need is a different protocol, then you can use
+Websocket to implement it.
    
+
    
+
    
+
    
+
    Implementation
    
+
    
+
    Cowboy implements Websocket as a protocol upgrade. Once the
+upgrade is performed from the init/2 callback, Cowboy
+switches to Websocket. Please consult the next chapter for
+more information on initiating and handling Websocket
+connections.
    
+
    The implementation of Websocket in Cowboy is validated using
+the Autobahn test suite, which is an extensive suite of tests
+covering all aspects of the protocol. Cowboy passes the
+suite with 100% success, including all optional tests.
    
+
    Cowboy’s Websocket implementation also includes the
+permessage-deflate and x-webkit-deflate-frame compression
+extensions.
    
+
    Cowboy will automatically use compression when the
+compress option is returned from the init/2 function.
    
+
    
+
    
+
+
+
+	
+		
+		
+		
+		
+		
+
+		
+	
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	
+	User Guide
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.1/manual/cowboy.set_env/index.html
new file mode 100644
index 00000000..7aa68373
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy.set_env/index.html
@@ -0,0 +1,252 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy:set_env(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy:set_env(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy:set_env - Update a listener’s environment value
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    set_env(Name  :: ranch:ref(),
+        Key   :: atom(),
+        Value :: any())
+    -> ok
    
+
    Set or update an environment value for a previously started
+listener.
    
+
    This is most useful for updating the routes dynamically,
+without having to restart the listener.
    
+
    The new value will only be available to new connections.
+Pre-existing connections will still use the old value.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+The name of the listener to update.
+
    
+
    The name of the listener is the first argument given to the
+cowboy:start_clear(3),
+cowboy:start_tls(3) or
+ranch:start_listener(3) function.
    
+
    
+
    
+Key
+
    
+
    
+
    
+The key in the environment map. Common keys include dispatch
+and middlewares.
+
    
+
    
+
    
+Value
+
    
+
    
+
    
+The new value.
+
    
+
    The type of the value differs depending on the key.
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The atom ok is returned on success.
    
+
    An exit:badarg exception is thrown when the listener does
+not exist.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Update a listener’s routes
    
+
    
+
    Dispatch = cowboy_router:compile([
+    {'_', [
+        {"/", toppage_h, []},
+        {"/ws", websocket_h, []}
+    ]}
+]),
+
+cowboy:set_env(example, dispatch, Dispatch).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(3),
+cowboy:start_clear(3),
+cowboy:start_tls(3),
+ranch:set_protocol_options(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.1/manual/cowboy.start_clear/index.html
new file mode 100644
index 00000000..539c8738
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy.start_clear/index.html
@@ -0,0 +1,283 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy:start_clear(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy:start_clear(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy:start_clear - Listen for connections using plain TCP
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    start_clear(Name          :: ranch:ref(),
+            TransportOpts :: ranch_tcp:opts(),
+            ProtocolOpts  :: opts())
+    -> {ok, ListenerPid :: pid()}
+     | {error, any()}
    
+
    Start listening for connections over a clear TCP channel.
    
+
    Both HTTP/1.1 and HTTP/2 are supported on this listener.
+HTTP/2 has two methods of establishing a connection over
+a clear TCP channel. Both the upgrade and the prior knowledge
+methods are supported.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+The listener name is used to refer to this listener in
+future calls, for example when stopping it or when
+updating the routes defined.
+
    
+
    It can be any Erlang term. An atom is generally good enough,
+for example api, my_app_clear or my_app_tls.
    
+
    
+
    
+TransportOpts
+
    
+
    
+
    
+The transport options are where the TCP options, including
+the listener’s port number, are defined. Transport options
+are provided as a list of keys and values, for example
+[{port, 8080}].
+
    
+
    The available options are documented in the
+ranch_tcp(3) manual.
    
+
    
+
    
+ProtocolOpts
+
    
+
    
+
    
+The protocol options are in a map containing all the options for
+the different protocols that may be involved when connecting
+to the listener, including HTTP/1.1 and HTTP/2.
+
    
+
    The HTTP/1.1 options are documented in the
+cowboy_http(3) manual;
+and the HTTP/2 options in
+cowboy_http2(3).
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    An ok tuple is returned on success. It contains the pid of
+the top-level supervisor for the listener.
    
+
    An error tuple is returned on error. The error reason may
+be any Erlang term.
    
+
    A common error is eaddrinuse. It indicates that the port
+configured for Cowboy is already in use.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: HTTP/2 support added.
+
      
+
      • 
+
    • 
+
      
+2.0: Function introduced. Replaces cowboy:start_http/4.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Start a listener
    
+
    
+
    Dispatch = cowboy_router:compile([
+    {'_', [
+        {"/", toppage_h, []}
+    ]}
+]),
+
+{ok, _} = cowboy:start_clear(example, [{port, 8080}], #{
+    env => #{dispatch => Dispatch}
+}).
    
+
    
+
    Start a listener on a random port
    
+
    
+
    Name = example,
+
+{ok, _} = cowboy:start_clear(Name, [], #{
+    env => #{dispatch => Dispatch}
+}),
+
+Port = ranch:get_port(Name).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(3),
+cowboy:start_tls(3),
+cowboy:stop_listener(3),
+ranch(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.1/manual/cowboy.start_tls/index.html
new file mode 100644
index 00000000..e64890d7
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy.start_tls/index.html
@@ -0,0 +1,288 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy:start_tls(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy:start_tls(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy:start_tls - Listen for connections using TLS
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    start_tls(Name          :: ranch:ref(),
+          TransportOpts :: ranch_ssl:opts(),
+          ProtocolOpts  :: opts())
+    -> {ok, ListenerPid :: pid()}
+     | {error, any()}
    
+
    Start listening for connections over a secure TLS channel.
    
+
    Both HTTP/1.1 and HTTP/2 are supported on this listener.
+The ALPN TLS extension must be used to initiate an HTTP/2
+connection.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+The listener name is used to refer to this listener in
+future calls, for example when stopping it or when
+updating the routes defined.
+
    
+
    It can be any Erlang term. An atom is generally good enough,
+for example api, my_app_clear or my_app_tls.
    
+
    
+
    
+TransportOpts
+
    
+
    
+
    
+The transport options are where the TCP options, including
+the listener’s port number, are defined. They also contain
+the TLS options, like the server’s certificate. Transport options
+are provided as a list of keys and values, for example
+[{port, 8443}, {certfile, "path/to/cert.pem"}].
+
    
+
    The available options are documented in the
+ranch_ssl(3) manual.
    
+
    
+
    
+ProtocolOpts
+
    
+
    
+
    
+The protocol options are in a map containing all the options for
+the different protocols that may be involved when connecting
+to the listener, including HTTP/1.1 and HTTP/2.
+
    
+
    The HTTP/1.1 options are documented in the
+cowboy_http(3) manual;
+and the HTTP/2 options in
+cowboy_http2(3).
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    An ok tuple is returned on success. It contains the pid of
+the top-level supervisor for the listener.
    
+
    An error tuple is returned on error. The error reason may
+be any Erlang term.
    
+
    A common error is eaddrinuse. It indicates that the port
+configured for Cowboy is already in use.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: HTTP/2 support added.
+
      
+
      • 
+
    • 
+
      
+2.0: Function introduced. Replaces cowboy:start_https/4.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Start a listener
    
+
    
+
    Dispatch = cowboy_router:compile([
+    {'_', [
+        {"/", toppage_h, []}
+    ]}
+]),
+
+{ok, _} = cowboy:start_tls(example, [
+    {port, 8443},
+    {cert, "path/to/cert.pem"}
+], #{
+    env => #{dispatch => Dispatch}
+}).
    
+
    
+
    Start a listener on a random port
    
+
    
+
    Name = example,
+
+{ok, _} = cowboy:start_tls(Name, [
+    {cert, "path/to/cert.pem"}
+], #{
+    env => #{dispatch => Dispatch}
+}),
+
+Port = ranch:get_port(Name).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(3),
+cowboy:start_clear(3),
+cowboy:stop_listener(3),
+ranch(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.1/manual/cowboy.stop_listener/index.html
new file mode 100644
index 00000000..7a453671
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy.stop_listener/index.html
@@ -0,0 +1,222 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy:stop_listener(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy:stop_listener(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy:stop_listener - Stop the given listener
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    stop_listener(Name :: ranch:ref())
+    -> ok | {error, not_found}.
    
+
    Stop a previously started listener.
    
+
    Alias of ranch:stop_listener(3).
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+The name of the listener to be stopped.
+
    
+
    The name of the listener is the first argument given to the
+cowboy:start_clear(3),
+cowboy:start_tls(3) or
+ranch:start_listener(3) function.
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The atom ok is returned on success.
    
+
    The {error, not_found} tuple is returned when the listener
+does not exist.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Stop a listener
    
+
    
+
    ok = cowboy:stop_listener(example).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(3),
+cowboy:start_clear(3),
+cowboy:start_tls(3),
+ranch(3),
+ranch:start_listener(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy/index.html b/docs/en/cowboy/2.1/manual/cowboy/index.html
new file mode 100644
index 00000000..fde1197e
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy/index.html
@@ -0,0 +1,264 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy - HTTP server
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The module cowboy provides convenience functions for
+manipulating Ranch listeners.
    
+
    
+
    
+
    
+
    Exports
    
+
    
+
    
+
    
+
    
+
    
+
    Types
    
+
    
+
    
+
    fields()
    
+
    
+
    
+
    fields() :: [Name
+           | {Name, Constraints}
+           | {Name, Constraints, Default}]
+
+Name        :: atom()
+Constraints :: Constraint | [Constraint]
+Constraint  :: cowboy_constraints:constraint()
+Default     :: any()
    
+
    Fields description for match operations.
    
+
    This type is used in cowboy_router(3)
+for matching bindings and in the match functions found in
+cowboy_req(3).
    
+
    
+
    
+
    http_headers()
    
+
    
+
    
+
    http_headers() :: #{binary() => iodata()}
    
+
    HTTP headers.
    
+
    
+
    
+
    http_status()
    
+
    
+
    
+
    http_status() :: non_neg_integer() | binary()
    
+
    HTTP response status.
    
+
    A binary status can be used to set a reason phrase. Note
+however that HTTP/2 only sends the status code and drops
+the reason phrase entirely.
    
+
    
+
    
+
    http_version()
    
+
    
+
    
+
    http_version() :: 'HTTP/2' | 'HTTP/1.1' | 'HTTP/1.0'
    
+
    HTTP version.
    
+
    Note that semantically, HTTP/1.1 and HTTP/2 are equivalent.
    
+
    
+
    
+
    opts()
    
+
    
+
    
+
    opts() :: map()
    
+
    Options for the HTTP/1.1, HTTP/2 and Websocket protocols.
    
+
    The protocol options are in a map containing all the options for
+the different protocols that may be involved when connecting
+to the listener, including HTTP/1.1 and HTTP/2.
    
+
    The HTTP/1.1 options are documented in the
+cowboy_http(3) manual
+and the HTTP/2 options in
+cowboy_http2(3).
    
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7),
+ranch(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_app/index.html b/docs/en/cowboy/2.1/manual/cowboy_app/index.html
new file mode 100644
index 00000000..5fc0da91
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_app/index.html
@@ -0,0 +1,306 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy(7)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy(7)
    
+
+
    
+
    Name
    
+
    
+
    cowboy - Small, fast, modern HTTP server for Erlang/OTP
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    Cowboy is an HTTP server for Erlang/OTP with support for the
+HTTP/1.1, HTTP/2 and Websocket protocols.
    
+
    Cowboy aims to provide a complete HTTP stack. This includes
+the implementation of the HTTP RFCs but also any directly
+related standards, like Websocket or Server-Sent Events.
    
+
    
+
    
+
    
+
    Modules
    
+
    
+
    Functions:
    
+
    
+
    Protocols:
    
+
    
+
    Handlers:
    
+
    
+
    Behaviors:
    
+
    
+
    Middlewares:
    
+
    
+
    
+
    
+
    
+
    Dependencies
    
+
    
+
      
+
    • 
+
      
+ranch(7) - Socket acceptor pool for TCP protocols
+
      
+
      • 
+
    • 
+
      
+cowlib(7) - Support library for manipulating Web protocols
+
      
+
      • 
+
    • 
+
      
+ssl - Secure communication over sockets
+
      
+
      • 
+
    • 
+
      
+crypto - Crypto functions
+
      
+
      • 
+
    
+
    All these applications must be started before the cowboy
+application. To start Cowboy and all dependencies at once:
    
+
    
+
    
+
    {ok, _} = application:ensure_all_started(cowboy).
    
+
    
+
    
+
    
+
    Environment
    
+
    
+
    The cowboy application does not define any application
+environment configuration parameters.
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    ranch(7),
+cowlib(7)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.1/manual/cowboy_constraints.int/index.html
new file mode 100644
index 00000000..8a3a75de
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_constraints.int/index.html
@@ -0,0 +1,227 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_constraints:int(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_constraints:int(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_constraints:int - Integer constraint
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    Constraint functions implement a number of different operations.
    
+
    
+
    
+
    int(forward, Bin) -> {ok, Int} | {error, not_an_integer}
+
+Bin :: binary()
+Int :: integer()
    
+
    Validate and convert the text representation of an integer.
    
+
    
+
    
+
    int(reverse, Int) -> {ok, Bin} | {error, not_an_integer}
    
+
    Convert an integer back to its text representation.
    
+
    
+
    
+
    int(format_error, Error) -> HumanReadable
+
+Error         :: {not_an_integer, Bin | Int}
+HumanReadable :: iolist()
    
+
    Generate a human-readable error message.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    Arguments vary depending on the operation. Constraint
+functions always take the operation type as first argument,
+and the value as second argument.
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The return value varies depending on the operation.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Interface modified to allow for a variety of operations.
+
      
+
      • 
+
    • 
+
      
+1.0: Constraint introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    This function is not meant to be called directly.
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_constraints(3),
+cowboy_constraints:nonempty(3),
+cowboy_router(3),
+cowboy_req:match_cookies(3),
+cowboy_req:match_qs(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.1/manual/cowboy_constraints.nonempty/index.html
new file mode 100644
index 00000000..92afe16a
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_constraints.nonempty/index.html
@@ -0,0 +1,226 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_constraints:nonempty(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_constraints:nonempty(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_constraints:nonempty - Non-empty constraint
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    Constraint functions implement a number of different operations.
    
+
    
+
    
+
    nonempty(forward | reverse, <<>>) -> {error, empty}
    
+
    Reject empty values.
    
+
    
+
    
+
    nonempty(forward | reverse, Bin) -> {ok, Bin}
+
+Bin :: binary()
    
+
    Accept any other binary values.
    
+
    
+
    
+
    nonempty(format_error, Error) -> HumanReadable
+
+Error         :: {empty, Bin}
+HumanReadable :: iolist()
    
+
    Generate a human-readable error message.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    Arguments vary depending on the operation. Constraint
+functions always take the operation type as first argument,
+and the value as second argument.
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The return value varies depending on the operation.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Interface modified to allow for a variety of operations.
+
      
+
      • 
+
    • 
+
      
+1.0: Constraint introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    This function is not meant to be called directly.
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_constraints(3),
+cowboy_constraints:int(3),
+cowboy_router(3),
+cowboy_req:match_cookies(3),
+cowboy_req:match_qs(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.1/manual/cowboy_constraints/index.html
new file mode 100644
index 00000000..c80f51f5
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_constraints/index.html
@@ -0,0 +1,219 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_constraints(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_constraints(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_constraints - Constraints
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The module cowboy_constraints defines the built-in
+constraints in Cowboy and provides an interface for
+manipulating these constraints.
    
+
    Constraints are functions that define what type of
+input is allowed. They are used throughout Cowboy,
+from the router to query strings to cookies.
    
+
    
+
    
+
    
+
    Exports
    
+
    
+
    Built-in constraints:
    
+
    
+
    
+
    
+
    
+
    Types
    
+
    
+
    
+
    constraint()
    
+
    
+
    
+
    constraint() :: int | nonempty | fun()
    
+
    A constraint function.
    
+
    The atom constraints are built-in, see the corresponding
+function in the exports list above.
    
+
    
+
    
+
    reason()
    
+
    
+
    
+
    reason() :: {constraint(), Reason, Value}
+
+Reason :: any()
+Value  :: any()
    
+
    Reason for the constraint failure.
    
+
    It includes the constraint function in question,
+a machine-readable error reason and the value that
+made the constraint fail.
    
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7),
+cowboy(3),
+cowboy_router(3),
+cowboy_req:match_cookies(3),
+cowboy_req:match_qs(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.1/manual/cowboy_handler.terminate/index.html
new file mode 100644
index 00000000..8b7f3cd8
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_handler.terminate/index.html
@@ -0,0 +1,244 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_handler:terminate(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_handler:terminate(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_handler:terminate - Terminate the handler
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    terminate(Reason, PartialReq, State, Handler) -> ok
+
+Reason     :: any()
+PartialReq :: map()
+State      :: any()
+Handler    :: module()
    
+
    Call the optional terminate callback if it is defined.
    
+
    Make sure to use this function at the end of the execution
+of modules that implement custom handler behaviors.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Reason
+
    
+
    
+
    
+Reason for termination.
+
    
+
    
+
    
+PartialReq
+
    
+
    
+
    
+The Req object.
+
    
+
    It is possible to remove fields from the Req object to save memory
+when the handler has no concept of requests/responses. The only
+requirement is that a map is provided.
    
+
    
+
    
+State
+
    
+
    
+
    
+Handler state.
+
    
+
    
+
    
+Handler
+
    
+
    
+
    
+Handler module.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The atom ok is always returned. It can be safely ignored.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Terminate a handler normally
    
+
    
+
    cowboy_handler:terminate(normal, Req, State, Handler).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_handler(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_handler/index.html b/docs/en/cowboy/2.1/manual/cowboy_handler/index.html
new file mode 100644
index 00000000..e83b6fab
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_handler/index.html
@@ -0,0 +1,231 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_handler(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_handler(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_handler - Plain HTTP handlers
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The cowboy_handler middleware executes the handler selected
+by the router or any other preceding middleware.
    
+
    This middleware takes the handler module and initial state
+from the handler and handler_opts environment values,
+respectively. On completion, it adds a result value to
+the middleware environment, containing the return value
+of the terminate/3 callback (if defined) and ok otherwise.
    
+
    This module also defines a callback interface for handling
+HTTP requests.
    
+
    
+
    
+
    
+
    Callbacks
    
+
    
+
    Plain HTTP handlers implement the following interface:
    
+
    
+
    
+
    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()}
    
+
    These two callbacks are common to all handlers.
    
+
    Plain HTTP handlers do all their work in the init/2
+callback. Returning ok terminates the handler. If no
+response is sent, Cowboy will send a 204 No Content.
    
+
    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 plain HTTP
+handlers:
    
+
    
+
    
+normal
+
    
+
    
+
    
+    The connection was closed normally.
+
    
+
    
+
    
+{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.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Exports
    
+
    
+
    The following function should be called by modules implementing
+custom handlers to execute the optional terminate callback:
    
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_http/index.html b/docs/en/cowboy/2.1/manual/cowboy_http/index.html
new file mode 100644
index 00000000..d344048d
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_http/index.html
@@ -0,0 +1,375 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_http(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_http(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_http - HTTP/1.1
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The module cowboy_http implements HTTP/1.1 and HTTP/1.0
+as a Ranch protocol.
    
+
    
+
    
+
    
+
    Options
    
+
    
+
    
+
    
+
    opts() :: #{
+    connection_type         => worker | supervisor,
+    env                     => cowboy_middleware:env(),
+    idle_timeout            => timeout(),
+    inactivity_timeout      => timeout(),
+    max_empty_lines         => non_neg_integer(),
+    max_header_name_length  => non_neg_integer(),
+    max_header_value_length => non_neg_integer(),
+    max_headers             => non_neg_integer(),
+    max_keepalive           => non_neg_integer(),
+    max_method_length       => non_neg_integer(),
+    max_request_line_length => non_neg_integer(),
+    middlewares             => [module()],
+    request_timeout         => timeout(),
+    shutdown_timeout        => timeout(),
+    stream_handlers         => [module()]
+}
    
+
    Configuration for the HTTP/1.1 protocol.
    
+
    This configuration is passed to Cowboy when starting listeners
+using cowboy:start_clear/3 or cowboy:start_tls/3 functions.
    
+
    It can be updated without restarting listeners using the
+Ranch functions ranch:get_protocol_options/1 and
+ranch:set_protocol_options/2.
    
+
    The default value is given next to the option name:
    
+
    
+
    
+connection_type (supervisor)
+
    
+
    
+
    
+    Whether the connection process also acts as a supervisor.
+
    
+
    
+
    
+env (#{})
+
    
+
    
+
    
+    Middleware environment.
+
    
+
    
+
    
+idle_timeout (60000)
+
    
+
    
+
    
+    Time in ms with no data received before Cowboy closes the connection.
+
    
+
    
+
    
+inactivity_timeout (300000)
+
    
+
    
+
    
+    Time in ms with nothing received at all before Cowboy closes the connection.
+
    
+
    
+
    
+max_empty_lines (5)
+
    
+
    
+
    
+    Maximum number of empty lines before a request.
+
    
+
    
+
    
+max_header_name_length (64)
+
    
+
    
+
    
+    Maximum length of header names.
+
    
+
    
+
    
+max_header_value_length (4096)
+
    
+
    
+
    
+    Maximum length of header values.
+
    
+
    
+
    
+max_headers (100)
+
    
+
    
+
    
+    Maximum number of headers allowed per request.
+
    
+
    
+
    
+max_keepalive (100)
+
    
+
    
+
    
+    Maximum number of requests allowed per connection.
+
    
+
    
+
    
+max_method_length (32)
+
    
+
    
+
    
+    Maximum length of the method.
+
    
+
    
+
    
+max_request_line_length (8000)
+
    
+
    
+
    
+    Maximum length of the request line.
+
    
+
    
+
    
+middlewares ([cowboy_router, cowboy_handler])
+
    
+
    
+
    
+    Middlewares to run for every request.
+
    
+
    
+
    
+request_timeout (5000)
+
    
+
    
+
    
+    Time in ms with no requests before Cowboy closes the connection.
+
    
+
    
+
    
+shutdown_timeout (5000)
+
    
+
    
+
    
+    Time in ms Cowboy will wait for child processes to shut down before killing them.
+
    
+
    
+
    
+stream_handlers ([cowboy_stream_h])
+
    
+
    
+
    
+    Ordered list of stream handlers that will handle all stream events.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: The timeout option was renamed request_timeout.
+
      
+
      • 
+
    • 
+
      
+2.0: The idle_timeout, inactivity_timeout and shutdown_timeout options were added.
+
      
+
      • 
+
    • 
+
      
+2.0: The max_method_length option was added.
+
      
+
      • 
+
    • 
+
      
+2.0: The max_request_line_length default was increased from 4096 to 8000.
+
      
+
      • 
+
    • 
+
      
+2.0: The connection_type option was added.
+
      
+
      • 
+
    • 
+
      
+2.0: The env option is now a map instead of a proplist.
+
      
+
      • 
+
    • 
+
      
+2.0: The stream_handlers option was added.
+
      
+
      • 
+
    • 
+
      
+2.0: The compress option was removed in favor of the cowboy_compress_h stream handler.
+
      
+
      • 
+
    • 
+
      
+2.0: Options are now a map instead of a proplist.
+
      
+
      • 
+
    • 
+
      
+2.0: Protocol introduced. Replaces cowboy_protocol.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7),
+cowboy_http2(3),
+cowboy_websocket(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_http2/index.html b/docs/en/cowboy/2.1/manual/cowboy_http2/index.html
new file mode 100644
index 00000000..c16719ff
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_http2/index.html
@@ -0,0 +1,258 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_http2(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_http2(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_http2 - HTTP/2
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The module cowboy_http2 implements HTTP/2
+as a Ranch protocol.
    
+
    
+
    
+
    
+
    Options
    
+
    
+
    
+
    
+
    opts() :: #{
+    connection_type    => worker | supervisor,
+    env                => cowboy_middleware:env(),
+    inactivity_timeout => timeout(),
+    middlewares        => [module()],
+    preface_timeout    => timeout(),
+    shutdown_timeout   => timeout(),
+    stream_handlers    => [module()]
+}
    
+
    Configuration for the HTTP/2 protocol.
    
+
    This configuration is passed to Cowboy when starting listeners
+using cowboy:start_clear/3 or cowboy:start_tls/3 functions.
    
+
    It can be updated without restarting listeners using the
+Ranch functions ranch:get_protocol_options/1 and
+ranch:set_protocol_options/2.
    
+
    The default value is given next to the option name:
    
+
    
+
    
+connection_type (supervisor)
+
    
+
    
+
    
+    Whether the connection process also acts as a supervisor.
+
    
+
    
+
    
+env (#{})
+
    
+
    
+
    
+    Middleware environment.
+
    
+
    
+
    
+inactivity_timeout (300000)
+
    
+
    
+
    
+    Time in ms with nothing received at all before Cowboy closes the connection.
+
    
+
    
+
    
+middlewares ([cowboy_router, cowboy_handler])
+
    
+
    
+
    
+    Middlewares to run for every request.
+
    
+
    
+
    
+preface_timeout (5000)
+
    
+
    
+
    
+    Time in ms Cowboy is willing to wait for the connection preface.
+
    
+
    
+
    
+shutdown_timeout (5000)
+
    
+
    
+
    
+    Time in ms Cowboy will wait for child processes to shut down before killing them.
+
    
+
    
+
    
+stream_handlers ([cowboy_stream_h])
+
    
+
    
+
    
+    Ordered list of stream handlers that will handle all stream events.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Protocol introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7),
+cowboy_http(3),
+cowboy_websocket(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_loop/index.html b/docs/en/cowboy/2.1/manual/cowboy_loop/index.html
new file mode 100644
index 00000000..81eb68a5
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_loop/index.html
@@ -0,0 +1,255 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_loop(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    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:
    
+
    
+
    
+
    init(Req, State)
+    -> {cowboy_loop, Req, State}
+     | {cowboy_loop, Req, State, 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
+        | {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.
+
    
+
    
+
    
+{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.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Loop handlers no longer need to handle overflow/timeouts.
+
      
+
      • 
+
    • 
+
      
+1.0: Behavior introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7),
+cowboy_handler(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.1/manual/cowboy_middleware/index.html
new file mode 100644
index 00000000..96db75ce
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_middleware/index.html
@@ -0,0 +1,250 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_middleware(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_middleware(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_middleware - Middlewares
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The module cowboy_middleware defines a callback interface for
+Cowboy middlewares.
    
+
    Middlewares process the request sequentially in the order they
+are configured.
    
+
    
+
    
+
    
+
    Callbacks
    
+
    
+
    Middlewares implement the following interface:
    
+
    
+
    
+
    execute(Req, Env)
+    -> {ok, Req, Env}
+     | {suspend, module(), atom(), [any()]}
+     | {stop, Req}
+
+Req :: cowboy_req:req()
+Env :: cowboy_middleware:env()
    
+
    The execute/2 is the only callback that needs to be
+implemented. It must execute the middleware and return
+with instructions for Cowboy.
    
+
    
+
    
+ok
+
    
+
    
+
    
+Cowboy should continue processing the request using the
+returned Req object and environment.
+
    
+
    
+
    
+suspend
+
    
+
    
+
    
+Cowboy will hibernate the process. When resuming, Cowboy
+will apply the returned module, function and arguments.
+
    
+
    
+
    
+stop
+
    
+
    
+
    
+Cowboy will stop middleware execution. No other middleware
+will be executed. This effectively ends the processing of
+the request.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Types
    
+
    
+
    
+
    env()
    
+
    
+
    
+
    env() :: #{atom() => any()}
    
+
    Middleware environment.
    
+
    A new environment is created for every request. The initial
+environment contained the user configured environment values
+(like dispatch for example) plus the listener value which
+contains the name of the listener for this connection.
    
+
    Middlewares may modify the environment as necessary.
    
+
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: The env type is now a map instead of a proplist.
+
      
+
      • 
+
    • 
+
      
+1.0: Behavior introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.binding/index.html
new file mode 100644
index 00000000..6e91f43d
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.binding/index.html
@@ -0,0 +1,251 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:binding(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:binding(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:binding - Access a value bound from the route
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    binding(Name, Req)          -> binding(Name, Req, undefined)
+binding(Name, Req, Default) -> any() | Default
+
+Name    :: atom()
+Req     :: cowboy_req:req()
+Default :: any()
    
+
    Return the value for the given binding.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+Desired binding name as an atom.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+Default
+
    
+
    
+
    
+Default value returned when the binding is missing.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    By default the value is a case sensitive binary string, however
+constraints may change the type of this value (for example
+automatically converting numbers to integer).
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the value is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the username from the path
    
+
    
+
    %% Route is "/users/:user"
+Username = cowboy_req:binding(user, Req).
    
+
    
+
    Get the branch name, with a default
    
+
    
+
    %% Route is "/log[/:branch]"
+Branch = cowboy_req:binding(branch, Req, <<"master">>)
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:bindings(3),
+cowboy_req:host_info(3),
+cowboy_req:path_info(3),
+cowboy_router(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.bindings/index.html
new file mode 100644
index 00000000..fba98427
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.bindings/index.html
@@ -0,0 +1,221 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:bindings(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:bindings(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:bindings - Access all values bound from the route
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    bindings(Req :: cowboy_req:req()) -> cowboy_router:bindings()
    
+
    Return a map containing all bindings.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    By default values are case sensitive binary strings, however
+constraints may change the type of this value (for example
+automatically converting numbers to integer).
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the values are returned, they are no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get all bindings
    
+
    
+
    Bindings = cowboy_req:bindings(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:binding(3),
+cowboy_req:host_info(3),
+cowboy_req:path_info(3),
+cowboy_router(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.body_length/index.html
new file mode 100644
index 00000000..9e7d7801
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.body_length/index.html
@@ -0,0 +1,224 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:body_length(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:body_length(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:body_length - Body length
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    body_length(Req :: cowboy_req:req()) -> undefined | non_neg_integer()
    
+
    Return the length of the request body.
    
+
    The length is not always known before reading the body.
+In those cases Cowboy will return undefined. The body
+length is available after the body has been fully read.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The length of the request body, or undefined if it is
+not known.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the length is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the body length
    
+
    
+
    Length = cowboy_req:body_length(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:has_body(3),
+cowboy_req:read_body(3),
+cowboy_req:read_urlencoded_body(3),
+cowboy_req:read_part(3),
+cowboy_req:read_part_body(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.cert/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.cert/index.html
new file mode 100644
index 00000000..0aa0cb31
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.cert/index.html
@@ -0,0 +1,239 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:cert(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:cert(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:cert - Client TLS certificate
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    cert(Req :: cowboy_req:req()) -> binary() | undefined
    
+
    Return the peer’s TLS certificate.
    
+
    Using the default configuration this function will always return
+undefined. You need to explicitly configure Cowboy to request
+the client certificate. To do this you need to set the verify
+transport option to verify_peer:
    
+
    
+
    
+
    {ok, _} = cowboy:start_tls(example, [
+    {port, 8443},
+    {cert, "path/to/cert.pem"},
+    {verify, verify_peer}
+], #{
+    env => #{dispatch => Dispatch}
+}).
    
+
    You may also want to customize the verify_fun function. Please
+consult the ssl application’s manual for more details.
    
+
    TCP connections do not allow a certificate and this function
+will therefore always return undefined.
    
+
    The certificate can also be obtained using pattern matching:
    
+
    
+
    
+
    #{cert := Cert} = Req.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The client TLS certificate.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the client TLS certificate.
    
+
    
+
    Cert = cowboy_req:cert(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:peer(3),
+cowboy_req:sock(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.delete_resp_header/index.html
new file mode 100644
index 00000000..86481a6a
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.delete_resp_header/index.html
@@ -0,0 +1,230 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:delete_resp_header(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:delete_resp_header(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:delete_resp_header - Delete a response header
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    delete_resp_header(Name, Req :: cowboy_req:req()) -> Req
+
+Name :: binary()  %% lowercase; case insensitive
    
+
    Delete the given response header.
    
+
    The header name must be given as a lowercase binary string.
+While header names are case insensitive, Cowboy requires them
+to be given as lowercase to function properly.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+Header name as a lowercase binary string.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A new Req object is returned.
    
+
    The returned Req object must be used from that point onward,
+otherwise the header will still be sent in the response.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Remove the content-type header from the response
    
+
    
+
    Req = cowboy_req:delete_resp_header(<<"content-type">>, Req0),
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:set_resp_header(3),
+cowboy_req:set_resp_headers(3),
+cowboy_req:has_resp_header(3),
+cowboy_req:resp_header(3),
+cowboy_req:resp_headers(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.has_body/index.html
new file mode 100644
index 00000000..de228002
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.has_body/index.html
@@ -0,0 +1,215 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:has_body(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:has_body(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:has_body - Is there a request body?
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    has_body(Req :: cowboy_req:req()) -> boolean()
    
+
    Return whether the request has a body.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A boolean indicating whether the request has a body.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Ensure the request has a body
    
+
    
+
    true = cowboy_req:has_body(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:body_length(3),
+cowboy_req:read_body(3),
+cowboy_req:read_urlencoded_body(3),
+cowboy_req:read_part(3),
+cowboy_req:read_part_body(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_body/index.html
new file mode 100644
index 00000000..a574744f
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_body/index.html
@@ -0,0 +1,217 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:has_resp_body(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:has_resp_body(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:has_resp_body - Is there a response body?
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    has_resp_body(Req :: cowboy_req:req()) -> boolean()
    
+
    Return whether a response body has been set.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A boolean indicating whether a response body has been set.
    
+
    This function will return false when an empty response
+body has been set.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Check whether a body has been set
    
+
    
+
    false = cowboy_req:has_resp_body(Req0),
+Req1 = cowboy_req:set_resp_body(<<"Hello!">>, Req0),
+true = cowboy_req:has_resp_body(Req1),
+Req = cowboy_req:set_resp_body(<<>>, Req1),
+false = cowboy_req:has_resp_body(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:set_resp_body(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_header/index.html
new file mode 100644
index 00000000..f3d69ac9
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_header/index.html
@@ -0,0 +1,230 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:has_resp_header(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:has_resp_header(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:has_resp_header - Is the given response header set?
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    has_resp_header(Name, Req :: cowboy_req:req()) -> boolean()
+
+Name :: binary()  %% lowercase; case insensitive
    
+
    Return whether the given response header has been set.
    
+
    The header name must be given as a lowercase binary string.
+While header names are case insensitive, Cowboy requires them
+to be given as lowercase to function properly.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+Header name as a lowercase binary string.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A boolean indicating whether the given response header has been set.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Check whether the content-type header has been set
    
+
    
+
    false = cowboy_req:has_resp_header(<<"content-type">>, Req0),
+Req = cowboy_req:set_resp_header(<<"content-type">>, <<"text/html">>, Req0),
+true = cowboy_req:has_resp_header(<<"content-type">>, Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:set_resp_header(3),
+cowboy_req:set_resp_headers(3),
+cowboy_req:resp_header(3),
+cowboy_req:resp_headers(3),
+cowboy_req:delete_resp_header(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.header/index.html
new file mode 100644
index 00000000..4937b9b6
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.header/index.html
@@ -0,0 +1,257 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:header(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:header(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:header - HTTP header
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    header(Name, Req)          -> header(Name, Req, undefined)
+header(Name, Req, Default) -> binary() | Default
+
+Name    :: binary()          %% lowercase; case insensitive
+Req     :: cowboy_req:req()
+Default :: any()
    
+
    Return the value for the given HTTP header.
    
+
    The header name must be given as a lowercase binary string.
+While header names are case insensitive, Cowboy requires them
+to be given as lowercase to function properly.
    
+
    Headers can also be obtained using pattern matching:
    
+
    
+
    
+
    #{headers := #{Name := Value}} = Req.
    
+
    Note that this snippet will crash if the header is missing.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+Desired HTTP header name as a lowercase binary string.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+Default
+
    
+
    
+
    
+Default value returned when the header is missing.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The header value is returned as a binary string. When the
+header is missing, the default argument is returned.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the header value is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the accept header
    
+
    
+
    Accept = cowboy_req:header(<<"accept">>, Req).
    
+
    
+
    Get the content-length header with a default value
    
+
    
+
    Length = cowboy_req:header(<<"content-length">>, Req, <<"0">>).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:headers(3),
+cowboy_req:parse_header(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.headers/index.html
new file mode 100644
index 00000000..17d40168
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.headers/index.html
@@ -0,0 +1,225 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:headers(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:headers(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:headers - HTTP headers
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    headers(Req :: cowboy_req:req()) -> cowboy:http_headers()
    
+
    Return all request headers.
    
+
    Request headers can also be obtained using pattern matching:
    
+
    
+
    
+
    #{headers := Headers} = Req.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    Headers are returned as a map with keys being lowercase
+binary strings, and values as binary strings.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the headers are returned, they are no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get all headers
    
+
    
+
    Headers = cowboy_req:headers(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:header(3),
+cowboy_req:parse_header(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.host/index.html
new file mode 100644
index 00000000..a7f1f8f0
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.host/index.html
@@ -0,0 +1,226 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:host(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:host(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:host - URI host name
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    host(Req :: cowboy_req:req()) -> Host :: binary()
    
+
    Return the host name of the effective request URI.
    
+
    The host name can also be obtained using pattern matching:
    
+
    
+
    
+
    #{host := Host} = Req.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The host name is returned as a lowercase binary string.
+It is case insensitive.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the host name is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the effective request URI’s host name
    
+
    
+
    Host = cowboy_req:host(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:binding(3),
+cowboy_req:bindings(3),
+cowboy_req:host_info(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.host_info/index.html
new file mode 100644
index 00000000..642dc273
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.host_info/index.html
@@ -0,0 +1,222 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:host_info(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:host_info(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:host_info - Access the route’s heading host segments
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    host_info(Req :: cowboy_req:req()) -> cowboy_router:tokens()
    
+
    Return the tokens for the heading host segments.
    
+
    This is the part of the host name that was matched using
+the ... notation.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The tokens are returned as a list of case insensitive
+binary strings.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the tokens are returned, they are no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the host_info tokens
    
+
    
+
    HostInfo = cowboy_req:host_info(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:binding(3),
+cowboy_req:bindings(3),
+cowboy_req:path_info(3),
+cowboy_router(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.inform/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.inform/index.html
new file mode 100644
index 00000000..c49904da
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.inform/index.html
@@ -0,0 +1,260 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:inform(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:inform(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:inform - Send an informational response
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    inform(Status, Req :: cowboy_req:req())
+    -> inform(StatusCode, #{}, Req)
+
+inform(Status, Headers, Req :: cowboy_req:req())
+    -> ok
+
+Status  :: cowboy:http_status()
+Headers :: cowboy:http_headers()
    
+
    Send an informational response.
    
+
    Informational responses use a status code between 100 and 199.
+They cannot include a body. This function will not use any
+of the previously set headers. All headers to be sent must
+be given directly.
    
+
    Any number of informational responses can be sent as long as
+they are sent before the proper response. Attempting to use
+this function after sending a normal response will result
+in an error.
    
+
    The header names must be given as lowercase binary strings.
+While header names are case insensitive, Cowboy requires them
+to be given as lowercase to function properly.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Status
+
    
+
    
+
    
+The status code for the response.
+
    
+
    
+
    
+Headers
+
    
+
    
+
    
+The response headers.
+
    
+
    
+
    
+
    Header names must be given as lowercase binary strings.
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The atom ok is always returned. It can be safely ignored.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Send an informational response
    
+
    
+
    Req = cowboy_req:inform(102, Req0).
    
+
    
+
    Send an informational response with headers
    
+
    
+
    Req = cowboy_req:inform(103, #{
+    <<"link">> => <<"</style.css>; rel=preload; as=style">>,
+    <<"link">> => <<"</script.js>; rel=preload; as=script">>
+}, Req0).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:reply(3),
+cowboy_req:stream_reply(3),
+cowboy_req:push(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.match_cookies/index.html
new file mode 100644
index 00000000..7fcc978f
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.match_cookies/index.html
@@ -0,0 +1,258 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:match_cookies(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:match_cookies(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:match_cookies - Match cookies against constraints
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req())
+    -> #{atom() => any()}
    
+
    Parse the cookies and match specific values against
+constraints.
    
+
    Cowboy will only return the cookie values specified in the
+fields list, and ignore all others. Fields can be either
+the name of the cookie requested; the name along with a
+list of constraints; or the name, a list of constraints
+and a default value in case the cookie is missing.
    
+
    This function will crash if the cookie is missing and no
+default value is provided. This function will also crash
+if a constraint fails.
    
+
    The name of the cookie must be provided as an atom. The
+key of the returned map will be that atom. The value may
+be converted through the use of constraints, making this
+function able to extract, validate and convert values all
+in one step.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Fields
+
    
+
    
+
    
+Cookies to retrieve.
+
    
+
    See cowboy(3) for a complete description.
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    Desired values are returned as a map. The key is the atom
+that was given in the list of fields, and the value is the
+optionally converted value after applying constraints.
    
+
    The map contains the same keys that were given in the fields.
    
+
    An exception is triggered when the match fails.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Match fields
    
+
    
+
    %% ID and Lang are binaries.
+#{id := ID, lang := Lang}
+    = cowboy_req:match_cookies([id, lang], Req).
    
+
    
+
    Match fields and apply constraints
    
+
    
+
    %% ID is an integer and Lang a non-empty binary.
+#{id := ID, lang := Lang}
+    = cowboy_req:match_cookies([{id, int}, {lang, nonempty}], Req).
    
+
    
+
    Match fields with default values
    
+
    
+
    #{lang := Lang}
+    = cowboy_req:match_cookies([{lang, [], <<"en-US">>}], Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:parse_cookies(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.match_qs/index.html
new file mode 100644
index 00000000..b1ae218c
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.match_qs/index.html
@@ -0,0 +1,258 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:match_qs(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:match_qs(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:match_qs - Match the query string against constraints
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req())
+    -> #{atom() => any()}
    
+
    Parse the query string and match specific values against
+constraints.
    
+
    Cowboy will only return the query string values specified
+in the fields list, and ignore all others. Fields can be
+either the key requested; the key along with a list of
+constraints; or the key, a list of constraints and a
+default value in case the key is missing.
    
+
    This function will crash if the key is missing and no
+default value is provided. This function will also crash
+if a constraint fails.
    
+
    The key must be provided as an atom. The key of the
+returned map will be that atom. The value may be converted
+through the use of constraints, making this function able
+to extract, validate and convert values all in one step.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Fields
+
    
+
    
+
    
+Fields to retrieve from the query string.
+
    
+
    See cowboy(3) for a complete description.
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    Desired values are returned as a map. The key is the atom
+that was given in the list of fields, and the value is the
+optionally converted value after applying constraints.
    
+
    The map contains the same keys that were given in the fields.
    
+
    An exception is triggered when the match fails.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Match fields
    
+
    
+
    %% ID and Lang are binaries.
+#{id := ID, lang := Lang}
+    = cowboy_req:match_qs([id, lang], Req).
    
+
    
+
    Match fields and apply constraints
    
+
    
+
    %% ID is an integer and Lang a non-empty binary.
+#{id := ID, lang := Lang}
+    = cowboy_req:match_qs([{id, int}, {lang, nonempty}], Req).
    
+
    
+
    Match fields with default values
    
+
    
+
    #{lang := Lang}
+    = cowboy_req:match_qs([{lang, [], <<"en-US">>}], Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:qs(3),
+cowboy_req:parse_qs(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.method/index.html
new file mode 100644
index 00000000..9463941a
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.method/index.html
@@ -0,0 +1,235 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:method(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:method(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:method - HTTP method
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    method(Req :: cowboy_req:req()) -> Method :: binary()
    
+
    Return the request’s HTTP method.
    
+
    The method can also be obtained using pattern matching:
    
+
    
+
    
+
    #{method := Method} = Req.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The request’s HTTP method is returned as a binary string.
+While methods are case sensitive, standard methods are
+always uppercase.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the method is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Ensure the request’s method is GET
    
+
    
+
    <<"GET">> = cowboy_req:method(Req).
    
+
    
+
    Allow methods from list
    
+
    
+
    init(Req, State) ->
+    case lists:member(cowboy_req:method(Req), [<<"GET">>, <<"POST">>]) of
+        true -> handle(Req, State);
+        false -> method_not_allowed(Req, State)
+    end.
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.parse_cookies/index.html
new file mode 100644
index 00000000..b8da0ffd
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.parse_cookies/index.html
@@ -0,0 +1,226 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:parse_cookies(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:parse_cookies(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:parse_cookies - Parse cookie headers
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    parse_cookies(Req) -> [{Name, Value}]
+
+Name  :: binary() %% case sensitive
+Value :: binary() %% case sensitive
    
+
    Parse cookie headers.
    
+
    Alias for cowboy_req:parse_header([cookie], Req).
    
+
    When the cookie header is missing, [] is returned.
    
+
    While an empty cookie header is not valid, some clients do
+send it. Cowboy will in this case also return [].
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The cookies are returned as a list of key/values. Keys and
+values are case sensitive binary strings.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the parsed header value is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+2.0: Function introduced. Replaces cookie/2,3 and cookies/1.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Look for a specific cookie
    
+
    
+
    Cookies = cowboy_req:parse_cookies(Req),
+{_, Token} = lists:keyfind(token, 1, Cookies).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:parse_header(3),
+cowboy_req:match_cookies(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.parse_header/index.html
new file mode 100644
index 00000000..99334ad7
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.parse_header/index.html
@@ -0,0 +1,418 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:parse_header(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:parse_header(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:parse_header - Parse the given HTTP header
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    parse_header(Name, Req)          -> ParsedValue | Default
+parse_header(Name, Req, Default) -> ParsedValue | Default
+
+Name        :: binary()
+Req         :: cowboy_req:req()
+ParsedValue :: any()
+Default     :: any()
    
+
    Parse the given HTTP header.
    
+
    The header name must be given as a lowercase binary string.
+While header names are case insensitive, Cowboy requires them
+to be given as lowercase to function properly.
    
+
    The type of the parsed value varies depending on
+the header. Similarly, the default value when calling
+cowboy_req:parse_header/2 differs depending on the
+header.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+Desired HTTP header name as a lowercase binary string.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+Default
+
    
+
    
+
    
+Default value returned when the header is missing.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The parsed header value varies depending on the header.
+When the header is missing, the default argument is returned.
    
+
    
+
    
+
    
+
    Headers
    
+
    
+
    The following snippets detail the types returned by the
+different headers. Unless mentioned otherwise, the
+default value when the header is missing will be undefined:
    
+
    
+
    accept
    
+
    
+
    parse_header(<<"accept">>, Req)
+    -> [{{Type, SubType, Params}, Quality, AcceptExt}]
+
+Type      :: binary()               %% case insensitive
+SubType   :: binary()               %% case insensitive
+Params    :: [{Key, Value}]
+Quality   :: 0..1000
+AcceptExt :: [Key | {Key, Value}]
+Key       :: binary()               %% case insensitive
+Value     :: binary()               %% case sensitive
    
+
    
+
    accept-charset, accept-encoding and accept-language
    
+
    
+
    parse_header(Name, Req) -> [{Value, Quality}]
+
+Name    :: <<"accept-charset">>
+         | <<"accept-encoding">>
+         | <<"accept-language">>
+Value   :: binary()                 %% case insensitive
+Quality :: 0..1000
    
+
    
+
    authorization
    
+
    
+
    parse_header(<<"authorization">>, Req)
+    -> {basic, Username :: binary(), Password :: binary()}
+     | {bearer, Token :: binary()}
+     | {digest, [{Key :: binary(), Value :: binary()}]}
    
+
    
+
    content-length
    
+
    
+
    parse_header(<<"content-length">>, Req) -> non_neg_integer()
    
+
    When the content-length header is missing, 0 is returned.
    
+
    
+
    content-type
    
+
    
+
    parse_header(<<"content-type">>, Req)
+    -> {Type, SubType, Params}
+
+Type      :: binary()               %% case insensitive
+SubType   :: binary()               %% case insensitive
+Params    :: [{Key, Value}]
+Key       :: binary()               %% case insensitive
+Value     :: binary()               %% case sensitive;
    
+
    Note that the value for the charset parameter is case insensitive
+and returned as a lowercase binary string.
    
+
    
+
    cookie
    
+
    
+
    parse_header(<<"cookie">>, Req) -> [{Name, Value}]
+
+Name  :: binary()                   %% case sensitive
+Value :: binary()                   %% case sensitive
    
+
    When the cookie header is missing, [] is returned.
    
+
    While an empty cookie header is not valid, some clients do
+send it. Cowboy will in this case also return [].
    
+
    
+
    expect
    
+
    
+
    parse_header(<<"expect">>, Req) -> continue
    
+
    
+
    if-match and if-none-match
    
+
    
+
    parse_header(Name, Req)
+    -> '*' | [{weak | strong, OpaqueTag}]
+
+Name      :: <<"if-match">>
+           | <<"if-none-match">>
+OpaqueTag :: binary()               %% case sensitive
    
+
    
+
    if-modified-since and if-unmodified-since
    
+
    
+
    parse_header(Name, Req) -> calendar:datetime()
    
+
    
+
    range
    
+
    
+
    parse_header(<<"range">>, Req) -> {From, To} | Final
+
+From  :: non_neg_integer()
+To    :: non_neg_integer() | infinity
+Final :: neg_integer()
    
+
    
+
    sec-websocket-extensions
    
+
    
+
    parse_header(<<"sec-websocket-extensions">>, Req)
+    -> [{Extension, Params}]
+
+Extension :: binary()               %% case sensitive
+Params    :: [Key | {Key, Value}]
+Key       :: binary()               %% case sensitive
+Value     :: binary()               %% case sensitive
    
+
    
+
    sec-websocket-protocol and upgrade
    
+
    
+
    parse_header(Name, Req) -> [Token]
+
+Name  :: <<"sec-websocket-protocol">>
+       | <<"upgrade">>
+Token :: binary()                   %% case insensitive
    
+
    
+
    x-forwarded-for
    
+
    
+
    parse_header(<<"x-forwarded-for">>, Req) -> [Token]
+
+Token :: binary()                   %% case sensitive
    
+
    
+
    Unknown headers
    
+
    
+
    parse_header(_, Req) -> {undefined, RawValue}
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the parsed header value is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Parse the accept header with a custom default value
    
+
    
+
    %% Accept everything when header is missing.
+Accept = cowboy_req:parse_header(<<"accept">>, Req,
+    [{{ <<"*">>, <<"*">>, []}, 1000, []}]).
    
+
    
+
    Parse the content-length header
    
+
    
+
    %% Default content-length is 0.
+Length = cowboy_req:header(<<"content-length">>, Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:header(3),
+cowboy_req:headers(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.parse_qs/index.html
new file mode 100644
index 00000000..a70ae879
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.parse_qs/index.html
@@ -0,0 +1,252 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:parse_qs(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:parse_qs(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:parse_qs - Parse the query string
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    parse_qs(Req :: cowboy_req:req())
+    -> [{Key :: binary(), Value :: binary() | true}]
    
+
    Parse the query string as a list of key/value pairs.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The parsed query string is returned as a list of key/value pairs.
+The key is a binary string. The value is either a binary string,
+or the atom true. Both key and value are case sensitive.
    
+
    The atom true is returned when a key is present in the query
+string without a value. For example, in the following URIs
+the key <<"edit">> will always have the value true:
    
+
      
+
    • 
+
      
+/posts/42?edit
+
      
+
      • 
+
    • 
+
      
+/posts/42?edit&exclusive=1
+
      
+
      • 
+
    • 
+
      
+/posts/42?exclusive=1&edit
+
      
+
      • 
+
    • 
+
      
+/posts/42?exclusive=1&edit&from=web
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: The parsed value is not longer cached in the Req object.
+
      
+
      • 
+
    • 
+
      
+2.0: Only the parsed query string is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+2.0: Function introduced. Replaces qs_val/1 and qs_vals/1.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Parse the query string and convert the keys to atoms
    
+
    
+
    ParsedQs = cowboy_req:parse_qs(Req),
+AtomsQs = [{binary_to_existing_atom(K, latin1), V}
+    || {K, V} <- ParsedQs].
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:qs(3),
+cowboy_req:match_qs(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.path/index.html
new file mode 100644
index 00000000..2fa48b5f
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.path/index.html
@@ -0,0 +1,225 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:path(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:path(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:path - URI path
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    path(Req :: cowboy_req:req()) -> Path :: binary()
    
+
    Return the path of the effective request URI.
    
+
    The path can also be obtained using pattern matching:
    
+
    
+
    
+
    #{path := Path} = Req.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The path is returned as a binary string. It is case sensitive.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the path is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the effective request URI’s path
    
+
    
+
    Path = cowboy_req:path(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:binding(3),
+cowboy_req:bindings(3),
+cowboy_req:path_info(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.path_info/index.html
new file mode 100644
index 00000000..433044b1
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.path_info/index.html
@@ -0,0 +1,222 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:path_info(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:path_info(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:path_info - Access the route’s trailing path segments
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    path_info(Req :: cowboy_req:req()) -> cowboy_router:tokens()
    
+
    Return the tokens for the trailing path segments.
    
+
    This is the part of the host name that was matched using
+the ... notation.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The tokens are returned as a list of case sensitive
+binary strings.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the tokens are returned, they are no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the path_info tokens
    
+
    
+
    PathInfo = cowboy_req:path_info(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:binding(3),
+cowboy_req:bindings(3),
+cowboy_req:host_info(3),
+cowboy_router(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.peer/index.html
new file mode 100644
index 00000000..c5c11501
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.peer/index.html
@@ -0,0 +1,233 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:peer(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:peer(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:peer - Peer address and port
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    peer(Req :: cowboy_req:req()) -> Info
+
+Info :: {inet:ip_address(), inet:port_number()}
    
+
    Return the peer’s IP address and port number.
    
+
    The peer information can also be obtained using pattern matching:
    
+
    
+
    
+
    #{peer := {IP, Port}} = Req.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The peer’s IP address and port number.
    
+
    The peer is not necessarily the client’s IP address and port.
+It is the IP address of the endpoint connecting directly to
+the server, which may be a gateway or a proxy.
    
+
    The forwarded header can be used to get better information
+about the different endpoints from the client to the server.
+Note however that it is only informative; there is no reliable
+way of determining the source of an HTTP request.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the peer is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the peer IP address and port number.
    
+
    
+
    {IP, Port} = cowboy_req:peer(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:sock(3),
+cowboy_req:cert(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.port/index.html
new file mode 100644
index 00000000..7306d0d2
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.port/index.html
@@ -0,0 +1,225 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:port(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:port(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:port - URI port number
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    port(Req :: cowboy_req:req()) -> Port :: inet:port_number()
    
+
    Return the port number of the effective request URI.
    
+
    Note that the port number returned by this function is obtained
+by parsing the host header. It may be different from the port
+the peer used to connect to Cowboy.
    
+
    The port number can also be obtained using pattern matching:
    
+
    
+
    
+
    #{port := Port} = Req.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The port number is returned as an integer.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the port number is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the effective request URI’s port number
    
+
    
+
    Port = cowboy_req:port(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.push/index.html
new file mode 100644
index 00000000..e40aa5b5
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.push/index.html
@@ -0,0 +1,277 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:push(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:push(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:push - Push a resource to the client
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    push(Path, Headers, Req :: cowboy_req:req())
+    -> push(Path, Headers, Req, #{})
+
+push(Path, Headers, Req :: cowboy_req:req(), Opts)
+    -> ok
+
+Path    :: iodata()                %% case sensitive
+Headers :: cowboy:http_headers()
+Opts    :: cowboy_req:push_opts()
    
+
    Push a resource to the client.
    
+
    Cowboy handles push requests the same way as if they came
+from the client, including the creation of a request handling
+process, routing and middlewares and so on.
    
+
    This function does nothing when the HTTP/1.1 protocol is
+used. You may call it safely without first checking whether
+the connection uses HTTP/2.
    
+
    The header names must be given as lowercase binary strings.
+While header names are case insensitive, Cowboy requires them
+to be given as lowercase to function properly.
    
+
    Note that the headers must be the headers the client is expected
+to send if it were to perform the request. They are therefore
+request headers, and not response headers.
    
+
    By default, Cowboy will use the GET method, an empty query string,
+and take the scheme, host and port directly from the current
+request’s URI. You can override them by passing options.
    
+
    It is not possible to push resources after sending a response.
+Any attempt will result in an error.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Path
+
    
+
    
+
    
+The status code for the response.
+
    
+
    
+
    
+Headers
+
    
+
    
+
    
+The response headers.
+
    
+
    
+
    
+
    Header names must be given as lowercase binary strings.
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+Opts
+
    
+
    
+
    
+Customize the HTTP method or the URI scheme, host, port
+or query string.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The atom ok is always returned. It can be safely ignored.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Push a resource
    
+
    
+
    cowboy_req:push("/static/style.css", #{
+    <<"accept">> => <<"text/css">>
+}, Req),
    
+
    
+
    Push a resource with a custom host
    
+
    
+
    cowboy_req:push("/static/style.css", #{
+    <<"accept">> => <<"text/css">>
+}, #{host => <<"cdn.example.org">>}, Req),
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:inform(3),
+cowboy_req:reply(3),
+cowboy_req:stream_reply(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.qs/index.html
new file mode 100644
index 00000000..8eb98e1c
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.qs/index.html
@@ -0,0 +1,224 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:qs(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:qs(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:qs - URI query string
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    qs(Req :: cowboy_req:req()) -> Qs :: binary()
    
+
    Return the query string of the effective request URI.
    
+
    The query string can also be obtained using pattern matching:
    
+
    
+
    
+
    #{qs := Qs} = Req.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The query string is returned as a binary string. It is case sensitive.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the query string is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the effective request URI’s query string
    
+
    
+
    Qs = cowboy_req:qs(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:parse_qs(3),
+cowboy_req:match_qs(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.read_body/index.html
new file mode 100644
index 00000000..fe0ab87c
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.read_body/index.html
@@ -0,0 +1,278 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:read_body(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:read_body(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:read_body - Read the request body
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    read_body(Req :: cowboy_req:req())
+    -> read_body(Req, #{})
+
+read_body(Req :: cowboy_req:req(), Opts)
+    -> {ok,   Data :: binary(), Req}
+     | {more, Data :: binary(), Req}
+
+Opts :: cowboy_req:read_body_opts()
    
+
    Read the request body.
    
+
    This function reads a chunk of the request body. A more tuple
+is returned when more data remains to be read. Call the function
+repeatedly until an ok tuple is returned to read the entire body.
    
+
    An ok tuple with empty data is returned when the request has no body,
+or when calling this function again after the body has already
+been read. It is therefore safe to call this function directly.
+Note that the body can only be read once.
    
+
    This function reads the request body from the connection process.
+The connection process is responsible for reading from the socket.
+The exact behavior varies depending on the protocol.
    
+
    The options therefore are only related to the communication
+between the request process and the connection process.
    
+
    Cowboy will automatically handle protocol details including
+the expect header, chunked transfer-encoding and others.
    
+
    Once the body has been read fully, Cowboy sets the content-length
+header if it was not previously provided.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+Opts
+
    
+
    
+
    
+A map of body reading options.
+
    
+
    The length option can be used to request smaller or bigger
+chunks of data to be sent. It is a best effort approach, Cowboy
+may send more data than configured on occasions. It defaults
+to 8MB.
    
+
    The period indicates how long the connection process will wait
+before it provides us with the data it received. It defaults
+to 15 seconds.
    
+
    The connection process sends data to the request process when
+either the length of data or the period of time is reached.
    
+
    The timeout option is a safeguard in case the connection
+process becomes unresponsive. The function will crash if no
+message was received in that interval. The timeout should be
+larger than the period. It defaults to the period + 1 second.
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A more tuple is returned when there are more data to be read.
    
+
    An ok tuple is returned when there are no more data to be read,
+either because this is the last chunk of data, the body has already
+been read, or there was no body to begin with.
    
+
    The data is always returned as a binary.
    
+
    The Req object returned in the tuple must be used for that point
+onward. It contains a more up to date representation of the request.
+For example it may have an added content-length header once the
+body has been read.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced. Replaces body/1,2.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Read the entire body
    
+
    
+
    read_body(Req0, Acc) ->
+    case cowboy_req:read_body(Req0) of
+        {ok, Data, Req} -> {ok, << Acc/binary, Data/binary >>, Req};
+        {more, Data, Req} -> read_body(Req, << Acc/binary, Data/binary >>)
+    end.
    
+
    
+
    Read the body in small chunks
    
+
    
+
    cowboy_req:read_body(Req, #{length => 64000}).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:has_body(3),
+cowboy_req:body_length(3),
+cowboy_req:read_urlencoded_body(3),
+cowboy_req:read_part(3),
+cowboy_req:read_part_body(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.read_part/index.html
new file mode 100644
index 00000000..1e0fb043
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.read_part/index.html
@@ -0,0 +1,297 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:read_part(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:read_part(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:read_part - Read the next multipart headers
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    read_part(Req :: cowboy_req:req())
+    -> read_part(Req, #{})
+
+read_part(Req :: cowboy_req:req(), Opts)
+    -> {ok, Headers, Req} | {done, Req}
+
+Opts    :: cowboy_req:read_body_opts()
+Headers :: #{binary() => binary()}
    
+
    Read the next part of a multipart body.
    
+
    This function reads the request body and parses it as
+multipart. Each parts of a multipart representation have
+their own headers and body. This function parses and returns
+headers. Examples of multipart media types are
+multipart/form-data and multipart/byteranges.
    
+
    Cowboy will skip any data remaining until the beginning of
+the next part. This includes the preamble to the multipart
+message but also the body of a previous part if it hasn’t
+been read. Both are skipped automatically when calling this
+function.
    
+
    Cowboy will read the body before parsing in chunks of size
+up to 64KB, with a period of 5 seconds. This is tailored for
+reading part headers and might not be the most efficient for
+skipping the previous part’s body.
    
+
    The headers returned are MIME headers, NOT HTTP headers.
+They can be parsed using the functions from the cow_multipart
+module. In addition, the cow_multipart:form_data/1 function
+can be used to quickly extract information from multipart/form-data
+representations.
    
+
    Once a part has been read, it can not be read again.
    
+
    Once the body has been read, Cowboy sets the content-length
+header if it was not previously provided.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+Opts
+
    
+
    
+
    
+A map of body reading options. Please refer to
+cowboy_req:read_body(3)
+for details about each option.
+
    
+
    This function defaults the length to 64KB and the period
+to 5 seconds.
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    An ok tuple is returned containing the next part’s headers
+as a map.
    
+
    A done tuple is returned if there are no more parts to read.
    
+
    The Req object returned in the tuple must be used for that point
+onward. It contains a more up to date representation of the request.
+For example it may have an added content-length header once the
+body has been read.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced. Replaces part/1,2.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Read all parts
    
+
    
+
    acc_multipart(Req0, Acc) ->
+    case cowboy_req:read_part(Req0) of
+        {ok, Headers, Req1} ->
+            {ok, Body, Req} = stream_body(Req1, <<>>),
+            acc_multipart(Req, [{Headers, Body}|Acc]);
+        {done, Req} ->
+            {lists:reverse(Acc), Req}
+    end.
+
+stream_body(Req0, Acc) ->
+    case cowboy_req:read_part_body(Req0) of
+        {more, Data, Req} ->
+            stream_body(Req, << Acc/binary, Data/binary >>);
+        {ok, Data, Req} ->
+            {ok, << Acc/binary, Data/binary >>, Req}
+    end.
    
+
    
+
    Read all part headers, skipping bodies
    
+
    
+
    skip_body_multipart(Req0, Acc) ->
+    case cowboy_req:read_part(Req0) of
+        {ok, Headers, Req} ->
+            skip_body_multipart(Req, [Headers|Acc]);
+        {done, Req} ->
+            {lists:reverse(Acc), Req}
+    end.
    
+
    
+
    Read a part header in larger chunks
    
+
    
+
    {ok, Headers, Req} = cowboy_req:read_part(Req0, #{length => 1000000}).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:has_body(3),
+cowboy_req:body_length(3),
+cowboy_req:read_body(3),
+cowboy_req:read_urlencoded_body(3),
+cowboy_req:read_part_body(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.read_part_body/index.html
new file mode 100644
index 00000000..01c2c7af
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.read_part_body/index.html
@@ -0,0 +1,265 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:read_part_body(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:read_part_body(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:read_part_body - Read the current part’s body
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    read_part_body(Req :: cowboy_req:req())
+    -> read_part_body(Req, #{})
+
+read_part_body(Req :: cowboy_req:req(), Opts)
+    -> {ok,   Data :: binary(), Req}
+     | {more, Data :: binary(), Req}
+
+Opts :: cowboy_req:read_body_opts()
    
+
    Read the body of the current part of the multipart message.
    
+
    This function reads the request body and parses it as
+multipart. Each parts of a multipart representation have
+their own headers and body. This function returns the
+body of the current part. Examples of multipart media types
+are multipart/form-data and multipart/byteranges.
    
+
    This function reads a chunk of the part’s body. A more tuple
+is returned when more data remains to be read. Call the function
+repeatedly until an ok tuple is returned to read the entire body.
    
+
    Once a part has been read, it can not be read again.
    
+
    Once the body has been read, Cowboy sets the content-length
+header if it was not previously provided.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+Opts
+
    
+
    
+
    
+A map of body reading options. Please refer to
+cowboy_req:read_body(3)
+for details about each option.
+
    
+
    This function uses the same default options as the
+cowboy_req:read_body(3)
+function.
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A more tuple is returned when there are more data to be read.
    
+
    An ok tuple is returned when there are no more data to be read.
    
+
    The data is always returned as a binary.
    
+
    The Req object returned in the tuple must be used for that point
+onward. It contains a more up to date representation of the request.
+For example it may have an added content-length header once the
+body has been read.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced. Replaces part_body/1,2.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Read a full part’s body
    
+
    
+
    stream_body(Req0, Acc) ->
+    case cowboy_req:read_part_body(Req0) of
+        {more, Data, Req} ->
+            stream_body(Req, << Acc/binary, Data/binary >>);
+        {ok, Data, Req} ->
+            {ok, << Acc/binary, Data/binary >>, Req}
+    end.
    
+
    
+
    Ensure a part’s body is smaller than 64KB
    
+
    
+
    {ok, Body, Req} = cowboy_req:read_part_body(Req0, #{length => 64000}).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:has_body(3),
+cowboy_req:body_length(3),
+cowboy_req:read_body(3),
+cowboy_req:read_urlencoded_body(3),
+cowboy_req:read_part(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.read_urlencoded_body/index.html
new file mode 100644
index 00000000..19363fe7
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.read_urlencoded_body/index.html
@@ -0,0 +1,261 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:read_urlencoded_body(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:read_urlencoded_body(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:read_urlencoded_body - Read and parse a urlencoded request body
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    read_urlencoded_body(Req :: cowboy_req:req())
+    -> read_urlencoded_body(Req, #{})
+
+read_urlencoded_body(Req :: cowboy_req:req(), Opts)
+    -> {ok, Body, Req}
+
+Opts :: cowboy_req:read_body_opts()
+Body :: [{Key :: binary(), Value :: binary() | true}]
    
+
    Read and parse a urlencoded request body.
    
+
    This function reads the request body and parses it as
+application/x-www-form-urlencoded. It returns a list
+of key/values.
    
+
    The urlencoded media type is used by Web browsers when
+submitting HTML forms using the POST method.
    
+
    Cowboy needs to read the full body before parsing. By default
+it will read bodies of size up to 64KB. It is possible to
+provide options to read larger bodies if required.
    
+
    Cowboy will automatically handle protocol details including
+the expect header, chunked transfer-encoding and others.
    
+
    Once the body has been read, Cowboy sets the content-length
+header if it was not previously provided.
    
+
    This function can only be called once. Calling it again will
+result in undefined behavior.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+Opts
+
    
+
    
+
    
+A map of body reading options. Please refer to
+cowboy_req:read_body(3)
+for details about each option.
+
    
+
    This function defaults the length to 64KB and the period
+to 5 seconds.
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    An ok tuple is returned containing a list of key/values found
+in the body.
    
+
    The Req object returned in the tuple must be used for that point
+onward. It contains a more up to date representation of the request.
+For example it may have an added content-length header once the
+body has been read.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced. Replaces body_qs/1,2.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Read a urlencoded body
    
+
    
+
    {ok, Body, Req} = cowboy_req:read_urlencoded_body(Req0),
+{_, Lang} = lists:keyfind(<<"lang">>, 1, Body).
    
+
    
+
    Allow large urlencoded bodies
    
+
    
+
    {ok, Body, Req} = cowboy_req:read_urlencoded_body(Req0, #{length => 1000000}).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:has_body(3),
+cowboy_req:body_length(3),
+cowboy_req:read_body(3),
+cowboy_req:read_part(3),
+cowboy_req:read_part_body(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.reply/index.html
new file mode 100644
index 00000000..bdfb7287
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.reply/index.html
@@ -0,0 +1,300 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:reply(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:reply(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:reply - Send the response
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    reply(Status, Req :: cowboy_req:req())
+    -> reply(StatusCode, #{}, Req)
+
+reply(Status, Headers, Req :: cowboy_req:req())
+    -> Req
+
+reply(Status, Headers, Body, Req :: cowboy_req:req())
+    -> Req
+
+Status  :: cowboy:http_status()
+Headers :: cowboy:http_headers()
+Body    :: cowboy_req:resp_body()
    
+
    Send the response.
    
+
    The header names must be given as lowercase binary strings.
+While header names are case insensitive, Cowboy requires them
+to be given as lowercase to function properly.
    
+
    Cowboy does not allow duplicate header names. Headers set
+by this function may overwrite those set by set_resp_header/3
+and set_resp_headers/2.
    
+
    Use cowboy_req:set_resp_cookie(3)
+instead of this function to set cookies.
    
+
    The reply/2,3 functions will send the body set previously,
+if any. The reply/4 function always sends the given body,
+overriding any previously set.
    
+
    You do not need to set the content-length header when
+sending a response body. Cowboy takes care of it automatically.
+You should however provide a content-type header.
    
+
    No further data can be transmitted after this function
+returns. This includes the push mechanism. Attempting to
+send two replies, or to push resources after a reply has
+been sent, will result in an error.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Status
+
    
+
    
+
    
+The status code for the response.
+
    
+
    
+
    
+Headers
+
    
+
    
+
    
+The response headers.
+
    
+
    
+
    
+
    Header names must be given as lowercase binary strings.
    
+
    
+
    
+Body
+
    
+
    
+
    
+The body can be either a binary value, an iolist or a
+sendfile tuple telling Cowboy to send the contents of
+a file.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A new Req object is returned.
    
+
    The returned Req object should be used from that point onward
+as it contains updated information about the state of the request.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the Req is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Reply
    
+
    
+
    Req = cowboy_req:reply(404, Req0).
    
+
    
+
    Reply with custom headers
    
+
    
+
    Req = cowboy_req:reply(401, #{
+    <<"www-authenticate">> => <<"Basic realm=\"erlang.org\"">>
+}, Req0).
    
+
    
+
    Reply with custom headers and a body
    
+
    
+
    Req = cowboy_req:reply(200, #{
+    <<"content-type">> => <<"text/plain">>
+}, "Hello world!", Req0).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:set_resp_cookie(3),
+cowboy_req:set_resp_header(3),
+cowboy_req:set_resp_headers(3),
+cowboy_req:set_resp_body(3),
+cowboy_req:inform(3),
+cowboy_req:stream_reply(3),
+cowboy_req:push(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.resp_header/index.html
new file mode 100644
index 00000000..e3e4fce8
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.resp_header/index.html
@@ -0,0 +1,248 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:resp_header(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:resp_header(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:resp_header - Response header
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    resp_header(Name, Req)          -> resp_header(Name, Req, undefined)
+resp_header(Name, Req, Default) -> binary() | Default
+
+Name    :: binary()          %% lowercase; case insensitive
+Req     :: cowboy_req:req()
+Default :: any()
    
+
    Return the value for the given response header.
    
+
    The response header must have been set previously using
+cowboy_req:set_resp_header(3) or
+cowboy_req:set_resp_headers(3).
    
+
    The header name must be given as a lowercase binary string.
+While header names are case insensitive, Cowboy requires them
+to be given as lowercase to function properly.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+Desired response header name as a lowercase binary string.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+Default
+
    
+
    
+
    
+Default value returned when the header is missing.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The header value is returned as a binary string. When the
+header is missing, the default argument is returned.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the content-type response header
    
+
    
+
    Type = cowboy_req:resp_header(<<"content-type">>, Req).
    
+
    
+
    Get the content-type response header with a default value
    
+
    
+
    Type = cowboy_req:resp_header(<<"content-type">>, Req, <<"text/html">>).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:resp_headers(3),
+cowboy_req:set_resp_header(3),
+cowboy_req:set_resp_headers(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.resp_headers/index.html
new file mode 100644
index 00000000..23593435
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.resp_headers/index.html
@@ -0,0 +1,214 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:resp_headers(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:resp_headers(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:resp_headers - Response headers
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    resp_headers(Req :: cowboy_req:req()) -> cowboy:http_headers()
    
+
    Return all response headers.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    Headers are returned as a map with keys being lowercase
+binary strings, and values as binary strings.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get all response headers
    
+
    
+
    Headers = cowboy_req:resp_headers(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:resp_header(3),
+cowboy_req:set_resp_header(3),
+cowboy_req:set_resp_headers(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.scheme/index.html
new file mode 100644
index 00000000..4ee243d9
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.scheme/index.html
@@ -0,0 +1,224 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:scheme(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:scheme(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:scheme - URI scheme
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    scheme(Req :: cowboy_req:req()) -> Scheme :: binary()
    
+
    Return the scheme of the effective request URI.
    
+
    The scheme can also be obtained using pattern matching:
    
+
    
+
    
+
    #{scheme := Scheme} = Req.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The scheme is returned as a binary. It is case insensitive.
    
+
    Cowboy will only set the scheme to <<"http">> or <<"https">>.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Redirect HTTP to HTTPS
    
+
    
+
    init(Req0=#{scheme := <<"http">>}, State) ->
+    Req = cowboy_req:reply(302, #{
+        <<"location">> => cowboy_req:uri(Req, #{scheme => <<"https">>})
+    }, Req0),
+    {ok, Req, State};
+init(Req, State) ->
+    {cowboy_rest, Req, State}.
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_body/index.html
new file mode 100644
index 00000000..cf7a2d73
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_body/index.html
@@ -0,0 +1,273 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:set_resp_body(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:set_resp_body(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:set_resp_body - Set the response body
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    set_resp_body(Body, Req :: cowboy_req:req())
+        -> Req
+
+Body :: cowboy_req:resp_body()
    
+
    Set the response body.
    
+
    The response body will be sent when a reply is initiated.
+Note that the functions stream_reply/2,3 and reply/4
+will override the body set by this function.
    
+
    This function can also be used to remove a response body
+that was set previously. To do so, simply call this function
+with an empty body.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Body
+
    
+
    
+
    
+The body can be either a binary value, an iolist or a
+sendfile tuple telling Cowboy to send the contents of
+a file.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A new Req object is returned.
    
+
    The returned Req object must be used from that point onward,
+otherwise the body will not be sent in the response.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: The function now accepts a sendfile tuple.
+
      
+
      • 
+
    • 
+
      
+2.0: The set_resp_body_fun/2,3 functions were removed.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Set the response body
    
+
    
+
    Req = cowboy_req:set_resp_body(<<"Hello world!">>, Req0).
    
+
    
+
    Set the response body as an iolist
    
+
    
+
    Req = cowboy_req:set_resp_body([
+    "<html><head><title>",
+    page_title(),
+    "</title></head><body>",
+    page_body(),
+    "</body></html>"
+], Req0).
    
+
    
+
    Tell Cowboy to send data from a file
    
+
    
+
    {ok, #file_info{size=Size}} = file:read_file_info(Filename),
+Req = cowboy_req:set_resp_body({sendfile, 0, Size, Filename}, Req0).
    
+
    
+
    Clear any previously set response body
    
+
    
+
    Req = cowboy_req:set_resp_body(<<>>, Req0).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:set_resp_header(3),
+cowboy_req:set_resp_headers(3),
+cowboy_req:reply(3),
+cowboy_req:stream_reply(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_cookie/index.html
new file mode 100644
index 00000000..87949aa7
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_cookie/index.html
@@ -0,0 +1,302 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:set_resp_cookie(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:set_resp_cookie(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:set_resp_cookie - Set a cookie
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    set_resp_cookie(Name, Value, Req :: cowboy_req:req())
+    -> set_resp_cookie(Name, Value, [], Req)
+
+set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts)
+    -> Req
+
+Name  :: binary()                  %% case sensitive
+Value :: iodata()                  %% case sensitive
+Opts  :: cow_cookie:cookie_opts()
    
+
    Set a cookie to be sent with the response.
    
+
    Note that cookie names are case sensitive.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+Cookie name.
+
    
+
    
+
    
+Value
+
    
+
    
+
    
+Cookie value.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+Opts
+
    
+
    
+
    
+Cookie options.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A new Req object is returned.
    
+
    The returned Req object must be used from that point onward,
+otherwise the cookie will not be sent in the response.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: set_resp_cookie/3 introduced as an alias to set_resp_cookie/4 with no options.
+
      
+
      • 
+
    • 
+
      
+2.0: The first argument type is now binary() instead of iodata().
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Set a session cookie
    
+
    
+
    SessionID = base64:encode(crypto:strong_rand_bytes(32)),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID, Req0).
    
+
    
+
    Set a cookie with an expiration time
    
+
    
+
    Req = cowboy_req:set_resp_cookie(<<"lang">>, <<"fr-FR">>,
+    Req0, #{max_age => 3600}).
    
+
    
+
    Delete a cookie
    
+
    
+
    Req = cowboy_req:set_resp_cookie(<<"sessionid">>, <<>>,
+    Req0, #{max_age => 0}).
    
+
    
+
    Set a cookie for a specific domain and path
    
+
    
+
    Req = cowboy_req:set_resp_cookie(<<"inaccount">>, <<"1">>,
+    Req0, #{domain => "my.example.org", path => "/account"}).
    
+
    
+
    Restrict a cookie to HTTPS
    
+
    
+
    SessionID = base64:encode(crypto:strong_rand_bytes(32)),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID,
+    Req0, #{secure => true}).
    
+
    
+
    Restrict a cookie to HTTP
    
+
    
+
    SessionID = base64:encode(crypto:strong_rand_bytes(32)),
+Req = cowboy_req:set_resp_cookie(<<"sessionid">>, SessionID,
+    Req0, #{http_only => true}).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:set_resp_header(3),
+cowboy_req:set_resp_headers(3),
+cowboy_req:reply(3),
+cowboy_req:stream_reply(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_header/index.html
new file mode 100644
index 00000000..44fb3122
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_header/index.html
@@ -0,0 +1,256 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:set_resp_header(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:set_resp_header(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:set_resp_header - Set a response header
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    set_resp_header(Name, Value, Req :: cowboy_req:req())
+        -> Req
+
+Name  :: binary()  %% lowercase; case insensitive
+Value :: iodata()  %% case depends on header
    
+
    Set a header to be sent with the response.
    
+
    The header name must be given as a lowercase binary string.
+While header names are case insensitive, Cowboy requires them
+to be given as lowercase to function properly.
    
+
    Cowboy does not allow duplicate header names. Headers set
+by this function may be overwritten by those set from the
+reply functions.
    
+
    Use cowboy_req:set_resp_cookie(3)
+instead of this function to set cookies.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Name
+
    
+
    
+
    
+Header name as a lowercase binary string.
+
    
+
    
+
    
+Value
+
    
+
    
+
    
+Header value.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A new Req object is returned.
    
+
    The returned Req object must be used from that point onward,
+otherwise the header will not be sent in the response.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Set a header in the response
    
+
    
+
    Req = cowboy_req:set_resp_header(<<"allow">>, "GET", Req0).
    
+
    
+
    Construct a header using iolists
    
+
    
+
    Req = cowboy_req:set_resp_header(<<"allow">>,
+    [allowed_methods(), ", OPTIONS"], Req0).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:set_resp_cookie(3),
+cowboy_req:set_resp_headers(3),
+cowboy_req:has_resp_header(3),
+cowboy_req:resp_header(3),
+cowboy_req:resp_headers(3),
+cowboy_req:delete_resp_header(3),
+cowboy_req:reply(3),
+cowboy_req:stream_reply(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_headers/index.html
new file mode 100644
index 00000000..48828ae9
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_headers/index.html
@@ -0,0 +1,244 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:set_resp_headers(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:set_resp_headers(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:set_resp_headers - Set several response headers
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    set_resp_headers(Headers, Req :: cowboy_req:req())
+    -> Req
+
+Headers :: cowboy:http_headers()
    
+
    Set several headers to be sent with the response.
    
+
    The header name must be given as a lowercase binary string.
+While header names are case insensitive, Cowboy requires them
+to be given as lowercase to function properly.
    
+
    Cowboy does not allow duplicate header names. Headers set
+by this function may be overwritten by those set from the
+reply functions. Likewise, headers set by this function may
+overwrite headers that were set previously.
    
+
    Use cowboy_req:set_resp_cookie(3)
+instead of this function to set cookies.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Headers
+
    
+
    
+
    
+Headers as a map with keys being lowercase binary strings,
+and values as binary strings.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A new Req object is returned.
    
+
    The returned Req object must be used from that point onward,
+otherwise the headers will not be sent in the response.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Set several response headers
    
+
    
+
    Req = cowboy_req:set_resp_headers(#{
+    <<"content-type">>     => <<"text/html">>,
+    <<"content-encoding">> => <<"gzip">>
+}, Req0).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:set_resp_cookie(3),
+cowboy_req:set_resp_header(3),
+cowboy_req:has_resp_header(3),
+cowboy_req:resp_header(3),
+cowboy_req:resp_headers(3),
+cowboy_req:delete_resp_header(3),
+cowboy_req:reply(3),
+cowboy_req:stream_reply(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.sock/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.sock/index.html
new file mode 100644
index 00000000..b22be2e9
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.sock/index.html
@@ -0,0 +1,221 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:sock(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:sock(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:sock - Socket address and port
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    sock(Req :: cowboy_req:req()) -> Info
+
+Info :: {inet:ip_address(), inet:port_number()}
    
+
    Return the socket’s IP address and port number.
    
+
    The socket information can also be obtained using pattern matching:
    
+
    
+
    
+
    #{sock := {IP, Port}} = Req.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The socket’s local IP address and port number.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the socket’s IP address and port number.
    
+
    
+
    {IP, Port} = cowboy_req:sock(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:peer(3),
+cowboy_req:cert(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.stream_body/index.html
new file mode 100644
index 00000000..544048a4
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.stream_body/index.html
@@ -0,0 +1,251 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:stream_body(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:stream_body(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:stream_body - Stream the response body
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    stream_body(Data, IsFin, Req :: cowboy_req:req()) -> ok
+
+Data  :: iodata()
+IsFin :: fin | nofin
    
+
    Stream the response body.
    
+
    This function may be called as many times as needed after
+initiating a response using the
+cowboy_req:stream_reply(3)
+function.
    
+
    The second argument indicates if this call is the final
+call. Use the nofin value until you know no more data
+will be sent. The final call should use fin (possibly
+with an empty data value).
    
+
    Note that not using fin for the final call is not an
+error; Cowboy will take care of it when the request
+handler terminates if needed. Depending on the resource
+it may however be more efficient to do it as early as
+possible.
    
+
    You do not need to handle HEAD requests specifically as
+Cowboy will ensure no data is sent when you call this function.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Data
+
    
+
    
+
    
+The data to be sent.
+
    
+
    
+
    
+IsFin
+
    
+
    
+
    
+A flag indicating whether this is the final piece of data
+to be sent.
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The atom ok is always returned. It can be safely ignored.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Function introduced. Replaces chunk/2.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Stream the response body
    
+
    
+
    Req = cowboy_req:stream_reply(200, #{
+    <<"content-type">> => <<"text/plain">>
+}, Req0),
+cowboy_req:stream_body(<<"Hello\n">>, nofin, Req),
+timer:sleep(1000),
+cowboy_req:stream_body(<<"World!\n">>, fin, Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:stream_reply(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.stream_reply/index.html
new file mode 100644
index 00000000..19f8d9ef
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.stream_reply/index.html
@@ -0,0 +1,284 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:stream_reply(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:stream_reply(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:stream_reply - Send the response headers
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    stream_reply(Status, Req :: cowboy_req:req())
+    -> stream_reply(StatusCode, #{}, Req)
+
+stream_reply(Status, Headers, Req :: cowboy_req:req())
+    -> Req
+
+Status  :: cowboy:http_status()
+Headers :: cowboy:http_headers()
    
+
    Send the response headers.
    
+
    The header names must be given as lowercase binary strings.
+While header names are case insensitive, Cowboy requires them
+to be given as lowercase to function properly.
    
+
    Cowboy does not allow duplicate header names. Headers set
+by this function may overwrite those set by set_resp_header/3.
    
+
    Use cowboy_req:set_resp_cookie(3)
+instead of this function to set cookies.
    
+
    If a response body was set before calling this function,
+it will not be sent.
    
+
    Use cowboy_req:stream_body(3)
+to stream the response body.
    
+
    You may want to set the content-length header when using
+this function, if it is known in advance. This will allow
+clients using HTTP/2 and HTTP/1.0 to process the response
+more efficiently.
    
+
    The streaming method varies depending on the protocol being
+used. HTTP/2 will use the usual DATA frames. HTTP/1.1 will
+use chunked transfer-encoding. HTTP/1.0 will send the body
+unmodified and close the connection at the end if no
+content-length was set.
    
+
    It is not possible to push resources after this function
+returns. Any attempt will result in an error.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Status
+
    
+
    
+
    
+The status code for the response.
+
    
+
    
+
    
+Headers
+
    
+
    
+
    
+The response headers.
+
    
+
    
+
    
+
    Header names must be given as lowercase binary strings.
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    A new Req object is returned.
    
+
    The returned Req object must be used from that point onward
+in order to be able to stream the response body.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the Req is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+2.0: Function introduced. Replaces chunked_reply/1,2.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Initiate the response
    
+
    
+
    Req = cowboy_req:stream_reply(200, Req0).
    
+
    
+
    Stream the response with custom headers
    
+
    
+
    Req = cowboy_req:stream_reply(200, #{
+    <<"content-type">> => <<"text/plain">>
+}, Req0),
+cowboy_req:stream_body(<<"Hello\n">>, nofin, Req),
+timer:sleep(1000),
+cowboy_req:stream_body(<<"World!\n">>, fin, Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:set_resp_cookie(3),
+cowboy_req:set_resp_header(3),
+cowboy_req:set_resp_headers(3),
+cowboy_req:inform(3),
+cowboy_req:reply(3),
+cowboy_req:stream_body(3),
+cowboy_req:push(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.uri/index.html
new file mode 100644
index 00000000..caf140e8
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.uri/index.html
@@ -0,0 +1,312 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:uri(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:uri(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:uri - Reconstructed URI
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    uri(Req :: cowboy_req:req())       -> uri(Req, #{})
+uri(Req :: cowboy_req:req(), Opts) -> URI :: iodata()
+
+Opts :: #{
+    scheme   => iodata()           | undefined,
+    host     => iodata()           | undefined,
+    port     => inet:port_number() | undefined,
+    path     => iodata()           | undefined,
+    qs       => iodata()           | undefined,
+    fragment => iodata()           | undefined
+}
    
+
    Reconstruct the effective request URI, optionally modifying components.
    
+
    By default Cowboy will build a URI using the components found
+in the request. Options allow disabling or replacing individual
+components.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+Opts
+
    
+
    
+
    
+Map for overriding individual components.
+
    
+
    To replace a component, provide its new value as a binary
+string or an iolist. To disable a component, set its value
+to undefined.
    
+
    As this function always returns a valid URI, there are some
+things to note:
    
+
      
+
    • 
+
      
+Disabling the host also disables the scheme and port.
+
      
+
      • 
+
    • 
+
      
+There is no fragment component by default as these are
+      not sent with the request.
+
      
+
      • 
+
    • 
+
      
+The port number may not appear in the resulting URI if
+      it is the default port for the given scheme (http: 80; https: 443).
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The reconstructed URI is returned as an iolist or a binary string.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Individual components can be replaced or disabled.
+
      
+
      • 
+
    • 
+
      
+2.0: Only the URI is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+2.0: Function introduced. Replaces host_url/1 and url/1.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    With an effective request URI http://example.org/path/to/res?edit=1
+we can have:
    
+
    
+
    Protocol relative form
    
+
    
+
    %% //example.org/path/to/res?edit=1
+cowboy_req:uri(Req, #{scheme => undefined}).
    
+
    
+
    Serialized origin for use in the origin header
    
+
    
+
    %% http://example.org
+cowboy_req:uri(Req, #{path => undefined, qs => undefined}).
    
+
    
+
    HTTP/1.1 origin form (path and query string only)
    
+
    
+
    %% /path/to/res?edit=1
+cowboy_req:uri(Req, #{host => undefined}).
    
+
    
+
    Add a fragment to the URI
    
+
    
+
    %% http://example.org/path/to/res?edit=1#errors
+cowboy_req:uri(Req, #{fragment => <<"errors">>}).
    
+
    
+
    Ensure the scheme is HTTPS
    
+
    
+
    %% https://example.org/path/to/res?edit=1
+cowboy_req:uri(Req, #{scheme => <<"https">>}).
    
+
    
+
    Convert the URI to a binary string
    
+
    
+
    iolist_to_binary(cowboy_req:uri(Req)).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3),
+cowboy_req:scheme(3),
+cowboy_req:host(3),
+cowboy_req:port(3),
+cowboy_req:path(3),
+cowboy_req:qs(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.version/index.html
new file mode 100644
index 00000000..d0747cd4
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req.version/index.html
@@ -0,0 +1,223 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req:version(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req:version(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req:version - HTTP version
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    version(Req :: cowboy_req:req()) -> Version :: cowboy:http_version()
    
+
    Return the HTTP version used for the request.
    
+
    The version can also be obtained using pattern matching:
    
+
    
+
    
+
    #{version := Version} = Req.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Req
+
    
+
    
+
    
+The Req object.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    The HTTP version used for the request is returned as an
+atom. It is provided for informative purposes only.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Only the version is returned, it is no longer wrapped in a tuple.
+
      
+
      • 
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Get the HTTP version
    
+
    
+
    Version = cowboy_req:version(Req).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_req(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_req/index.html b/docs/en/cowboy/2.1/manual/cowboy_req/index.html
new file mode 100644
index 00000000..4076b2b1
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_req/index.html
@@ -0,0 +1,544 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_req(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_req(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_req - HTTP request and response
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The module cowboy_req provides functions to access, manipulate
+and respond to requests.
    
+
    There are four types of functions in this module. They can be
+differentiated by their name and their return type:
    
+
    
+
++++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
    



     Type          Name pattern               Return type
    access
    no verb, parse_*, match_*
    Value
    question
    has_*
    boolean()
    modification
    set_*
    Req
    action
    any other verb
    ok | {Result, Value, Req}
    
+
    
+
    Any Req returned must be used in place of the one passed as
+argument. Functions that perform an action in particular write
+state in the Req object to make sure you are using the function
+correctly. For example, it’s only possible to send one response,
+and to read the body once.
    
+
    
+
    
+
    
+
    Exports
    
+
    
+
    Connection:
    
+
    
+
    Raw request:
    
+
    
+
    Processed request:
    
+
    
+
    Request body:
    
+
    
+
    Response:
    
+
    
+
    
+
    
+
    
+
    Types
    
+
    
+
    
+
    push_opts()
    
+
    
+
    
+
    push_opts() :: #{
+    method => binary(),            %% case sensitive
+    scheme => binary(),            %% lowercase; case insensitive
+    host   => binary(),            %% lowercase; case insensitive
+    port   => inet:port_number(),
+    qs     => binary()             %% case sensitive
+}
    
+
    Push options.
    
+
    By default, Cowboy will use the GET method, an empty query string,
+and take the scheme, host and port directly from the current
+request’s URI.
    
+
    
+
    
+
    read_body_opts()
    
+
    
+
    
+
    read_body_opts() :: #{
+    length  => non_neg_integer(),
+    period  => non_neg_integer(),
+    timeout => timeout()
+}
    
+
    Body reading options.
    
+
    The defaults are function-specific.
    
+
    
+
    
+
    req()
    
+
    
+
    
+
    req() :: #{
+    method  := binary(),               %% case sensitive
+    version := cowboy:http_version() | atom(),
+    scheme  := binary(),               %% lowercase; case insensitive
+    host    := binary(),               %% lowercase; case insensitive
+    port    := inet:port_number(),
+    path    := binary(),               %% case sensitive
+    qs      := binary(),               %% case sensitive
+    headers := cowboy:http_headers(),
+    peer    := {inet:ip_address(), inet:port_number()},
+    sock    := {inet:ip_address(), inet:port_number()},
+    cert    := binary() | undefined
+}
    
+
    The Req object.
    
+
    Contains information about the request and response. While
+some fields are publicly documented, others aren’t and shouldn’t
+be used.
    
+
    You may add custom fields if required. Make sure to namespace
+them by prepending an underscore and the name of your application:
    
+
    
+
    Setting a custom field
    
+
    
+
    Req#{_myapp_auth_method => pubkey}.
    
+
    
+
    
+
    resp_body()
    
+
    
+
    
+
    resp_body() :: iodata()
+    | {sendfile, Offset, Length, Filename}
+
+Offset   :: non_neg_integer()
+Length   :: non_neg_integer()
+Filename :: file:name_all()
    
+
    Response body.
    
+
    It can take two forms: the actual data to be sent or a
+tuple indicating which file to send.
    
+
    When sending data directly, the type is either a binary or
+an iolist. Iolists are an efficient way to build output.
+Instead of concatenating strings or binaries, you can simply
+build a list containing the fragments you want to send in the
+order they should be sent:
    
+
    
+
    Example iolists usage
    
+
    
+
    1> RespBody = ["Hello ", [<<"world">>, $!]].
+["Hello ",[<<"world">>,33]]
+2> io:format("~s~n", [RespBody]).
+Hello world!
    
+
    Note that the length must be greater than zero for any data
+to be sent. Cowboy will send an empty body when the length
+is zero.
    
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_rest/index.html b/docs/en/cowboy/2.1/manual/cowboy_rest/index.html
new file mode 100644
index 00000000..e4fc26c4
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_rest/index.html
@@ -0,0 +1,786 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_rest(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_rest(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_rest - REST handlers
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The module cowboy_rest implements the HTTP state machine.
    
+
    Implementing REST handlers is not enough to provide a REST
+interface; this interface must also follow the REST
+constraints including HATEOAS (hypermedia as the engine
+of application state).
    
+
    
+
    
+
    
+
    Callbacks
    
+
    
+
    REST handlers implement the following interface:
    
+
    
+
    
+
    init(Req, State)
+    -> {cowboy_rest, Req, State}
+
+Callback(Req, State)
+    -> {Result, Req, State}
+     | {stop, Req, State}
+     | {{switch_handler, Module}, Req, State}
+     | {{switch_handler, Module, Opts}, Req, State}
+
+terminate(Reason, Req, State) -> ok  %% optional
+
+Req    :: cowboy_req:req()
+State  :: any()
+Module :: module()
+Opts   :: any()
+Reason :: normal
+        | {crash, error | exit | throw, any()}
+
+Callback - see below
+Result   - see below
+Default  - see below
    
+
    The init/2 callback is common to all handlers. To switch
+to the REST handler behavior, it must return cowboy_rest
+as the first element of the tuple.
    
+
    The Callback/2 above represents all the REST-specific
+callbacks. They are described in the following section
+of this manual. REST-specific callbacks differ by their
+name, semantics, result and default values. The default
+value is the one used when the callback has not been
+implemented. They otherwise all follow the same interface.
    
+
    The stop tuple can be returned to stop REST processing.
+If no response was sent before then, Cowboy will send a
+204 No Content. The stop tuple can be returned from
+any callback, excluding expires, generate_etag,
+last_modified and variances.
    
+
    A switch_handler tuple can be returned from these same
+callbacks to stop REST processing and switch to a different
+handler type. This is very useful to, for example, to stream
+the response body.
    
+
    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:
    
+
    
+
    
+normal
+
    
+
    
+
    
+    The handler terminated normally.
+
    
+
    
+
    
+{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.
+
    
+
    
+
    
+
    
+
    
+
    
+
    REST callbacks
    
+
    
+
    
+
    AcceptCallback
    
+
    
+
    
+
    AcceptCallback(Req, State) -> {Result, Req, State}
+
+Result  :: true | {true, URI :: iodata()} | false}
+Default  - crash
    
+
    Process the request body.
    
+
    This function should create or update the resource using the
+request body.
    
+
    For PUT requests, the body is a representation of the resource
+that is being created or replaced.
    
+
    For POST requests, the body is typically application-specific
+instructions on how to process the request, but it may also
+be a representation of the resource. When creating a new
+resource with POST at a different location, return {true, URI}
+with URI the new location.
    
+
    For PATCH requests, the body is a series of instructions on
+how to update the resource. Patch files or JSON Patch are
+examples of such media types.
    
+
    A response body may be sent. The appropriate media type, charset
+and language for the response can be retrieved from the Req
+object using the media_type, charset and language keys,
+respectively. The body can be set using
+cowboy_req:set_resp_body(3).
    
+
    
+
    
+
    allowed_methods
    
+
    
+
    
+
    allowed_methods(Req, State) -> {Result, Req, State}
+
+Result  :: [binary()]  %% case sensitive
+Default :: [<<"GET">>, <<"HEAD">>, <<"OPTIONS">>]
    
+
    Return the list of allowed methods.
    
+
    
+
    
+
    allow_missing_post
    
+
    
+
    
+
    allow_missing_post(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: true
    
+
    Return whether POST is allowed when the resource doesn’t exist.
    
+
    Returning true here means that a new resource will be
+created. The URI for the newly created resource should be
+returned from the AcceptCallback function.
    
+
    
+
    
+
    charsets_provided
    
+
    
+
    
+
    charsets_provided(Req, State) -> {Result, Req, State}
+
+Result  :: [binary()]  %% lowercase; case insensitive
+Default  - skip this step
    
+
    Return the list of charsets the resource provides in order
+of preference.
    
+
    During content negotiation Cowboy will pick the most
+appropriate charset for the client. The client advertises
+charsets it prefers with the accept-charset header. When
+that header is missing, Cowboy picks the first charset
+from the resource.
    
+
    Cowboy will add the negotiated charset to the Req object
+after this step completes:
    
+
    
+
    
+
    req() :: #{
+    charset => binary()  %% lowercase; case insensitive
+}
    
+
    
+
    
+
    content_types_accepted
    
+
    
+
    
+
    content_types_accepted(Req, State) -> {Result, Req, State}
+
+Result     :: [{binary() | ParsedMime, AcceptCallback :: atom()}]
+ParsedMime :: {Type :: binary(), SubType :: binary(), '*' | Params}
+Params     :: [{Key :: binary(), Value :: binary()}]
+
+Default     - crash
    
+
    Return the list of media types the resource accepts in
+order of preference.
    
+
    A media type is made of different parts. The media type
+text/html;charset=utf-8 is of type text, subtype html
+and has a single parameter charset with value utf-8.
    
+
    Cowboy will match the content-type request header against
+the media types the server accepts and select the appropriate
+callback. When that header is missing, or when the server does not
+accept this media type, the request fails and an error response
+is returned. Cowboy will execute the callback immediately otherwise.
    
+
    An empty parameters list [] means that no parameters will be
+accepted. When any parameter is acceptable, the tuple form
+should be used with parameters as the atom '*'.
    
+
    Cowboy treats all parameters as case sensitive, except for the
+charset parameter, which is known to be case insensitive. You
+should therefore always provide the charset as a lowercase
+binary string.
    
+
    
+
    
+
    content_types_provided
    
+
    
+
    
+
    content_types_provided(Req, State) -> {Result, Req, State}
+
+Result     :: [{binary() | ParsedMime, ProvideCallback :: atom()}]
+ParsedMime :: {Type :: binary(), SubType :: binary(), '*' | Params}
+Params     :: [{Key :: binary(), Value :: binary()}]
+
+Default     - [{{ <<"text">>, <<"html">>, '*'}, to_html}]
    
+
    Return the list of media types the resource provides in
+order of preference.
    
+
    A media type is made of different parts. The media type
+text/html;charset=utf-8 is of type text, subtype html
+and has a single parameter charset with value utf-8.
    
+
    During content negotiation Cowboy will pick the most appropriate
+media type for the client. The client advertises media types it
+prefers with the accept header. When that header is missing,
+the content negotiation fails and an error response is returned.
    
+
    The callback given for the selected media type will be called
+at the end of the execution of GET and HEAD requests when a
+representation must be sent to the client.
    
+
    An empty parameters list [] means that no parameters will be
+accepted. When any parameter is acceptable, the tuple form
+should be used with parameters as the atom '*'.
    
+
    Cowboy treats all parameters as case sensitive, except for the
+charset parameter, which is known to be case insensitive. You
+should therefore always provide the charset as a lowercase
+binary string.
    
+
    Cowboy will add the negotiated media_type to the Req object
+after this step completes:
    
+
    
+
    
+
    req() :: #{
+    media_type => ParsedMime
+}
    
+
    
+
    
+
    delete_completed
    
+
    
+
    
+
    delete_completed(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: true
    
+
    Return whether the resource has been fully deleted from the
+system, including from any internal cache.
    
+
    Returning false will result in a 202 Accepted response
+being sent instead of a 200 OK or 204 No Content.
    
+
    
+
    
+
    delete_resource
    
+
    
+
    
+
    delete_resource(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: false
    
+
    Delete the resource.
    
+
    Cowboy will send an error response when this function
+returns false.
    
+
    
+
    
+
    expires
    
+
    
+
    
+
    expires(Req, State) -> {Result, Req, State}
+
+Result  :: calendar:datetime() | binary() | undefined
+Default :: undefined
    
+
    Return the resource’s expiration date.
    
+
    
+
    
+
    forbidden
    
+
    
+
    
+
    forbidden(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: false
    
+
    Return whether access to the resource is forbidden.
    
+
    A 403 Forbidden response will be sent if this
+function returns true. This status code means that
+access is forbidden regardless of authentication,
+and that the request shouldn’t be repeated.
    
+
    
+
    
+
    generate_etag
    
+
    
+
    
+
    generate_etag(Req, State) -> {Result, Req, State}
+
+Result  :: binary() | {weak | strong, binary()}
+Default  - no etag value
    
+
    Return the entity tag of the resource.
    
+
    When a binary is returned, the value is automatically
+parsed to a tuple. The binary must be in the same
+format as the etag header, including quotes.
    
+
    
+
    
+
    is_authorized
    
+
    
+
    
+
    is_authorized(Req, State) -> {Result, Req, State}
+
+Result  :: true | {false, AuthHeader :: iodata()}
+Default  - true
    
+
    Return whether the user is authorized to perform the action.
    
+
    This function should be used to perform any necessary
+authentication of the user before attempting to perform
+any action on the resource.
    
+
    When authentication fails, the AuthHeader value will
+be sent in the www-authenticate header for the
+401 Unauthorized response.
    
+
    
+
    
+
    is_conflict
    
+
    
+
    
+
    is_conflict(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: false
    
+
    Return whether the PUT request results in a conflict.
    
+
    A 409 Conflict response is sent when true.
    
+
    
+
    
+
    known_methods
    
+
    
+
    
+
    known_methods(Req, State) -> {Result, Req, State}
+
+Result  :: [binary()]  %% case sensitive
+Default :: [<<"GET">>, <<"HEAD">>, <<"POST">>, <<"PUT">>,
+            <<"PATCH">>, <<"DELETE">>, <<"OPTIONS">>]
    
+
    Return the list of known methods.
    
+
    The full list of methods known by the server should be
+returned, regardless of their use in the resource.
    
+
    The default value lists the methods Cowboy knows and
+implement in cowboy_rest.
    
+
    
+
    
+
    languages_provided
    
+
    
+
    
+
    languages_provided(Req, State) -> {Result, Req, State}
+
+Result  :: [binary()]  %% lowercase; case insensitive
+Default  - skip this step
    
+
    Return the list of languages the resource provides in order
+of preference.
    
+
    During content negotiation Cowboy will pick the most
+appropriate language for the client. The client advertises
+languages it prefers with the accept-language header. When
+that header is missing, Cowboy picks the first language
+from the resource.
    
+
    Cowboy will add the negotiated language to the Req object
+after this step completes:
    
+
    
+
    
+
    req() :: #{
+    language => binary()  %% lowercase; case insensitive
+}
    
+
    
+
    
+
    last_modified
    
+
    
+
    
+
    last_modified(Req, State) -> {Result, Req, State}
+
+Result  :: calendar:datetime()
+Default  - no last modified value
    
+
    Return the resource’s last modification date.
    
+
    This date will be used to test against the if-modified-since
+and if-unmodified-since headers, and sent as the last-modified
+header in the response to GET and HEAD requests.
    
+
    
+
    
+
    malformed_request
    
+
    
+
    
+
    malformed_request(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: false
    
+
    Return whether the request is malformed.
    
+
    A request is malformed when a component required by the
+resource is invalid. This may include the query string
+or individual headers. They should be parsed and validated
+in this function. The body should not be read at this point.
    
+
    
+
    
+
    moved_permanently
    
+
    
+
    
+
    moved_permanently(Req, State) -> {Result, Req, State}
+
+Result  :: {true, URI :: iodata()} | false
+Default :: false
    
+
    Return whether the resource was permanently moved, and
+what its new location is.
    
+
    
+
    
+
    moved_temporarily
    
+
    
+
    
+
    moved_temporarily(Req, State) -> {Result, Req, State}
+
+Result  :: {true, URI :: iodata()} | false
+Default :: false
    
+
    Return whether the resource was temporarily moved, and
+what its new location is.
    
+
    
+
    
+
    multiple_choices
    
+
    
+
    
+
    multiple_choices(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: false
    
+
    Return whether the client should engage in reactive
+negotiation.
    
+
    Return true when the server has multiple representations
+of a resource, each with their specific identifier, but is
+unable to determine which is best for the client. For
+example an image might have different sizes and the server
+is unable to determine the capabilities of the client.
    
+
    When returning true the server should send a body with
+links to the different representations. If the server has
+a preferred representation it can send its link inside a
+location header.
    
+
    
+
    
+
    options
    
+
    
+
    
+
    options(Req, State) -> {ok, Req, State}
    
+
    Respond to an OPTIONS request.
    
+
    The response should inform the client the communication
+options available for this resource. By default Cowboy
+will send a 200 OK response with the allow header set.
    
+
    
+
    
+
    previously_existed
    
+
    
+
    
+
    previously_existed(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: false
    
+
    Return whether the resource existed previously.
    
+
    
+
    
+
    ProvideCallback
    
+
    
+
    
+
    ProvideCallback(Req, State) -> {Result, Req, State}
+
+Result  :: cowboy_req:resp_body()
+Default  - crash
    
+
    Return the response body.
    
+
    The response body can be provided either as the actual data
+to be sent or a tuple indicating which file to send.
    
+
    This function is called for both GET and HEAD requests. For
+the latter the body is not sent, however.
    
+
    Note that there used to be a way to stream the response body.
+It was temporarily removed and will be added back in a later
+release.
    
+
    
+
    
+
    resource_exists
    
+
    
+
    
+
    resource_exists(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: true
    
+
    Return whether the resource exists.
    
+
    
+
    
+
    service_available
    
+
    
+
    
+
    service_available(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: true
    
+
    Return whether the service is available.
    
+
    A 503 Service Unavailable response will be sent when this
+function returns false.
    
+
    
+
    
+
    uri_too_long
    
+
    
+
    
+
    uri_too_long(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: false
    
+
    Return whether the requested URI is too long.
    
+
    This function can be used to further restrict the length
+of the URI for this specific resource.
    
+
    
+
    
+
    valid_content_headers
    
+
    
+
    
+
    valid_content_headers(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: true
    
+
    Return whether the content headers are valid.
    
+
    This callback can be used to reject requests that have
+invalid content header values, for example an unsupported
+content-encoding.
    
+
    
+
    
+
    valid_entity_length
    
+
    
+
    
+
    valid_entity_length(Req, State) -> {Result, Req, State}
+
+Result  :: boolean()
+Default :: true
    
+
    Return whether the request body length is within acceptable boundaries.
    
+
    A 413 Request Entity Too Large response will be sent if this
+function returns false.
    
+
    
+
    
+
    variances
    
+
    
+
    
+
    variances(Req, State) -> {Result, Req, State}
+
+Result  :: [binary()]  %% case insensitive
+Default :: []
    
+
    Return the list of request headers that affect the
+representation of the resource.
    
+
    Cowboy automatically adds the accept, accept-charset and
+accept-language headers when necessary.
    
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7),
+cowboy_handler(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.1/manual/cowboy_router.compile/index.html
new file mode 100644
index 00000000..b119608c
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_router.compile/index.html
@@ -0,0 +1,222 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_router:compile(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_router:compile(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_router:compile - Compile routes to the resources
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    
+
    
+
    compile(cowboy_router:routes()) -> cowboy_router:dispatch_rules()
    
+
    Compile routes to the resources.
    
+
    Takes a human readable list of routes and transforms it
+into a form more efficient to process.
    
+
    
+
    
+
    
+
    Arguments
    
+
    
+
    
+
    
+Routes
+
    
+
    
+
    
+Human readable list of routes.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Return value
    
+
    
+
    An opaque dispatch rules value is returned. This value
+must be given to Cowboy as a middleware environment value.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+1.0: Function introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Compile routes and start a listener
    
+
    
+
    Dispatch = cowboy_router:compile([
+    {'_', [
+        {"/", toppage_h, []},
+        {"/[...], cowboy_static, {priv_dir, my_example_app, ""}}
+    ]}
+]),
+
+{ok, _} = cowboy:start_clear(example, [{port, 8080}], #{
+    env => #{dispatch => Dispatch}
+}).
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy_router(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_router/index.html b/docs/en/cowboy/2.1/manual/cowboy_router/index.html
new file mode 100644
index 00000000..db9794b3
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_router/index.html
@@ -0,0 +1,245 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_router(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_router(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_router - Router middleware
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The cowboy_router middleware maps the requested host and
+path to the handler to be used for processing the request.
    
+
    The router takes the dispatch rules as input from the
+middleware environment. Dispatch rules are generated by
+calling the
+cowboy_router:compile(3)
+function.
    
+
    When a route matches, the router sets the handler and
+handler_opts middleware environment values containing
+the handler module and initial state, respectively.
    
+
    The router will stop execution when no route matches.
+It will send a 400 response if no host was found, and
+a 404 response otherwise.
    
+
    
+
    
+
    
+
    Exports
    
+
    
+
    
+
    
+
    
+
    
+
    Types
    
+
    
+
    
+
    bindings()
    
+
    
+
    
+
    bindings() :: #{atom() => any()}
    
+
    Bindings found during routing.
    
+
    
+
    
+
    dispatch_rules()
    
+
    Opaque type containing the compiled routes.
    
+
    
+
    
+
    routes()
    
+
    
+
    
+
    routes() = [
+    {Host, PathList} |
+    {Host, Fields, PathList}
+]
+
+PathList :: [
+    {Path, Handler, InitialState} |
+    {Path, Fields, Handler, InitialState}
+]
+
+Host         :: '_' | iodata()
+Path         :: '_' | iodata()
+Fields       :: cowboy:fields()
+Handler      :: module()
+InitialState :: any()
    
+
    Human readable list of routes to handlers.
    
+
    Cowboy uses this list to map hosts and paths, optionally
+augmented with constraints applied to the bindings, to
+handler modules.
    
+
    The syntax for routes is currently defined in the user guide.
    
+
    
+
    
+
    tokens()
    
+
    
+
    
+
    tokens() :: [binary()]
    
+
    List of host_info and path_info tokens that were found
+using the ... syntax.
    
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7),
+cowboy_req:binding(3),
+cowboy_req:bindings(3),
+cowboy_req:host_info(3),
+cowboy_req:path_info(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_static/index.html b/docs/en/cowboy/2.1/manual/cowboy_static/index.html
new file mode 100644
index 00000000..3833700f
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_static/index.html
@@ -0,0 +1,310 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_static(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_static(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_static - Static file handler
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The module cowboy_static implements file serving capabilities
+using the REST semantics provided by cowboy_rest.
    
+
    The static file handler is a pre-written handler coming with
+Cowboy. To serve files, use it in your routes.
    
+
    
+
    
+
    
+
    Options
    
+
    
+
    
+
    
+
    opts() :: {priv_file, App, Path}
+        | {priv_file, App, Path, Extra}
+        | {file, Path}
+        | {file, Path, Extra}
+        | {priv_dir, App, Path}
+        | {priv_dir, App, Path, Extra}
+        | {dir, Path}
+        | {dir, Path, Extra}
+
+App        :: atom()
+Path       :: binary() | string()
+Extra      :: [Etag | Mimetypes]
+
+Etag       :: {etag, module(), function()}
+            | {etag, false}
+
+Mimetypes  :: {mimetypes, module(), function()}
+            | {mimetypes, binary() | ParsedMime}
+
+ParsedMime :: {Type :: binary(), SubType :: binary(), Params}
+Params     :: [{Key :: binary(), Value :: binary()}]
    
+
    Static handler configuration.
    
+
    
+
    
+priv_file
+
    
+
    
+
    
+Send a file.
+
    
+
    The path is relative to the given application’s private
+directory.
    
+
    
+
    
+file
+
    
+
    
+
    
+Send a file.
+
    
+
    The path is either absolute or relative to the Erlang node’s
+current directory.
    
+
    
+
    
+priv_dir
+
    
+
    
+
    
+Recursively serve files from a directory.
+
    
+
    The path is relative to the given application’s private
+directory.
    
+
    
+
    
+dir
+
    
+
    
+
    
+Recursively serve files from a directory.
+
    
+
    The path is either absolute or relative to the Erlang node’s
+current directory.
    
+
    
+
    
+
    The extra options allow you to define how the etag should be
+calculated and how the MIME type of files should be detected.
    
+
    By default the static handler will generate an etag based
+on the size and modification time of the file. You may disable
+the etag entirely with {etag, false} or provide a module
+and function that will be called when needed:
    
+
    
+
    
+
    generate_etag(Path, Size, Mtime) -> {strong | weak, binary()}
+
+Path  :: binary()
+Size  :: non_neg_integer()
+Mtime :: file:date_time()
    
+
    By default the static handler will detect Web-related MIME types
+by looking at the file extension. You can provide a specific
+MIME type that will always be used, or a module and function that
+will be called when needed:
    
+
    
+
    
+
    detect_mimetype(Path) -> ParsedMime
+
+Path       :: binary()
+ParsedMime :: {Type :: binary(), SubType :: binary(), Params}
+Params     :: [{Key :: binary(), Value :: binary()}]
    
+
    Cowboy comes with two such functions; the default function
+cow_mimetypes:web/1, and a second function generated from
+the Apache mime.types file, cow_mimetypes:all/1.
    
+
    The MIME type function should return
+{<<"application">>, <<"octet-stream">>, []}
+when it fails to detect a file’s MIME type.
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+1.0: Handler introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    Examples
    
+
    
+
    
+
    Custom etag function
    
+
    
+
    generate_etag(Path, Size, Mtime) ->
+    {strong, integer_to_binary(
+        erlang:phash2({Path, Size, Mtime}, 16#ffffffff))}.
    
+
    
+
    Custom MIME type function
    
+
    
+
    always_octet_stream(_Path) ->
+    case filename:extension(Path) of
+        <<".erl">> -> {<<"text">>, <<"plain">>, []};
+        _ -> {<<"application">>, <<"octet-stream">>, []}
+    end.
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7),
+cowboy_router(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_stream/index.html b/docs/en/cowboy/2.1/manual/cowboy_stream/index.html
new file mode 100644
index 00000000..2dd1200b
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_stream/index.html
@@ -0,0 +1,546 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_stream(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_stream(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_handler - Stream handlers
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The module cowboy_stream defines a callback interface
+and a protocol for handling HTTP streams.
    
+
    An HTTP request and its associated response is called
+a stream. A connection may have many streams. In HTTP/1.1
+they are executed sequentially, while in HTTP/2 they are
+executed concurrently.
    
+
    Cowboy calls the stream handler for nearly all events
+related to a stream. Exceptions vary depending on the
+protocol.
    
+
    Extra care must be taken when implementing stream handlers
+to ensure compatibility. While some modification of the
+events and commands is allowed, it is generally not a good
+idea to completely omit them.
    
+
    
+
    
+
    
+
    Callbacks
    
+
    
+
    Stream handlers must implement the following interface:
    
+
    
+
    
+
    init(StreamID, Req, Opts) -> {Commands, State}
+data(StreamID, IsFin, Data, State) -> {Commands, State}
+info(StreamID, Info, State) -> {Commands, State}
+terminate(StreamID, Reason, State) -> any()
+early_error(StreamID, Reason, PartialReq, Resp, Opts) -> Resp
+
+StreamID   :: cowboy_stream:streamid()
+Req        :: cowboy_req:req()
+Opts       :: cowboy:opts()
+Commands   :: cowboy_stream:commands()
+State      :: any()
+IsFin      :: cowboy_stream:fin()
+Data       :: binary()
+Info       :: any()
+Reason     :: cowboy_stream:reason()
+PartialReq  - cowboy_req:req(), except all fields are optional
+Resp       :: cowboy_stream:resp_command()
    
+
    HTTP/1.1 will initialize a stream only when the request-line
+and all headers have been received. When errors occur before
+that point Cowboy will call the callback early_error/5
+with a partial request, the error reason and the response
+Cowboy intends to send. All other events go throuh the
+stream handler using the normal callbacks.
    
+
    HTTP/2 will initialize the stream when the HEADERS block has
+been fully received and decoded. Any protocol error occuring
+before that will not result in a response being sent and
+will therefore not go through the stream handler. In addition
+Cowboy may terminate streams without sending an HTTP response
+back.
    
+
    The stream is initialized by calling init/3. All streams
+that are initialized will eventually be terminated by calling
+terminate/3.
    
+
    When Cowboy receives data for the stream it will call data/4.
+The data given is the request body after any transfer decoding
+has been applied.
    
+
    When Cowboy receives a message addressed to a stream, or when
+Cowboy needs to inform the stream handler that an internal
+event has occurred, it will call info/3.
    
+
    
+
    
+
    
+
    Commands
    
+
    
+
    Stream handlers can return a list of commands to be executed
+from the init/3, data/4 and info/3 callbacks. In addition,
+the early_error/5 callback must return a response command.
    
+
    The following commands are defined:
    
+
    
+
    response
    
+
    Send a response to the client.
    
+
    
+
    
+
    {response, cowboy:http_status(), cowboy:http_headers(),
+    cowboy_req:resp_body()}
    
+
    No more data can be sent after this command.
    
+
    
+
    
+
    headers
    
+
    Initiate a response to the client.
    
+
    
+
    
+
    {headers, cowboy:http_status(), cowboy:http_headers()}
    
+
    This initiates a response to the client. The stream
+will end when a data command with the fin flag is
+returned.
    
+
    
+
    
+
    data
    
+
    Send data to the client.
    
+
    
+
    
+
    {data, fin(), iodata()}
    
+
    
+
    
+
    push
    
+
    Push a resource to the client.
    
+
    
+
    
+
    {push, Method, Scheme, Host, inet:port_number(),
+    Path, Qs, cowboy:http_headers()}
+
+Method = Scheme = Host = Path = Qs = binary()
    
+
    The command will be ignored if the protocol does not provide
+any server push mechanism.
    
+
    
+
    
+
    flow
    
+
    
+
    
+
    {flow, pos_integer()}
    
+
    Request more data to be read from the request body. The
+exact behavior depends on the protocol.
    
+
    
+
    
+
    spawn
    
+
    Inform Cowboy that a process was spawned and should be
+supervised.
    
+
    
+
    
+
    {spawn, pid(), timeout()}
    
+
    
+
    
+
    error_response
    
+
    Send an error response if no response was sent previously.
    
+
    
+
    
+
    {error_response, cowboy:http_status(), cowboy:http_headers(), iodata()}
    
+
    
+
    
+
    switch_protocol
    
+
    Switch to a different protocol.
    
+
    
+
    
+
    {switch_protocol, cowboy:http_headers(), module(), state()}
    
+
    Contains the headers that will be sent in the 101 response,
+along with the module implementing the protocol we are
+switching to and its initial state.
    
+
    
+
    
+
    stop
    
+
    Stop the stream.
    
+
    
+
    
+
    stop
    
+
    While no more data can be sent after the fin flag was set,
+the stream is still tracked by Cowboy until it is stopped by
+the handler.
    
+
    The behavior when stopping a stream for which no response
+has been sent will vary depending on the protocol. The stream
+will end successfully as far as the client is concerned.
    
+
    To indicate that an error occurred, either use error_response
+before stopping, or use internal_error.
    
+
    
+
    
+
    internal_error
    
+
    Stop the stream with an error.
    
+
    
+
    
+
    {internal_error, Reason, HumanReadable}
+
+Reason        = any()
+HumanReadable = atom()
    
+
    This command should be used when the stream cannot continue
+because of an internal error. An error_response command
+may be sent before that to advertise to the client why the
+stream is dropped.
    
+
    
+
    
+
    
+
    
+
    Predefined events
    
+
    
+
    Cowboy will forward all messages sent to the stream to
+the info/3 callback. To send a message to a stream,
+send a message to the connection process with the form
+{{Pid, StreamID}, Msg}. The connection process will
+then forward Msg to the stream handlers.
    
+
    Cowboy will also forward the exit signals for the
+processes that the stream spawned.
    
+
    
+
    EXIT
    
+
    A process spawned by this stream has exited.
    
+
    
+
    
+
    {'EXIT', pid(), any()}
    
+
    This is the raw exit message without any modification.
    
+
    
+
    
+
    response
    
+
    Same as the response command.
    
+
    Usually sent when the request process replies to the client.
+May also be sent by Cowboy internally.
    
+
    
+
    
+
    headers
    
+
    Same as the headers command.
    
+
    Sent when the request process starts replying to the client.
    
+
    
+
    
+
    data
    
+
    Same as the data command.
    
+
    Sent when the request process streams data to the client.
    
+
    
+
    
+
    push
    
+
    Same as the push command.
    
+
    Sent when the request process pushes a resource to the client.
    
+
    
+
    
+
    switch_protocol
    
+
    Same as the switch_protocol command.
    
+
    Sent when switching to the HTTP/2 or Websocket protocol.
    
+
    
+
    
+
    
+
    
+
    Exports
    
+
    
+
    The following function should be called by modules implementing
+stream handlers to execute the next stream handler in the list:
    
+
    
+
    
+
    
+
    
+
    Types
    
+
    
+
    
+
    commands()
    
+
    
+
    
+
    commands() :: [Command]
    
+
    See the list of commands for details.
    
+
    
+
    
+
    fin()
    
+
    
+
    
+
    fin() :: fin | nofin
    
+
    Used in commands and events to indicate that this is
+the end of the stream.
    
+
    
+
    
+
    partial_req()
    
+
    
+
    
+
    req() :: #{
+    method  => binary(),               %% case sensitive
+    version => cowboy:http_version() | atom(),
+    scheme  => binary(),               %% lowercase; case insensitive
+    host    => binary(),               %% lowercase; case insensitive
+    port    => inet:port_number(),
+    path    => binary(),               %% case sensitive
+    qs      => binary(),               %% case sensitive
+    headers => cowboy:http_headers(),
+    peer    => {inet:ip_address(), inet:port_number()}
+}
    
+
    Partial request information received when an early error is
+detected.
    
+
    
+
    
+
    reason()
    
+
    
+
    
+
    reason() :: normal | switch_protocol
+    | {internal_error, timeout | {error | exit | throw, any()}, HumanReadable}
+    | {socket_error, closed | atom(), HumanReadable}
+    | {stream_error, Error, HumanReadable}
+    | {connection_error, Error, HumanReadable}
+    | {stop, cow_http2:frame(), HumanReadable}
+
+Error         = atom()
+HumanReadable = atom()
    
+
    Reason for the stream termination.
    
+
    
+
    
+
    resp_command()
    
+
    
+
    
+
    resp_command() :: {response, cowboy:http_status(),
+    cowboy:http_headers(), cowboy_req:resp_body()}
    
+
    See the response command for details.
    
+
    
+
    
+
    streamid()
    
+
    
+
    
+
    streamid() :: any()
    
+
    The identifier for this stream.
    
+
    The identifier is unique over the connection process.
+It is possible to form a unique identifier node-wide and
+cluster-wide by wrapping it in a {self(), StreamID}
+tuple.
    
+
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: Module introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7),
+cowboy_http(3),
+cowboy_http2(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.1/manual/cowboy_websocket/index.html
new file mode 100644
index 00000000..4ecadb49
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/cowboy_websocket/index.html
@@ -0,0 +1,430 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: cowboy_websocket(3)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    cowboy_websocket(3)
    
+
+
    
+
    Name
    
+
    
+
    cowboy_websocket - Websocket
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    The module cowboy_websocket implements Websocket
+as a Ranch protocol. It also defines a callback interface
+for handling Websocket connections.
    
+
    
+
    
+
    
+
    Callbacks
    
+
    
+
    Websocket handlers must implement the following callback
+interface:
    
+
    
+
    
+
    init(Req, State)
+    -> {cowboy_websocket, Req, State}
+     | {cowboy_websocket, Req, State, Opts}
+
+websocket_init(State)            -> CallResult  %% optional
+websocket_handle(InFrame, State) -> CallResult
+websocket_info(Info, State)      -> CallResult
+
+terminate(Reason, PartialReq, State) -> ok      %% optional
+
+Req        :: cowboy_req:req()
+PartialReq :: map()
+State      :: any()
+Opts       :: cowboy_websocket:opts()
+InFrame    :: {text | binary | ping | pong, binary()}
+OutFrame   :: cow_ws:frame()                    %% see types below
+Info       :: any()
+
+CallResult :: {ok, State}
+            | {ok, State, hibernate}
+            | {reply, OutFrame | [OutFrame], State}
+            | {reply, OutFrame | [OutFrame], State, hibernate}
+            | {stop, State}
+
+Reason     :: normal | stop | timeout
+            | remote | {remote, cow_ws:close_code(), binary()}
+            | {error, badencoding | badframe | closed | atom()}
+            | {crash, error | exit | throw, any()}
    
+
    The init/2 callback is common to all handlers. To upgrade
+the connection to Websocket, it must return cowboy_websocket
+as the first element of the tuple.
    
+
    Any operation requiring the HTTP request must be done in the
+init/2 function, as the Req object will not be available
+after it returns. Websocket sub-protocol selection should
+therefore be done in this function.
    
+
    The optional websocket_init/1 callback will be called once
+the connection has been upgraded to Websocket. It can be used
+to perform any required initialization of the handler.
    
+
    Note that the init/2 function does not run in the same
+process as the Websocket callbacks. Any Websocket-specific
+initialization must be done in websocket_init/1.
    
+
    The websocket_handle/2 callback will be called for every
+frame received. The websocket_info/2 callback will be
+called for every Erlang message received.
    
+
    All three Websocket callbacks may send one or more frames
+back to the client (by returning a reply tuple) or terminate
+the connection (by sending a close frame or returning a stop
+tuple).
    
+
    The optional terminate/3 callback will ultimately be called
+with the reason for the termination of the connection. This
+callback is common to all handlers. Note that Websocket will
+not provide the full Req object by default, to save memory.
    
+
    Cowboy will terminate the process right after closing the
+Websocket connection. This means that there is no need to
+perform any cleanup in the terminate/3 callback.
    
+
    The following terminate reasons are defined for Websocket
+connections:
    
+
    
+
    
+normal
+
    
+
    
+
    
+    The connection was closed normally before establishing a Websocket
+    connection. This typically happens if an ok tuple is returned
+    from the init/2 callback.
+
    
+
    
+
    
+remote
+
    
+
    
+
    
+    The remote endpoint closed the connection without giving any
+    further details.
+
    
+
    
+
    
+{remote, Code, Payload}
+
    
+
    
+
    
+    The remote endpoint closed the connection with the given
+    Code and Payload as the reason.
+
    
+
    
+
    
+stop
+
    
+
    
+
    
+    The handler requested to close the connection, either by returning
+    a stop tuple or by sending a close frame.
+
    
+
    
+
    
+timeout
+
    
+
    
+
    
+    The connection has been closed due to inactivity. The timeout
+    value can be configured from init/2.
+
    
+
    
+
    
+{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, badencoding}
+
    
+
    
+
    
+    A text frame was sent by the client with invalid encoding. All
+    text frames must be valid UTF-8.
+
    
+
    
+
    
+{error, badframe}
+
    
+
    
+
    
+    A protocol error has been detected.
+
    
+
    
+
    
+{error, closed}
+
    
+
    
+
    
+    The socket has been closed brutally without a close frame being
+    received first.
+
    
+
    
+
    
+{error, Reason}
+
    
+
    
+
    
+    A socket error ocurred.
+
    
+
    
+
    
+
    
+
    
+
    
+
    Types
    
+
    
+
    
+
    cow_ws:frame()
    
+
    
+
    
+
    frame() :: {text, iodata()}
+    | {binary, iodata()}
+    | ping | {ping, iodata()}
+    | pong | {pong, iodata()}
+    | close | {close, iodata()} | {close, close_code(), iodata()}
+
+close_code() :: 1000..1003 | 1006..1011 | 3000..4999
    
+
    Websocket frames that can be sent as a response.
    
+
    Note that there is no need to send pong frames back as
+Cowboy does it automatically for you.
    
+
    
+
    
+
    opts()
    
+
    
+
    
+
    opts() :: #{
+    compress => boolean(),
+    idle_timeout => timeout(),
+    req_filter => fun((cowboy_req:req()) -> map())
+}
    
+
    Websocket handler options.
    
+
    This configuration is passed to Cowboy from the init/2
+function:
    
+
    
+
    
+
    init(Req, State) ->
+    Opts = #{compress => true},
+    {cowboy_websocket, Req, State, Opts}.
    
+
    The default value is given next to the option name:
    
+
    
+
    
+compress (false)
+
    
+
    
+
    
+    Whether to enable the Websocket frame compression
+    extension. Frames will only be compressed for the
+    clients that support this extension.
+
    
+
    
+
    
+idle_timeout (60000)
+
    
+
    
+
    
+    Time in milliseconds that Cowboy will keep the
+    connection open without receiving anything from
+    the client.
+
    
+
    
+
    
+req_filter
+
    
+
    
+
    
+    A function applied to the Req to compact it and
+    only keep required information. The Req is only
+    given back in the terminate/3 callback. By default
+    it keeps the method, version, URI components and peer
+    information.
+
    
+
    
+
    
+
    
+
    
+
    
+
    
+
    Changelog
    
+
    
+
      
+
    • 
+
      
+2.0: The Req object is no longer passed to Websocket callbacks.
+
      
+
      • 
+
    • 
+
      
+2.0: The callback websocket_terminate/3 was removed in favor of terminate/3.
+
      
+
      • 
+
    • 
+
      
+1.0: Protocol introduced.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    cowboy(7),
+cowboy_handler(3),
+cowboy_http(3),
+cowboy_http2(3)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/http_status_codes/index.html b/docs/en/cowboy/2.1/manual/http_status_codes/index.html
new file mode 100644
index 00000000..8349dd0f
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/http_status_codes/index.html
@@ -0,0 +1,406 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: HTTP status codes(7)
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    HTTP status codes(7)
    
+
+
    
+
    Name
    
+
    
+
    HTTP status codes - status codes used by Cowboy
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    This chapter aims to list all HTTP status codes that Cowboy
+may return, with details on the reasons why. The list given
+here only includes the replies that Cowboy sends, not user
+replies.
    
+
    
+
    
+
    
+
    100 Continue
    
+
    
+
    When the client sends an expect: 100-continue header,
+Cowboy automatically sends a this status code before
+trying to read the request body. This behavior can be
+disabled using the appropriate body option.
    
+
    
+
    
+
    
+
    101 Switching Protocols
    
+
    
+
    This is the status code sent when switching to the
+Websocket protocol.
    
+
    
+
    
+
    
+
    200 OK
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    201 Created
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    202 Accepted
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    204 No Content
    
+
    
+
    This status code is sent when the processing of a request
+ends without any reply having been sent. It may also be
+sent by cowboy_rest under normal conditions.
    
+
    
+
    
+
    
+
    300 Multiple Choices
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    301 Moved Permanently
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    303 See Other
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    304 Not Modified
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    307 Temporary Redirect
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    400 Bad Request
    
+
    
+
    Cowboy will send this status code for any of the
+following reasons:
    
+
      
+
    • 
+
      
+Too many empty lines were sent before the request.
+
      
+
      • 
+
    • 
+
      
+The request-line could not be parsed.
+
      
+
      • 
+
    • 
+
      
+Too many headers were sent.
+
      
+
      • 
+
    • 
+
      
+A header name was too long.
+
      
+
      • 
+
    • 
+
      
+A header value was too long.
+
      
+
      • 
+
    • 
+
      
+The host header was missing from an HTTP/1.1 request.
+
      
+
      • 
+
    • 
+
      
+The host header could not be parsed.
+
      
+
      • 
+
    • 
+
      
+The requested host was not found.
+
      
+
      • 
+
    • 
+
      
+The requested path could not be parsed.
+
      
+
      • 
+
    • 
+
      
+The accept header could not be parsed when using REST.
+
      
+
      • 
+
    • 
+
      
+REST under normal conditions.
+
      
+
      • 
+
    • 
+
      
+A Websocket upgrade failed.
+
      
+
      • 
+
    
+
    
+
    
+
    
+
    401 Unauthorized
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    403 Forbidden
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    404 Not Found
    
+
    
+
    This status code is sent when the router successfully
+resolved the host but didn’t find a matching path for
+the request. It may also be sent by cowboy_rest under
+normal conditions.
    
+
    
+
    
+
    
+
    405 Method Not Allowed
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    406 Not Acceptable
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    408 Request Timeout
    
+
    
+
    Cowboy will send this status code to the client if the
+client started to send a request, indicated by the
+request-line being received fully, but failed to send
+all headers in a reasonable time.
    
+
    
+
    
+
    
+
    409 Conflict
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    410 Gone
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    412 Precondition Failed
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    413 Request Entity Too Large
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    414 Request-URI Too Long
    
+
    
+
    Cowboy will send this status code to the client if the
+request-line is too long. It may also be sent by
+cowboy_rest under normal conditions.
    
+
    
+
    
+
    
+
    415 Unsupported Media Type
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    500 Internal Server Error
    
+
    
+
    This status code is sent when a crash occurs in HTTP, loop
+or REST handlers, or when an invalid return value is
+returned. It may also be sent by cowboy_rest under
+normal conditions.
    
+
    
+
    
+
    
+
    501 Not Implemented
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    503 Service Unavailable
    
+
    
+
    This status code is sent by cowboy_rest.
    
+
    
+
    
+
    
+
    505 HTTP Version Not Supported
    
+
    
+
    Cowboy only supports the versions 1.0 and 1.1 of HTTP.
+In all other cases this status code is sent back to the
+client and the connection is closed.
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/cowboy/2.1/manual/index.html b/docs/en/cowboy/2.1/manual/index.html
new file mode 100644
index 00000000..043f1c5e
--- /dev/null
+++ b/docs/en/cowboy/2.1/manual/index.html
@@ -0,0 +1,306 @@
+
+
+
+
+    
+    
+    
+    
+
+    
+
+    Nine Nines: Cowboy Function Reference
+
+    
+    
+
+    
+    
+    
+    
+
+    
+
+
+
+
+  
    
+    
    
+        
    
+          
    
+            
    99s
    
+          
    
+          
    
+            
+            
    
+               
+              
      
+                
    • 
+                  Github
+                
      • 
+                    
    • 
+						
+					
      • 
+                    
    • 
+						
+					
      • 
+              
    
+            
    
+          
    
+        
    
+    
    
+
+
+
    
+
+
    
+
    
+
    
+
    
+
+
    Cowboy Function Reference
    
+
+
    
+
    Name
    
+
    
+
    cowboy - Small, fast, modern HTTP server for Erlang/OTP
    
+
    
+
    
+
    
+
    Description
    
+
    
+
    Cowboy is an HTTP server for Erlang/OTP with support for the
+HTTP/1.1, HTTP/2 and Websocket protocols.
    
+
    Cowboy aims to provide a complete HTTP stack. This includes
+the implementation of the HTTP RFCs but also any directly
+related standards, like Websocket or Server-Sent Events.
    
+
    
+
    
+
    
+
    Modules
    
+
    
+
    Functions:
    
+
    
+
    Protocols:
    
+
    
+
    Handlers:
    
+
    
+
    Behaviors:
    
+
    
+
    Middlewares:
    
+
    
+
    
+
    
+
    
+
    Dependencies
    
+
    
+
      
+
    • 
+
      
+ranch(7) - Socket acceptor pool for TCP protocols
+
      
+
      • 
+
    • 
+
      
+cowlib(7) - Support library for manipulating Web protocols
+
      
+
      • 
+
    • 
+
      
+ssl - Secure communication over sockets
+
      
+
      • 
+
    • 
+
      
+crypto - Crypto functions
+
      
+
      • 
+
    
+
    All these applications must be started before the cowboy
+application. To start Cowboy and all dependencies at once:
    
+
    
+
    
+
    {ok, _} = application:ensure_all_started(cowboy).
    
+
    
+
    
+
    
+
    Environment
    
+
    
+
    The cowboy application does not define any application
+environment configuration parameters.
    
+
    
+
    
+
    
+
    See also
    
+
    
+
    ranch(7),
+cowlib(7)
    
+
    
+
    
+
+
+
+
+
+
    
+
+
    
+
+
+
    
+	Cowboy
+	2.1
+	Function Reference
+	
+
    
+
+
+
+
    Navigation
    
+
+
    Version select
    
+
+
+
    
+
    
+
    
+
    
+
+      
+
+    
+    
+  
+
+
+
diff --git a/docs/en/erlang.mk/1/guide/app/index.html b/docs/en/erlang.mk/1/guide/app/index.html
index c4fa21f7..670e898b 100644
--- a/docs/en/erlang.mk/1/guide/app/index.html
+++ b/docs/en/erlang.mk/1/guide/app/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Building
 
diff --git a/docs/en/erlang.mk/1/guide/asciidoc/index.html b/docs/en/erlang.mk/1/guide/asciidoc/index.html
index e0a10d20..0a51ddeb 100644
--- a/docs/en/erlang.mk/1/guide/asciidoc/index.html
+++ b/docs/en/erlang.mk/1/guide/asciidoc/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: AsciiDoc documentation
 
diff --git a/docs/en/erlang.mk/1/guide/ci/index.html b/docs/en/erlang.mk/1/guide/ci/index.html
index e73333f6..950eca18 100644
--- a/docs/en/erlang.mk/1/guide/ci/index.html
+++ b/docs/en/erlang.mk/1/guide/ci/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Continuous integration
 
diff --git a/docs/en/erlang.mk/1/guide/common_test/index.html b/docs/en/erlang.mk/1/guide/common_test/index.html
index 7933d41a..faf90773 100644
--- a/docs/en/erlang.mk/1/guide/common_test/index.html
+++ b/docs/en/erlang.mk/1/guide/common_test/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Common Test
 
diff --git a/docs/en/erlang.mk/1/guide/compat/index.html b/docs/en/erlang.mk/1/guide/compat/index.html
index d257d9ee..788e2fac 100644
--- a/docs/en/erlang.mk/1/guide/compat/index.html
+++ b/docs/en/erlang.mk/1/guide/compat/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Compatibility with other build tools
 
diff --git a/docs/en/erlang.mk/1/guide/contributing/index.html b/docs/en/erlang.mk/1/guide/contributing/index.html
index c6719e0c..661ff55a 100644
--- a/docs/en/erlang.mk/1/guide/contributing/index.html
+++ b/docs/en/erlang.mk/1/guide/contributing/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Contributing
 
diff --git a/docs/en/erlang.mk/1/guide/coverage/index.html b/docs/en/erlang.mk/1/guide/coverage/index.html
index d341f6f5..4c0aa76c 100644
--- a/docs/en/erlang.mk/1/guide/coverage/index.html
+++ b/docs/en/erlang.mk/1/guide/coverage/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Code coverage
 
diff --git a/docs/en/erlang.mk/1/guide/deps/index.html b/docs/en/erlang.mk/1/guide/deps/index.html
index c5a1904a..f74a5842 100644
--- a/docs/en/erlang.mk/1/guide/deps/index.html
+++ b/docs/en/erlang.mk/1/guide/deps/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Packages and dependencies
 
diff --git a/docs/en/erlang.mk/1/guide/dialyzer/index.html b/docs/en/erlang.mk/1/guide/dialyzer/index.html
index 5d8779f8..4472dbe4 100644
--- a/docs/en/erlang.mk/1/guide/dialyzer/index.html
+++ b/docs/en/erlang.mk/1/guide/dialyzer/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Dialyzer
 
diff --git a/docs/en/erlang.mk/1/guide/edoc/index.html b/docs/en/erlang.mk/1/guide/edoc/index.html
index 6fcaeeed..4d73d7ff 100644
--- a/docs/en/erlang.mk/1/guide/edoc/index.html
+++ b/docs/en/erlang.mk/1/guide/edoc/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: EDoc comments
 
diff --git a/docs/en/erlang.mk/1/guide/escripts/index.html b/docs/en/erlang.mk/1/guide/escripts/index.html
index 89cffc80..cccddf83 100644
--- a/docs/en/erlang.mk/1/guide/escripts/index.html
+++ b/docs/en/erlang.mk/1/guide/escripts/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Escripts
 
diff --git a/docs/en/erlang.mk/1/guide/eunit/index.html b/docs/en/erlang.mk/1/guide/eunit/index.html
index 83435883..97c4ee49 100644
--- a/docs/en/erlang.mk/1/guide/eunit/index.html
+++ b/docs/en/erlang.mk/1/guide/eunit/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: EUnit
 
diff --git a/docs/en/erlang.mk/1/guide/external_plugins/index.html b/docs/en/erlang.mk/1/guide/external_plugins/index.html
index 6a901281..3a8a1100 100644
--- a/docs/en/erlang.mk/1/guide/external_plugins/index.html
+++ b/docs/en/erlang.mk/1/guide/external_plugins/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: External plugins
 
diff --git a/docs/en/erlang.mk/1/guide/external_plugins_list/index.html b/docs/en/erlang.mk/1/guide/external_plugins_list/index.html
index 694b0c58..a72c4cfc 100644
--- a/docs/en/erlang.mk/1/guide/external_plugins_list/index.html
+++ b/docs/en/erlang.mk/1/guide/external_plugins_list/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: List of plugins
 
diff --git a/docs/en/erlang.mk/1/guide/getting_started/index.html b/docs/en/erlang.mk/1/guide/getting_started/index.html
index dc20db0c..fe8532bf 100644
--- a/docs/en/erlang.mk/1/guide/getting_started/index.html
+++ b/docs/en/erlang.mk/1/guide/getting_started/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Getting started
 
diff --git a/docs/en/erlang.mk/1/guide/history/index.html b/docs/en/erlang.mk/1/guide/history/index.html
index 5bad3b62..bdef70e6 100644
--- a/docs/en/erlang.mk/1/guide/history/index.html
+++ b/docs/en/erlang.mk/1/guide/history/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Short history
 
diff --git a/docs/en/erlang.mk/1/guide/index.html b/docs/en/erlang.mk/1/guide/index.html
index 0e1f31d0..6b7d7fd1 100644
--- a/docs/en/erlang.mk/1/guide/index.html
+++ b/docs/en/erlang.mk/1/guide/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Erlang.mk User Guide
 
diff --git a/docs/en/erlang.mk/1/guide/installation/index.html b/docs/en/erlang.mk/1/guide/installation/index.html
index c046eace..fd886c96 100644
--- a/docs/en/erlang.mk/1/guide/installation/index.html
+++ b/docs/en/erlang.mk/1/guide/installation/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Installation
 
diff --git a/docs/en/erlang.mk/1/guide/kerl/index.html b/docs/en/erlang.mk/1/guide/kerl/index.html
index d5474929..be6b2e46 100644
--- a/docs/en/erlang.mk/1/guide/kerl/index.html
+++ b/docs/en/erlang.mk/1/guide/kerl/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: OTP version management
 
diff --git a/docs/en/erlang.mk/1/guide/limitations/index.html b/docs/en/erlang.mk/1/guide/limitations/index.html
index 48561e8f..9620e115 100644
--- a/docs/en/erlang.mk/1/guide/limitations/index.html
+++ b/docs/en/erlang.mk/1/guide/limitations/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Limitations
 
diff --git a/docs/en/erlang.mk/1/guide/overview/index.html b/docs/en/erlang.mk/1/guide/overview/index.html
index 2a6cbf1f..cc2278e3 100644
--- a/docs/en/erlang.mk/1/guide/overview/index.html
+++ b/docs/en/erlang.mk/1/guide/overview/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Overview
 
diff --git a/docs/en/erlang.mk/1/guide/ports/index.html b/docs/en/erlang.mk/1/guide/ports/index.html
index 24fa8b15..246f574d 100644
--- a/docs/en/erlang.mk/1/guide/ports/index.html
+++ b/docs/en/erlang.mk/1/guide/ports/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: NIFs and port drivers
 
diff --git a/docs/en/erlang.mk/1/guide/releases/index.html b/docs/en/erlang.mk/1/guide/releases/index.html
index 606c47e3..0ee51c52 100644
--- a/docs/en/erlang.mk/1/guide/releases/index.html
+++ b/docs/en/erlang.mk/1/guide/releases/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Releases
 
diff --git a/docs/en/erlang.mk/1/guide/sfx/index.html b/docs/en/erlang.mk/1/guide/sfx/index.html
index a97c253f..5ef06d47 100644
--- a/docs/en/erlang.mk/1/guide/sfx/index.html
+++ b/docs/en/erlang.mk/1/guide/sfx/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Self-extracting releases
 
diff --git a/docs/en/erlang.mk/1/guide/shell/index.html b/docs/en/erlang.mk/1/guide/shell/index.html
index 873e7b2f..95cc3da1 100644
--- a/docs/en/erlang.mk/1/guide/shell/index.html
+++ b/docs/en/erlang.mk/1/guide/shell/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Erlang shell
 
diff --git a/docs/en/erlang.mk/1/guide/updating/index.html b/docs/en/erlang.mk/1/guide/updating/index.html
index 826e1b0d..06a96bfc 100644
--- a/docs/en/erlang.mk/1/guide/updating/index.html
+++ b/docs/en/erlang.mk/1/guide/updating/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Updating Erlang.mk
 
diff --git a/docs/en/erlang.mk/1/guide/why/index.html b/docs/en/erlang.mk/1/guide/why/index.html
index 0c73daaf..7aed235e 100644
--- a/docs/en/erlang.mk/1/guide/why/index.html
+++ b/docs/en/erlang.mk/1/guide/why/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Why Erlang.mk
 
diff --git a/docs/en/erlang.mk/1/guide/xref/index.html b/docs/en/erlang.mk/1/guide/xref/index.html
index 7913e3d9..2dc4951c 100644
--- a/docs/en/erlang.mk/1/guide/xref/index.html
+++ b/docs/en/erlang.mk/1/guide/xref/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Xref
 
diff --git a/docs/en/gun/1.0/guide/connect/index.html b/docs/en/gun/1.0/guide/connect/index.html
index 62b1619d..771dd5f5 100644
--- a/docs/en/gun/1.0/guide/connect/index.html
+++ b/docs/en/gun/1.0/guide/connect/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Connection
 
diff --git a/docs/en/gun/1.0/guide/http/index.html b/docs/en/gun/1.0/guide/http/index.html
index bbdb81ed..b61eb1b8 100644
--- a/docs/en/gun/1.0/guide/http/index.html
+++ b/docs/en/gun/1.0/guide/http/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: HTTP
 
diff --git a/docs/en/gun/1.0/guide/index.html b/docs/en/gun/1.0/guide/index.html
index d243d71c..743c116a 100644
--- a/docs/en/gun/1.0/guide/index.html
+++ b/docs/en/gun/1.0/guide/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Gun User Guide
 
diff --git a/docs/en/gun/1.0/guide/introduction/index.html b/docs/en/gun/1.0/guide/introduction/index.html
index 271dfbc9..a6fe644c 100644
--- a/docs/en/gun/1.0/guide/introduction/index.html
+++ b/docs/en/gun/1.0/guide/introduction/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Introduction
 
diff --git a/docs/en/gun/1.0/guide/protocols/index.html b/docs/en/gun/1.0/guide/protocols/index.html
index 36f9b62f..dac708b6 100644
--- a/docs/en/gun/1.0/guide/protocols/index.html
+++ b/docs/en/gun/1.0/guide/protocols/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Supported protocols
 
diff --git a/docs/en/gun/1.0/guide/start/index.html b/docs/en/gun/1.0/guide/start/index.html
index e7df8d53..8a709fcc 100644
--- a/docs/en/gun/1.0/guide/start/index.html
+++ b/docs/en/gun/1.0/guide/start/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Starting and stopping
 
diff --git a/docs/en/gun/1.0/guide/websocket/index.html b/docs/en/gun/1.0/guide/websocket/index.html
index b10064cf..6c70709d 100644
--- a/docs/en/gun/1.0/guide/websocket/index.html
+++ b/docs/en/gun/1.0/guide/websocket/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Websocket
 
diff --git a/docs/en/gun/1.0/manual/gun/index.html b/docs/en/gun/1.0/manual/gun/index.html
index aad74371..6992275d 100644
--- a/docs/en/gun/1.0/manual/gun/index.html
+++ b/docs/en/gun/1.0/manual/gun/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: gun(3)
 
diff --git a/docs/en/gun/1.0/manual/gun_app/index.html b/docs/en/gun/1.0/manual/gun_app/index.html
index 5690ca2b..f7258ddd 100644
--- a/docs/en/gun/1.0/manual/gun_app/index.html
+++ b/docs/en/gun/1.0/manual/gun_app/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: gun(7)
 
diff --git a/docs/en/gun/1.0/manual/index.html b/docs/en/gun/1.0/manual/index.html
index c3851885..8650d028 100644
--- a/docs/en/gun/1.0/manual/index.html
+++ b/docs/en/gun/1.0/manual/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Gun Function Reference
 
diff --git a/docs/en/ranch/1.2/guide/embedded/index.html b/docs/en/ranch/1.2/guide/embedded/index.html
index 5f17e1d9..4c766f00 100644
--- a/docs/en/ranch/1.2/guide/embedded/index.html
+++ b/docs/en/ranch/1.2/guide/embedded/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Embedded mode
 
diff --git a/docs/en/ranch/1.2/guide/index.html b/docs/en/ranch/1.2/guide/index.html
index fe654083..3e109e33 100644
--- a/docs/en/ranch/1.2/guide/index.html
+++ b/docs/en/ranch/1.2/guide/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Ranch User Guide
 
diff --git a/docs/en/ranch/1.2/guide/internals/index.html b/docs/en/ranch/1.2/guide/internals/index.html
index 4ad24619..ef756b9d 100644
--- a/docs/en/ranch/1.2/guide/internals/index.html
+++ b/docs/en/ranch/1.2/guide/internals/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Internals
 
diff --git a/docs/en/ranch/1.2/guide/introduction/index.html b/docs/en/ranch/1.2/guide/introduction/index.html
index 2a3c9321..544a350b 100644
--- a/docs/en/ranch/1.2/guide/introduction/index.html
+++ b/docs/en/ranch/1.2/guide/introduction/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Introduction
 
diff --git a/docs/en/ranch/1.2/guide/listeners/index.html b/docs/en/ranch/1.2/guide/listeners/index.html
index 39191182..cf99a5ae 100644
--- a/docs/en/ranch/1.2/guide/listeners/index.html
+++ b/docs/en/ranch/1.2/guide/listeners/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Listeners
 
diff --git a/docs/en/ranch/1.2/guide/parsers/index.html b/docs/en/ranch/1.2/guide/parsers/index.html
index 02686ce4..9221320f 100644
--- a/docs/en/ranch/1.2/guide/parsers/index.html
+++ b/docs/en/ranch/1.2/guide/parsers/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Writing parsers
 
diff --git a/docs/en/ranch/1.2/guide/protocols/index.html b/docs/en/ranch/1.2/guide/protocols/index.html
index 2006cb5d..ab2c374c 100644
--- a/docs/en/ranch/1.2/guide/protocols/index.html
+++ b/docs/en/ranch/1.2/guide/protocols/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Protocols
 
diff --git a/docs/en/ranch/1.2/guide/ssl_auth/index.html b/docs/en/ranch/1.2/guide/ssl_auth/index.html
index b04dedd0..71a1d061 100644
--- a/docs/en/ranch/1.2/guide/ssl_auth/index.html
+++ b/docs/en/ranch/1.2/guide/ssl_auth/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: SSL client authentication
 
diff --git a/docs/en/ranch/1.2/guide/transports/index.html b/docs/en/ranch/1.2/guide/transports/index.html
index 1d5c681e..e23ba498 100644
--- a/docs/en/ranch/1.2/guide/transports/index.html
+++ b/docs/en/ranch/1.2/guide/transports/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Transports
 
diff --git a/docs/en/ranch/1.2/manual/index.html b/docs/en/ranch/1.2/manual/index.html
index 55200d4c..c161ed75 100644
--- a/docs/en/ranch/1.2/manual/index.html
+++ b/docs/en/ranch/1.2/manual/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Ranch Function Reference
 
diff --git a/docs/en/ranch/1.2/manual/ranch/index.html b/docs/en/ranch/1.2/manual/ranch/index.html
index 3bf9b923..e87c1e15 100644
--- a/docs/en/ranch/1.2/manual/ranch/index.html
+++ b/docs/en/ranch/1.2/manual/ranch/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch(3)
 
diff --git a/docs/en/ranch/1.2/manual/ranch_app/index.html b/docs/en/ranch/1.2/manual/ranch_app/index.html
index 9e8e42c9..42db78ba 100644
--- a/docs/en/ranch/1.2/manual/ranch_app/index.html
+++ b/docs/en/ranch/1.2/manual/ranch_app/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch(7)
 
diff --git a/docs/en/ranch/1.2/manual/ranch_protocol/index.html b/docs/en/ranch/1.2/manual/ranch_protocol/index.html
index 2d258978..896e46ef 100644
--- a/docs/en/ranch/1.2/manual/ranch_protocol/index.html
+++ b/docs/en/ranch/1.2/manual/ranch_protocol/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_protocol(3)
 
diff --git a/docs/en/ranch/1.2/manual/ranch_ssl/index.html b/docs/en/ranch/1.2/manual/ranch_ssl/index.html
index 6b1fd169..2201161b 100644
--- a/docs/en/ranch/1.2/manual/ranch_ssl/index.html
+++ b/docs/en/ranch/1.2/manual/ranch_ssl/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_ssl(3)
 
diff --git a/docs/en/ranch/1.2/manual/ranch_tcp/index.html b/docs/en/ranch/1.2/manual/ranch_tcp/index.html
index cccc2cd6..c73d1c4e 100644
--- a/docs/en/ranch/1.2/manual/ranch_tcp/index.html
+++ b/docs/en/ranch/1.2/manual/ranch_tcp/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_tcp(3)
 
diff --git a/docs/en/ranch/1.2/manual/ranch_transport/index.html b/docs/en/ranch/1.2/manual/ranch_transport/index.html
index 4306cd5b..b0379717 100644
--- a/docs/en/ranch/1.2/manual/ranch_transport/index.html
+++ b/docs/en/ranch/1.2/manual/ranch_transport/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_transport(3)
 
diff --git a/docs/en/ranch/1.3/guide/embedded/index.html b/docs/en/ranch/1.3/guide/embedded/index.html
index c7d2bc57..2d09ba89 100644
--- a/docs/en/ranch/1.3/guide/embedded/index.html
+++ b/docs/en/ranch/1.3/guide/embedded/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Embedded mode
 
diff --git a/docs/en/ranch/1.3/guide/index.html b/docs/en/ranch/1.3/guide/index.html
index c3677fa1..82d159d8 100644
--- a/docs/en/ranch/1.3/guide/index.html
+++ b/docs/en/ranch/1.3/guide/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Ranch User Guide
 
diff --git a/docs/en/ranch/1.3/guide/internals/index.html b/docs/en/ranch/1.3/guide/internals/index.html
index 85c6d7b6..7f46a4e4 100644
--- a/docs/en/ranch/1.3/guide/internals/index.html
+++ b/docs/en/ranch/1.3/guide/internals/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Internals
 
diff --git a/docs/en/ranch/1.3/guide/introduction/index.html b/docs/en/ranch/1.3/guide/introduction/index.html
index 08d5ec07..8ba234b0 100644
--- a/docs/en/ranch/1.3/guide/introduction/index.html
+++ b/docs/en/ranch/1.3/guide/introduction/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Introduction
 
diff --git a/docs/en/ranch/1.3/guide/listeners/index.html b/docs/en/ranch/1.3/guide/listeners/index.html
index f21f169e..083f6a89 100644
--- a/docs/en/ranch/1.3/guide/listeners/index.html
+++ b/docs/en/ranch/1.3/guide/listeners/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Listeners
 
diff --git a/docs/en/ranch/1.3/guide/parsers/index.html b/docs/en/ranch/1.3/guide/parsers/index.html
index f0db1c8d..2bb1c41d 100644
--- a/docs/en/ranch/1.3/guide/parsers/index.html
+++ b/docs/en/ranch/1.3/guide/parsers/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Writing parsers
 
diff --git a/docs/en/ranch/1.3/guide/protocols/index.html b/docs/en/ranch/1.3/guide/protocols/index.html
index 513602aa..f42c5df2 100644
--- a/docs/en/ranch/1.3/guide/protocols/index.html
+++ b/docs/en/ranch/1.3/guide/protocols/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Protocols
 
diff --git a/docs/en/ranch/1.3/guide/ssl_auth/index.html b/docs/en/ranch/1.3/guide/ssl_auth/index.html
index ca934db0..538f0f36 100644
--- a/docs/en/ranch/1.3/guide/ssl_auth/index.html
+++ b/docs/en/ranch/1.3/guide/ssl_auth/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: SSL client authentication
 
diff --git a/docs/en/ranch/1.3/guide/transports/index.html b/docs/en/ranch/1.3/guide/transports/index.html
index d5130ec0..eb66c8a7 100644
--- a/docs/en/ranch/1.3/guide/transports/index.html
+++ b/docs/en/ranch/1.3/guide/transports/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Transports
 
diff --git a/docs/en/ranch/1.3/manual/index.html b/docs/en/ranch/1.3/manual/index.html
index d506129d..2d6f76a8 100644
--- a/docs/en/ranch/1.3/manual/index.html
+++ b/docs/en/ranch/1.3/manual/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Ranch Function Reference
 
diff --git a/docs/en/ranch/1.3/manual/ranch/index.html b/docs/en/ranch/1.3/manual/ranch/index.html
index fc67cf1d..8800071a 100644
--- a/docs/en/ranch/1.3/manual/ranch/index.html
+++ b/docs/en/ranch/1.3/manual/ranch/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch(3)
 
diff --git a/docs/en/ranch/1.3/manual/ranch_app/index.html b/docs/en/ranch/1.3/manual/ranch_app/index.html
index f0651f7f..0694f8c5 100644
--- a/docs/en/ranch/1.3/manual/ranch_app/index.html
+++ b/docs/en/ranch/1.3/manual/ranch_app/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch(7)
 
diff --git a/docs/en/ranch/1.3/manual/ranch_protocol/index.html b/docs/en/ranch/1.3/manual/ranch_protocol/index.html
index f7e1f5a1..dff8983b 100644
--- a/docs/en/ranch/1.3/manual/ranch_protocol/index.html
+++ b/docs/en/ranch/1.3/manual/ranch_protocol/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_protocol(3)
 
diff --git a/docs/en/ranch/1.3/manual/ranch_ssl/index.html b/docs/en/ranch/1.3/manual/ranch_ssl/index.html
index db8170d6..0836d0f9 100644
--- a/docs/en/ranch/1.3/manual/ranch_ssl/index.html
+++ b/docs/en/ranch/1.3/manual/ranch_ssl/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_ssl(3)
 
diff --git a/docs/en/ranch/1.3/manual/ranch_tcp/index.html b/docs/en/ranch/1.3/manual/ranch_tcp/index.html
index 135c5e2f..1d716c3d 100644
--- a/docs/en/ranch/1.3/manual/ranch_tcp/index.html
+++ b/docs/en/ranch/1.3/manual/ranch_tcp/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_tcp(3)
 
diff --git a/docs/en/ranch/1.3/manual/ranch_transport/index.html b/docs/en/ranch/1.3/manual/ranch_transport/index.html
index 9f74761f..31d8a6cd 100644
--- a/docs/en/ranch/1.3/manual/ranch_transport/index.html
+++ b/docs/en/ranch/1.3/manual/ranch_transport/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_transport(3)
 
diff --git a/docs/en/ranch/1.4/guide/embedded/index.html b/docs/en/ranch/1.4/guide/embedded/index.html
index 0b99dd05..4804f1bd 100644
--- a/docs/en/ranch/1.4/guide/embedded/index.html
+++ b/docs/en/ranch/1.4/guide/embedded/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Embedded mode
 
diff --git a/docs/en/ranch/1.4/guide/index.html b/docs/en/ranch/1.4/guide/index.html
index f500390e..eee68ab7 100644
--- a/docs/en/ranch/1.4/guide/index.html
+++ b/docs/en/ranch/1.4/guide/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Ranch User Guide
 
diff --git a/docs/en/ranch/1.4/guide/internals/index.html b/docs/en/ranch/1.4/guide/internals/index.html
index e45a609e..244a641b 100644
--- a/docs/en/ranch/1.4/guide/internals/index.html
+++ b/docs/en/ranch/1.4/guide/internals/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Internals
 
diff --git a/docs/en/ranch/1.4/guide/introduction/index.html b/docs/en/ranch/1.4/guide/introduction/index.html
index c7023a3c..d12534ed 100644
--- a/docs/en/ranch/1.4/guide/introduction/index.html
+++ b/docs/en/ranch/1.4/guide/introduction/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Introduction
 
diff --git a/docs/en/ranch/1.4/guide/listeners/index.html b/docs/en/ranch/1.4/guide/listeners/index.html
index 3f0b0710..06e5a376 100644
--- a/docs/en/ranch/1.4/guide/listeners/index.html
+++ b/docs/en/ranch/1.4/guide/listeners/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Listeners
 
diff --git a/docs/en/ranch/1.4/guide/parsers/index.html b/docs/en/ranch/1.4/guide/parsers/index.html
index c663bad3..2ec8b297 100644
--- a/docs/en/ranch/1.4/guide/parsers/index.html
+++ b/docs/en/ranch/1.4/guide/parsers/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Writing parsers
 
diff --git a/docs/en/ranch/1.4/guide/protocols/index.html b/docs/en/ranch/1.4/guide/protocols/index.html
index eef4ca91..b7b8f9af 100644
--- a/docs/en/ranch/1.4/guide/protocols/index.html
+++ b/docs/en/ranch/1.4/guide/protocols/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Protocols
 
diff --git a/docs/en/ranch/1.4/guide/ssl_auth/index.html b/docs/en/ranch/1.4/guide/ssl_auth/index.html
index d57afa20..172e24a1 100644
--- a/docs/en/ranch/1.4/guide/ssl_auth/index.html
+++ b/docs/en/ranch/1.4/guide/ssl_auth/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: SSL client authentication
 
diff --git a/docs/en/ranch/1.4/guide/transports/index.html b/docs/en/ranch/1.4/guide/transports/index.html
index fe8da963..75f87a82 100644
--- a/docs/en/ranch/1.4/guide/transports/index.html
+++ b/docs/en/ranch/1.4/guide/transports/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Transports
 
diff --git a/docs/en/ranch/1.4/manual/index.html b/docs/en/ranch/1.4/manual/index.html
index d5248194..f4d902b5 100644
--- a/docs/en/ranch/1.4/manual/index.html
+++ b/docs/en/ranch/1.4/manual/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: Ranch Function Reference
 
diff --git a/docs/en/ranch/1.4/manual/ranch/index.html b/docs/en/ranch/1.4/manual/ranch/index.html
index dd9cc9fe..bd357857 100644
--- a/docs/en/ranch/1.4/manual/ranch/index.html
+++ b/docs/en/ranch/1.4/manual/ranch/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch(3)
 
diff --git a/docs/en/ranch/1.4/manual/ranch_app/index.html b/docs/en/ranch/1.4/manual/ranch_app/index.html
index 41da7131..daee729b 100644
--- a/docs/en/ranch/1.4/manual/ranch_app/index.html
+++ b/docs/en/ranch/1.4/manual/ranch_app/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch(7)
 
diff --git a/docs/en/ranch/1.4/manual/ranch_protocol/index.html b/docs/en/ranch/1.4/manual/ranch_protocol/index.html
index 54cdbd45..94f86683 100644
--- a/docs/en/ranch/1.4/manual/ranch_protocol/index.html
+++ b/docs/en/ranch/1.4/manual/ranch_protocol/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_protocol(3)
 
diff --git a/docs/en/ranch/1.4/manual/ranch_ssl/index.html b/docs/en/ranch/1.4/manual/ranch_ssl/index.html
index b51cdd36..004cbc73 100644
--- a/docs/en/ranch/1.4/manual/ranch_ssl/index.html
+++ b/docs/en/ranch/1.4/manual/ranch_ssl/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_ssl(3)
 
diff --git a/docs/en/ranch/1.4/manual/ranch_tcp/index.html b/docs/en/ranch/1.4/manual/ranch_tcp/index.html
index e11bbb25..49ad61d2 100644
--- a/docs/en/ranch/1.4/manual/ranch_tcp/index.html
+++ b/docs/en/ranch/1.4/manual/ranch_tcp/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_tcp(3)
 
diff --git a/docs/en/ranch/1.4/manual/ranch_transport/index.html b/docs/en/ranch/1.4/manual/ranch_transport/index.html
index f15173fd..ee0948f4 100644
--- a/docs/en/ranch/1.4/manual/ranch_transport/index.html
+++ b/docs/en/ranch/1.4/manual/ranch_transport/index.html
@@ -7,7 +7,7 @@
     
     
 
-    
+    
 
     Nine Nines: ranch_transport(3)
 
-- 
cgit v1.2.3