From 48f39402181d959cad88cb3f460210c007169f50 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Wed, 12 May 2021 11:13:47 +0200 Subject: Cowboy 2.9.0 --- docs/en/cowboy/2.3/guide/constraints.asciidoc | 123 - docs/en/cowboy/2.3/guide/constraints/index.html | 260 -- docs/en/cowboy/2.3/guide/cookies.asciidoc | 139 - docs/en/cowboy/2.3/guide/cookies/index.html | 277 -- docs/en/cowboy/2.3/guide/cowboy.sty | 8 - docs/en/cowboy/2.3/guide/erlang_web.asciidoc | 209 -- docs/en/cowboy/2.3/guide/erlang_web/index.html | 226 -- docs/en/cowboy/2.3/guide/flow_diagram.asciidoc | 109 - docs/en/cowboy/2.3/guide/flow_diagram/index.html | 204 -- docs/en/cowboy/2.3/guide/getting_started.asciidoc | 147 - .../en/cowboy/2.3/guide/getting_started/index.html | 278 -- docs/en/cowboy/2.3/guide/handlers.asciidoc | 90 - docs/en/cowboy/2.3/guide/handlers/index.html | 231 -- docs/en/cowboy/2.3/guide/http_req_resp.png | Bin 20713 -> 0 bytes docs/en/cowboy/2.3/guide/http_req_resp.svg | 543 ---- docs/en/cowboy/2.3/guide/index.html | 237 -- docs/en/cowboy/2.3/guide/introduction.asciidoc | 75 - docs/en/cowboy/2.3/guide/introduction/index.html | 214 -- docs/en/cowboy/2.3/guide/listeners.asciidoc | 115 - docs/en/cowboy/2.3/guide/listeners/index.html | 235 -- docs/en/cowboy/2.3/guide/loop_handlers.asciidoc | 128 - docs/en/cowboy/2.3/guide/loop_handlers/index.html | 246 -- docs/en/cowboy/2.3/guide/middlewares.asciidoc | 69 - docs/en/cowboy/2.3/guide/middlewares/index.html | 212 -- .../cowboy/2.3/guide/migrating_from_1.0.asciidoc | 214 -- .../cowboy/2.3/guide/migrating_from_1.0/index.html | 294 -- .../cowboy/2.3/guide/migrating_from_2.0.asciidoc | 107 - .../cowboy/2.3/guide/migrating_from_2.0/index.html | 229 -- .../cowboy/2.3/guide/migrating_from_2.1.asciidoc | 107 - .../cowboy/2.3/guide/migrating_from_2.1/index.html | 240 -- .../cowboy/2.3/guide/migrating_from_2.2.asciidoc | 56 - .../cowboy/2.3/guide/migrating_from_2.2/index.html | 212 -- docs/en/cowboy/2.3/guide/modern_web.asciidoc | 122 - docs/en/cowboy/2.3/guide/modern_web/index.html | 208 -- docs/en/cowboy/2.3/guide/multipart.asciidoc | 169 -- docs/en/cowboy/2.3/guide/multipart/index.html | 281 -- docs/en/cowboy/2.3/guide/req.asciidoc | 366 --- docs/en/cowboy/2.3/guide/req/index.html | 457 --- docs/en/cowboy/2.3/guide/req_body.asciidoc | 130 - docs/en/cowboy/2.3/guide/req_body/index.html | 267 -- docs/en/cowboy/2.3/guide/resource_design.asciidoc | 220 -- .../en/cowboy/2.3/guide/resource_design/index.html | 240 -- docs/en/cowboy/2.3/guide/resp.asciidoc | 368 --- docs/en/cowboy/2.3/guide/resp/index.html | 423 --- docs/en/cowboy/2.3/guide/rest_cond.png | Bin 111628 -> 0 bytes docs/en/cowboy/2.3/guide/rest_cond.svg | 1656 ----------- docs/en/cowboy/2.3/guide/rest_conneg.png | Bin 78133 -> 0 bytes docs/en/cowboy/2.3/guide/rest_conneg.svg | 1135 ------- docs/en/cowboy/2.3/guide/rest_delete.png | Bin 122185 -> 0 bytes docs/en/cowboy/2.3/guide/rest_delete.svg | 1718 ----------- docs/en/cowboy/2.3/guide/rest_flowcharts.asciidoc | 248 -- .../en/cowboy/2.3/guide/rest_flowcharts/index.html | 238 -- docs/en/cowboy/2.3/guide/rest_get_head.png | Bin 94321 -> 0 bytes docs/en/cowboy/2.3/guide/rest_get_head.svg | 1523 ---------- docs/en/cowboy/2.3/guide/rest_handlers.asciidoc | 138 - docs/en/cowboy/2.3/guide/rest_handlers/index.html | 336 --- docs/en/cowboy/2.3/guide/rest_options.png | Bin 8539 -> 0 bytes docs/en/cowboy/2.3/guide/rest_options.svg | 387 --- docs/en/cowboy/2.3/guide/rest_principles.asciidoc | 160 - .../en/cowboy/2.3/guide/rest_principles/index.html | 212 -- docs/en/cowboy/2.3/guide/rest_put_post_patch.png | Bin 206747 -> 0 bytes docs/en/cowboy/2.3/guide/rest_put_post_patch.svg | 2856 ------------------ docs/en/cowboy/2.3/guide/rest_start.png | Bin 105640 -> 0 bytes docs/en/cowboy/2.3/guide/rest_start.svg | 1356 --------- docs/en/cowboy/2.3/guide/routing.asciidoc | 222 -- docs/en/cowboy/2.3/guide/routing/index.html | 355 --- docs/en/cowboy/2.3/guide/specs.asciidoc | 193 -- docs/en/cowboy/2.3/guide/specs/index.html | 515 ---- docs/en/cowboy/2.3/guide/static_files.asciidoc | 163 - docs/en/cowboy/2.3/guide/static_files/index.html | 275 -- docs/en/cowboy/2.3/guide/streams.asciidoc | 65 - docs/en/cowboy/2.3/guide/streams/index.html | 197 -- docs/en/cowboy/2.3/guide/ws_handlers.asciidoc | 293 -- docs/en/cowboy/2.3/guide/ws_handlers/index.html | 364 --- docs/en/cowboy/2.3/guide/ws_protocol.asciidoc | 69 - docs/en/cowboy/2.3/guide/ws_protocol/index.html | 196 -- .../en/cowboy/2.3/manual/cowboy.set_env/index.html | 211 -- .../2.3/manual/cowboy.start_clear/index.html | 229 -- .../cowboy/2.3/manual/cowboy.start_tls/index.html | 234 -- .../2.3/manual/cowboy.stop_listener/index.html | 194 -- docs/en/cowboy/2.3/manual/cowboy/index.html | 228 -- docs/en/cowboy/2.3/manual/cowboy_app/index.html | 229 -- .../2.3/manual/cowboy_constraints.int/index.html | 204 -- .../manual/cowboy_constraints.nonempty/index.html | 203 -- .../2.3/manual/cowboy_constraints/index.html | 195 -- .../2.3/manual/cowboy_handler.terminate/index.html | 206 -- .../en/cowboy/2.3/manual/cowboy_handler/index.html | 198 -- docs/en/cowboy/2.3/manual/cowboy_http/index.html | 268 -- docs/en/cowboy/2.3/manual/cowboy_http2/index.html | 212 -- docs/en/cowboy/2.3/manual/cowboy_loop/index.html | 212 -- .../cowboy/2.3/manual/cowboy_middleware/index.html | 208 -- .../2.3/manual/cowboy_req.binding/index.html | 212 -- .../2.3/manual/cowboy_req.bindings/index.html | 192 -- .../2.3/manual/cowboy_req.body_length/index.html | 193 -- .../cowboy/2.3/manual/cowboy_req.cert/index.html | 212 -- .../cowboy_req.delete_resp_header/index.html | 197 -- .../2.3/manual/cowboy_req.has_body/index.html | 190 -- .../2.3/manual/cowboy_req.has_resp_body/index.html | 195 -- .../manual/cowboy_req.has_resp_header/index.html | 198 -- .../cowboy/2.3/manual/cowboy_req.header/index.html | 219 -- .../2.3/manual/cowboy_req.headers/index.html | 199 -- .../cowboy/2.3/manual/cowboy_req.host/index.html | 199 -- .../2.3/manual/cowboy_req.host_info/index.html | 193 -- .../cowboy/2.3/manual/cowboy_req.inform/index.html | 218 -- .../2.3/manual/cowboy_req.match_cookies/index.html | 219 -- .../2.3/manual/cowboy_req.match_qs/index.html | 219 -- .../cowboy/2.3/manual/cowboy_req.method/index.html | 210 -- .../2.3/manual/cowboy_req.parse_cookies/index.html | 199 -- .../2.3/manual/cowboy_req.parse_header/index.html | 370 --- .../2.3/manual/cowboy_req.parse_qs/index.html | 207 -- .../cowboy/2.3/manual/cowboy_req.path/index.html | 199 -- .../2.3/manual/cowboy_req.path_info/index.html | 193 -- .../cowboy/2.3/manual/cowboy_req.peer/index.html | 203 -- .../cowboy/2.3/manual/cowboy_req.port/index.html | 200 -- .../cowboy/2.3/manual/cowboy_req.push/index.html | 226 -- docs/en/cowboy/2.3/manual/cowboy_req.qs/index.html | 199 -- .../2.3/manual/cowboy_req.read_body/index.html | 224 -- .../2.3/manual/cowboy_req.read_part/index.html | 246 -- .../manual/cowboy_req.read_part_body/index.html | 222 -- .../cowboy_req.read_urlencoded_body/index.html | 216 -- .../cowboy/2.3/manual/cowboy_req.reply/index.html | 239 -- .../2.3/manual/cowboy_req.resp_header/index.html | 210 -- .../2.3/manual/cowboy_req.resp_headers/index.html | 190 -- .../cowboy/2.3/manual/cowboy_req.scheme/index.html | 204 -- .../2.3/manual/cowboy_req.set_resp_body/index.html | 231 -- .../manual/cowboy_req.set_resp_cookie/index.html | 256 -- .../manual/cowboy_req.set_resp_header/index.html | 212 -- .../manual/cowboy_req.set_resp_headers/index.html | 203 -- .../cowboy/2.3/manual/cowboy_req.sock/index.html | 199 -- .../2.3/manual/cowboy_req.stream_body/index.html | 208 -- .../2.3/manual/cowboy_req.stream_reply/index.html | 228 -- .../manual/cowboy_req.stream_trailers/index.html | 207 -- .../en/cowboy/2.3/manual/cowboy_req.uri/index.html | 258 -- .../2.3/manual/cowboy_req.version/index.html | 199 -- docs/en/cowboy/2.3/manual/cowboy_req/index.html | 370 --- docs/en/cowboy/2.3/manual/cowboy_rest/index.html | 627 ---- .../2.3/manual/cowboy_router.compile/index.html | 200 -- docs/en/cowboy/2.3/manual/cowboy_router/index.html | 217 -- docs/en/cowboy/2.3/manual/cowboy_static/index.html | 262 -- docs/en/cowboy/2.3/manual/cowboy_stream/index.html | 459 --- .../cowboy/2.3/manual/cowboy_websocket/index.html | 300 -- .../cowboy/2.3/manual/http_status_codes/index.html | 244 -- docs/en/cowboy/2.3/manual/index.html | 229 -- docs/en/cowboy/2.4/guide/constraints/index.html | 4 +- docs/en/cowboy/2.4/guide/cookies/index.html | 4 +- docs/en/cowboy/2.4/guide/erlang_web/index.html | 4 +- docs/en/cowboy/2.4/guide/flow_diagram/index.html | 4 +- .../en/cowboy/2.4/guide/getting_started/index.html | 4 +- docs/en/cowboy/2.4/guide/handlers/index.html | 4 +- docs/en/cowboy/2.4/guide/index.html | 4 +- docs/en/cowboy/2.4/guide/introduction/index.html | 4 +- docs/en/cowboy/2.4/guide/listeners/index.html | 4 +- docs/en/cowboy/2.4/guide/loop_handlers/index.html | 4 +- docs/en/cowboy/2.4/guide/middlewares/index.html | 4 +- .../cowboy/2.4/guide/migrating_from_1.0/index.html | 4 +- .../cowboy/2.4/guide/migrating_from_2.0/index.html | 4 +- .../cowboy/2.4/guide/migrating_from_2.1/index.html | 4 +- .../cowboy/2.4/guide/migrating_from_2.2/index.html | 4 +- .../cowboy/2.4/guide/migrating_from_2.3/index.html | 4 +- docs/en/cowboy/2.4/guide/modern_web/index.html | 4 +- docs/en/cowboy/2.4/guide/multipart/index.html | 4 +- docs/en/cowboy/2.4/guide/req/index.html | 4 +- docs/en/cowboy/2.4/guide/req_body/index.html | 4 +- .../en/cowboy/2.4/guide/resource_design/index.html | 4 +- docs/en/cowboy/2.4/guide/resp/index.html | 4 +- .../en/cowboy/2.4/guide/rest_flowcharts/index.html | 4 +- docs/en/cowboy/2.4/guide/rest_handlers/index.html | 4 +- .../en/cowboy/2.4/guide/rest_principles/index.html | 4 +- docs/en/cowboy/2.4/guide/routing/index.html | 4 +- docs/en/cowboy/2.4/guide/specs/index.html | 4 +- docs/en/cowboy/2.4/guide/static_files/index.html | 4 +- docs/en/cowboy/2.4/guide/streams/index.html | 4 +- docs/en/cowboy/2.4/guide/ws_handlers/index.html | 4 +- docs/en/cowboy/2.4/guide/ws_protocol/index.html | 4 +- .../en/cowboy/2.4/manual/cowboy.set_env/index.html | 4 +- .../2.4/manual/cowboy.start_clear/index.html | 4 +- .../cowboy/2.4/manual/cowboy.start_tls/index.html | 4 +- .../2.4/manual/cowboy.stop_listener/index.html | 4 +- docs/en/cowboy/2.4/manual/cowboy/index.html | 4 +- docs/en/cowboy/2.4/manual/cowboy_app/index.html | 4 +- .../2.4/manual/cowboy_constraints.int/index.html | 4 +- .../manual/cowboy_constraints.nonempty/index.html | 4 +- .../2.4/manual/cowboy_constraints/index.html | 4 +- .../2.4/manual/cowboy_handler.terminate/index.html | 4 +- .../en/cowboy/2.4/manual/cowboy_handler/index.html | 4 +- docs/en/cowboy/2.4/manual/cowboy_http/index.html | 4 +- docs/en/cowboy/2.4/manual/cowboy_http2/index.html | 4 +- docs/en/cowboy/2.4/manual/cowboy_loop/index.html | 4 +- .../cowboy/2.4/manual/cowboy_middleware/index.html | 4 +- .../2.4/manual/cowboy_req.binding/index.html | 4 +- .../2.4/manual/cowboy_req.bindings/index.html | 4 +- .../2.4/manual/cowboy_req.body_length/index.html | 4 +- .../cowboy/2.4/manual/cowboy_req.cert/index.html | 4 +- .../cowboy_req.delete_resp_header/index.html | 4 +- .../2.4/manual/cowboy_req.has_body/index.html | 4 +- .../2.4/manual/cowboy_req.has_resp_body/index.html | 4 +- .../manual/cowboy_req.has_resp_header/index.html | 4 +- .../cowboy/2.4/manual/cowboy_req.header/index.html | 4 +- .../2.4/manual/cowboy_req.headers/index.html | 4 +- .../cowboy/2.4/manual/cowboy_req.host/index.html | 4 +- .../2.4/manual/cowboy_req.host_info/index.html | 4 +- .../cowboy/2.4/manual/cowboy_req.inform/index.html | 4 +- .../2.4/manual/cowboy_req.match_cookies/index.html | 4 +- .../2.4/manual/cowboy_req.match_qs/index.html | 4 +- .../cowboy/2.4/manual/cowboy_req.method/index.html | 4 +- .../2.4/manual/cowboy_req.parse_cookies/index.html | 4 +- .../2.4/manual/cowboy_req.parse_header/index.html | 4 +- .../2.4/manual/cowboy_req.parse_qs/index.html | 4 +- .../cowboy/2.4/manual/cowboy_req.path/index.html | 4 +- .../2.4/manual/cowboy_req.path_info/index.html | 4 +- .../cowboy/2.4/manual/cowboy_req.peer/index.html | 4 +- .../cowboy/2.4/manual/cowboy_req.port/index.html | 4 +- .../cowboy/2.4/manual/cowboy_req.push/index.html | 4 +- docs/en/cowboy/2.4/manual/cowboy_req.qs/index.html | 4 +- .../2.4/manual/cowboy_req.read_body/index.html | 4 +- .../2.4/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.4/manual/cowboy_req.reply/index.html | 4 +- .../2.4/manual/cowboy_req.resp_header/index.html | 4 +- .../2.4/manual/cowboy_req.resp_headers/index.html | 4 +- .../cowboy/2.4/manual/cowboy_req.scheme/index.html | 4 +- .../2.4/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 +- .../cowboy/2.4/manual/cowboy_req.sock/index.html | 4 +- .../2.4/manual/cowboy_req.stream_body/index.html | 4 +- .../2.4/manual/cowboy_req.stream_reply/index.html | 4 +- .../manual/cowboy_req.stream_trailers/index.html | 4 +- .../en/cowboy/2.4/manual/cowboy_req.uri/index.html | 4 +- .../2.4/manual/cowboy_req.version/index.html | 4 +- docs/en/cowboy/2.4/manual/cowboy_req/index.html | 4 +- docs/en/cowboy/2.4/manual/cowboy_rest/index.html | 4 +- .../2.4/manual/cowboy_router.compile/index.html | 4 +- docs/en/cowboy/2.4/manual/cowboy_router/index.html | 4 +- docs/en/cowboy/2.4/manual/cowboy_static/index.html | 4 +- docs/en/cowboy/2.4/manual/cowboy_stream/index.html | 4 +- .../cowboy/2.4/manual/cowboy_websocket/index.html | 4 +- .../cowboy/2.4/manual/http_status_codes/index.html | 4 +- docs/en/cowboy/2.4/manual/index.html | 4 +- docs/en/cowboy/2.5/guide/constraints/index.html | 4 +- docs/en/cowboy/2.5/guide/cookies/index.html | 4 +- docs/en/cowboy/2.5/guide/erlang_web/index.html | 4 +- docs/en/cowboy/2.5/guide/flow_diagram/index.html | 4 +- .../en/cowboy/2.5/guide/getting_started/index.html | 4 +- docs/en/cowboy/2.5/guide/handlers/index.html | 4 +- docs/en/cowboy/2.5/guide/index.html | 4 +- docs/en/cowboy/2.5/guide/introduction/index.html | 4 +- docs/en/cowboy/2.5/guide/listeners/index.html | 4 +- docs/en/cowboy/2.5/guide/loop_handlers/index.html | 4 +- docs/en/cowboy/2.5/guide/middlewares/index.html | 4 +- .../cowboy/2.5/guide/migrating_from_1.0/index.html | 4 +- .../cowboy/2.5/guide/migrating_from_2.0/index.html | 4 +- .../cowboy/2.5/guide/migrating_from_2.1/index.html | 4 +- .../cowboy/2.5/guide/migrating_from_2.2/index.html | 4 +- .../cowboy/2.5/guide/migrating_from_2.3/index.html | 4 +- .../cowboy/2.5/guide/migrating_from_2.4/index.html | 4 +- docs/en/cowboy/2.5/guide/modern_web/index.html | 4 +- docs/en/cowboy/2.5/guide/multipart/index.html | 4 +- docs/en/cowboy/2.5/guide/req/index.html | 4 +- docs/en/cowboy/2.5/guide/req_body/index.html | 4 +- .../en/cowboy/2.5/guide/resource_design/index.html | 4 +- docs/en/cowboy/2.5/guide/resp/index.html | 4 +- .../en/cowboy/2.5/guide/rest_flowcharts/index.html | 4 +- docs/en/cowboy/2.5/guide/rest_handlers/index.html | 4 +- .../en/cowboy/2.5/guide/rest_principles/index.html | 4 +- docs/en/cowboy/2.5/guide/routing/index.html | 4 +- docs/en/cowboy/2.5/guide/specs/index.html | 4 +- docs/en/cowboy/2.5/guide/static_files/index.html | 4 +- docs/en/cowboy/2.5/guide/streams/index.html | 4 +- docs/en/cowboy/2.5/guide/ws_handlers/index.html | 4 +- docs/en/cowboy/2.5/guide/ws_protocol/index.html | 4 +- .../en/cowboy/2.5/manual/cowboy.set_env/index.html | 4 +- .../2.5/manual/cowboy.start_clear/index.html | 4 +- .../cowboy/2.5/manual/cowboy.start_tls/index.html | 4 +- .../2.5/manual/cowboy.stop_listener/index.html | 4 +- docs/en/cowboy/2.5/manual/cowboy/index.html | 4 +- docs/en/cowboy/2.5/manual/cowboy_app/index.html | 4 +- .../2.5/manual/cowboy_constraints.int/index.html | 4 +- .../manual/cowboy_constraints.nonempty/index.html | 4 +- .../2.5/manual/cowboy_constraints/index.html | 4 +- .../2.5/manual/cowboy_handler.terminate/index.html | 4 +- .../en/cowboy/2.5/manual/cowboy_handler/index.html | 4 +- docs/en/cowboy/2.5/manual/cowboy_http/index.html | 4 +- docs/en/cowboy/2.5/manual/cowboy_http2/index.html | 4 +- docs/en/cowboy/2.5/manual/cowboy_loop/index.html | 4 +- .../cowboy/2.5/manual/cowboy_middleware/index.html | 4 +- .../2.5/manual/cowboy_req.binding/index.html | 4 +- .../2.5/manual/cowboy_req.bindings/index.html | 4 +- .../2.5/manual/cowboy_req.body_length/index.html | 4 +- .../cowboy/2.5/manual/cowboy_req.cert/index.html | 4 +- .../cowboy_req.delete_resp_header/index.html | 4 +- .../2.5/manual/cowboy_req.has_body/index.html | 4 +- .../2.5/manual/cowboy_req.has_resp_body/index.html | 4 +- .../manual/cowboy_req.has_resp_header/index.html | 4 +- .../cowboy/2.5/manual/cowboy_req.header/index.html | 4 +- .../2.5/manual/cowboy_req.headers/index.html | 4 +- .../cowboy/2.5/manual/cowboy_req.host/index.html | 4 +- .../2.5/manual/cowboy_req.host_info/index.html | 4 +- .../cowboy/2.5/manual/cowboy_req.inform/index.html | 4 +- .../2.5/manual/cowboy_req.match_cookies/index.html | 4 +- .../2.5/manual/cowboy_req.match_qs/index.html | 4 +- .../cowboy/2.5/manual/cowboy_req.method/index.html | 4 +- .../2.5/manual/cowboy_req.parse_cookies/index.html | 4 +- .../2.5/manual/cowboy_req.parse_header/index.html | 4 +- .../2.5/manual/cowboy_req.parse_qs/index.html | 4 +- .../cowboy/2.5/manual/cowboy_req.path/index.html | 4 +- .../2.5/manual/cowboy_req.path_info/index.html | 4 +- .../cowboy/2.5/manual/cowboy_req.peer/index.html | 4 +- .../cowboy/2.5/manual/cowboy_req.port/index.html | 4 +- .../cowboy/2.5/manual/cowboy_req.push/index.html | 4 +- docs/en/cowboy/2.5/manual/cowboy_req.qs/index.html | 4 +- .../index.html | 4 +- .../2.5/manual/cowboy_req.read_body/index.html | 4 +- .../2.5/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.5/manual/cowboy_req.reply/index.html | 4 +- .../2.5/manual/cowboy_req.resp_header/index.html | 4 +- .../2.5/manual/cowboy_req.resp_headers/index.html | 4 +- .../cowboy/2.5/manual/cowboy_req.scheme/index.html | 4 +- .../2.5/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 +- .../cowboy/2.5/manual/cowboy_req.sock/index.html | 4 +- .../2.5/manual/cowboy_req.stream_body/index.html | 4 +- .../2.5/manual/cowboy_req.stream_events/index.html | 4 +- .../2.5/manual/cowboy_req.stream_reply/index.html | 4 +- .../manual/cowboy_req.stream_trailers/index.html | 4 +- .../en/cowboy/2.5/manual/cowboy_req.uri/index.html | 4 +- .../2.5/manual/cowboy_req.version/index.html | 4 +- docs/en/cowboy/2.5/manual/cowboy_req/index.html | 4 +- docs/en/cowboy/2.5/manual/cowboy_rest/index.html | 4 +- .../2.5/manual/cowboy_router.compile/index.html | 4 +- docs/en/cowboy/2.5/manual/cowboy_router/index.html | 4 +- docs/en/cowboy/2.5/manual/cowboy_static/index.html | 4 +- docs/en/cowboy/2.5/manual/cowboy_stream/index.html | 4 +- .../cowboy/2.5/manual/cowboy_websocket/index.html | 4 +- .../cowboy/2.5/manual/http_status_codes/index.html | 4 +- docs/en/cowboy/2.5/manual/index.html | 4 +- docs/en/cowboy/2.6/guide/constraints/index.html | 4 +- docs/en/cowboy/2.6/guide/cookies/index.html | 4 +- docs/en/cowboy/2.6/guide/erlang_web/index.html | 4 +- docs/en/cowboy/2.6/guide/flow_diagram/index.html | 4 +- .../en/cowboy/2.6/guide/getting_started/index.html | 4 +- docs/en/cowboy/2.6/guide/handlers/index.html | 4 +- docs/en/cowboy/2.6/guide/index.html | 4 +- docs/en/cowboy/2.6/guide/introduction/index.html | 4 +- docs/en/cowboy/2.6/guide/listeners/index.html | 4 +- docs/en/cowboy/2.6/guide/loop_handlers/index.html | 4 +- docs/en/cowboy/2.6/guide/middlewares/index.html | 4 +- .../cowboy/2.6/guide/migrating_from_1.0/index.html | 4 +- .../cowboy/2.6/guide/migrating_from_2.0/index.html | 4 +- .../cowboy/2.6/guide/migrating_from_2.1/index.html | 4 +- .../cowboy/2.6/guide/migrating_from_2.2/index.html | 4 +- .../cowboy/2.6/guide/migrating_from_2.3/index.html | 4 +- .../cowboy/2.6/guide/migrating_from_2.4/index.html | 4 +- .../cowboy/2.6/guide/migrating_from_2.5/index.html | 4 +- .../cowboy/2.6/guide/migrating_from_2.6/index.html | 4 +- docs/en/cowboy/2.6/guide/modern_web/index.html | 4 +- docs/en/cowboy/2.6/guide/multipart/index.html | 4 +- docs/en/cowboy/2.6/guide/req/index.html | 4 +- docs/en/cowboy/2.6/guide/req_body/index.html | 4 +- .../en/cowboy/2.6/guide/resource_design/index.html | 4 +- docs/en/cowboy/2.6/guide/resp/index.html | 4 +- .../en/cowboy/2.6/guide/rest_flowcharts/index.html | 4 +- docs/en/cowboy/2.6/guide/rest_handlers/index.html | 4 +- .../en/cowboy/2.6/guide/rest_principles/index.html | 4 +- docs/en/cowboy/2.6/guide/routing/index.html | 4 +- docs/en/cowboy/2.6/guide/specs/index.html | 4 +- docs/en/cowboy/2.6/guide/static_files/index.html | 4 +- docs/en/cowboy/2.6/guide/streams/index.html | 4 +- docs/en/cowboy/2.6/guide/ws_handlers/index.html | 4 +- docs/en/cowboy/2.6/guide/ws_protocol/index.html | 4 +- .../en/cowboy/2.6/manual/cowboy.set_env/index.html | 4 +- .../2.6/manual/cowboy.start_clear/index.html | 4 +- .../cowboy/2.6/manual/cowboy.start_tls/index.html | 4 +- .../2.6/manual/cowboy.stop_listener/index.html | 4 +- docs/en/cowboy/2.6/manual/cowboy/index.html | 4 +- docs/en/cowboy/2.6/manual/cowboy_app/index.html | 4 +- .../cowboy/2.6/manual/cowboy_compress_h/index.html | 4 +- .../2.6/manual/cowboy_constraints.int/index.html | 4 +- .../manual/cowboy_constraints.nonempty/index.html | 4 +- .../2.6/manual/cowboy_constraints/index.html | 4 +- .../2.6/manual/cowboy_handler.terminate/index.html | 4 +- .../en/cowboy/2.6/manual/cowboy_handler/index.html | 4 +- docs/en/cowboy/2.6/manual/cowboy_http/index.html | 4 +- docs/en/cowboy/2.6/manual/cowboy_http2/index.html | 4 +- docs/en/cowboy/2.6/manual/cowboy_loop/index.html | 4 +- .../cowboy/2.6/manual/cowboy_middleware/index.html | 4 +- .../2.6/manual/cowboy_req.binding/index.html | 4 +- .../2.6/manual/cowboy_req.bindings/index.html | 4 +- .../2.6/manual/cowboy_req.body_length/index.html | 4 +- .../cowboy/2.6/manual/cowboy_req.cert/index.html | 4 +- .../cowboy_req.delete_resp_header/index.html | 4 +- .../2.6/manual/cowboy_req.has_body/index.html | 4 +- .../2.6/manual/cowboy_req.has_resp_body/index.html | 4 +- .../manual/cowboy_req.has_resp_header/index.html | 4 +- .../cowboy/2.6/manual/cowboy_req.header/index.html | 4 +- .../2.6/manual/cowboy_req.headers/index.html | 4 +- .../cowboy/2.6/manual/cowboy_req.host/index.html | 4 +- .../2.6/manual/cowboy_req.host_info/index.html | 4 +- .../cowboy/2.6/manual/cowboy_req.inform/index.html | 4 +- .../2.6/manual/cowboy_req.match_cookies/index.html | 4 +- .../2.6/manual/cowboy_req.match_qs/index.html | 4 +- .../cowboy/2.6/manual/cowboy_req.method/index.html | 4 +- .../2.6/manual/cowboy_req.parse_cookies/index.html | 4 +- .../2.6/manual/cowboy_req.parse_header/index.html | 4 +- .../2.6/manual/cowboy_req.parse_qs/index.html | 4 +- .../cowboy/2.6/manual/cowboy_req.path/index.html | 4 +- .../2.6/manual/cowboy_req.path_info/index.html | 4 +- .../cowboy/2.6/manual/cowboy_req.peer/index.html | 4 +- .../cowboy/2.6/manual/cowboy_req.port/index.html | 4 +- .../cowboy/2.6/manual/cowboy_req.push/index.html | 4 +- docs/en/cowboy/2.6/manual/cowboy_req.qs/index.html | 4 +- .../index.html | 4 +- .../2.6/manual/cowboy_req.read_body/index.html | 4 +- .../2.6/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.6/manual/cowboy_req.reply/index.html | 4 +- .../2.6/manual/cowboy_req.resp_header/index.html | 4 +- .../2.6/manual/cowboy_req.resp_headers/index.html | 4 +- .../cowboy/2.6/manual/cowboy_req.scheme/index.html | 4 +- .../2.6/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 +- .../cowboy/2.6/manual/cowboy_req.sock/index.html | 4 +- .../2.6/manual/cowboy_req.stream_body/index.html | 4 +- .../2.6/manual/cowboy_req.stream_events/index.html | 4 +- .../2.6/manual/cowboy_req.stream_reply/index.html | 4 +- .../manual/cowboy_req.stream_trailers/index.html | 4 +- .../en/cowboy/2.6/manual/cowboy_req.uri/index.html | 4 +- .../2.6/manual/cowboy_req.version/index.html | 4 +- docs/en/cowboy/2.6/manual/cowboy_req/index.html | 4 +- docs/en/cowboy/2.6/manual/cowboy_rest/index.html | 4 +- .../2.6/manual/cowboy_router.compile/index.html | 4 +- docs/en/cowboy/2.6/manual/cowboy_router/index.html | 4 +- docs/en/cowboy/2.6/manual/cowboy_static/index.html | 4 +- docs/en/cowboy/2.6/manual/cowboy_stream/index.html | 4 +- .../cowboy/2.6/manual/cowboy_stream_h/index.html | 4 +- .../cowboy/2.6/manual/cowboy_websocket/index.html | 4 +- .../cowboy/2.6/manual/http_status_codes/index.html | 4 +- docs/en/cowboy/2.6/manual/index.html | 4 +- docs/en/cowboy/2.7/guide/constraints/index.html | 4 +- docs/en/cowboy/2.7/guide/cookies/index.html | 4 +- docs/en/cowboy/2.7/guide/erlang_web/index.html | 4 +- docs/en/cowboy/2.7/guide/flow_diagram/index.html | 4 +- .../en/cowboy/2.7/guide/getting_started/index.html | 4 +- docs/en/cowboy/2.7/guide/handlers/index.html | 4 +- docs/en/cowboy/2.7/guide/index.html | 4 +- docs/en/cowboy/2.7/guide/introduction/index.html | 4 +- docs/en/cowboy/2.7/guide/listeners/index.html | 4 +- docs/en/cowboy/2.7/guide/loop_handlers/index.html | 4 +- docs/en/cowboy/2.7/guide/middlewares/index.html | 4 +- .../cowboy/2.7/guide/migrating_from_1.0/index.html | 4 +- .../cowboy/2.7/guide/migrating_from_2.0/index.html | 4 +- .../cowboy/2.7/guide/migrating_from_2.1/index.html | 4 +- .../cowboy/2.7/guide/migrating_from_2.2/index.html | 4 +- .../cowboy/2.7/guide/migrating_from_2.3/index.html | 4 +- .../cowboy/2.7/guide/migrating_from_2.4/index.html | 4 +- .../cowboy/2.7/guide/migrating_from_2.5/index.html | 4 +- .../cowboy/2.7/guide/migrating_from_2.6/index.html | 4 +- docs/en/cowboy/2.7/guide/modern_web/index.html | 4 +- docs/en/cowboy/2.7/guide/multipart/index.html | 4 +- docs/en/cowboy/2.7/guide/req/index.html | 4 +- docs/en/cowboy/2.7/guide/req_body/index.html | 4 +- .../en/cowboy/2.7/guide/resource_design/index.html | 4 +- docs/en/cowboy/2.7/guide/resp/index.html | 4 +- .../en/cowboy/2.7/guide/rest_flowcharts/index.html | 4 +- docs/en/cowboy/2.7/guide/rest_handlers/index.html | 4 +- .../en/cowboy/2.7/guide/rest_principles/index.html | 4 +- docs/en/cowboy/2.7/guide/routing/index.html | 4 +- docs/en/cowboy/2.7/guide/specs/index.html | 4 +- docs/en/cowboy/2.7/guide/static_files/index.html | 4 +- docs/en/cowboy/2.7/guide/streams/index.html | 4 +- docs/en/cowboy/2.7/guide/ws_handlers/index.html | 4 +- docs/en/cowboy/2.7/guide/ws_protocol/index.html | 4 +- .../en/cowboy/2.7/manual/cowboy.set_env/index.html | 4 +- .../2.7/manual/cowboy.start_clear/index.html | 4 +- .../cowboy/2.7/manual/cowboy.start_tls/index.html | 4 +- .../2.7/manual/cowboy.stop_listener/index.html | 4 +- docs/en/cowboy/2.7/manual/cowboy/index.html | 4 +- docs/en/cowboy/2.7/manual/cowboy_app/index.html | 4 +- .../cowboy/2.7/manual/cowboy_compress_h/index.html | 4 +- .../2.7/manual/cowboy_constraints.int/index.html | 4 +- .../manual/cowboy_constraints.nonempty/index.html | 4 +- .../2.7/manual/cowboy_constraints/index.html | 4 +- .../2.7/manual/cowboy_handler.terminate/index.html | 4 +- .../en/cowboy/2.7/manual/cowboy_handler/index.html | 4 +- docs/en/cowboy/2.7/manual/cowboy_http/index.html | 4 +- docs/en/cowboy/2.7/manual/cowboy_http2/index.html | 4 +- docs/en/cowboy/2.7/manual/cowboy_loop/index.html | 4 +- .../cowboy/2.7/manual/cowboy_metrics_h/index.html | 4 +- .../cowboy/2.7/manual/cowboy_middleware/index.html | 4 +- .../2.7/manual/cowboy_req.binding/index.html | 4 +- .../2.7/manual/cowboy_req.bindings/index.html | 4 +- .../2.7/manual/cowboy_req.body_length/index.html | 4 +- .../cowboy/2.7/manual/cowboy_req.cast/index.html | 4 +- .../cowboy/2.7/manual/cowboy_req.cert/index.html | 4 +- .../cowboy_req.delete_resp_header/index.html | 4 +- .../manual/cowboy_req.filter_cookies/index.html | 4 +- .../2.7/manual/cowboy_req.has_body/index.html | 4 +- .../2.7/manual/cowboy_req.has_resp_body/index.html | 4 +- .../manual/cowboy_req.has_resp_header/index.html | 4 +- .../cowboy/2.7/manual/cowboy_req.header/index.html | 4 +- .../2.7/manual/cowboy_req.headers/index.html | 4 +- .../cowboy/2.7/manual/cowboy_req.host/index.html | 4 +- .../2.7/manual/cowboy_req.host_info/index.html | 4 +- .../cowboy/2.7/manual/cowboy_req.inform/index.html | 4 +- .../2.7/manual/cowboy_req.match_cookies/index.html | 4 +- .../2.7/manual/cowboy_req.match_qs/index.html | 4 +- .../cowboy/2.7/manual/cowboy_req.method/index.html | 4 +- .../2.7/manual/cowboy_req.parse_cookies/index.html | 4 +- .../2.7/manual/cowboy_req.parse_header/index.html | 4 +- .../2.7/manual/cowboy_req.parse_qs/index.html | 4 +- .../cowboy/2.7/manual/cowboy_req.path/index.html | 4 +- .../2.7/manual/cowboy_req.path_info/index.html | 4 +- .../cowboy/2.7/manual/cowboy_req.peer/index.html | 4 +- .../cowboy/2.7/manual/cowboy_req.port/index.html | 4 +- .../cowboy/2.7/manual/cowboy_req.push/index.html | 4 +- docs/en/cowboy/2.7/manual/cowboy_req.qs/index.html | 4 +- .../index.html | 4 +- .../2.7/manual/cowboy_req.read_body/index.html | 4 +- .../2.7/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.7/manual/cowboy_req.reply/index.html | 4 +- .../2.7/manual/cowboy_req.resp_header/index.html | 4 +- .../2.7/manual/cowboy_req.resp_headers/index.html | 4 +- .../cowboy/2.7/manual/cowboy_req.scheme/index.html | 4 +- .../2.7/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 +- .../cowboy/2.7/manual/cowboy_req.sock/index.html | 4 +- .../2.7/manual/cowboy_req.stream_body/index.html | 4 +- .../2.7/manual/cowboy_req.stream_events/index.html | 4 +- .../2.7/manual/cowboy_req.stream_reply/index.html | 4 +- .../manual/cowboy_req.stream_trailers/index.html | 4 +- .../en/cowboy/2.7/manual/cowboy_req.uri/index.html | 4 +- .../2.7/manual/cowboy_req.version/index.html | 4 +- docs/en/cowboy/2.7/manual/cowboy_req/index.html | 4 +- docs/en/cowboy/2.7/manual/cowboy_rest/index.html | 4 +- .../2.7/manual/cowboy_router.compile/index.html | 4 +- docs/en/cowboy/2.7/manual/cowboy_router/index.html | 4 +- docs/en/cowboy/2.7/manual/cowboy_static/index.html | 4 +- docs/en/cowboy/2.7/manual/cowboy_stream/index.html | 4 +- .../cowboy/2.7/manual/cowboy_stream_h/index.html | 4 +- .../cowboy/2.7/manual/cowboy_tracer_h/index.html | 4 +- .../cowboy/2.7/manual/cowboy_websocket/index.html | 4 +- .../cowboy/2.7/manual/http_status_codes/index.html | 4 +- docs/en/cowboy/2.7/manual/index.html | 4 +- docs/en/cowboy/2.8/guide/constraints/index.html | 4 +- docs/en/cowboy/2.8/guide/cookies/index.html | 4 +- docs/en/cowboy/2.8/guide/erlang_web/index.html | 4 +- docs/en/cowboy/2.8/guide/flow_diagram/index.html | 4 +- .../en/cowboy/2.8/guide/getting_started/index.html | 4 +- docs/en/cowboy/2.8/guide/handlers/index.html | 4 +- docs/en/cowboy/2.8/guide/index.html | 4 +- docs/en/cowboy/2.8/guide/introduction/index.html | 4 +- docs/en/cowboy/2.8/guide/listeners/index.html | 4 +- docs/en/cowboy/2.8/guide/loop_handlers/index.html | 4 +- docs/en/cowboy/2.8/guide/middlewares/index.html | 4 +- .../cowboy/2.8/guide/migrating_from_1.0/index.html | 4 +- .../cowboy/2.8/guide/migrating_from_2.0/index.html | 4 +- .../cowboy/2.8/guide/migrating_from_2.1/index.html | 4 +- .../cowboy/2.8/guide/migrating_from_2.2/index.html | 4 +- .../cowboy/2.8/guide/migrating_from_2.3/index.html | 4 +- .../cowboy/2.8/guide/migrating_from_2.4/index.html | 4 +- .../cowboy/2.8/guide/migrating_from_2.5/index.html | 4 +- .../cowboy/2.8/guide/migrating_from_2.6/index.html | 4 +- .../cowboy/2.8/guide/migrating_from_2.7/index.html | 4 +- docs/en/cowboy/2.8/guide/modern_web/index.html | 4 +- docs/en/cowboy/2.8/guide/multipart/index.html | 4 +- docs/en/cowboy/2.8/guide/performance/index.html | 4 +- docs/en/cowboy/2.8/guide/req/index.html | 4 +- docs/en/cowboy/2.8/guide/req_body/index.html | 4 +- .../en/cowboy/2.8/guide/resource_design/index.html | 4 +- docs/en/cowboy/2.8/guide/resp/index.html | 4 +- .../en/cowboy/2.8/guide/rest_flowcharts/index.html | 4 +- docs/en/cowboy/2.8/guide/rest_handlers/index.html | 4 +- .../en/cowboy/2.8/guide/rest_principles/index.html | 4 +- docs/en/cowboy/2.8/guide/routing/index.html | 4 +- docs/en/cowboy/2.8/guide/specs/index.html | 4 +- docs/en/cowboy/2.8/guide/static_files/index.html | 4 +- docs/en/cowboy/2.8/guide/streams/index.html | 4 +- docs/en/cowboy/2.8/guide/ws_handlers/index.html | 4 +- docs/en/cowboy/2.8/guide/ws_protocol/index.html | 4 +- .../en/cowboy/2.8/manual/cowboy.set_env/index.html | 4 +- .../2.8/manual/cowboy.start_clear/index.html | 4 +- .../cowboy/2.8/manual/cowboy.start_tls/index.html | 4 +- .../2.8/manual/cowboy.stop_listener/index.html | 4 +- docs/en/cowboy/2.8/manual/cowboy/index.html | 4 +- docs/en/cowboy/2.8/manual/cowboy_app/index.html | 4 +- .../cowboy/2.8/manual/cowboy_compress_h/index.html | 4 +- .../2.8/manual/cowboy_constraints.int/index.html | 4 +- .../manual/cowboy_constraints.nonempty/index.html | 4 +- .../2.8/manual/cowboy_constraints/index.html | 4 +- .../2.8/manual/cowboy_handler.terminate/index.html | 4 +- .../en/cowboy/2.8/manual/cowboy_handler/index.html | 4 +- docs/en/cowboy/2.8/manual/cowboy_http/index.html | 4 +- docs/en/cowboy/2.8/manual/cowboy_http2/index.html | 4 +- docs/en/cowboy/2.8/manual/cowboy_loop/index.html | 4 +- .../cowboy/2.8/manual/cowboy_metrics_h/index.html | 4 +- .../cowboy/2.8/manual/cowboy_middleware/index.html | 4 +- .../2.8/manual/cowboy_req.binding/index.html | 4 +- .../2.8/manual/cowboy_req.bindings/index.html | 4 +- .../2.8/manual/cowboy_req.body_length/index.html | 4 +- .../cowboy/2.8/manual/cowboy_req.cast/index.html | 4 +- .../cowboy/2.8/manual/cowboy_req.cert/index.html | 4 +- .../cowboy_req.delete_resp_header/index.html | 4 +- .../manual/cowboy_req.filter_cookies/index.html | 4 +- .../2.8/manual/cowboy_req.has_body/index.html | 4 +- .../2.8/manual/cowboy_req.has_resp_body/index.html | 4 +- .../manual/cowboy_req.has_resp_header/index.html | 4 +- .../cowboy/2.8/manual/cowboy_req.header/index.html | 4 +- .../2.8/manual/cowboy_req.headers/index.html | 4 +- .../cowboy/2.8/manual/cowboy_req.host/index.html | 4 +- .../2.8/manual/cowboy_req.host_info/index.html | 4 +- .../cowboy/2.8/manual/cowboy_req.inform/index.html | 4 +- .../2.8/manual/cowboy_req.match_cookies/index.html | 4 +- .../2.8/manual/cowboy_req.match_qs/index.html | 4 +- .../cowboy/2.8/manual/cowboy_req.method/index.html | 4 +- .../2.8/manual/cowboy_req.parse_cookies/index.html | 4 +- .../2.8/manual/cowboy_req.parse_header/index.html | 4 +- .../2.8/manual/cowboy_req.parse_qs/index.html | 4 +- .../cowboy/2.8/manual/cowboy_req.path/index.html | 4 +- .../2.8/manual/cowboy_req.path_info/index.html | 4 +- .../cowboy/2.8/manual/cowboy_req.peer/index.html | 4 +- .../cowboy/2.8/manual/cowboy_req.port/index.html | 4 +- .../cowboy/2.8/manual/cowboy_req.push/index.html | 4 +- docs/en/cowboy/2.8/manual/cowboy_req.qs/index.html | 4 +- .../index.html | 4 +- .../2.8/manual/cowboy_req.read_body/index.html | 4 +- .../2.8/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.8/manual/cowboy_req.reply/index.html | 4 +- .../2.8/manual/cowboy_req.resp_header/index.html | 4 +- .../2.8/manual/cowboy_req.resp_headers/index.html | 4 +- .../cowboy/2.8/manual/cowboy_req.scheme/index.html | 4 +- .../2.8/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 +- .../cowboy/2.8/manual/cowboy_req.sock/index.html | 4 +- .../2.8/manual/cowboy_req.stream_body/index.html | 4 +- .../2.8/manual/cowboy_req.stream_events/index.html | 4 +- .../2.8/manual/cowboy_req.stream_reply/index.html | 4 +- .../manual/cowboy_req.stream_trailers/index.html | 4 +- .../en/cowboy/2.8/manual/cowboy_req.uri/index.html | 4 +- .../2.8/manual/cowboy_req.version/index.html | 4 +- docs/en/cowboy/2.8/manual/cowboy_req/index.html | 4 +- docs/en/cowboy/2.8/manual/cowboy_rest/index.html | 4 +- .../2.8/manual/cowboy_router.compile/index.html | 4 +- docs/en/cowboy/2.8/manual/cowboy_router/index.html | 4 +- docs/en/cowboy/2.8/manual/cowboy_static/index.html | 4 +- docs/en/cowboy/2.8/manual/cowboy_stream/index.html | 4 +- .../cowboy/2.8/manual/cowboy_stream_h/index.html | 4 +- .../cowboy/2.8/manual/cowboy_tracer_h/index.html | 4 +- .../cowboy/2.8/manual/cowboy_websocket/index.html | 4 +- .../cowboy/2.8/manual/http_status_codes/index.html | 4 +- docs/en/cowboy/2.8/manual/index.html | 4 +- docs/en/cowboy/2.9/guide/constraints.asciidoc | 123 + docs/en/cowboy/2.9/guide/constraints/index.html | 260 ++ docs/en/cowboy/2.9/guide/cookies.asciidoc | 139 + docs/en/cowboy/2.9/guide/cookies/index.html | 277 ++ docs/en/cowboy/2.9/guide/cowboy.sty | 8 + docs/en/cowboy/2.9/guide/erlang_web.asciidoc | 209 ++ docs/en/cowboy/2.9/guide/erlang_web/index.html | 226 ++ docs/en/cowboy/2.9/guide/flow_diagram.asciidoc | 109 + docs/en/cowboy/2.9/guide/flow_diagram/index.html | 204 ++ docs/en/cowboy/2.9/guide/getting_started.asciidoc | 148 + .../en/cowboy/2.9/guide/getting_started/index.html | 278 ++ docs/en/cowboy/2.9/guide/handlers.asciidoc | 90 + docs/en/cowboy/2.9/guide/handlers/index.html | 231 ++ docs/en/cowboy/2.9/guide/http_req_resp.png | Bin 0 -> 20713 bytes docs/en/cowboy/2.9/guide/http_req_resp.svg | 543 ++++ docs/en/cowboy/2.9/guide/index.html | 251 ++ docs/en/cowboy/2.9/guide/introduction.asciidoc | 75 + docs/en/cowboy/2.9/guide/introduction/index.html | 214 ++ docs/en/cowboy/2.9/guide/listeners.asciidoc | 128 + docs/en/cowboy/2.9/guide/listeners/index.html | 244 ++ docs/en/cowboy/2.9/guide/loop_handlers.asciidoc | 125 + docs/en/cowboy/2.9/guide/loop_handlers/index.html | 245 ++ docs/en/cowboy/2.9/guide/middlewares.asciidoc | 69 + docs/en/cowboy/2.9/guide/middlewares/index.html | 212 ++ .../cowboy/2.9/guide/migrating_from_1.0.asciidoc | 214 ++ .../cowboy/2.9/guide/migrating_from_1.0/index.html | 294 ++ .../cowboy/2.9/guide/migrating_from_2.0.asciidoc | 107 + .../cowboy/2.9/guide/migrating_from_2.0/index.html | 229 ++ .../cowboy/2.9/guide/migrating_from_2.1.asciidoc | 107 + .../cowboy/2.9/guide/migrating_from_2.1/index.html | 240 ++ .../cowboy/2.9/guide/migrating_from_2.2.asciidoc | 56 + .../cowboy/2.9/guide/migrating_from_2.2/index.html | 212 ++ .../cowboy/2.9/guide/migrating_from_2.3.asciidoc | 66 + .../cowboy/2.9/guide/migrating_from_2.3/index.html | 214 ++ .../cowboy/2.9/guide/migrating_from_2.4.asciidoc | 109 + .../cowboy/2.9/guide/migrating_from_2.4/index.html | 242 ++ .../cowboy/2.9/guide/migrating_from_2.5.asciidoc | 148 + .../cowboy/2.9/guide/migrating_from_2.5/index.html | 257 ++ .../cowboy/2.9/guide/migrating_from_2.6.asciidoc | 224 ++ .../cowboy/2.9/guide/migrating_from_2.6/index.html | 278 ++ .../cowboy/2.9/guide/migrating_from_2.7.asciidoc | 118 + .../cowboy/2.9/guide/migrating_from_2.7/index.html | 234 ++ .../cowboy/2.9/guide/migrating_from_2.8.asciidoc | 50 + .../cowboy/2.9/guide/migrating_from_2.8/index.html | 205 ++ docs/en/cowboy/2.9/guide/modern_web.asciidoc | 122 + docs/en/cowboy/2.9/guide/modern_web/index.html | 208 ++ docs/en/cowboy/2.9/guide/multipart.asciidoc | 169 ++ docs/en/cowboy/2.9/guide/multipart/index.html | 281 ++ docs/en/cowboy/2.9/guide/performance.asciidoc | 29 + docs/en/cowboy/2.9/guide/performance/index.html | 186 ++ docs/en/cowboy/2.9/guide/req.asciidoc | 367 +++ docs/en/cowboy/2.9/guide/req/index.html | 456 +++ docs/en/cowboy/2.9/guide/req_body.asciidoc | 130 + docs/en/cowboy/2.9/guide/req_body/index.html | 267 ++ docs/en/cowboy/2.9/guide/resource_design.asciidoc | 226 ++ .../en/cowboy/2.9/guide/resource_design/index.html | 241 ++ docs/en/cowboy/2.9/guide/resp.asciidoc | 368 +++ docs/en/cowboy/2.9/guide/resp/index.html | 423 +++ docs/en/cowboy/2.9/guide/rest_cond.png | Bin 0 -> 111628 bytes docs/en/cowboy/2.9/guide/rest_cond.svg | 1656 +++++++++++ docs/en/cowboy/2.9/guide/rest_conneg.png | Bin 0 -> 78133 bytes docs/en/cowboy/2.9/guide/rest_conneg.svg | 1135 +++++++ docs/en/cowboy/2.9/guide/rest_delete.png | Bin 0 -> 122185 bytes docs/en/cowboy/2.9/guide/rest_delete.svg | 1718 +++++++++++ docs/en/cowboy/2.9/guide/rest_flowcharts.asciidoc | 249 ++ .../en/cowboy/2.9/guide/rest_flowcharts/index.html | 238 ++ docs/en/cowboy/2.9/guide/rest_get_head.png | Bin 0 -> 94321 bytes docs/en/cowboy/2.9/guide/rest_get_head.svg | 1523 ++++++++++ docs/en/cowboy/2.9/guide/rest_handlers.asciidoc | 139 + docs/en/cowboy/2.9/guide/rest_handlers/index.html | 339 +++ docs/en/cowboy/2.9/guide/rest_options.png | Bin 0 -> 8539 bytes docs/en/cowboy/2.9/guide/rest_options.svg | 387 +++ docs/en/cowboy/2.9/guide/rest_principles.asciidoc | 160 + .../en/cowboy/2.9/guide/rest_principles/index.html | 212 ++ docs/en/cowboy/2.9/guide/rest_put_post_patch.png | Bin 0 -> 234474 bytes docs/en/cowboy/2.9/guide/rest_put_post_patch.svg | 3143 ++++++++++++++++++++ docs/en/cowboy/2.9/guide/rest_start.png | Bin 0 -> 110820 bytes docs/en/cowboy/2.9/guide/rest_start.svg | 1656 +++++++++++ docs/en/cowboy/2.9/guide/routing.asciidoc | 271 ++ docs/en/cowboy/2.9/guide/routing/index.html | 389 +++ docs/en/cowboy/2.9/guide/specs.asciidoc | 215 ++ docs/en/cowboy/2.9/guide/specs/index.html | 559 ++++ docs/en/cowboy/2.9/guide/static_files.asciidoc | 163 + docs/en/cowboy/2.9/guide/static_files/index.html | 275 ++ docs/en/cowboy/2.9/guide/streams.asciidoc | 75 + docs/en/cowboy/2.9/guide/streams/index.html | 199 ++ docs/en/cowboy/2.9/guide/ws_handlers.asciidoc | 292 ++ docs/en/cowboy/2.9/guide/ws_handlers/index.html | 364 +++ docs/en/cowboy/2.9/guide/ws_protocol.asciidoc | 69 + docs/en/cowboy/2.9/guide/ws_protocol/index.html | 196 ++ .../en/cowboy/2.9/manual/cowboy.set_env/index.html | 211 ++ .../2.9/manual/cowboy.start_clear/index.html | 229 ++ .../cowboy/2.9/manual/cowboy.start_tls/index.html | 234 ++ .../2.9/manual/cowboy.stop_listener/index.html | 194 ++ docs/en/cowboy/2.9/manual/cowboy/index.html | 228 ++ docs/en/cowboy/2.9/manual/cowboy_app/index.html | 239 ++ .../cowboy/2.9/manual/cowboy_compress_h/index.html | 195 ++ .../2.9/manual/cowboy_constraints.int/index.html | 204 ++ .../manual/cowboy_constraints.nonempty/index.html | 203 ++ .../2.9/manual/cowboy_constraints/index.html | 195 ++ .../2.9/manual/cowboy_handler.terminate/index.html | 206 ++ .../en/cowboy/2.9/manual/cowboy_handler/index.html | 198 ++ docs/en/cowboy/2.9/manual/cowboy_http/index.html | 298 ++ docs/en/cowboy/2.9/manual/cowboy_http2/index.html | 332 +++ docs/en/cowboy/2.9/manual/cowboy_loop/index.html | 212 ++ .../cowboy/2.9/manual/cowboy_metrics_h/index.html | 289 ++ .../cowboy/2.9/manual/cowboy_middleware/index.html | 209 ++ .../2.9/manual/cowboy_req.binding/index.html | 212 ++ .../2.9/manual/cowboy_req.bindings/index.html | 192 ++ .../2.9/manual/cowboy_req.body_length/index.html | 193 ++ .../cowboy/2.9/manual/cowboy_req.cast/index.html | 204 ++ .../cowboy/2.9/manual/cowboy_req.cert/index.html | 212 ++ .../cowboy_req.delete_resp_header/index.html | 197 ++ .../manual/cowboy_req.filter_cookies/index.html | 200 ++ .../2.9/manual/cowboy_req.has_body/index.html | 190 ++ .../2.9/manual/cowboy_req.has_resp_body/index.html | 195 ++ .../manual/cowboy_req.has_resp_header/index.html | 198 ++ .../cowboy/2.9/manual/cowboy_req.header/index.html | 219 ++ .../2.9/manual/cowboy_req.headers/index.html | 199 ++ .../cowboy/2.9/manual/cowboy_req.host/index.html | 199 ++ .../2.9/manual/cowboy_req.host_info/index.html | 193 ++ .../cowboy/2.9/manual/cowboy_req.inform/index.html | 217 ++ .../2.9/manual/cowboy_req.match_cookies/index.html | 220 ++ .../2.9/manual/cowboy_req.match_qs/index.html | 219 ++ .../cowboy/2.9/manual/cowboy_req.method/index.html | 210 ++ .../2.9/manual/cowboy_req.parse_cookies/index.html | 218 ++ .../2.9/manual/cowboy_req.parse_header/index.html | 426 +++ .../2.9/manual/cowboy_req.parse_qs/index.html | 207 ++ .../cowboy/2.9/manual/cowboy_req.path/index.html | 199 ++ .../2.9/manual/cowboy_req.path_info/index.html | 193 ++ .../cowboy/2.9/manual/cowboy_req.peer/index.html | 203 ++ .../cowboy/2.9/manual/cowboy_req.port/index.html | 200 ++ .../cowboy/2.9/manual/cowboy_req.push/index.html | 226 ++ docs/en/cowboy/2.9/manual/cowboy_req.qs/index.html | 199 ++ .../index.html | 250 ++ .../2.9/manual/cowboy_req.read_body/index.html | 224 ++ .../2.9/manual/cowboy_req.read_part/index.html | 246 ++ .../manual/cowboy_req.read_part_body/index.html | 222 ++ .../cowboy_req.read_urlencoded_body/index.html | 216 ++ .../cowboy/2.9/manual/cowboy_req.reply/index.html | 238 ++ .../2.9/manual/cowboy_req.resp_header/index.html | 210 ++ .../2.9/manual/cowboy_req.resp_headers/index.html | 190 ++ .../cowboy/2.9/manual/cowboy_req.scheme/index.html | 204 ++ .../2.9/manual/cowboy_req.set_resp_body/index.html | 231 ++ .../manual/cowboy_req.set_resp_cookie/index.html | 256 ++ .../manual/cowboy_req.set_resp_header/index.html | 212 ++ .../manual/cowboy_req.set_resp_headers/index.html | 203 ++ .../cowboy/2.9/manual/cowboy_req.sock/index.html | 199 ++ .../2.9/manual/cowboy_req.stream_body/index.html | 210 ++ .../2.9/manual/cowboy_req.stream_events/index.html | 224 ++ .../2.9/manual/cowboy_req.stream_reply/index.html | 227 ++ .../manual/cowboy_req.stream_trailers/index.html | 207 ++ .../en/cowboy/2.9/manual/cowboy_req.uri/index.html | 258 ++ .../2.9/manual/cowboy_req.version/index.html | 199 ++ docs/en/cowboy/2.9/manual/cowboy_req/index.html | 380 +++ docs/en/cowboy/2.9/manual/cowboy_rest/index.html | 664 +++++ .../2.9/manual/cowboy_router.compile/index.html | 200 ++ docs/en/cowboy/2.9/manual/cowboy_router/index.html | 217 ++ docs/en/cowboy/2.9/manual/cowboy_static/index.html | 275 ++ docs/en/cowboy/2.9/manual/cowboy_stream/index.html | 435 +++ .../cowboy/2.9/manual/cowboy_stream_h/index.html | 199 ++ .../cowboy/2.9/manual/cowboy_tracer_h/index.html | 212 ++ .../cowboy/2.9/manual/cowboy_websocket/index.html | 360 +++ .../cowboy/2.9/manual/http_status_codes/index.html | 244 ++ docs/en/cowboy/2.9/manual/index.html | 239 ++ .../2.10/manual/cow_cookie.cookie/index.html | 2 + .../2.10/manual/cow_cookie.parse_cookie/index.html | 2 + .../manual/cow_cookie.parse_set_cookie/index.html | 2 + .../2.10/manual/cow_cookie.setcookie/index.html | 2 + docs/en/cowlib/2.10/manual/cow_cookie/index.html | 2 + docs/en/cowlib/2.10/manual/cowlib_app/index.html | 2 + docs/en/cowlib/2.10/manual/index.html | 2 + .../2.11/manual/cow_cookie.cookie/index.html | 186 ++ .../2.11/manual/cow_cookie.parse_cookie/index.html | 188 ++ .../manual/cow_cookie.parse_set_cookie/index.html | 195 ++ .../2.11/manual/cow_cookie.setcookie/index.html | 196 ++ docs/en/cowlib/2.11/manual/cow_cookie/index.html | 230 ++ docs/en/cowlib/2.11/manual/cowlib_app/index.html | 177 ++ docs/en/cowlib/2.11/manual/index.html | 177 ++ .../2.8/manual/cow_cookie.parse_cookie/index.html | 2 + .../2.8/manual/cow_cookie.setcookie/index.html | 2 + docs/en/cowlib/2.8/manual/cow_cookie/index.html | 2 + docs/en/cowlib/2.8/manual/cowlib_app/index.html | 2 + docs/en/cowlib/2.8/manual/index.html | 2 + .../cowlib/2.9/manual/cow_cookie.cookie/index.html | 2 + .../2.9/manual/cow_cookie.parse_cookie/index.html | 2 + .../manual/cow_cookie.parse_set_cookie/index.html | 2 + .../2.9/manual/cow_cookie.setcookie/index.html | 2 + docs/en/cowlib/2.9/manual/cow_cookie/index.html | 2 + docs/en/cowlib/2.9/manual/cowlib_app/index.html | 2 + docs/en/cowlib/2.9/manual/index.html | 2 + docs/en/gun/2.0/guide/migrating_from_1.3.asciidoc | 2 +- .../en/gun/2.0/guide/migrating_from_1.3/index.html | 2 +- docs/en/gun/2.0/manual/gun_up/index.html | 2 +- docs/en/ranch/1.4/guide/embedded.asciidoc | 48 - docs/en/ranch/1.4/guide/embedded/index.html | 202 -- docs/en/ranch/1.4/guide/index.html | 174 -- docs/en/ranch/1.4/guide/internals.asciidoc | 94 - docs/en/ranch/1.4/guide/internals/index.html | 202 -- docs/en/ranch/1.4/guide/introduction.asciidoc | 28 - docs/en/ranch/1.4/guide/introduction/index.html | 186 -- docs/en/ranch/1.4/guide/listeners.asciidoc | 320 -- docs/en/ranch/1.4/guide/listeners/index.html | 385 --- docs/en/ranch/1.4/guide/parsers.asciidoc | 92 - docs/en/ranch/1.4/guide/parsers/index.html | 241 -- docs/en/ranch/1.4/guide/protocols.asciidoc | 99 - docs/en/ranch/1.4/guide/protocols/index.html | 248 -- docs/en/ranch/1.4/guide/ssl_auth.asciidoc | 120 - docs/en/ranch/1.4/guide/ssl_auth/index.html | 254 -- docs/en/ranch/1.4/guide/transports.asciidoc | 161 - docs/en/ranch/1.4/guide/transports/index.html | 279 -- docs/en/ranch/1.4/manual/index.html | 170 -- docs/en/ranch/1.4/manual/ranch/index.html | 382 --- docs/en/ranch/1.4/manual/ranch_app/index.html | 168 -- docs/en/ranch/1.4/manual/ranch_protocol/index.html | 183 -- docs/en/ranch/1.4/manual/ranch_ssl/index.html | 324 -- docs/en/ranch/1.4/manual/ranch_tcp/index.html | 277 -- .../en/ranch/1.4/manual/ranch_transport/index.html | 348 --- docs/en/ranch/1.5/guide/embedded/index.html | 4 +- docs/en/ranch/1.5/guide/index.html | 4 +- docs/en/ranch/1.5/guide/internals/index.html | 4 +- docs/en/ranch/1.5/guide/introduction/index.html | 4 +- docs/en/ranch/1.5/guide/listeners/index.html | 4 +- docs/en/ranch/1.5/guide/parsers/index.html | 4 +- docs/en/ranch/1.5/guide/protocols/index.html | 4 +- docs/en/ranch/1.5/guide/ssl_auth/index.html | 4 +- docs/en/ranch/1.5/guide/transports/index.html | 4 +- docs/en/ranch/1.5/manual/index.html | 4 +- docs/en/ranch/1.5/manual/ranch/index.html | 4 +- docs/en/ranch/1.5/manual/ranch_app/index.html | 4 +- docs/en/ranch/1.5/manual/ranch_protocol/index.html | 4 +- docs/en/ranch/1.5/manual/ranch_ssl/index.html | 4 +- docs/en/ranch/1.5/manual/ranch_tcp/index.html | 4 +- .../en/ranch/1.5/manual/ranch_transport/index.html | 4 +- docs/en/ranch/1.6/guide/embedded/index.html | 4 +- docs/en/ranch/1.6/guide/index.html | 4 +- docs/en/ranch/1.6/guide/internals/index.html | 4 +- docs/en/ranch/1.6/guide/introduction/index.html | 4 +- docs/en/ranch/1.6/guide/listeners/index.html | 4 +- .../ranch/1.6/guide/migrating_from_1.5/index.html | 4 +- .../ranch/1.6/guide/migrating_from_1.6/index.html | 4 +- .../ranch/1.6/guide/migrating_from_1.x/index.html | 4 +- docs/en/ranch/1.6/guide/parsers/index.html | 4 +- docs/en/ranch/1.6/guide/protocols/index.html | 4 +- docs/en/ranch/1.6/guide/ssl_auth/index.html | 4 +- docs/en/ranch/1.6/guide/transports/index.html | 4 +- .../1.6/guide/upcoming_2.0_changes/index.html | 4 +- docs/en/ranch/1.6/manual/index.html | 4 +- .../ranch/1.6/manual/ranch.child_spec/index.html | 4 +- docs/en/ranch/1.6/manual/ranch.get_addr/index.html | 4 +- .../manual/ranch.get_max_connections/index.html | 4 +- docs/en/ranch/1.6/manual/ranch.get_port/index.html | 4 +- .../manual/ranch.get_protocol_options/index.html | 4 +- .../ranch/1.6/manual/ranch.get_status/index.html | 4 +- .../manual/ranch.get_transport_options/index.html | 4 +- .../en/ranch/1.6/manual/ranch.handshake/index.html | 4 +- docs/en/ranch/1.6/manual/ranch.info/index.html | 4 +- docs/en/ranch/1.6/manual/ranch.procs/index.html | 4 +- .../1.6/manual/ranch.remove_connection/index.html | 4 +- .../1.6/manual/ranch.resume_listener/index.html | 4 +- .../manual/ranch.set_max_connections/index.html | 4 +- .../manual/ranch.set_protocol_options/index.html | 4 +- .../manual/ranch.set_transport_options/index.html | 4 +- .../1.6/manual/ranch.start_listener/index.html | 4 +- .../1.6/manual/ranch.stop_listener/index.html | 4 +- .../1.6/manual/ranch.suspend_listener/index.html | 4 +- .../manual/ranch.wait_for_connections/index.html | 4 +- docs/en/ranch/1.6/manual/ranch/index.html | 4 +- docs/en/ranch/1.6/manual/ranch_app/index.html | 4 +- docs/en/ranch/1.6/manual/ranch_protocol/index.html | 4 +- docs/en/ranch/1.6/manual/ranch_ssl/index.html | 4 +- docs/en/ranch/1.6/manual/ranch_tcp/index.html | 4 +- .../1.6/manual/ranch_transport.sendfile/index.html | 4 +- .../en/ranch/1.6/manual/ranch_transport/index.html | 4 +- docs/en/ranch/1.7/guide/embedded/index.html | 4 +- docs/en/ranch/1.7/guide/index.html | 4 +- docs/en/ranch/1.7/guide/internals/index.html | 4 +- docs/en/ranch/1.7/guide/introduction/index.html | 4 +- docs/en/ranch/1.7/guide/listeners/index.html | 4 +- .../ranch/1.7/guide/migrating_from_1.5/index.html | 4 +- .../ranch/1.7/guide/migrating_from_1.6/index.html | 4 +- .../ranch/1.7/guide/migrating_from_1.7/index.html | 4 +- .../ranch/1.7/guide/migrating_from_1.x/index.html | 4 +- docs/en/ranch/1.7/guide/parsers/index.html | 4 +- docs/en/ranch/1.7/guide/protocols/index.html | 4 +- docs/en/ranch/1.7/guide/ssl_auth/index.html | 4 +- docs/en/ranch/1.7/guide/transports/index.html | 4 +- .../1.7/guide/upcoming_2.0_changes/index.html | 4 +- docs/en/ranch/1.7/manual/index.html | 4 +- .../ranch/1.7/manual/ranch.child_spec/index.html | 4 +- docs/en/ranch/1.7/manual/ranch.get_addr/index.html | 4 +- .../manual/ranch.get_max_connections/index.html | 4 +- docs/en/ranch/1.7/manual/ranch.get_port/index.html | 4 +- .../manual/ranch.get_protocol_options/index.html | 4 +- .../ranch/1.7/manual/ranch.get_status/index.html | 4 +- .../manual/ranch.get_transport_options/index.html | 4 +- .../en/ranch/1.7/manual/ranch.handshake/index.html | 4 +- docs/en/ranch/1.7/manual/ranch.info/index.html | 4 +- docs/en/ranch/1.7/manual/ranch.procs/index.html | 4 +- .../1.7/manual/ranch.recv_proxy_header/index.html | 4 +- .../1.7/manual/ranch.remove_connection/index.html | 4 +- .../1.7/manual/ranch.resume_listener/index.html | 4 +- .../manual/ranch.set_max_connections/index.html | 4 +- .../manual/ranch.set_protocol_options/index.html | 4 +- .../manual/ranch.set_transport_options/index.html | 4 +- .../1.7/manual/ranch.start_listener/index.html | 4 +- .../1.7/manual/ranch.stop_listener/index.html | 4 +- .../1.7/manual/ranch.suspend_listener/index.html | 4 +- .../manual/ranch.wait_for_connections/index.html | 4 +- docs/en/ranch/1.7/manual/ranch/index.html | 4 +- docs/en/ranch/1.7/manual/ranch_app/index.html | 4 +- docs/en/ranch/1.7/manual/ranch_protocol/index.html | 4 +- .../manual/ranch_proxy_header.header/index.html | 4 +- .../1.7/manual/ranch_proxy_header.parse/index.html | 4 +- .../ranch/1.7/manual/ranch_proxy_header/index.html | 4 +- docs/en/ranch/1.7/manual/ranch_ssl/index.html | 4 +- docs/en/ranch/1.7/manual/ranch_tcp/index.html | 4 +- .../1.7/manual/ranch_transport.sendfile/index.html | 4 +- .../en/ranch/1.7/manual/ranch_transport/index.html | 4 +- docs/en/ranch/1.8/guide/embedded.asciidoc | 48 + docs/en/ranch/1.8/guide/embedded/index.html | 202 ++ docs/en/ranch/1.8/guide/index.html | 191 ++ docs/en/ranch/1.8/guide/internals.asciidoc | 94 + docs/en/ranch/1.8/guide/internals/index.html | 206 ++ docs/en/ranch/1.8/guide/introduction.asciidoc | 25 + docs/en/ranch/1.8/guide/introduction/index.html | 185 ++ docs/en/ranch/1.8/guide/listeners.asciidoc | 364 +++ docs/en/ranch/1.8/guide/listeners/index.html | 421 +++ .../en/ranch/1.8/guide/migrating_from_1.5.asciidoc | 76 + .../ranch/1.8/guide/migrating_from_1.5/index.html | 221 ++ .../en/ranch/1.8/guide/migrating_from_1.6.asciidoc | 46 + .../ranch/1.8/guide/migrating_from_1.6/index.html | 201 ++ .../en/ranch/1.8/guide/migrating_from_1.7.asciidoc | 15 + .../ranch/1.8/guide/migrating_from_1.7/index.html | 185 ++ .../en/ranch/1.8/guide/migrating_from_1.x.asciidoc | 70 + .../ranch/1.8/guide/migrating_from_1.x/index.html | 274 ++ docs/en/ranch/1.8/guide/parsers.asciidoc | 92 + docs/en/ranch/1.8/guide/parsers/index.html | 241 ++ docs/en/ranch/1.8/guide/protocols.asciidoc | 99 + docs/en/ranch/1.8/guide/protocols/index.html | 248 ++ docs/en/ranch/1.8/guide/ssl_auth.asciidoc | 120 + docs/en/ranch/1.8/guide/ssl_auth/index.html | 254 ++ docs/en/ranch/1.8/guide/transports.asciidoc | 172 ++ docs/en/ranch/1.8/guide/transports/index.html | 288 ++ .../ranch/1.8/guide/upcoming_2.0_changes.asciidoc | 34 + .../1.8/guide/upcoming_2.0_changes/index.html | 195 ++ docs/en/ranch/1.8/manual/index.html | 201 ++ .../ranch/1.8/manual/ranch.child_spec/index.html | 219 ++ docs/en/ranch/1.8/manual/ranch.get_addr/index.html | 187 ++ .../manual/ranch.get_max_connections/index.html | 185 ++ docs/en/ranch/1.8/manual/ranch.get_port/index.html | 186 ++ .../manual/ranch.get_protocol_options/index.html | 185 ++ .../ranch/1.8/manual/ranch.get_status/index.html | 188 ++ .../manual/ranch.get_transport_options/index.html | 185 ++ .../en/ranch/1.8/manual/ranch.handshake/index.html | 208 ++ docs/en/ranch/1.8/manual/ranch.info/index.html | 233 ++ docs/en/ranch/1.8/manual/ranch.procs/index.html | 196 ++ .../1.8/manual/ranch.recv_proxy_header/index.html | 206 ++ .../1.8/manual/ranch.remove_connection/index.html | 186 ++ .../1.8/manual/ranch.resume_listener/index.html | 192 ++ .../manual/ranch.set_max_connections/index.html | 190 ++ .../manual/ranch.set_protocol_options/index.html | 190 ++ .../manual/ranch.set_transport_options/index.html | 195 ++ .../1.8/manual/ranch.start_listener/index.html | 244 ++ .../1.8/manual/ranch.stop_listener/index.html | 189 ++ .../1.8/manual/ranch.suspend_listener/index.html | 193 ++ .../manual/ranch.wait_for_connections/index.html | 213 ++ docs/en/ranch/1.8/manual/ranch/index.html | 298 ++ docs/en/ranch/1.8/manual/ranch_app/index.html | 201 ++ docs/en/ranch/1.8/manual/ranch_protocol/index.html | 185 ++ .../manual/ranch_proxy_header.header/index.html | 220 ++ .../1.8/manual/ranch_proxy_header.parse/index.html | 191 ++ .../ranch/1.8/manual/ranch_proxy_header/index.html | 274 ++ docs/en/ranch/1.8/manual/ranch_ssl/index.html | 337 +++ docs/en/ranch/1.8/manual/ranch_tcp/index.html | 284 ++ .../1.8/manual/ranch_transport.sendfile/index.html | 220 ++ .../en/ranch/1.8/manual/ranch_transport/index.html | 385 +++ .../ranch/2.0/guide/connection_draining/index.html | 4 +- docs/en/ranch/2.0/guide/embedded/index.html | 4 +- docs/en/ranch/2.0/guide/index.html | 4 +- docs/en/ranch/2.0/guide/internals/index.html | 4 +- docs/en/ranch/2.0/guide/introduction/index.html | 4 +- docs/en/ranch/2.0/guide/listeners/index.html | 4 +- .../ranch/2.0/guide/migrating_from_1.5/index.html | 4 +- .../ranch/2.0/guide/migrating_from_1.6/index.html | 4 +- .../ranch/2.0/guide/migrating_from_1.7/index.html | 4 +- .../ranch/2.0/guide/migrating_from_1.x/index.html | 4 +- docs/en/ranch/2.0/guide/parsers/index.html | 4 +- docs/en/ranch/2.0/guide/protocols/index.html | 4 +- docs/en/ranch/2.0/guide/ssl_auth/index.html | 4 +- docs/en/ranch/2.0/guide/transports/index.html | 4 +- docs/en/ranch/2.0/manual/index.html | 4 +- .../ranch/2.0/manual/ranch.child_spec/index.html | 4 +- docs/en/ranch/2.0/manual/ranch.get_addr/index.html | 4 +- .../manual/ranch.get_max_connections/index.html | 4 +- docs/en/ranch/2.0/manual/ranch.get_port/index.html | 4 +- .../manual/ranch.get_protocol_options/index.html | 4 +- .../ranch/2.0/manual/ranch.get_status/index.html | 4 +- .../manual/ranch.get_transport_options/index.html | 4 +- .../en/ranch/2.0/manual/ranch.handshake/index.html | 4 +- .../2.0/manual/ranch.handshake_cancel/index.html | 4 +- .../2.0/manual/ranch.handshake_continue/index.html | 4 +- docs/en/ranch/2.0/manual/ranch.info/index.html | 4 +- docs/en/ranch/2.0/manual/ranch.procs/index.html | 4 +- .../2.0/manual/ranch.recv_proxy_header/index.html | 4 +- .../2.0/manual/ranch.remove_connection/index.html | 4 +- .../2.0/manual/ranch.resume_listener/index.html | 4 +- .../manual/ranch.set_max_connections/index.html | 4 +- .../manual/ranch.set_protocol_options/index.html | 4 +- .../manual/ranch.set_transport_options/index.html | 4 +- .../2.0/manual/ranch.start_listener/index.html | 4 +- .../2.0/manual/ranch.stop_listener/index.html | 4 +- .../2.0/manual/ranch.suspend_listener/index.html | 4 +- .../manual/ranch.wait_for_connections/index.html | 4 +- docs/en/ranch/2.0/manual/ranch/index.html | 4 +- docs/en/ranch/2.0/manual/ranch_app/index.html | 4 +- docs/en/ranch/2.0/manual/ranch_protocol/index.html | 4 +- .../manual/ranch_proxy_header.header/index.html | 4 +- .../2.0/manual/ranch_proxy_header.parse/index.html | 4 +- .../ranch/2.0/manual/ranch_proxy_header/index.html | 4 +- docs/en/ranch/2.0/manual/ranch_ssl/index.html | 4 +- docs/en/ranch/2.0/manual/ranch_tcp/index.html | 4 +- .../2.0/manual/ranch_transport.sendfile/index.html | 4 +- .../en/ranch/2.0/manual/ranch_transport/index.html | 4 +- docs/index.html | 33 +- docs/index.xml | 2432 +++++++++------ 1093 files changed, 60186 insertions(+), 46559 deletions(-) delete mode 100644 docs/en/cowboy/2.3/guide/constraints.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/constraints/index.html delete mode 100644 docs/en/cowboy/2.3/guide/cookies.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/cookies/index.html delete mode 100644 docs/en/cowboy/2.3/guide/cowboy.sty delete mode 100644 docs/en/cowboy/2.3/guide/erlang_web.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/erlang_web/index.html delete mode 100644 docs/en/cowboy/2.3/guide/flow_diagram.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/flow_diagram/index.html delete mode 100644 docs/en/cowboy/2.3/guide/getting_started.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/getting_started/index.html delete mode 100644 docs/en/cowboy/2.3/guide/handlers.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/handlers/index.html delete mode 100644 docs/en/cowboy/2.3/guide/http_req_resp.png delete mode 100644 docs/en/cowboy/2.3/guide/http_req_resp.svg delete mode 100644 docs/en/cowboy/2.3/guide/index.html delete mode 100644 docs/en/cowboy/2.3/guide/introduction.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/introduction/index.html delete mode 100644 docs/en/cowboy/2.3/guide/listeners.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/listeners/index.html delete mode 100644 docs/en/cowboy/2.3/guide/loop_handlers.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/loop_handlers/index.html delete mode 100644 docs/en/cowboy/2.3/guide/middlewares.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/middlewares/index.html delete mode 100644 docs/en/cowboy/2.3/guide/migrating_from_1.0.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/migrating_from_1.0/index.html delete mode 100644 docs/en/cowboy/2.3/guide/migrating_from_2.0.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/migrating_from_2.0/index.html delete mode 100644 docs/en/cowboy/2.3/guide/migrating_from_2.1.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/migrating_from_2.1/index.html delete mode 100644 docs/en/cowboy/2.3/guide/migrating_from_2.2.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/migrating_from_2.2/index.html delete mode 100644 docs/en/cowboy/2.3/guide/modern_web.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/modern_web/index.html delete mode 100644 docs/en/cowboy/2.3/guide/multipart.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/multipart/index.html delete mode 100644 docs/en/cowboy/2.3/guide/req.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/req/index.html delete mode 100644 docs/en/cowboy/2.3/guide/req_body.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/req_body/index.html delete mode 100644 docs/en/cowboy/2.3/guide/resource_design.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/resource_design/index.html delete mode 100644 docs/en/cowboy/2.3/guide/resp.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/resp/index.html delete mode 100644 docs/en/cowboy/2.3/guide/rest_cond.png delete mode 100644 docs/en/cowboy/2.3/guide/rest_cond.svg delete mode 100644 docs/en/cowboy/2.3/guide/rest_conneg.png delete mode 100644 docs/en/cowboy/2.3/guide/rest_conneg.svg delete mode 100644 docs/en/cowboy/2.3/guide/rest_delete.png delete mode 100644 docs/en/cowboy/2.3/guide/rest_delete.svg delete mode 100644 docs/en/cowboy/2.3/guide/rest_flowcharts.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/rest_flowcharts/index.html delete mode 100644 docs/en/cowboy/2.3/guide/rest_get_head.png delete mode 100644 docs/en/cowboy/2.3/guide/rest_get_head.svg delete mode 100644 docs/en/cowboy/2.3/guide/rest_handlers.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/rest_handlers/index.html delete mode 100644 docs/en/cowboy/2.3/guide/rest_options.png delete mode 100644 docs/en/cowboy/2.3/guide/rest_options.svg delete mode 100644 docs/en/cowboy/2.3/guide/rest_principles.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/rest_principles/index.html delete mode 100644 docs/en/cowboy/2.3/guide/rest_put_post_patch.png delete mode 100644 docs/en/cowboy/2.3/guide/rest_put_post_patch.svg delete mode 100644 docs/en/cowboy/2.3/guide/rest_start.png delete mode 100644 docs/en/cowboy/2.3/guide/rest_start.svg delete mode 100644 docs/en/cowboy/2.3/guide/routing.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/routing/index.html delete mode 100644 docs/en/cowboy/2.3/guide/specs.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/specs/index.html delete mode 100644 docs/en/cowboy/2.3/guide/static_files.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/static_files/index.html delete mode 100644 docs/en/cowboy/2.3/guide/streams.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/streams/index.html delete mode 100644 docs/en/cowboy/2.3/guide/ws_handlers.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/ws_handlers/index.html delete mode 100644 docs/en/cowboy/2.3/guide/ws_protocol.asciidoc delete mode 100644 docs/en/cowboy/2.3/guide/ws_protocol/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy.set_env/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy.start_clear/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy.start_tls/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy.stop_listener/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_app/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_constraints.int/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_constraints.nonempty/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_constraints/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_handler.terminate/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_handler/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_http/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_http2/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_loop/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_middleware/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.binding/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.bindings/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.body_length/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.cert/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.delete_resp_header/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.has_body/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.has_resp_body/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.has_resp_header/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.header/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.headers/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.host/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.host_info/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.inform/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.match_cookies/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.match_qs/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.method/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.parse_cookies/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.parse_header/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.parse_qs/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.path/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.path_info/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.peer/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.port/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.push/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.qs/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.read_body/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.read_part/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.read_part_body/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.read_urlencoded_body/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.reply/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.resp_header/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.resp_headers/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.scheme/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.set_resp_body/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.set_resp_cookie/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.set_resp_header/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.set_resp_headers/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.sock/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.stream_body/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.stream_reply/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.stream_trailers/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.uri/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req.version/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_req/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_rest/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_router.compile/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_router/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_static/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_stream/index.html delete mode 100644 docs/en/cowboy/2.3/manual/cowboy_websocket/index.html delete mode 100644 docs/en/cowboy/2.3/manual/http_status_codes/index.html delete mode 100644 docs/en/cowboy/2.3/manual/index.html create mode 100644 docs/en/cowboy/2.9/guide/constraints.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/constraints/index.html create mode 100644 docs/en/cowboy/2.9/guide/cookies.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/cookies/index.html create mode 100644 docs/en/cowboy/2.9/guide/cowboy.sty create mode 100644 docs/en/cowboy/2.9/guide/erlang_web.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/erlang_web/index.html create mode 100644 docs/en/cowboy/2.9/guide/flow_diagram.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/flow_diagram/index.html create mode 100644 docs/en/cowboy/2.9/guide/getting_started.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/getting_started/index.html create mode 100644 docs/en/cowboy/2.9/guide/handlers.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/handlers/index.html create mode 100644 docs/en/cowboy/2.9/guide/http_req_resp.png create mode 100644 docs/en/cowboy/2.9/guide/http_req_resp.svg create mode 100644 docs/en/cowboy/2.9/guide/index.html create mode 100644 docs/en/cowboy/2.9/guide/introduction.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/introduction/index.html create mode 100644 docs/en/cowboy/2.9/guide/listeners.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/listeners/index.html create mode 100644 docs/en/cowboy/2.9/guide/loop_handlers.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/loop_handlers/index.html create mode 100644 docs/en/cowboy/2.9/guide/middlewares.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/middlewares/index.html create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_1.0.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_1.0/index.html create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.0.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.0/index.html create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.1.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.1/index.html create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.2.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.2/index.html create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.3.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.3/index.html create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.4.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.4/index.html create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.5.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.5/index.html create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.6.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.6/index.html create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.7.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.7/index.html create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.8.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/migrating_from_2.8/index.html create mode 100644 docs/en/cowboy/2.9/guide/modern_web.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/modern_web/index.html create mode 100644 docs/en/cowboy/2.9/guide/multipart.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/multipart/index.html create mode 100644 docs/en/cowboy/2.9/guide/performance.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/performance/index.html create mode 100644 docs/en/cowboy/2.9/guide/req.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/req/index.html create mode 100644 docs/en/cowboy/2.9/guide/req_body.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/req_body/index.html create mode 100644 docs/en/cowboy/2.9/guide/resource_design.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/resource_design/index.html create mode 100644 docs/en/cowboy/2.9/guide/resp.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/resp/index.html create mode 100644 docs/en/cowboy/2.9/guide/rest_cond.png create mode 100644 docs/en/cowboy/2.9/guide/rest_cond.svg create mode 100644 docs/en/cowboy/2.9/guide/rest_conneg.png create mode 100644 docs/en/cowboy/2.9/guide/rest_conneg.svg create mode 100644 docs/en/cowboy/2.9/guide/rest_delete.png create mode 100644 docs/en/cowboy/2.9/guide/rest_delete.svg create mode 100644 docs/en/cowboy/2.9/guide/rest_flowcharts.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/rest_flowcharts/index.html create mode 100644 docs/en/cowboy/2.9/guide/rest_get_head.png create mode 100644 docs/en/cowboy/2.9/guide/rest_get_head.svg create mode 100644 docs/en/cowboy/2.9/guide/rest_handlers.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/rest_handlers/index.html create mode 100644 docs/en/cowboy/2.9/guide/rest_options.png create mode 100644 docs/en/cowboy/2.9/guide/rest_options.svg create mode 100644 docs/en/cowboy/2.9/guide/rest_principles.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/rest_principles/index.html create mode 100644 docs/en/cowboy/2.9/guide/rest_put_post_patch.png create mode 100644 docs/en/cowboy/2.9/guide/rest_put_post_patch.svg create mode 100644 docs/en/cowboy/2.9/guide/rest_start.png create mode 100644 docs/en/cowboy/2.9/guide/rest_start.svg create mode 100644 docs/en/cowboy/2.9/guide/routing.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/routing/index.html create mode 100644 docs/en/cowboy/2.9/guide/specs.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/specs/index.html create mode 100644 docs/en/cowboy/2.9/guide/static_files.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/static_files/index.html create mode 100644 docs/en/cowboy/2.9/guide/streams.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/streams/index.html create mode 100644 docs/en/cowboy/2.9/guide/ws_handlers.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/ws_handlers/index.html create mode 100644 docs/en/cowboy/2.9/guide/ws_protocol.asciidoc create mode 100644 docs/en/cowboy/2.9/guide/ws_protocol/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy.set_env/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy.start_clear/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy.start_tls/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy.stop_listener/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_app/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_compress_h/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_constraints.int/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_constraints.nonempty/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_constraints/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_handler.terminate/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_handler/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_http/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_http2/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_loop/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_metrics_h/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_middleware/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.binding/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.bindings/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.body_length/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.cast/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.cert/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.delete_resp_header/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.filter_cookies/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.has_body/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.has_resp_body/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.has_resp_header/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.header/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.headers/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.host/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.host_info/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.inform/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.match_cookies/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.match_qs/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.method/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.parse_cookies/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.parse_header/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.parse_qs/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.path/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.path_info/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.peer/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.port/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.push/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.qs/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.read_and_match_urlencoded_body/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.read_body/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.read_part/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.read_part_body/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.read_urlencoded_body/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.reply/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.resp_header/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.resp_headers/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.scheme/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.set_resp_body/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.set_resp_cookie/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.set_resp_header/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.set_resp_headers/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.sock/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.stream_body/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.stream_events/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.stream_reply/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.stream_trailers/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.uri/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req.version/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_req/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_rest/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_router.compile/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_router/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_static/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_stream/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_stream_h/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_tracer_h/index.html create mode 100644 docs/en/cowboy/2.9/manual/cowboy_websocket/index.html create mode 100644 docs/en/cowboy/2.9/manual/http_status_codes/index.html create mode 100644 docs/en/cowboy/2.9/manual/index.html create mode 100644 docs/en/cowlib/2.11/manual/cow_cookie.cookie/index.html create mode 100644 docs/en/cowlib/2.11/manual/cow_cookie.parse_cookie/index.html create mode 100644 docs/en/cowlib/2.11/manual/cow_cookie.parse_set_cookie/index.html create mode 100644 docs/en/cowlib/2.11/manual/cow_cookie.setcookie/index.html create mode 100644 docs/en/cowlib/2.11/manual/cow_cookie/index.html create mode 100644 docs/en/cowlib/2.11/manual/cowlib_app/index.html create mode 100644 docs/en/cowlib/2.11/manual/index.html delete mode 100644 docs/en/ranch/1.4/guide/embedded.asciidoc delete mode 100644 docs/en/ranch/1.4/guide/embedded/index.html delete mode 100644 docs/en/ranch/1.4/guide/index.html delete mode 100644 docs/en/ranch/1.4/guide/internals.asciidoc delete mode 100644 docs/en/ranch/1.4/guide/internals/index.html delete mode 100644 docs/en/ranch/1.4/guide/introduction.asciidoc delete mode 100644 docs/en/ranch/1.4/guide/introduction/index.html delete mode 100644 docs/en/ranch/1.4/guide/listeners.asciidoc delete mode 100644 docs/en/ranch/1.4/guide/listeners/index.html delete mode 100644 docs/en/ranch/1.4/guide/parsers.asciidoc delete mode 100644 docs/en/ranch/1.4/guide/parsers/index.html delete mode 100644 docs/en/ranch/1.4/guide/protocols.asciidoc delete mode 100644 docs/en/ranch/1.4/guide/protocols/index.html delete mode 100644 docs/en/ranch/1.4/guide/ssl_auth.asciidoc delete mode 100644 docs/en/ranch/1.4/guide/ssl_auth/index.html delete mode 100644 docs/en/ranch/1.4/guide/transports.asciidoc delete mode 100644 docs/en/ranch/1.4/guide/transports/index.html delete mode 100644 docs/en/ranch/1.4/manual/index.html delete mode 100644 docs/en/ranch/1.4/manual/ranch/index.html delete mode 100644 docs/en/ranch/1.4/manual/ranch_app/index.html delete mode 100644 docs/en/ranch/1.4/manual/ranch_protocol/index.html delete mode 100644 docs/en/ranch/1.4/manual/ranch_ssl/index.html delete mode 100644 docs/en/ranch/1.4/manual/ranch_tcp/index.html delete mode 100644 docs/en/ranch/1.4/manual/ranch_transport/index.html create mode 100644 docs/en/ranch/1.8/guide/embedded.asciidoc create mode 100644 docs/en/ranch/1.8/guide/embedded/index.html create mode 100644 docs/en/ranch/1.8/guide/index.html create mode 100644 docs/en/ranch/1.8/guide/internals.asciidoc create mode 100644 docs/en/ranch/1.8/guide/internals/index.html create mode 100644 docs/en/ranch/1.8/guide/introduction.asciidoc create mode 100644 docs/en/ranch/1.8/guide/introduction/index.html create mode 100644 docs/en/ranch/1.8/guide/listeners.asciidoc create mode 100644 docs/en/ranch/1.8/guide/listeners/index.html create mode 100644 docs/en/ranch/1.8/guide/migrating_from_1.5.asciidoc create mode 100644 docs/en/ranch/1.8/guide/migrating_from_1.5/index.html create mode 100644 docs/en/ranch/1.8/guide/migrating_from_1.6.asciidoc create mode 100644 docs/en/ranch/1.8/guide/migrating_from_1.6/index.html create mode 100644 docs/en/ranch/1.8/guide/migrating_from_1.7.asciidoc create mode 100644 docs/en/ranch/1.8/guide/migrating_from_1.7/index.html create mode 100644 docs/en/ranch/1.8/guide/migrating_from_1.x.asciidoc create mode 100644 docs/en/ranch/1.8/guide/migrating_from_1.x/index.html create mode 100644 docs/en/ranch/1.8/guide/parsers.asciidoc create mode 100644 docs/en/ranch/1.8/guide/parsers/index.html create mode 100644 docs/en/ranch/1.8/guide/protocols.asciidoc create mode 100644 docs/en/ranch/1.8/guide/protocols/index.html create mode 100644 docs/en/ranch/1.8/guide/ssl_auth.asciidoc create mode 100644 docs/en/ranch/1.8/guide/ssl_auth/index.html create mode 100644 docs/en/ranch/1.8/guide/transports.asciidoc create mode 100644 docs/en/ranch/1.8/guide/transports/index.html create mode 100644 docs/en/ranch/1.8/guide/upcoming_2.0_changes.asciidoc create mode 100644 docs/en/ranch/1.8/guide/upcoming_2.0_changes/index.html create mode 100644 docs/en/ranch/1.8/manual/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.child_spec/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.get_addr/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.get_max_connections/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.get_port/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.get_protocol_options/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.get_status/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.get_transport_options/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.handshake/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.info/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.procs/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.recv_proxy_header/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.remove_connection/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.resume_listener/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.set_max_connections/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.set_protocol_options/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.set_transport_options/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.start_listener/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.stop_listener/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.suspend_listener/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch.wait_for_connections/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch_app/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch_protocol/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch_proxy_header.header/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch_proxy_header.parse/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch_proxy_header/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch_ssl/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch_tcp/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch_transport.sendfile/index.html create mode 100644 docs/en/ranch/1.8/manual/ranch_transport/index.html (limited to 'docs') diff --git a/docs/en/cowboy/2.3/guide/constraints.asciidoc b/docs/en/cowboy/2.3/guide/constraints.asciidoc deleted file mode 100644 index 6cc10752..00000000 --- a/docs/en/cowboy/2.3/guide/constraints.asciidoc +++ /dev/null @@ -1,123 +0,0 @@ -[[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.3/guide/constraints/index.html b/docs/en/cowboy/2.3/guide/constraints/index.html deleted file mode 100644 index f30cd1f5..00000000 --- a/docs/en/cowboy/2.3/guide/constraints/index.html +++ /dev/null @@ -1,260 +0,0 @@ - - - - - - - - - - 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:

- - - - - - - - - -
ConstraintDescription
intConverts binary value to integer.
nonemptyEnsures 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/cookies.asciidoc b/docs/en/cowboy/2.3/guide/cookies.asciidoc deleted file mode 100644 index 4825031b..00000000 --- a/docs/en/cowboy/2.3/guide/cookies.asciidoc +++ /dev/null @@ -1,139 +0,0 @@ -[[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.3/guide/cookies/index.html b/docs/en/cowboy/2.3/guide/cookies/index.html deleted file mode 100644 index d50ac4a4..00000000 --- a/docs/en/cowboy/2.3/guide/cookies/index.html +++ /dev/null @@ -1,277 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/cowboy.sty b/docs/en/cowboy/2.3/guide/cowboy.sty deleted file mode 100644 index d5e0d3be..00000000 --- a/docs/en/cowboy/2.3/guide/cowboy.sty +++ /dev/null @@ -1,8 +0,0 @@ -\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.3/guide/erlang_web.asciidoc b/docs/en/cowboy/2.3/guide/erlang_web.asciidoc deleted file mode 100644 index f528adc3..00000000 --- a/docs/en/cowboy/2.3/guide/erlang_web.asciidoc +++ /dev/null @@ -1,209 +0,0 @@ -[[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.3/guide/erlang_web/index.html b/docs/en/cowboy/2.3/guide/erlang_web/index.html deleted file mode 100644 index ad6a3f3c..00000000 --- a/docs/en/cowboy/2.3/guide/erlang_web/index.html +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/flow_diagram.asciidoc b/docs/en/cowboy/2.3/guide/flow_diagram.asciidoc deleted file mode 100644 index 2d35d4d6..00000000 --- a/docs/en/cowboy/2.3/guide/flow_diagram.asciidoc +++ /dev/null @@ -1,109 +0,0 @@ -[[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.3/guide/flow_diagram/index.html b/docs/en/cowboy/2.3/guide/flow_diagram/index.html deleted file mode 100644 index 2e71a426..00000000 --- a/docs/en/cowboy/2.3/guide/flow_diagram/index.html +++ /dev/null @@ -1,204 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/getting_started.asciidoc b/docs/en/cowboy/2.3/guide/getting_started.asciidoc deleted file mode 100644 index 2d2adb09..00000000 --- a/docs/en/cowboy/2.3/guide/getting_started.asciidoc +++ /dev/null @@ -1,147 +0,0 @@ -[[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.3.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.3/guide/getting_started/index.html b/docs/en/cowboy/2.3/guide/getting_started/index.html deleted file mode 100644 index a6961504..00000000 --- a/docs/en/cowboy/2.3/guide/getting_started/index.html +++ /dev/null @@ -1,278 +0,0 @@ - - - - - - - - - - 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.3.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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/handlers.asciidoc b/docs/en/cowboy/2.3/guide/handlers.asciidoc deleted file mode 100644 index fe6f4623..00000000 --- a/docs/en/cowboy/2.3/guide/handlers.asciidoc +++ /dev/null @@ -1,90 +0,0 @@ -[[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.3/guide/handlers/index.html b/docs/en/cowboy/2.3/guide/handlers/index.html deleted file mode 100644 index 1e1a463e..00000000 --- a/docs/en/cowboy/2.3/guide/handlers/index.html +++ /dev/null @@ -1,231 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/http_req_resp.png b/docs/en/cowboy/2.3/guide/http_req_resp.png deleted file mode 100644 index 41c17c8a..00000000 Binary files a/docs/en/cowboy/2.3/guide/http_req_resp.png and /dev/null differ diff --git a/docs/en/cowboy/2.3/guide/http_req_resp.svg b/docs/en/cowboy/2.3/guide/http_req_resp.svg deleted file mode 100644 index acedb152..00000000 --- a/docs/en/cowboy/2.3/guide/http_req_resp.svg +++ /dev/null @@ -1,543 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - some text - - - - acceptor - - - - - protocol - - - - router - - some text - - - handler - - middlewares - some text - - - client - - - - stream - - - diff --git a/docs/en/cowboy/2.3/guide/index.html b/docs/en/cowboy/2.3/guide/index.html deleted file mode 100644 index 42636ad2..00000000 --- a/docs/en/cowboy/2.3/guide/index.html +++ /dev/null @@ -1,237 +0,0 @@ - - - - - - - - - - Nine Nines: Cowboy User Guide - - - - - - - - - - - - - - -
-
-
-
-

99s

-
-
- -
- -
    -
  • - Github -
    • -
  • - -
    • -
-
-
-
-
- - -
- -
-
-
- - -
- - -

- Cowboy - 2.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/introduction.asciidoc b/docs/en/cowboy/2.3/guide/introduction.asciidoc deleted file mode 100644 index 1f9b52e4..00000000 --- a/docs/en/cowboy/2.3/guide/introduction.asciidoc +++ /dev/null @@ -1,75 +0,0 @@ -[[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.3/guide/introduction/index.html b/docs/en/cowboy/2.3/guide/introduction/index.html deleted file mode 100644 index 9b670732..00000000 --- a/docs/en/cowboy/2.3/guide/introduction/index.html +++ /dev/null @@ -1,214 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/listeners.asciidoc b/docs/en/cowboy/2.3/guide/listeners.asciidoc deleted file mode 100644 index 10ac4aad..00000000 --- a/docs/en/cowboy/2.3/guide/listeners.asciidoc +++ /dev/null @@ -1,115 +0,0 @@ -[[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.3/guide/listeners/index.html b/docs/en/cowboy/2.3/guide/listeners/index.html deleted file mode 100644 index 44c1ac59..00000000 --- a/docs/en/cowboy/2.3/guide/listeners/index.html +++ /dev/null @@ -1,235 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/loop_handlers.asciidoc b/docs/en/cowboy/2.3/guide/loop_handlers.asciidoc deleted file mode 100644 index 21bf8424..00000000 --- a/docs/en/cowboy/2.3/guide/loop_handlers.asciidoc +++ /dev/null @@ -1,128 +0,0 @@ -[[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.3/guide/loop_handlers/index.html b/docs/en/cowboy/2.3/guide/loop_handlers/index.html deleted file mode 100644 index 2aebadcd..00000000 --- a/docs/en/cowboy/2.3/guide/loop_handlers/index.html +++ /dev/null @@ -1,246 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/middlewares.asciidoc b/docs/en/cowboy/2.3/guide/middlewares.asciidoc deleted file mode 100644 index e6be30dd..00000000 --- a/docs/en/cowboy/2.3/guide/middlewares.asciidoc +++ /dev/null @@ -1,69 +0,0 @@ -[[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.3/guide/middlewares/index.html b/docs/en/cowboy/2.3/guide/middlewares/index.html deleted file mode 100644 index 7f7998e3..00000000 --- a/docs/en/cowboy/2.3/guide/middlewares/index.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/migrating_from_1.0.asciidoc b/docs/en/cowboy/2.3/guide/migrating_from_1.0.asciidoc deleted file mode 100644 index 4f4ea5bf..00000000 --- a/docs/en/cowboy/2.3/guide/migrating_from_1.0.asciidoc +++ /dev/null @@ -1,214 +0,0 @@ -[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.3/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.3/guide/migrating_from_1.0/index.html deleted file mode 100644 index 455ab1f8..00000000 --- a/docs/en/cowboy/2.3/guide/migrating_from_1.0/index.html +++ /dev/null @@ -1,294 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/migrating_from_2.0.asciidoc b/docs/en/cowboy/2.3/guide/migrating_from_2.0.asciidoc deleted file mode 100644 index c76430c2..00000000 --- a/docs/en/cowboy/2.3/guide/migrating_from_2.0.asciidoc +++ /dev/null @@ -1,107 +0,0 @@ -[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.3/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.3/guide/migrating_from_2.0/index.html deleted file mode 100644 index e910e003..00000000 --- a/docs/en/cowboy/2.3/guide/migrating_from_2.0/index.html +++ /dev/null @@ -1,229 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/migrating_from_2.1.asciidoc b/docs/en/cowboy/2.3/guide/migrating_from_2.1.asciidoc deleted file mode 100644 index 3c0681ff..00000000 --- a/docs/en/cowboy/2.3/guide/migrating_from_2.1.asciidoc +++ /dev/null @@ -1,107 +0,0 @@ -[appendix] -== Migrating from Cowboy 2.1 to 2.2 - -Cowboy 2.2 focused on adding features required for writing -gRPC servers and on completing test suites for the core -HTTP RFCs, fixing many bugs along the way. - -=== Features added - -* Add support for sending trailers at the end of response bodies. - Trailers are additional header fields that may be sent after the - body to add more information to the response. Their usage is - required in gRPC servers. They are optional and may be discarded - in other scenarios (for example if the request goes through an - HTTP/1.0 proxy, as HTTP/1.0 does not support trailers). - -* The `max_skip_body_length` option was added to `cowboy_http`. - It controls how much of a request body Cowboy is willing to skip - when the handler did not touch it. If the remaining body size is - too large Cowboy instead closes the connection. It defaults to 1MB. - -* The CONNECT and TRACE methods are now rejected as they are - currently not implemented and must be handled differently than - other methods. They will be implemented in a future release. - -=== New functions - -* The function `stream_trailers/2` has been added. It terminates - a stream and adds trailer fields at the end of the response. A - corresponding stream handler command `{trailers, Trailers}` - has also been added. - -=== Bugs fixed - -* Test suites for the core HTTP RFCs RFC7230, RFC7231 and RFC7540 - have been completed. Many of the bugs listed here were fixed as - a result of this work. - -* Many HTTP/2 edge cases when clients are misbehaving have been - corrected. This includes many cases where the request is malformed - (for example when a pseudo-header is present twice). - -* When the HTTP/2 SETTINGS_INITIAL_WINDOW_SIZE value changes, - Cowboy now properly updates the flow control windows. - -* HTTP/2 could mistakenly log stray messages that actually were - expected. This is no longer the case. - -* We no longer send a GOAWAY frame when the HTTP/2 preface is invalid. - -* Some values in the Req object of pushed requests were in the - wrong type. They are now the expected binary instead of iolist. - -* A response body was sometimes sent in response to HEAD requests - when using HTTP/2. The body is now ignored. - -* The `max_headers` option for `cowboy_http` was not always respected - depending on the contents of the buffer. The limit is now strict. - -* When an early error occurred on the HTTP/1.1 request line, the - partial Req given to stream handlers was missing the `ref` and - `peer` information. This has been corrected. - -* Absolute URIs with a userinfo component, or without an authority - component, are now properly rejected for HTTP/1.0 and HTTP/1.1. - -* Whitespace is no longer allowed in header lines before the colon. - -* 408 responses to HTTP/1.1 requests now properly include a - connection: close header indicating that we are going to - close the connection. This header will also be sent for - other early errors resulting in the closing of the connection. - -* When both the transfer-encoding and content-length headers are - sent in an HTTP/1.1 request, the transfer-encoding now takes - precedence over the content-length header and the latter is - removed from the Req object. - -* A 400 response is now returned when the transfer-encoding - header is invalid or contains any transfer-coding other - than chunked. - -* Invalid chunk sizes are now rejected immediately. - -* Chunk extensions are now limited to 129 characters. They are - not used in practice and are still ignored by Cowboy. The limit - is not configurable. - -* The final chunk was mistakenly sent in responses to HEAD - requests. This is now corrected. - -* `OPTIONS *` requests were broken in Cowboy 2.0. They are now - working again. Both the routing and `cowboy_req:uri/1,2` have - been corrected. - -* 204 responses no longer include a content-length header. - -* A packet could be lost when switching to Websocket or any - other protocol via the `switch_protocol` command. This is - now fixed. - -* A 426 response will now be sent when a handler requires - the client to upgrade to Websocket and the request did not - include the required headers. - -* Both experimental stream handlers `cowboy_metrics_h` and - `cowboy_tracer_h` received a number of fixes and improvements. diff --git a/docs/en/cowboy/2.3/guide/migrating_from_2.1/index.html b/docs/en/cowboy/2.3/guide/migrating_from_2.1/index.html deleted file mode 100644 index 061b6d8c..00000000 --- a/docs/en/cowboy/2.3/guide/migrating_from_2.1/index.html +++ /dev/null @@ -1,240 +0,0 @@ - - - - - - - - - - Nine Nines: Migrating from Cowboy 2.1 to 2.2 - - - - - - - - - - - - - - -
-
-
-
-

99s

-
-
- -
- -
    -
  • - Github -
    • -
  • - -
    • -
-
-
-
-
- - -
- -
-
-
-
- -

Migrating from Cowboy 2.1 to 2.2

- -

Cowboy 2.2 focused on adding features required for writing gRPC servers and on completing test suites for the core HTTP RFCs, fixing many bugs along the way.

-

Features added

-
  • Add support for sending trailers at the end of response bodies. Trailers are additional header fields that may be sent after the body to add more information to the response. Their usage is required in gRPC servers. They are optional and may be discarded in other scenarios (for example if the request goes through an HTTP/1.0 proxy, as HTTP/1.0 does not support trailers). -
    • -
  • The max_skip_body_length option was added to cowboy_http. It controls how much of a request body Cowboy is willing to skip when the handler did not touch it. If the remaining body size is too large Cowboy instead closes the connection. It defaults to 1MB. -
    • -
  • The CONNECT and TRACE methods are now rejected as they are currently not implemented and must be handled differently than other methods. They will be implemented in a future release. -
    • -
-

New functions

-
  • The function stream_trailers/2 has been added. It terminates a stream and adds trailer fields at the end of the response. A corresponding stream handler command {trailers, Trailers} has also been added. -
    • -
-

Bugs fixed

-
  • Test suites for the core HTTP RFCs RFC7230, RFC7231 and RFC7540 have been completed. Many of the bugs listed here were fixed as a result of this work. -
    • -
  • Many HTTP/2 edge cases when clients are misbehaving have been corrected. This includes many cases where the request is malformed (for example when a pseudo-header is present twice). -
    • -
  • When the HTTP/2 SETTINGS_INITIAL_WINDOW_SIZE value changes, Cowboy now properly updates the flow control windows. -
    • -
  • HTTP/2 could mistakenly log stray messages that actually were expected. This is no longer the case. -
    • -
  • We no longer send a GOAWAY frame when the HTTP/2 preface is invalid. -
    • -
  • Some values in the Req object of pushed requests were in the wrong type. They are now the expected binary instead of iolist. -
    • -
  • A response body was sometimes sent in response to HEAD requests when using HTTP/2. The body is now ignored. -
    • -
  • The max_headers option for cowboy_http was not always respected depending on the contents of the buffer. The limit is now strict. -
    • -
  • When an early error occurred on the HTTP/1.1 request line, the partial Req given to stream handlers was missing the ref and peer information. This has been corrected. -
    • -
  • Absolute URIs with a userinfo component, or without an authority component, are now properly rejected for HTTP/1.0 and HTTP/1.1. -
    • -
  • Whitespace is no longer allowed in header lines before the colon. -
    • -
  • 408 responses to HTTP/1.1 requests now properly include a connection: close header indicating that we are going to close the connection. This header will also be sent for other early errors resulting in the closing of the connection. -
    • -
  • When both the transfer-encoding and content-length headers are sent in an HTTP/1.1 request, the transfer-encoding now takes precedence over the content-length header and the latter is removed from the Req object. -
    • -
  • A 400 response is now returned when the transfer-encoding header is invalid or contains any transfer-coding other than chunked. -
    • -
  • Invalid chunk sizes are now rejected immediately. -
    • -
  • Chunk extensions are now limited to 129 characters. They are not used in practice and are still ignored by Cowboy. The limit is not configurable. -
    • -
  • The final chunk was mistakenly sent in responses to HEAD requests. This is now corrected. -
    • -
  • OPTIONS * requests were broken in Cowboy 2.0. They are now working again. Both the routing and cowboy_req:uri/1,2 have been corrected. -
    • -
  • 204 responses no longer include a content-length header. -
    • -
  • A packet could be lost when switching to Websocket or any other protocol via the switch_protocol command. This is now fixed. -
    • -
  • A 426 response will now be sent when a handler requires the client to upgrade to Websocket and the request did not include the required headers. -
    • -
  • Both experimental stream handlers cowboy_metrics_h and cowboy_tracer_h received a number of fixes and improvements. -
    • -
- - - - - - - - - - - - - - - - -
- -
- - -

- Cowboy - 2.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/migrating_from_2.2.asciidoc b/docs/en/cowboy/2.3/guide/migrating_from_2.2.asciidoc deleted file mode 100644 index dacf790e..00000000 --- a/docs/en/cowboy/2.3/guide/migrating_from_2.2.asciidoc +++ /dev/null @@ -1,56 +0,0 @@ -[appendix] -== Migrating from Cowboy 2.2 to 2.3 - -Cowboy 2.3 focused on making the Cowboy processes behave -properly according to OTP principles. This version is a -very good milestone toward that goal and most of everything -should now work. Release upgrades and a few details will -be improved in future versions. - -=== Features added - -* Add support for all functions from the module `sys`. Note - that Cowboy currently does not implement the `sys` debugging - mechanisms as tracing is recommended instead. - -* Add a `max_frame_size` option for Websocket handlers - to close the connection when the client attempts to - send a frame that's too large. It currently defaults - to `infinity` to avoid breaking existing code but will - be changed in a future version. - -* Update Cowlib to 2.2.1. - -* Add support for the 308 status code and a test suite - for RFC7538 where it is defined. - -=== Bugs fixed - -* Ensure timeout options accept the value `infinity` as - documented. - -* Properly reject HTTP/2 requests with an invalid content-length - header instead of simply crashing. - -* When switching from HTTP/1.1 to Websocket or user protocols - all the messages in the mailbox were flushed. Only messages - specific to `cowboy_http` should now be flushed. - -* Parsing of the x-forwarded-for header has been corrected. - It now supports IPv6 addresses both with and without port. - -* Websocket subprotocol tokens are now parsed in a case - insensitive manner, according to the spec. - -* Cookies without values are now allowed. For example `Cookie: foo`. - -* Colons are now allowed within path segments in routes provided - to `cowboy_router:compile/1` as long as they are not the first - character of the path segment. - -* The `cowboy_req:delete_resp_header/2` function will no longer - crash when no response header was set before calling it. - -* A miscount of the output HTTP/2 flow control window has been - fixed. It prevented sending the response body fully to some - clients. The issue only affected response bodies sent as iolists. diff --git a/docs/en/cowboy/2.3/guide/migrating_from_2.2/index.html b/docs/en/cowboy/2.3/guide/migrating_from_2.2/index.html deleted file mode 100644 index cab5ca5a..00000000 --- a/docs/en/cowboy/2.3/guide/migrating_from_2.2/index.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - - - Nine Nines: Migrating from Cowboy 2.2 to 2.3 - - - - - - - - - - - - - - -
-
-
-
-

99s

-
-
- -
- -
    -
  • - Github -
    • -
  • - -
    • -
-
-
-
-
- - -
- -
-
-
-
- -

Migrating from Cowboy 2.2 to 2.3

- -

Cowboy 2.3 focused on making the Cowboy processes behave properly according to OTP principles. This version is a very good milestone toward that goal and most of everything should now work. Release upgrades and a few details will be improved in future versions.

-

Features added

-
  • Add support for all functions from the module sys. Note that Cowboy currently does not implement the sys debugging mechanisms as tracing is recommended instead. -
    • -
  • Add a max_frame_size option for Websocket handlers to close the connection when the client attempts to send a frame that's too large. It currently defaults to infinity to avoid breaking existing code but will be changed in a future version. -
    • -
  • Update Cowlib to 2.2.1. -
    • -
  • Add support for the 308 status code and a test suite for RFC7538 where it is defined. -
    • -
-

Bugs fixed

-
  • Ensure timeout options accept the value infinity as documented. -
    • -
  • Properly reject HTTP/2 requests with an invalid content-length header instead of simply crashing. -
    • -
  • When switching from HTTP/1.1 to Websocket or user protocols all the messages in the mailbox were flushed. Only messages specific to cowboy_http should now be flushed. -
    • -
  • Parsing of the x-forwarded-for header has been corrected. It now supports IPv6 addresses both with and without port. -
    • -
  • Websocket subprotocol tokens are now parsed in a case insensitive manner, according to the spec. -
    • -
  • Cookies without values are now allowed. For example Cookie: foo. -
    • -
  • Colons are now allowed within path segments in routes provided to cowboy_router:compile/1 as long as they are not the first character of the path segment. -
    • -
  • The cowboy_req:delete_resp_header/2 function will no longer crash when no response header was set before calling it. -
    • -
  • A miscount of the output HTTP/2 flow control window has been fixed. It prevented sending the response body fully to some clients. The issue only affected response bodies sent as iolists. -
    • -
- - - - - - - - - - - - - - - - -
- -
- - -

- Cowboy - 2.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/modern_web.asciidoc b/docs/en/cowboy/2.3/guide/modern_web.asciidoc deleted file mode 100644 index 48525732..00000000 --- a/docs/en/cowboy/2.3/guide/modern_web.asciidoc +++ /dev/null @@ -1,122 +0,0 @@ -[[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.3/guide/modern_web/index.html b/docs/en/cowboy/2.3/guide/modern_web/index.html deleted file mode 100644 index 2b82957d..00000000 --- a/docs/en/cowboy/2.3/guide/modern_web/index.html +++ /dev/null @@ -1,208 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/multipart.asciidoc b/docs/en/cowboy/2.3/guide/multipart.asciidoc deleted file mode 100644 index 0825244c..00000000 --- a/docs/en/cowboy/2.3/guide/multipart.asciidoc +++ /dev/null @@ -1,169 +0,0 @@ -[[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.3/guide/multipart/index.html b/docs/en/cowboy/2.3/guide/multipart/index.html deleted file mode 100644 index bdeba457..00000000 --- a/docs/en/cowboy/2.3/guide/multipart/index.html +++ /dev/null @@ -1,281 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/req.asciidoc b/docs/en/cowboy/2.3/guide/req.asciidoc deleted file mode 100644 index b879fa3d..00000000 --- a/docs/en/cowboy/2.3/guide/req.asciidoc +++ /dev/null @@ -1,366 +0,0 @@ -[[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.3/guide/req/index.html b/docs/en/cowboy/2.3/guide/req/index.html deleted file mode 100644 index 32d3957a..00000000 --- a/docs/en/cowboy/2.3/guide/req/index.html +++ /dev/null @@ -1,457 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/req_body.asciidoc b/docs/en/cowboy/2.3/guide/req_body.asciidoc deleted file mode 100644 index 4906811e..00000000 --- a/docs/en/cowboy/2.3/guide/req_body.asciidoc +++ /dev/null @@ -1,130 +0,0 @@ -[[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.3/guide/req_body/index.html b/docs/en/cowboy/2.3/guide/req_body/index.html deleted file mode 100644 index 9964769d..00000000 --- a/docs/en/cowboy/2.3/guide/req_body/index.html +++ /dev/null @@ -1,267 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/resource_design.asciidoc b/docs/en/cowboy/2.3/guide/resource_design.asciidoc deleted file mode 100644 index fa0c6122..00000000 --- a/docs/en/cowboy/2.3/guide/resource_design.asciidoc +++ /dev/null @@ -1,220 +0,0 @@ -[[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.3/guide/resource_design/index.html b/docs/en/cowboy/2.3/guide/resource_design/index.html deleted file mode 100644 index 484ba125..00000000 --- a/docs/en/cowboy/2.3/guide/resource_design/index.html +++ /dev/null @@ -1,240 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/resp.asciidoc b/docs/en/cowboy/2.3/guide/resp.asciidoc deleted file mode 100644 index 1664aefc..00000000 --- a/docs/en/cowboy/2.3/guide/resp.asciidoc +++ /dev/null @@ -1,368 +0,0 @@ -[[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. - -Cowboy also provides a function to send response trailers. -Response trailers are semantically equivalent to the headers -you send in the response, only they are sent at the end. -This is especially useful to attach information to the -response that could not be generated until the response -body was fully generated. - -Trailer fields must be listed in the trailer header. Any -field not listed might be dropped by the client or an intermediary. - -[source,erlang] ----- -Req = cowboy_req:stream_reply(200, #{ - <<"content-type">> => <<"text/html">>, - <<"trailer">> => <<"expires, content-md5">> -}, Req0), - -cowboy_req:stream_body("Hello world!", nofin, Req), -cowboy_req:stream_body("

Hats off!

", nofin, Req), - -cowboy_req:stream_trailers(#{ - <<"expires">> => <<"Sun, 10 Dec 2017 19:13:47 GMT">>, - <<"content-md5">> => <<"c6081d20ff41a42ce17048ed1c0345e2">> -}, Req). ----- - -The stream ends with trailers. It is no longer possible to -send data after sending trailers. You cannot send trailers -after setting the `fin` flag when streaming the body. - -=== Preset response headers - -Cowboy provides functions to set response headers without -immediately sending them. They are stored in the Req object -and sent as part of the response when a reply function is -called. - -To set response headers: - -[source,erlang] -Req = cowboy_req:set_resp_header(<<"allow">>, "GET", Req0). - -Header names must be a lowercase binary. - -Do not use this function for setting cookies. Refer to -the xref:cookies[Cookies] chapter for more information. - -To check if a response header has already been set: - -[source,erlang] -cowboy_req:has_resp_header(<<"allow">>, Req). - -It returns `true` if the header was set, `false` otherwise. - -To delete a response header that was set previously: - -[source,erlang] -Req = cowboy_req:delete_resp_header(<<"allow">>, Req0). - -=== Overriding headers - -As Cowboy provides different ways of setting response -headers and body, clashes may occur, so it's important -to understand what happens when a header is set twice. - -Headers come from five different origins: - -* Protocol-specific headers (for example HTTP/1.1's connection header) -* Other required headers (for example the date header) -* Preset headers -* Headers given to the reply function -* Set-cookie headers - -Cowboy does not allow overriding protocol-specific headers. - -Set-cookie headers will always be appended at the end of -the list of headers before sending the response. - -Headers given to the reply function will always override -preset headers and required headers. If a header is found -in two or three of these, then the one in the reply function -is picked and the others are dropped. - -Similarly, preset headers will always override required -headers. - -To illustrate, look at the following snippet. Cowboy by -default sends the server header with the value "Cowboy". -We can override it: - -[source,erlang] ----- -Req = cowboy_req:reply(200, #{ - <<"server">> => <<"yaws">> -}, Req0). ----- - -=== Preset response body - -Cowboy provides functions to set the response body without -immediately sending it. It is stored in the Req object and -sent when the reply function is called. - -To set the response body: - -[source,erlang] -Req = cowboy_req:set_resp_body("Hello world!", Req0). - -// @todo Yeah we probably should add that function that -// also sets the content-type at the same time... - -To check if a response body has already been set: - -[source,erlang] -cowboy_req:has_resp_body(Req). - -It returns `true` if the body was set and is non-empty, -`false` otherwise. - -// @todo We probably should also have a function that -// properly removes the response body, including any -// content-* headers. - -The preset response body is only sent if the reply function -used is `cowboy_req:reply/2` or `cowboy_req:reply/3`. - -=== Sending files - -Cowboy provides a shortcut for sending files. When -using `cowboy_req:reply/4`, or when presetting the -response header, you can give a `sendfile` tuple to -Cowboy: - -[source,erlang] -{sendfile, Offset, Length, Filename} - -Depending on the values for `Offset` or `Length`, the -entire file may be sent, or just a part of it. - -The length is required even for sending the entire file. -Cowboy sends it in the content-length header. - -To send a file while replying: - -[source,erlang] ----- -Req = cowboy_req:reply(200, #{ - <<"content-type">> => "image/png" -}, {sendfile, 0, 12345, "path/to/logo.png"}, Req0). ----- - -// @todo An example of presetting a file would be useful, -// but let's wait for the function that can set the -// content-type at the same time. - -// @todo What about streaming many files? For example -// it should be possible to build a tar file on the fly -// while still using sendfile. Another example could be -// proper support for multipart byte ranges. Yet another -// example would be automatic concatenation of CSS or JS -// files. - -=== Informational responses - -Cowboy allows you to send informational responses. - -Informational responses are responses that have a status -code between 100 and 199. Any number can be sent before -the proper response. Sending an informational response -does not change the behavior of the proper response, and -clients are expected to ignore any informational response -they do not understand. - -The following snippet sends a 103 informational response -with some headers that are expected to be in the final -response. - -[source,erlang] ----- -Req = cowboy_req:inform(103, #{ - <<"link">> => <<"; rel=preload; as=style, ; 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.3/guide/resp/index.html b/docs/en/cowboy/2.3/guide/resp/index.html deleted file mode 100644 index c7873020..00000000 --- a/docs/en/cowboy/2.3/guide/resp/index.html +++ /dev/null @@ -1,423 +0,0 @@ - - - - - - - - - - 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.

-

Cowboy also provides a function to send response trailers. Response trailers are semantically equivalent to the headers you send in the response, only they are sent at the end. This is especially useful to attach information to the response that could not be generated until the response body was fully generated.

-

Trailer fields must be listed in the trailer header. Any field not listed might be dropped by the client or an intermediary.

-
-
Req = cowboy_req:stream_reply(200, #{
-    <<"content-type">> => <<"text/html">>,
-    <<"trailer">> => <<"expires, content-md5">>
-}, Req0),
-
-cowboy_req:stream_body("<html><head>Hello world!</head>", nofin, Req),
-cowboy_req:stream_body("<body><p>Hats off!</p></body></html>", nofin, Req),
-
-cowboy_req:stream_trailers(#{
-    <<"expires">> => <<"Sun, 10 Dec 2017 19:13:47 GMT">>,
-    <<"content-md5">> => <<"c6081d20ff41a42ce17048ed1c0345e2">>
-}, Req).
-
-

The stream ends with trailers. It is no longer possible to send data after sending trailers. You cannot send trailers after setting the fin flag when streaming the body.

-

Preset response headers

-

Cowboy provides functions to set response headers without immediately sending them. They are stored in the Req object and sent as part of the response when a reply function is called.

-

To set response headers:

-
-
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, </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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/rest_cond.png b/docs/en/cowboy/2.3/guide/rest_cond.png deleted file mode 100644 index 64cda347..00000000 Binary files a/docs/en/cowboy/2.3/guide/rest_cond.png and /dev/null differ diff --git a/docs/en/cowboy/2.3/guide/rest_cond.svg b/docs/en/cowboy/2.3/guide/rest_cond.svg deleted file mode 100644 index 542ae17d..00000000 --- a/docs/en/cowboy/2.3/guide/rest_cond.svg +++ /dev/null @@ -1,1656 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - 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.3/guide/rest_conneg.png b/docs/en/cowboy/2.3/guide/rest_conneg.png deleted file mode 100644 index 65ecdcf3..00000000 Binary files a/docs/en/cowboy/2.3/guide/rest_conneg.png and /dev/null differ diff --git a/docs/en/cowboy/2.3/guide/rest_conneg.svg b/docs/en/cowboy/2.3/guide/rest_conneg.svg deleted file mode 100644 index 247567a0..00000000 --- a/docs/en/cowboy/2.3/guide/rest_conneg.svg +++ /dev/null @@ -1,1135 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - 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.3/guide/rest_delete.png b/docs/en/cowboy/2.3/guide/rest_delete.png deleted file mode 100644 index 56a861c0..00000000 Binary files a/docs/en/cowboy/2.3/guide/rest_delete.png and /dev/null differ diff --git a/docs/en/cowboy/2.3/guide/rest_delete.svg b/docs/en/cowboy/2.3/guide/rest_delete.svg deleted file mode 100644 index 2f5513cd..00000000 --- a/docs/en/cowboy/2.3/guide/rest_delete.svg +++ /dev/null @@ -1,1718 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - 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.3/guide/rest_flowcharts.asciidoc b/docs/en/cowboy/2.3/guide/rest_flowcharts.asciidoc deleted file mode 100644 index b5697825..00000000 --- a/docs/en/cowboy/2.3/guide/rest_flowcharts.asciidoc +++ /dev/null @@ -1,248 +0,0 @@ -[[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.3/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.3/guide/rest_flowcharts/index.html deleted file mode 100644 index 6ec48679..00000000 --- a/docs/en/cowboy/2.3/guide/rest_flowcharts/index.html +++ /dev/null @@ -1,238 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/rest_get_head.png b/docs/en/cowboy/2.3/guide/rest_get_head.png deleted file mode 100644 index 211ab603..00000000 Binary files a/docs/en/cowboy/2.3/guide/rest_get_head.png and /dev/null differ diff --git a/docs/en/cowboy/2.3/guide/rest_get_head.svg b/docs/en/cowboy/2.3/guide/rest_get_head.svg deleted file mode 100644 index 92030cf3..00000000 --- a/docs/en/cowboy/2.3/guide/rest_get_head.svg +++ /dev/null @@ -1,1523 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - 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.3/guide/rest_handlers.asciidoc b/docs/en/cowboy/2.3/guide/rest_handlers.asciidoc deleted file mode 100644 index dab5bead..00000000 --- a/docs/en/cowboy/2.3/guide/rest_handlers.asciidoc +++ /dev/null @@ -1,138 +0,0 @@ -[[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.3/guide/rest_handlers/index.html b/docs/en/cowboy/2.3/guide/rest_handlers/index.html deleted file mode 100644 index c030684a..00000000 --- a/docs/en/cowboy/2.3/guide/rest_handlers/index.html +++ /dev/null @@ -1,336 +0,0 @@ - - - - - - - - - - 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 nameDefault value
allowed_methods[<<"GET">>, <<"HEAD">>, <<"OPTIONS">>]
allow_missing_posttrue
charsets_providedskip
content_types_acceptednone
content_types_provided[{{ <<"text">>, <<"html">>, '*'}, to_html}]
delete_completedtrue
delete_resourcefalse
expiresundefined
forbiddenfalse
generate_etagundefined
is_authorizedtrue
is_conflictfalse
known_methods[<<"GET">>, <<"HEAD">>, <<"POST">>, <<"PUT">>, <<"PATCH">>, <<"DELETE">>, <<"OPTIONS">>]
languages_providedskip
last_modifiedundefined
malformed_requestfalse
moved_permanentlyfalse
moved_temporarilyfalse
multiple_choicesfalse
optionsok
previously_existedfalse
resource_existstrue
service_availabletrue
uri_too_longfalse
valid_content_headerstrue
valid_entity_lengthtrue
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:

- - - - - - - - - - - - -
KeyDetails
media_typeThe content-type negotiated for the response entity.
languageThe language negotiated for the response entity.
charsetThe 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 nameDetails
content-languageLanguage used in the response body
content-typeMedia type and charset of the response body
etagEtag of the resource
expiresExpiration date of the resource
last-modifiedLast modification date for the resource
locationRelative or absolute URI to the requested resource
varyList of headers that may change the representation of the resource
- - - - - - - - - - - - - - - - -
- -
- - -

- Cowboy - 2.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/rest_options.png b/docs/en/cowboy/2.3/guide/rest_options.png deleted file mode 100644 index 90fd6f06..00000000 Binary files a/docs/en/cowboy/2.3/guide/rest_options.png and /dev/null differ diff --git a/docs/en/cowboy/2.3/guide/rest_options.svg b/docs/en/cowboy/2.3/guide/rest_options.svg deleted file mode 100644 index 496c050c..00000000 --- a/docs/en/cowboy/2.3/guide/rest_options.svg +++ /dev/null @@ -1,387 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - some text - some text - some text - start - options - 200 OK - - - - - - - middlewares - - diff --git a/docs/en/cowboy/2.3/guide/rest_principles.asciidoc b/docs/en/cowboy/2.3/guide/rest_principles.asciidoc deleted file mode 100644 index 66939cb7..00000000 --- a/docs/en/cowboy/2.3/guide/rest_principles.asciidoc +++ /dev/null @@ -1,160 +0,0 @@ -[[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.3/guide/rest_principles/index.html b/docs/en/cowboy/2.3/guide/rest_principles/index.html deleted file mode 100644 index c625eefb..00000000 --- a/docs/en/cowboy/2.3/guide/rest_principles/index.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/rest_put_post_patch.png b/docs/en/cowboy/2.3/guide/rest_put_post_patch.png deleted file mode 100644 index 176650e9..00000000 Binary files a/docs/en/cowboy/2.3/guide/rest_put_post_patch.png and /dev/null differ diff --git a/docs/en/cowboy/2.3/guide/rest_put_post_patch.svg b/docs/en/cowboy/2.3/guide/rest_put_post_patch.svg deleted file mode 100644 index 06d55052..00000000 --- a/docs/en/cowboy/2.3/guide/rest_put_post_patch.svg +++ /dev/null @@ -1,2856 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - 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.3/guide/rest_start.png b/docs/en/cowboy/2.3/guide/rest_start.png deleted file mode 100644 index 1f1e312e..00000000 Binary files a/docs/en/cowboy/2.3/guide/rest_start.png and /dev/null differ diff --git a/docs/en/cowboy/2.3/guide/rest_start.svg b/docs/en/cowboy/2.3/guide/rest_start.svg deleted file mode 100644 index 076c6195..00000000 --- a/docs/en/cowboy/2.3/guide/rest_start.svg +++ /dev/null @@ -1,1356 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - 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.3/guide/routing.asciidoc b/docs/en/cowboy/2.3/guide/routing.asciidoc deleted file mode 100644 index 47ef3c57..00000000 --- a/docs/en/cowboy/2.3/guide/routing.asciidoc +++ /dev/null @@ -1,222 +0,0 @@ -[[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.3/guide/routing/index.html b/docs/en/cowboy/2.3/guide/routing/index.html deleted file mode 100644 index 1f0d625d..00000000 --- a/docs/en/cowboy/2.3/guide/routing/index.html +++ /dev/null @@ -1,355 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/specs.asciidoc b/docs/en/cowboy/2.3/guide/specs.asciidoc deleted file mode 100644 index d1a0ab86..00000000 --- a/docs/en/cowboy/2.3/guide/specs.asciidoc +++ /dev/null @@ -1,193 +0,0 @@ -[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 -* https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt[PROXY]: The PROXY protocol -* 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://tools.ietf.org/html/rfc8297[RFC 8297]: An HTTP Status Code for Indicating Hints -* https://tools.ietf.org/html/rfc8336[RFC 8336]: The ORIGIN HTTP/2 Frame -* 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 -* https://tools.ietf.org/html/rfc8323[RFC 8323]: CoAP over TCP, TLS, and WebSockets diff --git a/docs/en/cowboy/2.3/guide/specs/index.html b/docs/en/cowboy/2.3/guide/specs/index.html deleted file mode 100644 index e18c45b0..00000000 --- a/docs/en/cowboy/2.3/guide/specs/index.html +++ /dev/null @@ -1,515 +0,0 @@ - - - - - - - - - - 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 -
    • -
  • PROXY: The PROXY protocol -
    • -
  • 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 -
    • -
  • RFC 8297: An HTTP Status Code for Indicating Hints -
    • -
  • RFC 8336: The ORIGIN HTTP/2 Frame -
    • -
  • 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 -
    • -
  • RFC 8323: CoAP over TCP, TLS, and WebSockets -
    • -
- - - - - - - - - - - - - - - - -
- -
- - -

- Cowboy - 2.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/static_files.asciidoc b/docs/en/cowboy/2.3/guide/static_files.asciidoc deleted file mode 100644 index 9d9b8cc2..00000000 --- a/docs/en/cowboy/2.3/guide/static_files.asciidoc +++ /dev/null @@ -1,163 +0,0 @@ -[[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.3/guide/static_files/index.html b/docs/en/cowboy/2.3/guide/static_files/index.html deleted file mode 100644 index 78d5c8fc..00000000 --- a/docs/en/cowboy/2.3/guide/static_files/index.html +++ /dev/null @@ -1,275 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/streams.asciidoc b/docs/en/cowboy/2.3/guide/streams.asciidoc deleted file mode 100644 index 841a9712..00000000 --- a/docs/en/cowboy/2.3/guide/streams.asciidoc +++ /dev/null @@ -1,65 +0,0 @@ -[[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.3/guide/streams/index.html b/docs/en/cowboy/2.3/guide/streams/index.html deleted file mode 100644 index 15562e8b..00000000 --- a/docs/en/cowboy/2.3/guide/streams/index.html +++ /dev/null @@ -1,197 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/ws_handlers.asciidoc b/docs/en/cowboy/2.3/guide/ws_handlers.asciidoc deleted file mode 100644 index 71165afb..00000000 --- a/docs/en/cowboy/2.3/guide/ws_handlers.asciidoc +++ /dev/null @@ -1,293 +0,0 @@ -[[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`. - -=== Limiting frame sizes - -Cowboy accepts frames of any size by default. You should -limit the size depending on what your handler may handle. -You can do this via the `init/2` callback: - -[source,erlang] ----- -init(Req, State) -> - {cowboy_websocket, Req, State, #{ - max_frame_size => 8000000}}. ----- - -The lack of limit is historical. A future version of -Cowboy will have a more reasonable default. - -=== 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. - -The following example sends a close frame with a reason message: - -[source,erlang] ----- -websocket_info(_Info, State) -> - {reply, {close, 1000, <<"some-reason">>}, State}. ----- diff --git a/docs/en/cowboy/2.3/guide/ws_handlers/index.html b/docs/en/cowboy/2.3/guide/ws_handlers/index.html deleted file mode 100644 index aa1ee4bf..00000000 --- a/docs/en/cowboy/2.3/guide/ws_handlers/index.html +++ /dev/null @@ -1,364 +0,0 @@ - - - - - - - - - - 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.

-

Limiting frame sizes

-

Cowboy accepts frames of any size by default. You should limit the size depending on what your handler may handle. You can do this via the init/2 callback:

-
-
init(Req, State) ->
-    {cowboy_websocket, Req, State, #{
-        max_frame_size => 8000000}}.
-
-

The lack of limit is historical. A future version of Cowboy will have a more reasonable default.

-

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.

-

The following example sends a close frame with a reason message:

-
-
websocket_info(_Info, State) ->
-    {reply, {close, 1000, <<"some-reason">>}, State}.
-
- - - - - - - - - - - - - - - - -
- -
- - -

- Cowboy - 2.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/guide/ws_protocol.asciidoc b/docs/en/cowboy/2.3/guide/ws_protocol.asciidoc deleted file mode 100644 index 8fa0673d..00000000 --- a/docs/en/cowboy/2.3/guide/ws_protocol.asciidoc +++ /dev/null @@ -1,69 +0,0 @@ -[[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.3/guide/ws_protocol/index.html b/docs/en/cowboy/2.3/guide/ws_protocol/index.html deleted file mode 100644 index 835d4962..00000000 --- a/docs/en/cowboy/2.3/guide/ws_protocol/index.html +++ /dev/null @@ -1,196 +0,0 @@ - - - - - - - - - - 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.3 - - User Guide -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.3/manual/cowboy.set_env/index.html deleted file mode 100644 index db0862c5..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy.set_env/index.html +++ /dev/null @@ -1,211 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.3/manual/cowboy.start_clear/index.html deleted file mode 100644 index 2e800da1..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy.start_clear/index.html +++ /dev/null @@ -1,229 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.3/manual/cowboy.start_tls/index.html deleted file mode 100644 index 90e55f24..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy.start_tls/index.html +++ /dev/null @@ -1,234 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.3/manual/cowboy.stop_listener/index.html deleted file mode 100644 index 30d954e5..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy.stop_listener/index.html +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy/index.html b/docs/en/cowboy/2.3/manual/cowboy/index.html deleted file mode 100644 index f83f4aa9..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy/index.html +++ /dev/null @@ -1,228 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_app/index.html b/docs/en/cowboy/2.3/manual/cowboy_app/index.html deleted file mode 100644 index 5560fdde..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_app/index.html +++ /dev/null @@ -1,229 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.3/manual/cowboy_constraints.int/index.html deleted file mode 100644 index 32981392..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_constraints.int/index.html +++ /dev/null @@ -1,204 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.3/manual/cowboy_constraints.nonempty/index.html deleted file mode 100644 index 2504b0fe..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_constraints.nonempty/index.html +++ /dev/null @@ -1,203 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.3/manual/cowboy_constraints/index.html deleted file mode 100644 index 812b3a5d..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_constraints/index.html +++ /dev/null @@ -1,195 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.3/manual/cowboy_handler.terminate/index.html deleted file mode 100644 index 911602e4..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_handler.terminate/index.html +++ /dev/null @@ -1,206 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_handler/index.html b/docs/en/cowboy/2.3/manual/cowboy_handler/index.html deleted file mode 100644 index ae2fa279..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_handler/index.html +++ /dev/null @@ -1,198 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_http/index.html b/docs/en/cowboy/2.3/manual/cowboy_http/index.html deleted file mode 100644 index e1406828..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_http/index.html +++ /dev/null @@ -1,268 +0,0 @@ - - - - - - - - - - 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(),
-    max_skip_body_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.

-
-
max_skip_body_length (1000000)
-

Maximum length Cowboy is willing to skip when the user code did not read the body fully. When the remaining length is too large or unknown Cowboy will close the connection.

-
-
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.2: The max_skip_body_length option was added. -
    • -
  • 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_http2/index.html b/docs/en/cowboy/2.3/manual/cowboy_http2/index.html deleted file mode 100644 index d43b5e70..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_http2/index.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_loop/index.html b/docs/en/cowboy/2.3/manual/cowboy_loop/index.html deleted file mode 100644 index dff1145c..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_loop/index.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.3/manual/cowboy_middleware/index.html deleted file mode 100644 index 0c7123b0..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_middleware/index.html +++ /dev/null @@ -1,208 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.binding/index.html deleted file mode 100644 index c64ecb98..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.binding/index.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.bindings/index.html deleted file mode 100644 index b1ab7a5b..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.bindings/index.html +++ /dev/null @@ -1,192 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.body_length/index.html deleted file mode 100644 index 75b904d4..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.body_length/index.html +++ /dev/null @@ -1,193 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.cert/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.cert/index.html deleted file mode 100644 index 4ba0b957..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.cert/index.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - - - 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.1: 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.delete_resp_header/index.html deleted file mode 100644 index 774b47f5..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.delete_resp_header/index.html +++ /dev/null @@ -1,197 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.has_body/index.html deleted file mode 100644 index 3a75f9bc..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.has_body/index.html +++ /dev/null @@ -1,190 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_body/index.html deleted file mode 100644 index 05d1f649..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_body/index.html +++ /dev/null @@ -1,195 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_header/index.html deleted file mode 100644 index 975ef619..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_header/index.html +++ /dev/null @@ -1,198 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.header/index.html deleted file mode 100644 index fab40770..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.header/index.html +++ /dev/null @@ -1,219 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.headers/index.html deleted file mode 100644 index 46f760c7..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.headers/index.html +++ /dev/null @@ -1,199 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.host/index.html deleted file mode 100644 index 9c7f8f1e..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.host/index.html +++ /dev/null @@ -1,199 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.host_info/index.html deleted file mode 100644 index 8abff0f6..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.host_info/index.html +++ /dev/null @@ -1,193 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.inform/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.inform/index.html deleted file mode 100644 index 47d95f98..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.inform/index.html +++ /dev/null @@ -1,218 +0,0 @@ - - - - - - - - - - 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.1: 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.match_cookies/index.html deleted file mode 100644 index 17f961ad..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.match_cookies/index.html +++ /dev/null @@ -1,219 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.match_qs/index.html deleted file mode 100644 index 6feb291d..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.match_qs/index.html +++ /dev/null @@ -1,219 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.method/index.html deleted file mode 100644 index c24f9ba7..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.method/index.html +++ /dev/null @@ -1,210 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.parse_cookies/index.html deleted file mode 100644 index 827f9498..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.parse_cookies/index.html +++ /dev/null @@ -1,199 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.parse_header/index.html deleted file mode 100644 index 7204d728..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.parse_header/index.html +++ /dev/null @@ -1,370 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.parse_qs/index.html deleted file mode 100644 index f7efef13..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.parse_qs/index.html +++ /dev/null @@ -1,207 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.path/index.html deleted file mode 100644 index fbd78f9a..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.path/index.html +++ /dev/null @@ -1,199 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.path_info/index.html deleted file mode 100644 index 4542c470..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.path_info/index.html +++ /dev/null @@ -1,193 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.peer/index.html deleted file mode 100644 index 8cf1f5ce..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.peer/index.html +++ /dev/null @@ -1,203 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.port/index.html deleted file mode 100644 index 0e8d09c8..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.port/index.html +++ /dev/null @@ -1,200 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.push/index.html deleted file mode 100644 index ecc0a190..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.push/index.html +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.qs/index.html deleted file mode 100644 index 66df9409..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.qs/index.html +++ /dev/null @@ -1,199 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.read_body/index.html deleted file mode 100644 index 5957c281..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.read_body/index.html +++ /dev/null @@ -1,224 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.read_part/index.html deleted file mode 100644 index 51a30968..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.read_part/index.html +++ /dev/null @@ -1,246 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.read_part_body/index.html deleted file mode 100644 index 7a8913a5..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.read_part_body/index.html +++ /dev/null @@ -1,222 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.read_urlencoded_body/index.html deleted file mode 100644 index c8048dac..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.read_urlencoded_body/index.html +++ /dev/null @@ -1,216 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.reply/index.html deleted file mode 100644 index 7c177c91..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.reply/index.html +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.resp_header/index.html deleted file mode 100644 index ff56f564..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.resp_header/index.html +++ /dev/null @@ -1,210 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.resp_headers/index.html deleted file mode 100644 index f2efb481..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.resp_headers/index.html +++ /dev/null @@ -1,190 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.scheme/index.html deleted file mode 100644 index e8a03087..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.scheme/index.html +++ /dev/null @@ -1,204 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_body/index.html deleted file mode 100644 index 623f2db8..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_body/index.html +++ /dev/null @@ -1,231 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_cookie/index.html deleted file mode 100644 index 792d8048..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_cookie/index.html +++ /dev/null @@ -1,256 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_header/index.html deleted file mode 100644 index 46e7ed7a..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_header/index.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_headers/index.html deleted file mode 100644 index 16779044..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_headers/index.html +++ /dev/null @@ -1,203 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.sock/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.sock/index.html deleted file mode 100644 index 7ba90742..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.sock/index.html +++ /dev/null @@ -1,199 +0,0 @@ - - - - - - - - - - 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.1: 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.stream_body/index.html deleted file mode 100644 index 585af51b..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.stream_body/index.html +++ /dev/null @@ -1,208 +0,0 @@ - - - - - - - - - - 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) or be a call to the cowboy_req:stream_trailers(3) function.

-

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_req:stream_trailers(3)

- - - - - - -
- -
- - -

- Cowboy - 2.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.stream_reply/index.html deleted file mode 100644 index 434e0b31..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.stream_reply/index.html +++ /dev/null @@ -1,228 +0,0 @@ - - - - - - - - - - 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 and optionally cowboy_req:stream_trailers(3) to send response trailer field values.

-

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:stream_trailers(3), cowboy_req:push(3)

- - - - - - -
- -
- - -

- Cowboy - 2.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.stream_trailers/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.stream_trailers/index.html deleted file mode 100644 index 2a8c37c1..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.stream_trailers/index.html +++ /dev/null @@ -1,207 +0,0 @@ - - - - - - - - - - Nine Nines: cowboy_req:stream_trailers(3) - - - - - - - - - - - - - - -
-
-
-
-

99s

-
-
- -
- -
    -
  • - Github -
    • -
  • - -
    • -
-
-
-
-
- - -
- -
-
-
-
- -

cowboy_req:stream_trailers(3)

- -

Name

-

cowboy_req:stream_trailers - Send the response trailers

-

Description

-
-
stream_trailers(Trailers, Req :: cowboy_req:req()) -> ok
-
-Trailers :: cowboy:http_headers()
-
-

Send the response trailers and terminate the stream.

-

This function can only be called once, after initiating a response using cowboy_req:stream_reply(3) and sending zero or more body chunks using cowboy_req:stream_body(3) with the nofin argument set. The function stream_trailers/2 implies fin and automatically terminate the response.

-

You must list all field names sent in trailers in the trailer header, otherwise they might be dropped by intermediaries or clients.

-

Arguments

-
Trailers
-

Trailer field values to be sent.

-
-
Req
-

The Req object.

-
-
-

Return value

-

The atom ok is always returned. It can be safely ignored.

-

Changelog

-
  • 2.2: Function introduced. -
    • -
-

Examples

-
Stream a response body with trailers
-
-
Req = cowboy_req:stream_reply(200, #{
-    <<"content-type">> => <<"text/plain">>,
-    <<"trailer">> => <<"expires, content-md5">>
-}, Req0),
-cowboy_req:stream_body(<<"Hello\n">>, nofin, Req),
-timer:sleep(1000),
-cowboy_req:stream_body(<<"World!\n">>, nofin, Req).
-cowboy_req:stream_trailers(#{
-    <<"expires">> => <<"Sun, 10 Dec 2017 19:13:47 GMT">>,
-    <<"content-md5">> => <<"fbf68a8e34b2ded53bba54e68794b4fe">>
-}, Req).
-
-

See also

-

cowboy_req(3), cowboy_req:stream_reply(3), cowboy_req:stream_body(3)

- - - - - - -
- -
- - -

- Cowboy - 2.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.uri/index.html deleted file mode 100644 index 44b1e948..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.uri/index.html +++ /dev/null @@ -1,258 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.3/manual/cowboy_req.version/index.html deleted file mode 100644 index ce282711..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req.version/index.html +++ /dev/null @@ -1,199 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_req/index.html b/docs/en/cowboy/2.3/manual/cowboy_req/index.html deleted file mode 100644 index 45867ce6..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_req/index.html +++ /dev/null @@ -1,370 +0,0 @@ - - - - - - - - - - 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:

- - - - - - - - - - - - - - - - - - - - -
TypeName patternReturn type
accessno verb, parse_*, match_*Value
questionhas_*boolean()
modificationset_*Req
actionany other verbok | {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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_rest/index.html b/docs/en/cowboy/2.3/manual/cowboy_rest/index.html deleted file mode 100644 index 2a92f83b..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_rest/index.html +++ /dev/null @@ -1,627 +0,0 @@ - - - - - - - - - - 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. It's also useful to note that some standard headers also do not need to be listed here, like the authorization header.

-

Changelog

-
  • 2.1: The switch_handler return value was added. -
    • -
  • 1.0: Behavior introduced. -
    • -
-

See also

-

cowboy(7), cowboy_handler(3)

- - - - - - -
- -
- - -

- Cowboy - 2.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.3/manual/cowboy_router.compile/index.html deleted file mode 100644 index a75b8bc2..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_router.compile/index.html +++ /dev/null @@ -1,200 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_router/index.html b/docs/en/cowboy/2.3/manual/cowboy_router/index.html deleted file mode 100644 index c2425ce9..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_router/index.html +++ /dev/null @@ -1,217 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_static/index.html b/docs/en/cowboy/2.3/manual/cowboy_static/index.html deleted file mode 100644 index 55a2aa8b..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_static/index.html +++ /dev/null @@ -1,262 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_stream/index.html b/docs/en/cowboy/2.3/manual/cowboy_stream/index.html deleted file mode 100644 index f340e605..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_stream/index.html +++ /dev/null @@ -1,459 +0,0 @@ - - - - - - - - - - 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:

-

inform

-

Send an informational response to the client.

-
-
{inform, cowboy:http_status(), cowboy:http_headers()}
-
-

Any number of informational responses may be sent, but only until the final response is sent.

-

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 or a trailer command is returned.

-

data

-

Send data to the client.

-
-
{data, fin(), iodata()}
-
-

trailers

-

Send response trailers to the client.

-
-
{trailers, cowboy:http_headers()}
-
-

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.

- - - - - - - - - - - - - - - - - -

inform

-

Same as the inform command.

-

Sent when the request process reads the body and an expect: 100-continue header was present in the request, or when the request process sends an informational response on its own.

-

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.

-

trailers

-

Same as the trailers command.

-

Sent when the request process sends the trailer field values 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.2: The trailers command was introduced. -
    • -
  • 2.0: Module introduced. -
    • -
-

See also

-

cowboy(7), cowboy_http(3), cowboy_http2(3)

- - - - - - -
- -
- - -

- Cowboy - 2.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.3/manual/cowboy_websocket/index.html deleted file mode 100644 index 709da28c..00000000 --- a/docs/en/cowboy/2.3/manual/cowboy_websocket/index.html +++ /dev/null @@ -1,300 +0,0 @@ - - - - - - - - - - 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(),
-    max_frame_size => non_neg_integer() | infinity,
-    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.

-
-
max_frame_size (infinity)
-

Maximum frame size allowed by this Websocket handler. Cowboy will close the connection when a client attempts to send a frame that goes over this limit. For fragmented frames this applies to the size of the reconstituted frame.

-
-
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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/http_status_codes/index.html b/docs/en/cowboy/2.3/manual/http_status_codes/index.html deleted file mode 100644 index 8914a51d..00000000 --- a/docs/en/cowboy/2.3/manual/http_status_codes/index.html +++ /dev/null @@ -1,244 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.3/manual/index.html b/docs/en/cowboy/2.3/manual/index.html deleted file mode 100644 index ffdf6203..00000000 --- a/docs/en/cowboy/2.3/manual/index.html +++ /dev/null @@ -1,229 +0,0 @@ - - - - - - - - - - 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.3 - Function Reference - -

- - - -

Navigation

- -

Version select

- - -

Like my work? Donate!

-

Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

-
- - - - - - - - - -

Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

- - - -
-
-
-
- - - - - - - - - diff --git a/docs/en/cowboy/2.4/guide/constraints/index.html b/docs/en/cowboy/2.4/guide/constraints/index.html index 24754632..03752f4c 100644 --- a/docs/en/cowboy/2.4/guide/constraints/index.html +++ b/docs/en/cowboy/2.4/guide/constraints/index.html @@ -198,6 +198,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -208,8 +210,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/cookies/index.html b/docs/en/cowboy/2.4/guide/cookies/index.html index 8c538aa2..313b56a9 100644 --- a/docs/en/cowboy/2.4/guide/cookies/index.html +++ b/docs/en/cowboy/2.4/guide/cookies/index.html @@ -215,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -225,8 +227,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/erlang_web/index.html b/docs/en/cowboy/2.4/guide/erlang_web/index.html index 5e6b38dd..64e7793c 100644 --- a/docs/en/cowboy/2.4/guide/erlang_web/index.html +++ b/docs/en/cowboy/2.4/guide/erlang_web/index.html @@ -164,6 +164,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -174,8 +176,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/flow_diagram/index.html b/docs/en/cowboy/2.4/guide/flow_diagram/index.html index 1cf1ef84..012eb6e6 100644 --- a/docs/en/cowboy/2.4/guide/flow_diagram/index.html +++ b/docs/en/cowboy/2.4/guide/flow_diagram/index.html @@ -142,6 +142,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/getting_started/index.html b/docs/en/cowboy/2.4/guide/getting_started/index.html index 8c5e9c68..de27c132 100644 --- a/docs/en/cowboy/2.4/guide/getting_started/index.html +++ b/docs/en/cowboy/2.4/guide/getting_started/index.html @@ -216,6 +216,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -226,8 +228,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/handlers/index.html b/docs/en/cowboy/2.4/guide/handlers/index.html index a64f619f..5699690f 100644 --- a/docs/en/cowboy/2.4/guide/handlers/index.html +++ b/docs/en/cowboy/2.4/guide/handlers/index.html @@ -169,6 +169,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -179,8 +181,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/index.html b/docs/en/cowboy/2.4/guide/index.html index d17b0102..2a37c20d 100644 --- a/docs/en/cowboy/2.4/guide/index.html +++ b/docs/en/cowboy/2.4/guide/index.html @@ -177,6 +177,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -187,8 +189,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/introduction/index.html b/docs/en/cowboy/2.4/guide/introduction/index.html index 1ae7d05d..5129b329 100644 --- a/docs/en/cowboy/2.4/guide/introduction/index.html +++ b/docs/en/cowboy/2.4/guide/introduction/index.html @@ -152,6 +152,8 @@ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -162,8 +164,6 @@ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/listeners/index.html b/docs/en/cowboy/2.4/guide/listeners/index.html index da9d7280..55fe2adf 100644 --- a/docs/en/cowboy/2.4/guide/listeners/index.html +++ b/docs/en/cowboy/2.4/guide/listeners/index.html @@ -173,6 +173,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -183,8 +185,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/loop_handlers/index.html b/docs/en/cowboy/2.4/guide/loop_handlers/index.html index 9954325f..dfa3e846 100644 --- a/docs/en/cowboy/2.4/guide/loop_handlers/index.html +++ b/docs/en/cowboy/2.4/guide/loop_handlers/index.html @@ -184,6 +184,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -194,8 +196,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/middlewares/index.html b/docs/en/cowboy/2.4/guide/middlewares/index.html index dd2b07b8..1b833f89 100644 --- a/docs/en/cowboy/2.4/guide/middlewares/index.html +++ b/docs/en/cowboy/2.4/guide/middlewares/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.4/guide/migrating_from_1.0/index.html index 2398072f..469eaf40 100644 --- a/docs/en/cowboy/2.4/guide/migrating_from_1.0/index.html +++ b/docs/en/cowboy/2.4/guide/migrating_from_1.0/index.html @@ -232,6 +232,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -242,8 +244,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.4/guide/migrating_from_2.0/index.html index 1a957006..bdcaa3d4 100644 --- a/docs/en/cowboy/2.4/guide/migrating_from_2.0/index.html +++ b/docs/en/cowboy/2.4/guide/migrating_from_2.0/index.html @@ -167,6 +167,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/migrating_from_2.1/index.html b/docs/en/cowboy/2.4/guide/migrating_from_2.1/index.html index 65e54a0e..8a3f71ce 100644 --- a/docs/en/cowboy/2.4/guide/migrating_from_2.1/index.html +++ b/docs/en/cowboy/2.4/guide/migrating_from_2.1/index.html @@ -178,6 +178,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -188,8 +190,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/migrating_from_2.2/index.html b/docs/en/cowboy/2.4/guide/migrating_from_2.2/index.html index 74895773..a473806c 100644 --- a/docs/en/cowboy/2.4/guide/migrating_from_2.2/index.html +++ b/docs/en/cowboy/2.4/guide/migrating_from_2.2/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/migrating_from_2.3/index.html b/docs/en/cowboy/2.4/guide/migrating_from_2.3/index.html index 6e0762ae..488e5d8e 100644 --- a/docs/en/cowboy/2.4/guide/migrating_from_2.3/index.html +++ b/docs/en/cowboy/2.4/guide/migrating_from_2.3/index.html @@ -152,6 +152,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -162,8 +164,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/modern_web/index.html b/docs/en/cowboy/2.4/guide/modern_web/index.html index 5d288035..3df63de5 100644 --- a/docs/en/cowboy/2.4/guide/modern_web/index.html +++ b/docs/en/cowboy/2.4/guide/modern_web/index.html @@ -146,6 +146,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -156,8 +158,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/multipart/index.html b/docs/en/cowboy/2.4/guide/multipart/index.html index 168879ca..49a23e05 100644 --- a/docs/en/cowboy/2.4/guide/multipart/index.html +++ b/docs/en/cowboy/2.4/guide/multipart/index.html @@ -219,6 +219,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -229,8 +231,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/req/index.html b/docs/en/cowboy/2.4/guide/req/index.html index 3706c5d9..bed5ccc4 100644 --- a/docs/en/cowboy/2.4/guide/req/index.html +++ b/docs/en/cowboy/2.4/guide/req/index.html @@ -394,6 +394,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -404,8 +406,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/req_body/index.html b/docs/en/cowboy/2.4/guide/req_body/index.html index f8be0009..eb0ac364 100644 --- a/docs/en/cowboy/2.4/guide/req_body/index.html +++ b/docs/en/cowboy/2.4/guide/req_body/index.html @@ -205,6 +205,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -215,8 +217,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/resource_design/index.html b/docs/en/cowboy/2.4/guide/resource_design/index.html index 1cab3a02..0f1058e2 100644 --- a/docs/en/cowboy/2.4/guide/resource_design/index.html +++ b/docs/en/cowboy/2.4/guide/resource_design/index.html @@ -178,6 +178,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -188,8 +190,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/resp/index.html b/docs/en/cowboy/2.4/guide/resp/index.html index 6df85fa1..12c13f88 100644 --- a/docs/en/cowboy/2.4/guide/resp/index.html +++ b/docs/en/cowboy/2.4/guide/resp/index.html @@ -361,6 +361,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -371,8 +373,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.4/guide/rest_flowcharts/index.html index 97990d76..6d7b8137 100644 --- a/docs/en/cowboy/2.4/guide/rest_flowcharts/index.html +++ b/docs/en/cowboy/2.4/guide/rest_flowcharts/index.html @@ -176,6 +176,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -186,8 +188,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/rest_handlers/index.html b/docs/en/cowboy/2.4/guide/rest_handlers/index.html index 5727582f..fdd3216a 100644 --- a/docs/en/cowboy/2.4/guide/rest_handlers/index.html +++ b/docs/en/cowboy/2.4/guide/rest_handlers/index.html @@ -274,6 +274,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -284,8 +286,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/rest_principles/index.html b/docs/en/cowboy/2.4/guide/rest_principles/index.html index 3e434b7d..54e75a01 100644 --- a/docs/en/cowboy/2.4/guide/rest_principles/index.html +++ b/docs/en/cowboy/2.4/guide/rest_principles/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/routing/index.html b/docs/en/cowboy/2.4/guide/routing/index.html index 8e672f10..e2c7e045 100644 --- a/docs/en/cowboy/2.4/guide/routing/index.html +++ b/docs/en/cowboy/2.4/guide/routing/index.html @@ -293,6 +293,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -303,8 +305,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/specs/index.html b/docs/en/cowboy/2.4/guide/specs/index.html index c9d33bde..ad99647b 100644 --- a/docs/en/cowboy/2.4/guide/specs/index.html +++ b/docs/en/cowboy/2.4/guide/specs/index.html @@ -453,6 +453,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -463,8 +465,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/static_files/index.html b/docs/en/cowboy/2.4/guide/static_files/index.html index dd326f1d..eb3a7123 100644 --- a/docs/en/cowboy/2.4/guide/static_files/index.html +++ b/docs/en/cowboy/2.4/guide/static_files/index.html @@ -213,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -223,8 +225,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/streams/index.html b/docs/en/cowboy/2.4/guide/streams/index.html index dfa73ef7..0fa3b340 100644 --- a/docs/en/cowboy/2.4/guide/streams/index.html +++ b/docs/en/cowboy/2.4/guide/streams/index.html @@ -135,6 +135,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -145,8 +147,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/ws_handlers/index.html b/docs/en/cowboy/2.4/guide/ws_handlers/index.html index 04205f03..f30e8542 100644 --- a/docs/en/cowboy/2.4/guide/ws_handlers/index.html +++ b/docs/en/cowboy/2.4/guide/ws_handlers/index.html @@ -302,6 +302,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -312,8 +314,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/guide/ws_protocol/index.html b/docs/en/cowboy/2.4/guide/ws_protocol/index.html index 0eb01dfe..e4cca3fd 100644 --- a/docs/en/cowboy/2.4/guide/ws_protocol/index.html +++ b/docs/en/cowboy/2.4/guide/ws_protocol/index.html @@ -134,6 +134,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -144,8 +146,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.4/manual/cowboy.set_env/index.html index 489f6cbf..cbb1e89e 100644 --- a/docs/en/cowboy/2.4/manual/cowboy.set_env/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy.set_env/index.html @@ -149,6 +149,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -159,8 +161,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.4/manual/cowboy.start_clear/index.html index 1ec8eb88..e95ffbdc 100644 --- a/docs/en/cowboy/2.4/manual/cowboy.start_clear/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy.start_clear/index.html @@ -167,6 +167,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.4/manual/cowboy.start_tls/index.html index 18e736d2..8858bec2 100644 --- a/docs/en/cowboy/2.4/manual/cowboy.start_tls/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy.start_tls/index.html @@ -172,6 +172,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -182,8 +184,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.4/manual/cowboy.stop_listener/index.html index a482323a..052fa501 100644 --- a/docs/en/cowboy/2.4/manual/cowboy.stop_listener/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy.stop_listener/index.html @@ -132,6 +132,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -142,8 +144,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy/index.html b/docs/en/cowboy/2.4/manual/cowboy/index.html index 9c94605e..1fd7058f 100644 --- a/docs/en/cowboy/2.4/manual/cowboy/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy/index.html @@ -166,6 +166,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -176,8 +178,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_app/index.html b/docs/en/cowboy/2.4/manual/cowboy_app/index.html index cb15b605..b9501653 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_app/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_app/index.html @@ -167,6 +167,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.4/manual/cowboy_constraints.int/index.html index 199bb53c..61ecfd11 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_constraints.int/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_constraints.int/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.4/manual/cowboy_constraints.nonempty/index.html index b4dfc154..39ebae17 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_constraints.nonempty/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_constraints.nonempty/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.4/manual/cowboy_constraints/index.html index 3216eebe..c8fb5874 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_constraints/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_constraints/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.4/manual/cowboy_handler.terminate/index.html index 5416922d..b4b2934a 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_handler.terminate/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_handler.terminate/index.html @@ -144,6 +144,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -154,8 +156,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_handler/index.html b/docs/en/cowboy/2.4/manual/cowboy_handler/index.html index a8e2ce56..1adf85d7 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_handler/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_handler/index.html @@ -136,6 +136,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -146,8 +148,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_http/index.html b/docs/en/cowboy/2.4/manual/cowboy_http/index.html index 91a5e28e..5d6d7102 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_http/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_http/index.html @@ -206,6 +206,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -216,8 +218,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_http2/index.html b/docs/en/cowboy/2.4/manual/cowboy_http2/index.html index 7215833b..fe6ae024 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_http2/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_http2/index.html @@ -192,6 +192,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -202,8 +204,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_loop/index.html b/docs/en/cowboy/2.4/manual/cowboy_loop/index.html index dcd5a6aa..7c00fae7 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_loop/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_loop/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.4/manual/cowboy_middleware/index.html index c2039a79..a46c50b7 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_middleware/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_middleware/index.html @@ -146,6 +146,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -156,8 +158,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.binding/index.html index 11950d33..beda8308 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.binding/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.binding/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.bindings/index.html index ce1a4b88..cf92c18a 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.bindings/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.bindings/index.html @@ -130,6 +130,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -140,8 +142,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.body_length/index.html index 385a66ff..02fc5c3a 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.body_length/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.body_length/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.cert/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.cert/index.html index 76cee9a5..99b27d31 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.cert/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.cert/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.delete_resp_header/index.html index 40f8011d..13881975 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.delete_resp_header/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.delete_resp_header/index.html @@ -135,6 +135,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -145,8 +147,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.has_body/index.html index ecae42a7..45afd214 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.has_body/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.has_body/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -138,8 +140,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_body/index.html index 089f04ce..ec705355 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_body/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_body/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_header/index.html index 63eba803..d1919ca7 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_header/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_header/index.html @@ -136,6 +136,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -146,8 +148,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.header/index.html index 45a12d7a..5bfc64c2 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.header/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.header/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.headers/index.html index 28ce621f..a2b47ce2 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.headers/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.headers/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.host/index.html index e9a36c94..d693e74f 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.host/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.host/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.host_info/index.html index faf0d154..56775c4b 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.host_info/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.host_info/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.inform/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.inform/index.html index ab201b73..503ec6b2 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.inform/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.inform/index.html @@ -156,6 +156,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -166,8 +168,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.match_cookies/index.html index 24b13c35..2726d1e2 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.match_cookies/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.match_cookies/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.match_qs/index.html index 3b26a439..33fecedc 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.match_qs/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.match_qs/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.method/index.html index 60c102be..ceb979ca 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.method/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.method/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.parse_cookies/index.html index 066db11d..f58006d4 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.parse_cookies/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.parse_cookies/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.parse_header/index.html index d66b3bb2..f90c9c5a 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.parse_header/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.parse_header/index.html @@ -308,6 +308,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -318,8 +320,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.parse_qs/index.html index 46a2b019..0be32fd7 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.parse_qs/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.parse_qs/index.html @@ -145,6 +145,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -155,8 +157,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.path/index.html index ccd22456..6e595f04 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.path/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.path/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.path_info/index.html index 5c79a1e0..1674ab91 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.path_info/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.path_info/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.peer/index.html index b2435bbb..c661a302 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.peer/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.peer/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.port/index.html index 3361b9fe..27d9e38c 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.port/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.port/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.push/index.html index b93dbfcf..4c7642c4 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.push/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.push/index.html @@ -164,6 +164,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -174,8 +176,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.qs/index.html index eb1d836b..a372b125 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.qs/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.qs/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.read_body/index.html index e8cef8da..7ea5c58f 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.read_body/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.read_body/index.html @@ -162,6 +162,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -172,8 +174,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.read_part/index.html index 81248b24..9dc158e4 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.read_part/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.read_part/index.html @@ -184,6 +184,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -194,8 +196,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.read_part_body/index.html index f9687154..1be9f1ce 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.read_part_body/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.read_part_body/index.html @@ -160,6 +160,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -170,8 +172,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.read_urlencoded_body/index.html index cf991344..13598202 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.read_urlencoded_body/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.read_urlencoded_body/index.html @@ -154,6 +154,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -164,8 +166,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.reply/index.html index ea3135fb..3c4fff4f 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.reply/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.reply/index.html @@ -177,6 +177,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -187,8 +189,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.resp_header/index.html index 0f0eeb40..2d744e74 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.resp_header/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.resp_header/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.resp_headers/index.html index d41c97c8..a85a40f3 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.resp_headers/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.resp_headers/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -138,8 +140,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.scheme/index.html index 062bb0d8..be881251 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.scheme/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.scheme/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_body/index.html index 88e6c96f..6f6516fe 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_body/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_body/index.html @@ -169,6 +169,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -179,8 +181,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_cookie/index.html index 8c809c69..2f17af07 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_cookie/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_cookie/index.html @@ -194,6 +194,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -204,8 +206,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_header/index.html index 7967f000..f1282a85 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_header/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_header/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_headers/index.html index 93cc19f1..7dc3b8f8 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_headers/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_headers/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.sock/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.sock/index.html index 70f7722a..1bedaeea 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.sock/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.sock/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.stream_body/index.html index 0382b6b4..a6ceefb5 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.stream_body/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.stream_body/index.html @@ -146,6 +146,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -156,8 +158,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.stream_reply/index.html index 8814611c..2c986d4f 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.stream_reply/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.stream_reply/index.html @@ -166,6 +166,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -176,8 +178,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.stream_trailers/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.stream_trailers/index.html index ac754f1c..73f0b216 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.stream_trailers/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.stream_trailers/index.html @@ -145,6 +145,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -155,8 +157,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.uri/index.html index 0b70c835..d08ace8b 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.uri/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.uri/index.html @@ -196,6 +196,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -206,8 +208,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.4/manual/cowboy_req.version/index.html index 60385bc4..ba1786be 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req.version/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req.version/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_req/index.html b/docs/en/cowboy/2.4/manual/cowboy_req/index.html index 8892c342..7ec89668 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_req/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_req/index.html @@ -308,6 +308,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -318,8 +320,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_rest/index.html b/docs/en/cowboy/2.4/manual/cowboy_rest/index.html index 68e9f755..1f385864 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_rest/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_rest/index.html @@ -565,6 +565,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -575,8 +577,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.4/manual/cowboy_router.compile/index.html index 78b1bca9..c436bfc2 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_router.compile/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_router.compile/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_router/index.html b/docs/en/cowboy/2.4/manual/cowboy_router/index.html index b201fdb2..9a9d74b5 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_router/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_router/index.html @@ -155,6 +155,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -165,8 +167,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_static/index.html b/docs/en/cowboy/2.4/manual/cowboy_static/index.html index 8964bed8..d88a2f11 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_static/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_static/index.html @@ -200,6 +200,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -210,8 +212,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_stream/index.html b/docs/en/cowboy/2.4/manual/cowboy_stream/index.html index 728cb43c..d432cd36 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_stream/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_stream/index.html @@ -396,6 +396,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -406,8 +408,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.4/manual/cowboy_websocket/index.html index d88d00dd..9a8a2300 100644 --- a/docs/en/cowboy/2.4/manual/cowboy_websocket/index.html +++ b/docs/en/cowboy/2.4/manual/cowboy_websocket/index.html @@ -238,6 +238,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -248,8 +250,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/http_status_codes/index.html b/docs/en/cowboy/2.4/manual/http_status_codes/index.html index ce9a0a0b..0a62893b 100644 --- a/docs/en/cowboy/2.4/manual/http_status_codes/index.html +++ b/docs/en/cowboy/2.4/manual/http_status_codes/index.html @@ -182,6 +182,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -192,8 +194,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.4/manual/index.html b/docs/en/cowboy/2.4/manual/index.html index e0ec0e08..48539989 100644 --- a/docs/en/cowboy/2.4/manual/index.html +++ b/docs/en/cowboy/2.4/manual/index.html @@ -167,6 +167,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/constraints/index.html b/docs/en/cowboy/2.5/guide/constraints/index.html index 3b4fd5fd..4fa69841 100644 --- a/docs/en/cowboy/2.5/guide/constraints/index.html +++ b/docs/en/cowboy/2.5/guide/constraints/index.html @@ -198,6 +198,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -208,8 +210,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/cookies/index.html b/docs/en/cowboy/2.5/guide/cookies/index.html index 113fd446..ecd41bb3 100644 --- a/docs/en/cowboy/2.5/guide/cookies/index.html +++ b/docs/en/cowboy/2.5/guide/cookies/index.html @@ -215,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -225,8 +227,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/erlang_web/index.html b/docs/en/cowboy/2.5/guide/erlang_web/index.html index 76d1c705..37520120 100644 --- a/docs/en/cowboy/2.5/guide/erlang_web/index.html +++ b/docs/en/cowboy/2.5/guide/erlang_web/index.html @@ -164,6 +164,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -174,8 +176,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/flow_diagram/index.html b/docs/en/cowboy/2.5/guide/flow_diagram/index.html index 91f09db8..529e66e9 100644 --- a/docs/en/cowboy/2.5/guide/flow_diagram/index.html +++ b/docs/en/cowboy/2.5/guide/flow_diagram/index.html @@ -142,6 +142,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/getting_started/index.html b/docs/en/cowboy/2.5/guide/getting_started/index.html index 4f219ad8..d4e9a9c2 100644 --- a/docs/en/cowboy/2.5/guide/getting_started/index.html +++ b/docs/en/cowboy/2.5/guide/getting_started/index.html @@ -216,6 +216,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -226,8 +228,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/handlers/index.html b/docs/en/cowboy/2.5/guide/handlers/index.html index 6aba5f8a..c33d751b 100644 --- a/docs/en/cowboy/2.5/guide/handlers/index.html +++ b/docs/en/cowboy/2.5/guide/handlers/index.html @@ -169,6 +169,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -179,8 +181,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/index.html b/docs/en/cowboy/2.5/guide/index.html index 8f86ec69..c15c93b4 100644 --- a/docs/en/cowboy/2.5/guide/index.html +++ b/docs/en/cowboy/2.5/guide/index.html @@ -179,6 +179,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -189,8 +191,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/introduction/index.html b/docs/en/cowboy/2.5/guide/introduction/index.html index f0e2b586..180fd43d 100644 --- a/docs/en/cowboy/2.5/guide/introduction/index.html +++ b/docs/en/cowboy/2.5/guide/introduction/index.html @@ -152,6 +152,8 @@ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -162,8 +164,6 @@ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/listeners/index.html b/docs/en/cowboy/2.5/guide/listeners/index.html index 154f9be5..a1027ff0 100644 --- a/docs/en/cowboy/2.5/guide/listeners/index.html +++ b/docs/en/cowboy/2.5/guide/listeners/index.html @@ -173,6 +173,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -183,8 +185,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/loop_handlers/index.html b/docs/en/cowboy/2.5/guide/loop_handlers/index.html index 68c2f61c..798d51e7 100644 --- a/docs/en/cowboy/2.5/guide/loop_handlers/index.html +++ b/docs/en/cowboy/2.5/guide/loop_handlers/index.html @@ -183,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -193,8 +195,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/middlewares/index.html b/docs/en/cowboy/2.5/guide/middlewares/index.html index fc29dd7c..97477110 100644 --- a/docs/en/cowboy/2.5/guide/middlewares/index.html +++ b/docs/en/cowboy/2.5/guide/middlewares/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.5/guide/migrating_from_1.0/index.html index 3cd99816..9a8d8563 100644 --- a/docs/en/cowboy/2.5/guide/migrating_from_1.0/index.html +++ b/docs/en/cowboy/2.5/guide/migrating_from_1.0/index.html @@ -232,6 +232,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -242,8 +244,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.5/guide/migrating_from_2.0/index.html index 0addc67f..a2e74c68 100644 --- a/docs/en/cowboy/2.5/guide/migrating_from_2.0/index.html +++ b/docs/en/cowboy/2.5/guide/migrating_from_2.0/index.html @@ -167,6 +167,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/migrating_from_2.1/index.html b/docs/en/cowboy/2.5/guide/migrating_from_2.1/index.html index ae6c43fb..9bdc59c6 100644 --- a/docs/en/cowboy/2.5/guide/migrating_from_2.1/index.html +++ b/docs/en/cowboy/2.5/guide/migrating_from_2.1/index.html @@ -178,6 +178,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -188,8 +190,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/migrating_from_2.2/index.html b/docs/en/cowboy/2.5/guide/migrating_from_2.2/index.html index 204f29bd..a0805032 100644 --- a/docs/en/cowboy/2.5/guide/migrating_from_2.2/index.html +++ b/docs/en/cowboy/2.5/guide/migrating_from_2.2/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/migrating_from_2.3/index.html b/docs/en/cowboy/2.5/guide/migrating_from_2.3/index.html index a60f341e..04269716 100644 --- a/docs/en/cowboy/2.5/guide/migrating_from_2.3/index.html +++ b/docs/en/cowboy/2.5/guide/migrating_from_2.3/index.html @@ -152,6 +152,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -162,8 +164,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/migrating_from_2.4/index.html b/docs/en/cowboy/2.5/guide/migrating_from_2.4/index.html index c2933700..07376f5f 100644 --- a/docs/en/cowboy/2.5/guide/migrating_from_2.4/index.html +++ b/docs/en/cowboy/2.5/guide/migrating_from_2.4/index.html @@ -180,6 +180,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -190,8 +192,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/modern_web/index.html b/docs/en/cowboy/2.5/guide/modern_web/index.html index a8907260..5a75e8c2 100644 --- a/docs/en/cowboy/2.5/guide/modern_web/index.html +++ b/docs/en/cowboy/2.5/guide/modern_web/index.html @@ -146,6 +146,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -156,8 +158,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/multipart/index.html b/docs/en/cowboy/2.5/guide/multipart/index.html index b1e634bb..281138f2 100644 --- a/docs/en/cowboy/2.5/guide/multipart/index.html +++ b/docs/en/cowboy/2.5/guide/multipart/index.html @@ -219,6 +219,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -229,8 +231,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/req/index.html b/docs/en/cowboy/2.5/guide/req/index.html index 836483b6..1715c8d6 100644 --- a/docs/en/cowboy/2.5/guide/req/index.html +++ b/docs/en/cowboy/2.5/guide/req/index.html @@ -394,6 +394,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -404,8 +406,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/req_body/index.html b/docs/en/cowboy/2.5/guide/req_body/index.html index c5282e84..e24700c5 100644 --- a/docs/en/cowboy/2.5/guide/req_body/index.html +++ b/docs/en/cowboy/2.5/guide/req_body/index.html @@ -205,6 +205,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -215,8 +217,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/resource_design/index.html b/docs/en/cowboy/2.5/guide/resource_design/index.html index 4eb7e992..62146e1e 100644 --- a/docs/en/cowboy/2.5/guide/resource_design/index.html +++ b/docs/en/cowboy/2.5/guide/resource_design/index.html @@ -178,6 +178,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -188,8 +190,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/resp/index.html b/docs/en/cowboy/2.5/guide/resp/index.html index 0b259779..65b2d46b 100644 --- a/docs/en/cowboy/2.5/guide/resp/index.html +++ b/docs/en/cowboy/2.5/guide/resp/index.html @@ -361,6 +361,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -371,8 +373,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.5/guide/rest_flowcharts/index.html index 760ad784..0bfaa721 100644 --- a/docs/en/cowboy/2.5/guide/rest_flowcharts/index.html +++ b/docs/en/cowboy/2.5/guide/rest_flowcharts/index.html @@ -176,6 +176,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -186,8 +188,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/rest_handlers/index.html b/docs/en/cowboy/2.5/guide/rest_handlers/index.html index 6b8c970f..a4c7277b 100644 --- a/docs/en/cowboy/2.5/guide/rest_handlers/index.html +++ b/docs/en/cowboy/2.5/guide/rest_handlers/index.html @@ -274,6 +274,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -284,8 +286,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/rest_principles/index.html b/docs/en/cowboy/2.5/guide/rest_principles/index.html index 901bcba5..9d66792c 100644 --- a/docs/en/cowboy/2.5/guide/rest_principles/index.html +++ b/docs/en/cowboy/2.5/guide/rest_principles/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/routing/index.html b/docs/en/cowboy/2.5/guide/routing/index.html index 519e15dd..db87de91 100644 --- a/docs/en/cowboy/2.5/guide/routing/index.html +++ b/docs/en/cowboy/2.5/guide/routing/index.html @@ -293,6 +293,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -303,8 +305,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/specs/index.html b/docs/en/cowboy/2.5/guide/specs/index.html index 5fbe05ab..4d889deb 100644 --- a/docs/en/cowboy/2.5/guide/specs/index.html +++ b/docs/en/cowboy/2.5/guide/specs/index.html @@ -459,6 +459,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -469,8 +471,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/static_files/index.html b/docs/en/cowboy/2.5/guide/static_files/index.html index c77295dc..6d7ab673 100644 --- a/docs/en/cowboy/2.5/guide/static_files/index.html +++ b/docs/en/cowboy/2.5/guide/static_files/index.html @@ -213,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -223,8 +225,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/streams/index.html b/docs/en/cowboy/2.5/guide/streams/index.html index 1c6d8d35..9a2648aa 100644 --- a/docs/en/cowboy/2.5/guide/streams/index.html +++ b/docs/en/cowboy/2.5/guide/streams/index.html @@ -135,6 +135,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -145,8 +147,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/ws_handlers/index.html b/docs/en/cowboy/2.5/guide/ws_handlers/index.html index 59d36482..45885fbe 100644 --- a/docs/en/cowboy/2.5/guide/ws_handlers/index.html +++ b/docs/en/cowboy/2.5/guide/ws_handlers/index.html @@ -302,6 +302,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -312,8 +314,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/guide/ws_protocol/index.html b/docs/en/cowboy/2.5/guide/ws_protocol/index.html index 6a4caf29..14670b93 100644 --- a/docs/en/cowboy/2.5/guide/ws_protocol/index.html +++ b/docs/en/cowboy/2.5/guide/ws_protocol/index.html @@ -134,6 +134,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -144,8 +146,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.5/manual/cowboy.set_env/index.html index 7e839724..18916578 100644 --- a/docs/en/cowboy/2.5/manual/cowboy.set_env/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy.set_env/index.html @@ -149,6 +149,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -159,8 +161,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.5/manual/cowboy.start_clear/index.html index c48c6d1d..3b5d0088 100644 --- a/docs/en/cowboy/2.5/manual/cowboy.start_clear/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy.start_clear/index.html @@ -167,6 +167,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.5/manual/cowboy.start_tls/index.html index 682d1739..2b7182e4 100644 --- a/docs/en/cowboy/2.5/manual/cowboy.start_tls/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy.start_tls/index.html @@ -172,6 +172,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -182,8 +184,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.5/manual/cowboy.stop_listener/index.html index 49d7cef9..c061ebab 100644 --- a/docs/en/cowboy/2.5/manual/cowboy.stop_listener/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy.stop_listener/index.html @@ -132,6 +132,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -142,8 +144,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy/index.html b/docs/en/cowboy/2.5/manual/cowboy/index.html index 7d40e54a..45183800 100644 --- a/docs/en/cowboy/2.5/manual/cowboy/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy/index.html @@ -166,6 +166,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -176,8 +178,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_app/index.html b/docs/en/cowboy/2.5/manual/cowboy_app/index.html index f667be72..c19b908f 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_app/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_app/index.html @@ -167,6 +167,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.5/manual/cowboy_constraints.int/index.html index c2cfbc39..3a730fd1 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_constraints.int/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_constraints.int/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.5/manual/cowboy_constraints.nonempty/index.html index f4d98bc6..98434bbb 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_constraints.nonempty/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_constraints.nonempty/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.5/manual/cowboy_constraints/index.html index 4627b3c3..630f906a 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_constraints/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_constraints/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.5/manual/cowboy_handler.terminate/index.html index 94ab5443..edcc6859 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_handler.terminate/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_handler.terminate/index.html @@ -144,6 +144,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -154,8 +156,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_handler/index.html b/docs/en/cowboy/2.5/manual/cowboy_handler/index.html index 159682d2..eac85326 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_handler/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_handler/index.html @@ -136,6 +136,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -146,8 +148,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_http/index.html b/docs/en/cowboy/2.5/manual/cowboy_http/index.html index a5c45b41..cad6ee52 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_http/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_http/index.html @@ -212,6 +212,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -222,8 +224,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_http2/index.html b/docs/en/cowboy/2.5/manual/cowboy_http2/index.html index 0a0d80e8..465a9088 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_http2/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_http2/index.html @@ -192,6 +192,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -202,8 +204,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_loop/index.html b/docs/en/cowboy/2.5/manual/cowboy_loop/index.html index c6a29752..07ad07c1 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_loop/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_loop/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.5/manual/cowboy_middleware/index.html index 01a7a7d9..43e96b2d 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_middleware/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_middleware/index.html @@ -146,6 +146,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -156,8 +158,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.binding/index.html index ea4f0af4..be786d84 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.binding/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.binding/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.bindings/index.html index dfa0c08f..ee01d7e6 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.bindings/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.bindings/index.html @@ -130,6 +130,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -140,8 +142,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.body_length/index.html index 0ba76926..44716725 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.body_length/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.body_length/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.cert/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.cert/index.html index 3a0090f4..65db550a 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.cert/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.cert/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.delete_resp_header/index.html index 7a97d4ea..7886d742 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.delete_resp_header/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.delete_resp_header/index.html @@ -135,6 +135,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -145,8 +147,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.has_body/index.html index 4ca5918e..32011807 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.has_body/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.has_body/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -138,8 +140,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.has_resp_body/index.html index 96a0291e..e228b691 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.has_resp_body/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.has_resp_body/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.has_resp_header/index.html index a470b17c..37b042eb 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.has_resp_header/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.has_resp_header/index.html @@ -136,6 +136,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -146,8 +148,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.header/index.html index 547b464f..a7bac650 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.header/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.header/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.headers/index.html index 85c6110e..982c54ad 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.headers/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.headers/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.host/index.html index 7f951624..f8c2d656 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.host/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.host/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.host_info/index.html index 14d96b37..4fdb4122 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.host_info/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.host_info/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.inform/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.inform/index.html index 1ac9b456..4fd59706 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.inform/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.inform/index.html @@ -155,6 +155,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -165,8 +167,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.match_cookies/index.html index 4fc41e65..53f2fd6d 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.match_cookies/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.match_cookies/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.match_qs/index.html index 19b0d90e..4ef26c5c 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.match_qs/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.match_qs/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.method/index.html index fe1fc4a6..cc2521ac 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.method/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.method/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.parse_cookies/index.html index 2219ea5f..b627771d 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.parse_cookies/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.parse_cookies/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.parse_header/index.html index 82f933e0..6ca597d2 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.parse_header/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.parse_header/index.html @@ -308,6 +308,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -318,8 +320,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.parse_qs/index.html index 16828c27..645268d0 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.parse_qs/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.parse_qs/index.html @@ -145,6 +145,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -155,8 +157,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.path/index.html index 42ea94cd..f496fc27 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.path/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.path/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.path_info/index.html index 1fdecdc0..5ee7f107 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.path_info/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.path_info/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.peer/index.html index 3b1238fc..44b5980c 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.peer/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.peer/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.port/index.html index 5b919461..d638a6fc 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.port/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.port/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.push/index.html index 30bd120d..026cb1db 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.push/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.push/index.html @@ -164,6 +164,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -174,8 +176,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.qs/index.html index b222d868..c30293a0 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.qs/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.qs/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.read_and_match_urlencoded_body/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.read_and_match_urlencoded_body/index.html index c6990934..d03c68d7 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.read_and_match_urlencoded_body/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.read_and_match_urlencoded_body/index.html @@ -188,6 +188,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -198,8 +200,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.read_body/index.html index 16de8ab5..81f6881b 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.read_body/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.read_body/index.html @@ -162,6 +162,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -172,8 +174,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.read_part/index.html index 9e1d55e9..2dd7f5e4 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.read_part/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.read_part/index.html @@ -184,6 +184,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -194,8 +196,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.read_part_body/index.html index d17ff5f0..b42b9894 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.read_part_body/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.read_part_body/index.html @@ -160,6 +160,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -170,8 +172,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.read_urlencoded_body/index.html index 6c6ab313..8622582c 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.read_urlencoded_body/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.read_urlencoded_body/index.html @@ -154,6 +154,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -164,8 +166,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.reply/index.html index f8a75398..6e54312d 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.reply/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.reply/index.html @@ -176,6 +176,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -186,8 +188,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.resp_header/index.html index 7e3a7ac9..3cf01010 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.resp_header/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.resp_header/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.resp_headers/index.html index 5d4dffa6..0bb3de2c 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.resp_headers/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.resp_headers/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -138,8 +140,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.scheme/index.html index 32692388..33fb9e3a 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.scheme/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.scheme/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_body/index.html index 65439eb0..d33f235c 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_body/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_body/index.html @@ -169,6 +169,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -179,8 +181,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_cookie/index.html index 677a4108..9ce981d6 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_cookie/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_cookie/index.html @@ -194,6 +194,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -204,8 +206,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_header/index.html index 24c4b88c..71f65d42 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_header/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_header/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_headers/index.html index e9f6e5c5..d32d7915 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_headers/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.set_resp_headers/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.sock/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.sock/index.html index bfdd4e58..83ae647f 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.sock/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.sock/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.stream_body/index.html index cd623ae5..87837bbe 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.stream_body/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.stream_body/index.html @@ -146,6 +146,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -156,8 +158,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.stream_events/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.stream_events/index.html index d785f0df..660e0f6c 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.stream_events/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.stream_events/index.html @@ -162,6 +162,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -172,8 +174,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.stream_reply/index.html index 03011eaf..a3f4fa17 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.stream_reply/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.stream_reply/index.html @@ -165,6 +165,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -175,8 +177,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.stream_trailers/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.stream_trailers/index.html index 8635c7fb..d6140b10 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.stream_trailers/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.stream_trailers/index.html @@ -145,6 +145,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -155,8 +157,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.uri/index.html index 2436012e..c84e1ca3 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.uri/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.uri/index.html @@ -196,6 +196,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -206,8 +208,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.5/manual/cowboy_req.version/index.html index d5af69e0..7bc8da6f 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req.version/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req.version/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_req/index.html b/docs/en/cowboy/2.5/manual/cowboy_req/index.html index 76f6e3be..94f209c3 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_req/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_req/index.html @@ -312,6 +312,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -322,8 +324,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_rest/index.html b/docs/en/cowboy/2.5/manual/cowboy_rest/index.html index 6e0804fe..adae7334 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_rest/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_rest/index.html @@ -565,6 +565,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -575,8 +577,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.5/manual/cowboy_router.compile/index.html index ef264f01..ec12c2cd 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_router.compile/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_router.compile/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_router/index.html b/docs/en/cowboy/2.5/manual/cowboy_router/index.html index 8c5aa3d0..89bb4009 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_router/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_router/index.html @@ -155,6 +155,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -165,8 +167,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_static/index.html b/docs/en/cowboy/2.5/manual/cowboy_static/index.html index cc225395..7c2603c5 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_static/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_static/index.html @@ -200,6 +200,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -210,8 +212,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_stream/index.html b/docs/en/cowboy/2.5/manual/cowboy_stream/index.html index 8d154131..1961c5c1 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_stream/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_stream/index.html @@ -383,6 +383,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -393,8 +395,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.5/manual/cowboy_websocket/index.html index 4cdc26c3..858a376d 100644 --- a/docs/en/cowboy/2.5/manual/cowboy_websocket/index.html +++ b/docs/en/cowboy/2.5/manual/cowboy_websocket/index.html @@ -238,6 +238,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -248,8 +250,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/http_status_codes/index.html b/docs/en/cowboy/2.5/manual/http_status_codes/index.html index 68be885b..46144516 100644 --- a/docs/en/cowboy/2.5/manual/http_status_codes/index.html +++ b/docs/en/cowboy/2.5/manual/http_status_codes/index.html @@ -182,6 +182,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -192,8 +194,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.5/manual/index.html b/docs/en/cowboy/2.5/manual/index.html index 7530dcfb..2981c2de 100644 --- a/docs/en/cowboy/2.5/manual/index.html +++ b/docs/en/cowboy/2.5/manual/index.html @@ -167,6 +167,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/constraints/index.html b/docs/en/cowboy/2.6/guide/constraints/index.html index 91149dde..6dd25260 100644 --- a/docs/en/cowboy/2.6/guide/constraints/index.html +++ b/docs/en/cowboy/2.6/guide/constraints/index.html @@ -198,6 +198,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -208,8 +210,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/cookies/index.html b/docs/en/cowboy/2.6/guide/cookies/index.html index 5e07a0d0..475108ac 100644 --- a/docs/en/cowboy/2.6/guide/cookies/index.html +++ b/docs/en/cowboy/2.6/guide/cookies/index.html @@ -215,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -225,8 +227,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/erlang_web/index.html b/docs/en/cowboy/2.6/guide/erlang_web/index.html index 5867c70a..5e924783 100644 --- a/docs/en/cowboy/2.6/guide/erlang_web/index.html +++ b/docs/en/cowboy/2.6/guide/erlang_web/index.html @@ -164,6 +164,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -174,8 +176,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/flow_diagram/index.html b/docs/en/cowboy/2.6/guide/flow_diagram/index.html index 330a9c5a..84416b95 100644 --- a/docs/en/cowboy/2.6/guide/flow_diagram/index.html +++ b/docs/en/cowboy/2.6/guide/flow_diagram/index.html @@ -142,6 +142,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/getting_started/index.html b/docs/en/cowboy/2.6/guide/getting_started/index.html index bd46737c..c489935d 100644 --- a/docs/en/cowboy/2.6/guide/getting_started/index.html +++ b/docs/en/cowboy/2.6/guide/getting_started/index.html @@ -216,6 +216,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -226,8 +228,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/handlers/index.html b/docs/en/cowboy/2.6/guide/handlers/index.html index c6c36081..0bd69984 100644 --- a/docs/en/cowboy/2.6/guide/handlers/index.html +++ b/docs/en/cowboy/2.6/guide/handlers/index.html @@ -169,6 +169,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -179,8 +181,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/index.html b/docs/en/cowboy/2.6/guide/index.html index 80ec3bac..0517a4db 100644 --- a/docs/en/cowboy/2.6/guide/index.html +++ b/docs/en/cowboy/2.6/guide/index.html @@ -183,6 +183,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -193,8 +195,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/introduction/index.html b/docs/en/cowboy/2.6/guide/introduction/index.html index cc448d37..dfbac829 100644 --- a/docs/en/cowboy/2.6/guide/introduction/index.html +++ b/docs/en/cowboy/2.6/guide/introduction/index.html @@ -152,6 +152,8 @@ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -162,8 +164,6 @@ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/listeners/index.html b/docs/en/cowboy/2.6/guide/listeners/index.html index 65480585..caff8f8c 100644 --- a/docs/en/cowboy/2.6/guide/listeners/index.html +++ b/docs/en/cowboy/2.6/guide/listeners/index.html @@ -173,6 +173,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -183,8 +185,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/loop_handlers/index.html b/docs/en/cowboy/2.6/guide/loop_handlers/index.html index a9a0710e..e5960cf3 100644 --- a/docs/en/cowboy/2.6/guide/loop_handlers/index.html +++ b/docs/en/cowboy/2.6/guide/loop_handlers/index.html @@ -183,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -193,8 +195,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/middlewares/index.html b/docs/en/cowboy/2.6/guide/middlewares/index.html index 22942cde..26bd534b 100644 --- a/docs/en/cowboy/2.6/guide/middlewares/index.html +++ b/docs/en/cowboy/2.6/guide/middlewares/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.6/guide/migrating_from_1.0/index.html index b634915f..cec03f38 100644 --- a/docs/en/cowboy/2.6/guide/migrating_from_1.0/index.html +++ b/docs/en/cowboy/2.6/guide/migrating_from_1.0/index.html @@ -232,6 +232,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -242,8 +244,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.6/guide/migrating_from_2.0/index.html index 80a7ad7c..3a2f58d8 100644 --- a/docs/en/cowboy/2.6/guide/migrating_from_2.0/index.html +++ b/docs/en/cowboy/2.6/guide/migrating_from_2.0/index.html @@ -167,6 +167,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/migrating_from_2.1/index.html b/docs/en/cowboy/2.6/guide/migrating_from_2.1/index.html index 79226f6b..d773f275 100644 --- a/docs/en/cowboy/2.6/guide/migrating_from_2.1/index.html +++ b/docs/en/cowboy/2.6/guide/migrating_from_2.1/index.html @@ -178,6 +178,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -188,8 +190,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/migrating_from_2.2/index.html b/docs/en/cowboy/2.6/guide/migrating_from_2.2/index.html index c4ee4b83..e1d0a9e9 100644 --- a/docs/en/cowboy/2.6/guide/migrating_from_2.2/index.html +++ b/docs/en/cowboy/2.6/guide/migrating_from_2.2/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/migrating_from_2.3/index.html b/docs/en/cowboy/2.6/guide/migrating_from_2.3/index.html index 8e5bb643..9a8200a6 100644 --- a/docs/en/cowboy/2.6/guide/migrating_from_2.3/index.html +++ b/docs/en/cowboy/2.6/guide/migrating_from_2.3/index.html @@ -152,6 +152,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -162,8 +164,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/migrating_from_2.4/index.html b/docs/en/cowboy/2.6/guide/migrating_from_2.4/index.html index 2e6fbf2f..8733a12f 100644 --- a/docs/en/cowboy/2.6/guide/migrating_from_2.4/index.html +++ b/docs/en/cowboy/2.6/guide/migrating_from_2.4/index.html @@ -180,6 +180,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -190,8 +192,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/migrating_from_2.5/index.html b/docs/en/cowboy/2.6/guide/migrating_from_2.5/index.html index a55d1e4f..9988a44e 100644 --- a/docs/en/cowboy/2.6/guide/migrating_from_2.5/index.html +++ b/docs/en/cowboy/2.6/guide/migrating_from_2.5/index.html @@ -195,6 +195,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -205,8 +207,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/migrating_from_2.6/index.html b/docs/en/cowboy/2.6/guide/migrating_from_2.6/index.html index 9ebf0c77..ef6a8cfa 100644 --- a/docs/en/cowboy/2.6/guide/migrating_from_2.6/index.html +++ b/docs/en/cowboy/2.6/guide/migrating_from_2.6/index.html @@ -132,6 +132,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -142,8 +144,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/modern_web/index.html b/docs/en/cowboy/2.6/guide/modern_web/index.html index 7aa912d6..6e66ec5a 100644 --- a/docs/en/cowboy/2.6/guide/modern_web/index.html +++ b/docs/en/cowboy/2.6/guide/modern_web/index.html @@ -146,6 +146,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -156,8 +158,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/multipart/index.html b/docs/en/cowboy/2.6/guide/multipart/index.html index 44a5242c..ff2eb593 100644 --- a/docs/en/cowboy/2.6/guide/multipart/index.html +++ b/docs/en/cowboy/2.6/guide/multipart/index.html @@ -219,6 +219,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -229,8 +231,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/req/index.html b/docs/en/cowboy/2.6/guide/req/index.html index ead42b7b..6bab68a1 100644 --- a/docs/en/cowboy/2.6/guide/req/index.html +++ b/docs/en/cowboy/2.6/guide/req/index.html @@ -394,6 +394,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -404,8 +406,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/req_body/index.html b/docs/en/cowboy/2.6/guide/req_body/index.html index cd656ca4..b2a1652b 100644 --- a/docs/en/cowboy/2.6/guide/req_body/index.html +++ b/docs/en/cowboy/2.6/guide/req_body/index.html @@ -205,6 +205,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -215,8 +217,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/resource_design/index.html b/docs/en/cowboy/2.6/guide/resource_design/index.html index b72f54a7..cf3f92ff 100644 --- a/docs/en/cowboy/2.6/guide/resource_design/index.html +++ b/docs/en/cowboy/2.6/guide/resource_design/index.html @@ -179,6 +179,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -189,8 +191,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/resp/index.html b/docs/en/cowboy/2.6/guide/resp/index.html index b685fab1..25946c81 100644 --- a/docs/en/cowboy/2.6/guide/resp/index.html +++ b/docs/en/cowboy/2.6/guide/resp/index.html @@ -361,6 +361,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -371,8 +373,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.6/guide/rest_flowcharts/index.html index d5804c1f..5179ae04 100644 --- a/docs/en/cowboy/2.6/guide/rest_flowcharts/index.html +++ b/docs/en/cowboy/2.6/guide/rest_flowcharts/index.html @@ -176,6 +176,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -186,8 +188,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/rest_handlers/index.html b/docs/en/cowboy/2.6/guide/rest_handlers/index.html index 5f50471e..eb4dfd4c 100644 --- a/docs/en/cowboy/2.6/guide/rest_handlers/index.html +++ b/docs/en/cowboy/2.6/guide/rest_handlers/index.html @@ -277,6 +277,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -287,8 +289,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/rest_principles/index.html b/docs/en/cowboy/2.6/guide/rest_principles/index.html index 705df244..b98149f1 100644 --- a/docs/en/cowboy/2.6/guide/rest_principles/index.html +++ b/docs/en/cowboy/2.6/guide/rest_principles/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/routing/index.html b/docs/en/cowboy/2.6/guide/routing/index.html index fea6658e..254dc9c7 100644 --- a/docs/en/cowboy/2.6/guide/routing/index.html +++ b/docs/en/cowboy/2.6/guide/routing/index.html @@ -300,6 +300,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -310,8 +312,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/specs/index.html b/docs/en/cowboy/2.6/guide/specs/index.html index e7f3fdfc..e9765afd 100644 --- a/docs/en/cowboy/2.6/guide/specs/index.html +++ b/docs/en/cowboy/2.6/guide/specs/index.html @@ -467,6 +467,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -477,8 +479,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/static_files/index.html b/docs/en/cowboy/2.6/guide/static_files/index.html index 9c6a0047..49a49b1a 100644 --- a/docs/en/cowboy/2.6/guide/static_files/index.html +++ b/docs/en/cowboy/2.6/guide/static_files/index.html @@ -213,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -223,8 +225,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/streams/index.html b/docs/en/cowboy/2.6/guide/streams/index.html index c8b5b875..b4b9e441 100644 --- a/docs/en/cowboy/2.6/guide/streams/index.html +++ b/docs/en/cowboy/2.6/guide/streams/index.html @@ -135,6 +135,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -145,8 +147,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/ws_handlers/index.html b/docs/en/cowboy/2.6/guide/ws_handlers/index.html index 1e953792..466d2916 100644 --- a/docs/en/cowboy/2.6/guide/ws_handlers/index.html +++ b/docs/en/cowboy/2.6/guide/ws_handlers/index.html @@ -302,6 +302,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -312,8 +314,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/guide/ws_protocol/index.html b/docs/en/cowboy/2.6/guide/ws_protocol/index.html index eab13a03..3efb5988 100644 --- a/docs/en/cowboy/2.6/guide/ws_protocol/index.html +++ b/docs/en/cowboy/2.6/guide/ws_protocol/index.html @@ -134,6 +134,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -144,8 +146,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.6/manual/cowboy.set_env/index.html index b3203b5b..01852de7 100644 --- a/docs/en/cowboy/2.6/manual/cowboy.set_env/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy.set_env/index.html @@ -149,6 +149,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -159,8 +161,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.6/manual/cowboy.start_clear/index.html index 64a748b0..75a9df0d 100644 --- a/docs/en/cowboy/2.6/manual/cowboy.start_clear/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy.start_clear/index.html @@ -167,6 +167,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.6/manual/cowboy.start_tls/index.html index eda887b4..71f023f4 100644 --- a/docs/en/cowboy/2.6/manual/cowboy.start_tls/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy.start_tls/index.html @@ -172,6 +172,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -182,8 +184,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.6/manual/cowboy.stop_listener/index.html index 87c575c9..46da6862 100644 --- a/docs/en/cowboy/2.6/manual/cowboy.stop_listener/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy.stop_listener/index.html @@ -132,6 +132,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -142,8 +144,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy/index.html b/docs/en/cowboy/2.6/manual/cowboy/index.html index 55c1d58e..dcfb5463 100644 --- a/docs/en/cowboy/2.6/manual/cowboy/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy/index.html @@ -166,6 +166,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -176,8 +178,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_app/index.html b/docs/en/cowboy/2.6/manual/cowboy_app/index.html index 060c04a8..42ebbdca 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_app/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_app/index.html @@ -173,6 +173,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -183,8 +185,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_compress_h/index.html b/docs/en/cowboy/2.6/manual/cowboy_compress_h/index.html index 7660088a..3ffde28e 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_compress_h/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_compress_h/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.6/manual/cowboy_constraints.int/index.html index f8daf0b7..5cd109c8 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_constraints.int/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_constraints.int/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.6/manual/cowboy_constraints.nonempty/index.html index 4a0594d8..f52dd8bd 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_constraints.nonempty/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_constraints.nonempty/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.6/manual/cowboy_constraints/index.html index 12b4c613..ce22f375 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_constraints/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_constraints/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.6/manual/cowboy_handler.terminate/index.html index fe97dff5..a5abc94b 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_handler.terminate/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_handler.terminate/index.html @@ -144,6 +144,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -154,8 +156,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_handler/index.html b/docs/en/cowboy/2.6/manual/cowboy_handler/index.html index a191f459..348a63bf 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_handler/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_handler/index.html @@ -136,6 +136,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -146,8 +148,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_http/index.html b/docs/en/cowboy/2.6/manual/cowboy_http/index.html index 4eb76ea0..71509cff 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_http/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_http/index.html @@ -218,6 +218,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -228,8 +230,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_http2/index.html b/docs/en/cowboy/2.6/manual/cowboy_http2/index.html index b34aebcc..f6f9a4fb 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_http2/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_http2/index.html @@ -194,6 +194,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -204,8 +206,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_loop/index.html b/docs/en/cowboy/2.6/manual/cowboy_loop/index.html index d5cc0df6..aa2042b8 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_loop/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_loop/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.6/manual/cowboy_middleware/index.html index 5d5e666b..f6d1080e 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_middleware/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_middleware/index.html @@ -146,6 +146,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -156,8 +158,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.binding/index.html index 3c9e670f..73841d49 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.binding/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.binding/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.bindings/index.html index d0c45086..223f161d 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.bindings/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.bindings/index.html @@ -130,6 +130,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -140,8 +142,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.body_length/index.html index ca97caf5..6c4a438c 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.body_length/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.body_length/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.cert/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.cert/index.html index 4ca7618e..a6865dd2 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.cert/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.cert/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.delete_resp_header/index.html index 6e12f529..4c2cf6df 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.delete_resp_header/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.delete_resp_header/index.html @@ -135,6 +135,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -145,8 +147,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.has_body/index.html index c52cbec0..0b108bbf 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.has_body/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.has_body/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -138,8 +140,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.has_resp_body/index.html index 1e432f3d..7ed7554f 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.has_resp_body/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.has_resp_body/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.has_resp_header/index.html index 0c611659..85889350 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.has_resp_header/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.has_resp_header/index.html @@ -136,6 +136,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -146,8 +148,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.header/index.html index 44c3ffdc..69d989e8 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.header/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.header/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.headers/index.html index 0c423776..173d506a 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.headers/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.headers/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.host/index.html index 989dfd8f..52140dde 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.host/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.host/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.host_info/index.html index bfff0210..0df03bc7 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.host_info/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.host_info/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.inform/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.inform/index.html index 8e836855..1d80ea18 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.inform/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.inform/index.html @@ -155,6 +155,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -165,8 +167,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.match_cookies/index.html index d97c21b0..08729747 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.match_cookies/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.match_cookies/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.match_qs/index.html index 53fc37fb..83db2984 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.match_qs/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.match_qs/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.method/index.html index 7f5414f4..dc7804fd 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.method/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.method/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.parse_cookies/index.html index 261d3cbe..a2296894 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.parse_cookies/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.parse_cookies/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.parse_header/index.html index 5dd024dd..67f10f1d 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.parse_header/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.parse_header/index.html @@ -308,6 +308,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -318,8 +320,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.parse_qs/index.html index 8864f0a0..29fcab70 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.parse_qs/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.parse_qs/index.html @@ -145,6 +145,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -155,8 +157,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.path/index.html index e4e25d3c..0dbce8e9 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.path/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.path/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.path_info/index.html index 76363bef..b9e891e9 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.path_info/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.path_info/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.peer/index.html index 57a485e6..0ec9d3c2 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.peer/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.peer/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.port/index.html index 801f723c..8898a7ac 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.port/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.port/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.push/index.html index 303379ba..65263ec0 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.push/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.push/index.html @@ -164,6 +164,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -174,8 +176,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.qs/index.html index e3d353bd..32275c39 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.qs/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.qs/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.read_and_match_urlencoded_body/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.read_and_match_urlencoded_body/index.html index 74be90ed..df5205fd 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.read_and_match_urlencoded_body/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.read_and_match_urlencoded_body/index.html @@ -188,6 +188,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -198,8 +200,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.read_body/index.html index 49323e9e..9f76521a 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.read_body/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.read_body/index.html @@ -162,6 +162,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -172,8 +174,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.read_part/index.html index b69e73d6..52616c8b 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.read_part/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.read_part/index.html @@ -184,6 +184,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -194,8 +196,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.read_part_body/index.html index c8b8668f..91f4b09b 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.read_part_body/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.read_part_body/index.html @@ -160,6 +160,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -170,8 +172,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.read_urlencoded_body/index.html index d63d2b47..6da6a063 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.read_urlencoded_body/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.read_urlencoded_body/index.html @@ -154,6 +154,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -164,8 +166,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.reply/index.html index c46be448..016dec1e 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.reply/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.reply/index.html @@ -176,6 +176,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -186,8 +188,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.resp_header/index.html index 6a9e6749..d1426b1c 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.resp_header/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.resp_header/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.resp_headers/index.html index 491876a5..1d30adbd 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.resp_headers/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.resp_headers/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -138,8 +140,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.scheme/index.html index 51bec928..ada04b37 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.scheme/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.scheme/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_body/index.html index f29ebee1..b2c2293c 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_body/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_body/index.html @@ -169,6 +169,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -179,8 +181,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_cookie/index.html index b2c54376..bfc7f00b 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_cookie/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_cookie/index.html @@ -194,6 +194,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -204,8 +206,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_header/index.html index 33ef5908..08628e3e 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_header/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_header/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_headers/index.html index b56714c0..d105e684 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_headers/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.set_resp_headers/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.sock/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.sock/index.html index 8fec2483..0e642333 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.sock/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.sock/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.stream_body/index.html index 8936d7f3..a4d424e9 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.stream_body/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.stream_body/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.stream_events/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.stream_events/index.html index 36ba08f7..a5db8564 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.stream_events/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.stream_events/index.html @@ -162,6 +162,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -172,8 +174,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.stream_reply/index.html index 88576529..728b867a 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.stream_reply/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.stream_reply/index.html @@ -165,6 +165,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -175,8 +177,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.stream_trailers/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.stream_trailers/index.html index 7a2d8cc8..2bcbcb9c 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.stream_trailers/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.stream_trailers/index.html @@ -145,6 +145,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -155,8 +157,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.uri/index.html index 39e39be5..2780405d 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.uri/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.uri/index.html @@ -196,6 +196,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -206,8 +208,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.6/manual/cowboy_req.version/index.html index 1ce370a2..58e2be96 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req.version/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req.version/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_req/index.html b/docs/en/cowboy/2.6/manual/cowboy_req/index.html index cbc6be32..242319a0 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_req/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_req/index.html @@ -312,6 +312,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -322,8 +324,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_rest/index.html b/docs/en/cowboy/2.6/manual/cowboy_rest/index.html index be663eec..4dbe93fd 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_rest/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_rest/index.html @@ -593,6 +593,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -603,8 +605,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.6/manual/cowboy_router.compile/index.html index 1fc6aaef..6dd6bd3e 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_router.compile/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_router.compile/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_router/index.html b/docs/en/cowboy/2.6/manual/cowboy_router/index.html index 88ebac36..49f3481f 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_router/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_router/index.html @@ -155,6 +155,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -165,8 +167,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_static/index.html b/docs/en/cowboy/2.6/manual/cowboy_static/index.html index 05338934..b9d6bab9 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_static/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_static/index.html @@ -213,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -223,8 +225,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_stream/index.html b/docs/en/cowboy/2.6/manual/cowboy_stream/index.html index dfd4bdf2..19c91ab9 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_stream/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_stream/index.html @@ -350,6 +350,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -360,8 +362,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_stream_h/index.html b/docs/en/cowboy/2.6/manual/cowboy_stream_h/index.html index e9dc3aa1..a697ca21 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_stream_h/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_stream_h/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.6/manual/cowboy_websocket/index.html index a648a608..c9908239 100644 --- a/docs/en/cowboy/2.6/manual/cowboy_websocket/index.html +++ b/docs/en/cowboy/2.6/manual/cowboy_websocket/index.html @@ -244,6 +244,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -254,8 +256,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/http_status_codes/index.html b/docs/en/cowboy/2.6/manual/http_status_codes/index.html index bbd90b86..5fb9c72b 100644 --- a/docs/en/cowboy/2.6/manual/http_status_codes/index.html +++ b/docs/en/cowboy/2.6/manual/http_status_codes/index.html @@ -182,6 +182,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -192,8 +194,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.6/manual/index.html b/docs/en/cowboy/2.6/manual/index.html index 0e8bea92..0915edc6 100644 --- a/docs/en/cowboy/2.6/manual/index.html +++ b/docs/en/cowboy/2.6/manual/index.html @@ -173,6 +173,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -183,8 +185,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/constraints/index.html b/docs/en/cowboy/2.7/guide/constraints/index.html index c25f4e5c..96f6908d 100644 --- a/docs/en/cowboy/2.7/guide/constraints/index.html +++ b/docs/en/cowboy/2.7/guide/constraints/index.html @@ -198,6 +198,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -208,8 +210,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/cookies/index.html b/docs/en/cowboy/2.7/guide/cookies/index.html index 4b952626..d714328f 100644 --- a/docs/en/cowboy/2.7/guide/cookies/index.html +++ b/docs/en/cowboy/2.7/guide/cookies/index.html @@ -215,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -225,8 +227,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/erlang_web/index.html b/docs/en/cowboy/2.7/guide/erlang_web/index.html index f39b0a4b..a2cf76c3 100644 --- a/docs/en/cowboy/2.7/guide/erlang_web/index.html +++ b/docs/en/cowboy/2.7/guide/erlang_web/index.html @@ -164,6 +164,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -174,8 +176,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/flow_diagram/index.html b/docs/en/cowboy/2.7/guide/flow_diagram/index.html index 62e74f9d..7a9991a8 100644 --- a/docs/en/cowboy/2.7/guide/flow_diagram/index.html +++ b/docs/en/cowboy/2.7/guide/flow_diagram/index.html @@ -142,6 +142,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/getting_started/index.html b/docs/en/cowboy/2.7/guide/getting_started/index.html index d9394bdf..4d5848d5 100644 --- a/docs/en/cowboy/2.7/guide/getting_started/index.html +++ b/docs/en/cowboy/2.7/guide/getting_started/index.html @@ -216,6 +216,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -226,8 +228,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/handlers/index.html b/docs/en/cowboy/2.7/guide/handlers/index.html index 783bec48..43fe70d6 100644 --- a/docs/en/cowboy/2.7/guide/handlers/index.html +++ b/docs/en/cowboy/2.7/guide/handlers/index.html @@ -169,6 +169,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -179,8 +181,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/index.html b/docs/en/cowboy/2.7/guide/index.html index 266f58c2..f33df100 100644 --- a/docs/en/cowboy/2.7/guide/index.html +++ b/docs/en/cowboy/2.7/guide/index.html @@ -183,6 +183,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -193,8 +195,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/introduction/index.html b/docs/en/cowboy/2.7/guide/introduction/index.html index adb564c6..51efa5e8 100644 --- a/docs/en/cowboy/2.7/guide/introduction/index.html +++ b/docs/en/cowboy/2.7/guide/introduction/index.html @@ -152,6 +152,8 @@ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -162,8 +164,6 @@ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/listeners/index.html b/docs/en/cowboy/2.7/guide/listeners/index.html index 2a3cc85e..38031723 100644 --- a/docs/en/cowboy/2.7/guide/listeners/index.html +++ b/docs/en/cowboy/2.7/guide/listeners/index.html @@ -182,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -192,8 +194,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/loop_handlers/index.html b/docs/en/cowboy/2.7/guide/loop_handlers/index.html index 8f56b6bf..22e58e2a 100644 --- a/docs/en/cowboy/2.7/guide/loop_handlers/index.html +++ b/docs/en/cowboy/2.7/guide/loop_handlers/index.html @@ -183,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -193,8 +195,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/middlewares/index.html b/docs/en/cowboy/2.7/guide/middlewares/index.html index 602f5d76..51cc359f 100644 --- a/docs/en/cowboy/2.7/guide/middlewares/index.html +++ b/docs/en/cowboy/2.7/guide/middlewares/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.7/guide/migrating_from_1.0/index.html index d11996f3..5c6cf16a 100644 --- a/docs/en/cowboy/2.7/guide/migrating_from_1.0/index.html +++ b/docs/en/cowboy/2.7/guide/migrating_from_1.0/index.html @@ -232,6 +232,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -242,8 +244,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.7/guide/migrating_from_2.0/index.html index 2f882516..7b6da4bc 100644 --- a/docs/en/cowboy/2.7/guide/migrating_from_2.0/index.html +++ b/docs/en/cowboy/2.7/guide/migrating_from_2.0/index.html @@ -167,6 +167,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/migrating_from_2.1/index.html b/docs/en/cowboy/2.7/guide/migrating_from_2.1/index.html index 2026bede..a1224afc 100644 --- a/docs/en/cowboy/2.7/guide/migrating_from_2.1/index.html +++ b/docs/en/cowboy/2.7/guide/migrating_from_2.1/index.html @@ -178,6 +178,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -188,8 +190,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/migrating_from_2.2/index.html b/docs/en/cowboy/2.7/guide/migrating_from_2.2/index.html index 36d3ed6a..7cf681f1 100644 --- a/docs/en/cowboy/2.7/guide/migrating_from_2.2/index.html +++ b/docs/en/cowboy/2.7/guide/migrating_from_2.2/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/migrating_from_2.3/index.html b/docs/en/cowboy/2.7/guide/migrating_from_2.3/index.html index 5e12de18..d010cd4c 100644 --- a/docs/en/cowboy/2.7/guide/migrating_from_2.3/index.html +++ b/docs/en/cowboy/2.7/guide/migrating_from_2.3/index.html @@ -152,6 +152,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -162,8 +164,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/migrating_from_2.4/index.html b/docs/en/cowboy/2.7/guide/migrating_from_2.4/index.html index 66a8c005..13974c4f 100644 --- a/docs/en/cowboy/2.7/guide/migrating_from_2.4/index.html +++ b/docs/en/cowboy/2.7/guide/migrating_from_2.4/index.html @@ -180,6 +180,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -190,8 +192,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/migrating_from_2.5/index.html b/docs/en/cowboy/2.7/guide/migrating_from_2.5/index.html index aee9d297..33f487a6 100644 --- a/docs/en/cowboy/2.7/guide/migrating_from_2.5/index.html +++ b/docs/en/cowboy/2.7/guide/migrating_from_2.5/index.html @@ -195,6 +195,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -205,8 +207,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/migrating_from_2.6/index.html b/docs/en/cowboy/2.7/guide/migrating_from_2.6/index.html index 7bdc316a..8a4f53b8 100644 --- a/docs/en/cowboy/2.7/guide/migrating_from_2.6/index.html +++ b/docs/en/cowboy/2.7/guide/migrating_from_2.6/index.html @@ -216,6 +216,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -226,8 +228,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/modern_web/index.html b/docs/en/cowboy/2.7/guide/modern_web/index.html index 848b6b54..7c0e0085 100644 --- a/docs/en/cowboy/2.7/guide/modern_web/index.html +++ b/docs/en/cowboy/2.7/guide/modern_web/index.html @@ -146,6 +146,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -156,8 +158,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/multipart/index.html b/docs/en/cowboy/2.7/guide/multipart/index.html index b8a2fe4b..54830532 100644 --- a/docs/en/cowboy/2.7/guide/multipart/index.html +++ b/docs/en/cowboy/2.7/guide/multipart/index.html @@ -219,6 +219,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -229,8 +231,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/req/index.html b/docs/en/cowboy/2.7/guide/req/index.html index b6fbc997..51db1020 100644 --- a/docs/en/cowboy/2.7/guide/req/index.html +++ b/docs/en/cowboy/2.7/guide/req/index.html @@ -394,6 +394,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -404,8 +406,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/req_body/index.html b/docs/en/cowboy/2.7/guide/req_body/index.html index 89c778a0..13566fbb 100644 --- a/docs/en/cowboy/2.7/guide/req_body/index.html +++ b/docs/en/cowboy/2.7/guide/req_body/index.html @@ -205,6 +205,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -215,8 +217,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/resource_design/index.html b/docs/en/cowboy/2.7/guide/resource_design/index.html index d0a808f4..debc884a 100644 --- a/docs/en/cowboy/2.7/guide/resource_design/index.html +++ b/docs/en/cowboy/2.7/guide/resource_design/index.html @@ -179,6 +179,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -189,8 +191,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/resp/index.html b/docs/en/cowboy/2.7/guide/resp/index.html index a5928ced..e9e62fca 100644 --- a/docs/en/cowboy/2.7/guide/resp/index.html +++ b/docs/en/cowboy/2.7/guide/resp/index.html @@ -361,6 +361,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -371,8 +373,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.7/guide/rest_flowcharts/index.html index f0cc741f..dd38ffe1 100644 --- a/docs/en/cowboy/2.7/guide/rest_flowcharts/index.html +++ b/docs/en/cowboy/2.7/guide/rest_flowcharts/index.html @@ -176,6 +176,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -186,8 +188,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/rest_handlers/index.html b/docs/en/cowboy/2.7/guide/rest_handlers/index.html index b10f42d3..8d74141d 100644 --- a/docs/en/cowboy/2.7/guide/rest_handlers/index.html +++ b/docs/en/cowboy/2.7/guide/rest_handlers/index.html @@ -277,6 +277,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -287,8 +289,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/rest_principles/index.html b/docs/en/cowboy/2.7/guide/rest_principles/index.html index ad8184f6..fb65ced2 100644 --- a/docs/en/cowboy/2.7/guide/rest_principles/index.html +++ b/docs/en/cowboy/2.7/guide/rest_principles/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/routing/index.html b/docs/en/cowboy/2.7/guide/routing/index.html index 22f45c21..8cfbfe0e 100644 --- a/docs/en/cowboy/2.7/guide/routing/index.html +++ b/docs/en/cowboy/2.7/guide/routing/index.html @@ -317,6 +317,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -327,8 +329,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/specs/index.html b/docs/en/cowboy/2.7/guide/specs/index.html index fdf35d1f..1ce3d4ac 100644 --- a/docs/en/cowboy/2.7/guide/specs/index.html +++ b/docs/en/cowboy/2.7/guide/specs/index.html @@ -481,6 +481,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -491,8 +493,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/static_files/index.html b/docs/en/cowboy/2.7/guide/static_files/index.html index fd32b5c7..88ce25f9 100644 --- a/docs/en/cowboy/2.7/guide/static_files/index.html +++ b/docs/en/cowboy/2.7/guide/static_files/index.html @@ -213,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -223,8 +225,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/streams/index.html b/docs/en/cowboy/2.7/guide/streams/index.html index 8a39f784..90fad898 100644 --- a/docs/en/cowboy/2.7/guide/streams/index.html +++ b/docs/en/cowboy/2.7/guide/streams/index.html @@ -137,6 +137,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/ws_handlers/index.html b/docs/en/cowboy/2.7/guide/ws_handlers/index.html index 8a90ee96..43826837 100644 --- a/docs/en/cowboy/2.7/guide/ws_handlers/index.html +++ b/docs/en/cowboy/2.7/guide/ws_handlers/index.html @@ -302,6 +302,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -312,8 +314,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/guide/ws_protocol/index.html b/docs/en/cowboy/2.7/guide/ws_protocol/index.html index 449e8ffe..43d43d5f 100644 --- a/docs/en/cowboy/2.7/guide/ws_protocol/index.html +++ b/docs/en/cowboy/2.7/guide/ws_protocol/index.html @@ -134,6 +134,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -144,8 +146,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.7/manual/cowboy.set_env/index.html index 71247d13..16dece07 100644 --- a/docs/en/cowboy/2.7/manual/cowboy.set_env/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy.set_env/index.html @@ -149,6 +149,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -159,8 +161,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.7/manual/cowboy.start_clear/index.html index 1aca22e0..7b6cf152 100644 --- a/docs/en/cowboy/2.7/manual/cowboy.start_clear/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy.start_clear/index.html @@ -167,6 +167,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.7/manual/cowboy.start_tls/index.html index bbd95c0a..653ee7ea 100644 --- a/docs/en/cowboy/2.7/manual/cowboy.start_tls/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy.start_tls/index.html @@ -172,6 +172,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -182,8 +184,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.7/manual/cowboy.stop_listener/index.html index d054fa01..a8005640 100644 --- a/docs/en/cowboy/2.7/manual/cowboy.stop_listener/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy.stop_listener/index.html @@ -132,6 +132,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -142,8 +144,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy/index.html b/docs/en/cowboy/2.7/manual/cowboy/index.html index d3307f9f..d026c025 100644 --- a/docs/en/cowboy/2.7/manual/cowboy/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy/index.html @@ -166,6 +166,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -176,8 +178,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_app/index.html b/docs/en/cowboy/2.7/manual/cowboy_app/index.html index b9af8975..cf99a31b 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_app/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_app/index.html @@ -177,6 +177,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -187,8 +189,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_compress_h/index.html b/docs/en/cowboy/2.7/manual/cowboy_compress_h/index.html index 52839006..a8419882 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_compress_h/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_compress_h/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.7/manual/cowboy_constraints.int/index.html index c614a4a0..8c7a3b3b 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_constraints.int/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_constraints.int/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.7/manual/cowboy_constraints.nonempty/index.html index add064c8..4d2d09c6 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_constraints.nonempty/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_constraints.nonempty/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.7/manual/cowboy_constraints/index.html index 4d9c707c..6c693d45 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_constraints/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_constraints/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.7/manual/cowboy_handler.terminate/index.html index 0889b6fb..36cfb3ae 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_handler.terminate/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_handler.terminate/index.html @@ -144,6 +144,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -154,8 +156,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_handler/index.html b/docs/en/cowboy/2.7/manual/cowboy_handler/index.html index 35081cfc..b9660fe8 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_handler/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_handler/index.html @@ -136,6 +136,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -146,8 +148,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_http/index.html b/docs/en/cowboy/2.7/manual/cowboy_http/index.html index 31cd5cf8..ca756e42 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_http/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_http/index.html @@ -230,6 +230,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -240,8 +242,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_http2/index.html b/docs/en/cowboy/2.7/manual/cowboy_http2/index.html index 59145846..43535590 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_http2/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_http2/index.html @@ -246,6 +246,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -256,8 +258,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_loop/index.html b/docs/en/cowboy/2.7/manual/cowboy_loop/index.html index 03b92515..7d2584c5 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_loop/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_loop/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_metrics_h/index.html b/docs/en/cowboy/2.7/manual/cowboy_metrics_h/index.html index b522c771..ae818172 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_metrics_h/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_metrics_h/index.html @@ -227,6 +227,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -237,8 +239,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.7/manual/cowboy_middleware/index.html index 5ae524c1..d86405a5 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_middleware/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_middleware/index.html @@ -147,6 +147,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -157,8 +159,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.binding/index.html index aa5d1d42..fd25de59 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.binding/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.binding/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.bindings/index.html index 9c4053b8..cd769889 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.bindings/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.bindings/index.html @@ -130,6 +130,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -140,8 +142,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.body_length/index.html index e00a132c..48b24ec5 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.body_length/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.body_length/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.cast/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.cast/index.html index 259c9ab5..e80a9ebb 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.cast/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.cast/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.cert/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.cert/index.html index 1b7a29bd..903a33f5 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.cert/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.cert/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.delete_resp_header/index.html index 062cecdd..12465d7e 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.delete_resp_header/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.delete_resp_header/index.html @@ -135,6 +135,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -145,8 +147,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.filter_cookies/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.filter_cookies/index.html index 3287ab65..2d29f538 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.filter_cookies/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.filter_cookies/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.has_body/index.html index 83d39a1b..f3b2d99f 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.has_body/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.has_body/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -138,8 +140,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.has_resp_body/index.html index 9b4c3c4a..451493f7 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.has_resp_body/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.has_resp_body/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.has_resp_header/index.html index a52df7ee..f43f8273 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.has_resp_header/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.has_resp_header/index.html @@ -136,6 +136,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -146,8 +148,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.header/index.html index 06d14c00..47b2ea4e 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.header/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.header/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.headers/index.html index e19f384a..dc45fa21 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.headers/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.headers/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.host/index.html index e6a5aa80..616ca052 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.host/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.host/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.host_info/index.html index b7e420ed..31d6523d 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.host_info/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.host_info/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.inform/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.inform/index.html index c675aca3..bef1b88b 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.inform/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.inform/index.html @@ -155,6 +155,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -165,8 +167,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.match_cookies/index.html index 71b2286c..333467b6 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.match_cookies/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.match_cookies/index.html @@ -158,6 +158,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -168,8 +170,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.match_qs/index.html index 2277c7d3..93d4b140 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.match_qs/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.match_qs/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.method/index.html index f8eea88c..95248fbf 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.method/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.method/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.parse_cookies/index.html index 93037767..eb7fb77f 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.parse_cookies/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.parse_cookies/index.html @@ -156,6 +156,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -166,8 +168,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.parse_header/index.html index d8090c13..b2278431 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.parse_header/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.parse_header/index.html @@ -308,6 +308,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -318,8 +320,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.parse_qs/index.html index 00d42e95..d5dbac63 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.parse_qs/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.parse_qs/index.html @@ -145,6 +145,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -155,8 +157,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.path/index.html index 35df026f..5d51457f 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.path/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.path/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.path_info/index.html index dbfe405e..4f6549e2 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.path_info/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.path_info/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.peer/index.html index 0f637342..c01a80c2 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.peer/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.peer/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.port/index.html index 9c0d1720..e2c338e6 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.port/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.port/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.push/index.html index 28dc0c74..e30f3316 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.push/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.push/index.html @@ -164,6 +164,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -174,8 +176,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.qs/index.html index 604fce62..9d69c5de 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.qs/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.qs/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.read_and_match_urlencoded_body/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.read_and_match_urlencoded_body/index.html index 860a6e61..ee4fd755 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.read_and_match_urlencoded_body/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.read_and_match_urlencoded_body/index.html @@ -188,6 +188,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -198,8 +200,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.read_body/index.html index a60dbea8..72ff04f4 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.read_body/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.read_body/index.html @@ -162,6 +162,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -172,8 +174,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.read_part/index.html index 05ec9007..14c23a09 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.read_part/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.read_part/index.html @@ -184,6 +184,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -194,8 +196,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.read_part_body/index.html index b05218f3..6dce95ba 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.read_part_body/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.read_part_body/index.html @@ -160,6 +160,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -170,8 +172,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.read_urlencoded_body/index.html index 333d7ec3..75fa7962 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.read_urlencoded_body/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.read_urlencoded_body/index.html @@ -154,6 +154,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -164,8 +166,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.reply/index.html index e50e685e..dfc4bd60 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.reply/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.reply/index.html @@ -176,6 +176,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -186,8 +188,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.resp_header/index.html index 1b9a4ab8..a0a2d25a 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.resp_header/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.resp_header/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.resp_headers/index.html index d236bb1e..483af6cb 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.resp_headers/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.resp_headers/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -138,8 +140,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.scheme/index.html index 3b582af3..2b615e50 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.scheme/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.scheme/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_body/index.html index 9ae29078..77532db5 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_body/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_body/index.html @@ -169,6 +169,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -179,8 +181,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_cookie/index.html index 68e9dd23..a4b015fb 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_cookie/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_cookie/index.html @@ -194,6 +194,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -204,8 +206,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_header/index.html index c45c3d38..a62c7447 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_header/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_header/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_headers/index.html index 4df64975..0a373605 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_headers/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.set_resp_headers/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.sock/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.sock/index.html index 7448bb55..0f1dc99a 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.sock/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.sock/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.stream_body/index.html index fe73c668..17a7e0d6 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.stream_body/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.stream_body/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.stream_events/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.stream_events/index.html index 96d74f2c..7b06624c 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.stream_events/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.stream_events/index.html @@ -162,6 +162,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -172,8 +174,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.stream_reply/index.html index f74cf565..fd259d12 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.stream_reply/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.stream_reply/index.html @@ -165,6 +165,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -175,8 +177,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.stream_trailers/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.stream_trailers/index.html index e0df54db..13ba4e74 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.stream_trailers/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.stream_trailers/index.html @@ -145,6 +145,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -155,8 +157,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.uri/index.html index b7244272..2bca291a 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.uri/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.uri/index.html @@ -196,6 +196,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -206,8 +208,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.7/manual/cowboy_req.version/index.html index 5cb3f6d2..c52fbf89 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req.version/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req.version/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_req/index.html b/docs/en/cowboy/2.7/manual/cowboy_req/index.html index 8a9aa660..830fc3ae 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_req/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_req/index.html @@ -318,6 +318,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -328,8 +330,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_rest/index.html b/docs/en/cowboy/2.7/manual/cowboy_rest/index.html index 54bb0ba0..daf43bb8 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_rest/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_rest/index.html @@ -596,6 +596,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -606,8 +608,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.7/manual/cowboy_router.compile/index.html index a9083237..e1a834ef 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_router.compile/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_router.compile/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_router/index.html b/docs/en/cowboy/2.7/manual/cowboy_router/index.html index 4e6a681f..b4546431 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_router/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_router/index.html @@ -155,6 +155,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -165,8 +167,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_static/index.html b/docs/en/cowboy/2.7/manual/cowboy_static/index.html index 6eb813d0..01f4fb45 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_static/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_static/index.html @@ -213,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -223,8 +225,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_stream/index.html b/docs/en/cowboy/2.7/manual/cowboy_stream/index.html index 5256b658..bdac07dc 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_stream/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_stream/index.html @@ -373,6 +373,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -383,8 +385,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_stream_h/index.html b/docs/en/cowboy/2.7/manual/cowboy_stream_h/index.html index c898b1c1..cec85184 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_stream_h/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_stream_h/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_tracer_h/index.html b/docs/en/cowboy/2.7/manual/cowboy_tracer_h/index.html index 622274da..8b986f4e 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_tracer_h/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_tracer_h/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.7/manual/cowboy_websocket/index.html index 4326fe98..68cbec6d 100644 --- a/docs/en/cowboy/2.7/manual/cowboy_websocket/index.html +++ b/docs/en/cowboy/2.7/manual/cowboy_websocket/index.html @@ -291,6 +291,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -301,8 +303,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/http_status_codes/index.html b/docs/en/cowboy/2.7/manual/http_status_codes/index.html index 4bd95be6..d8c971c5 100644 --- a/docs/en/cowboy/2.7/manual/http_status_codes/index.html +++ b/docs/en/cowboy/2.7/manual/http_status_codes/index.html @@ -182,6 +182,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -192,8 +194,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.7/manual/index.html b/docs/en/cowboy/2.7/manual/index.html index ce6550b3..6227d71f 100644 --- a/docs/en/cowboy/2.7/manual/index.html +++ b/docs/en/cowboy/2.7/manual/index.html @@ -177,6 +177,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -187,8 +189,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/constraints/index.html b/docs/en/cowboy/2.8/guide/constraints/index.html index 89b00946..ee6280d1 100644 --- a/docs/en/cowboy/2.8/guide/constraints/index.html +++ b/docs/en/cowboy/2.8/guide/constraints/index.html @@ -198,6 +198,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -208,8 +210,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/cookies/index.html b/docs/en/cowboy/2.8/guide/cookies/index.html index 49e529d4..5156040f 100644 --- a/docs/en/cowboy/2.8/guide/cookies/index.html +++ b/docs/en/cowboy/2.8/guide/cookies/index.html @@ -215,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -225,8 +227,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/erlang_web/index.html b/docs/en/cowboy/2.8/guide/erlang_web/index.html index 6f367c61..49ba861d 100644 --- a/docs/en/cowboy/2.8/guide/erlang_web/index.html +++ b/docs/en/cowboy/2.8/guide/erlang_web/index.html @@ -164,6 +164,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -174,8 +176,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/flow_diagram/index.html b/docs/en/cowboy/2.8/guide/flow_diagram/index.html index 072f6c0a..bb95185f 100644 --- a/docs/en/cowboy/2.8/guide/flow_diagram/index.html +++ b/docs/en/cowboy/2.8/guide/flow_diagram/index.html @@ -142,6 +142,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/getting_started/index.html b/docs/en/cowboy/2.8/guide/getting_started/index.html index 00b72914..448f511a 100644 --- a/docs/en/cowboy/2.8/guide/getting_started/index.html +++ b/docs/en/cowboy/2.8/guide/getting_started/index.html @@ -216,6 +216,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -226,8 +228,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/handlers/index.html b/docs/en/cowboy/2.8/guide/handlers/index.html index c034b531..a60ce8e8 100644 --- a/docs/en/cowboy/2.8/guide/handlers/index.html +++ b/docs/en/cowboy/2.8/guide/handlers/index.html @@ -169,6 +169,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -179,8 +181,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/index.html b/docs/en/cowboy/2.8/guide/index.html index 53a80762..2acdcd78 100644 --- a/docs/en/cowboy/2.8/guide/index.html +++ b/docs/en/cowboy/2.8/guide/index.html @@ -187,6 +187,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -197,8 +199,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/introduction/index.html b/docs/en/cowboy/2.8/guide/introduction/index.html index c6117651..c5a3c786 100644 --- a/docs/en/cowboy/2.8/guide/introduction/index.html +++ b/docs/en/cowboy/2.8/guide/introduction/index.html @@ -152,6 +152,8 @@ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -162,8 +164,6 @@ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/listeners/index.html b/docs/en/cowboy/2.8/guide/listeners/index.html index 1c0161f3..d8303608 100644 --- a/docs/en/cowboy/2.8/guide/listeners/index.html +++ b/docs/en/cowboy/2.8/guide/listeners/index.html @@ -182,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -192,8 +194,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/loop_handlers/index.html b/docs/en/cowboy/2.8/guide/loop_handlers/index.html index 0cc3c388..31f91278 100644 --- a/docs/en/cowboy/2.8/guide/loop_handlers/index.html +++ b/docs/en/cowboy/2.8/guide/loop_handlers/index.html @@ -183,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -193,8 +195,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/middlewares/index.html b/docs/en/cowboy/2.8/guide/middlewares/index.html index 33fad4bc..d59d1928 100644 --- a/docs/en/cowboy/2.8/guide/middlewares/index.html +++ b/docs/en/cowboy/2.8/guide/middlewares/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.8/guide/migrating_from_1.0/index.html index 6280d406..efbce879 100644 --- a/docs/en/cowboy/2.8/guide/migrating_from_1.0/index.html +++ b/docs/en/cowboy/2.8/guide/migrating_from_1.0/index.html @@ -232,6 +232,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -242,8 +244,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.8/guide/migrating_from_2.0/index.html index 3d7361ca..887e75c5 100644 --- a/docs/en/cowboy/2.8/guide/migrating_from_2.0/index.html +++ b/docs/en/cowboy/2.8/guide/migrating_from_2.0/index.html @@ -167,6 +167,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/migrating_from_2.1/index.html b/docs/en/cowboy/2.8/guide/migrating_from_2.1/index.html index 29bcad0b..28a39c5b 100644 --- a/docs/en/cowboy/2.8/guide/migrating_from_2.1/index.html +++ b/docs/en/cowboy/2.8/guide/migrating_from_2.1/index.html @@ -178,6 +178,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -188,8 +190,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/migrating_from_2.2/index.html b/docs/en/cowboy/2.8/guide/migrating_from_2.2/index.html index b87883e9..8cbc10d4 100644 --- a/docs/en/cowboy/2.8/guide/migrating_from_2.2/index.html +++ b/docs/en/cowboy/2.8/guide/migrating_from_2.2/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/migrating_from_2.3/index.html b/docs/en/cowboy/2.8/guide/migrating_from_2.3/index.html index 2d7377f1..3e14ab72 100644 --- a/docs/en/cowboy/2.8/guide/migrating_from_2.3/index.html +++ b/docs/en/cowboy/2.8/guide/migrating_from_2.3/index.html @@ -152,6 +152,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -162,8 +164,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/migrating_from_2.4/index.html b/docs/en/cowboy/2.8/guide/migrating_from_2.4/index.html index 5119423b..0d079d42 100644 --- a/docs/en/cowboy/2.8/guide/migrating_from_2.4/index.html +++ b/docs/en/cowboy/2.8/guide/migrating_from_2.4/index.html @@ -180,6 +180,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -190,8 +192,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/migrating_from_2.5/index.html b/docs/en/cowboy/2.8/guide/migrating_from_2.5/index.html index 90a632dc..99ce422c 100644 --- a/docs/en/cowboy/2.8/guide/migrating_from_2.5/index.html +++ b/docs/en/cowboy/2.8/guide/migrating_from_2.5/index.html @@ -195,6 +195,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -205,8 +207,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/migrating_from_2.6/index.html b/docs/en/cowboy/2.8/guide/migrating_from_2.6/index.html index 4abd3017..696f551a 100644 --- a/docs/en/cowboy/2.8/guide/migrating_from_2.6/index.html +++ b/docs/en/cowboy/2.8/guide/migrating_from_2.6/index.html @@ -216,6 +216,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -226,8 +228,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/migrating_from_2.7/index.html b/docs/en/cowboy/2.8/guide/migrating_from_2.7/index.html index 19feb9fa..56e5bdc1 100644 --- a/docs/en/cowboy/2.8/guide/migrating_from_2.7/index.html +++ b/docs/en/cowboy/2.8/guide/migrating_from_2.7/index.html @@ -172,6 +172,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -182,8 +184,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/modern_web/index.html b/docs/en/cowboy/2.8/guide/modern_web/index.html index 5872574a..47d1b3b3 100644 --- a/docs/en/cowboy/2.8/guide/modern_web/index.html +++ b/docs/en/cowboy/2.8/guide/modern_web/index.html @@ -146,6 +146,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -156,8 +158,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/multipart/index.html b/docs/en/cowboy/2.8/guide/multipart/index.html index 71b8914f..3db3f5da 100644 --- a/docs/en/cowboy/2.8/guide/multipart/index.html +++ b/docs/en/cowboy/2.8/guide/multipart/index.html @@ -219,6 +219,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -229,8 +231,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/performance/index.html b/docs/en/cowboy/2.8/guide/performance/index.html index 4c81fe27..a040baa4 100644 --- a/docs/en/cowboy/2.8/guide/performance/index.html +++ b/docs/en/cowboy/2.8/guide/performance/index.html @@ -124,6 +124,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -134,8 +136,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/req/index.html b/docs/en/cowboy/2.8/guide/req/index.html index 2db5f136..13d1b8be 100644 --- a/docs/en/cowboy/2.8/guide/req/index.html +++ b/docs/en/cowboy/2.8/guide/req/index.html @@ -394,6 +394,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -404,8 +406,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/req_body/index.html b/docs/en/cowboy/2.8/guide/req_body/index.html index 8bad10ee..df30e8aa 100644 --- a/docs/en/cowboy/2.8/guide/req_body/index.html +++ b/docs/en/cowboy/2.8/guide/req_body/index.html @@ -205,6 +205,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -215,8 +217,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/resource_design/index.html b/docs/en/cowboy/2.8/guide/resource_design/index.html index 81bc4974..62ca7ea0 100644 --- a/docs/en/cowboy/2.8/guide/resource_design/index.html +++ b/docs/en/cowboy/2.8/guide/resource_design/index.html @@ -179,6 +179,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -189,8 +191,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/resp/index.html b/docs/en/cowboy/2.8/guide/resp/index.html index d57d9516..e6c060b6 100644 --- a/docs/en/cowboy/2.8/guide/resp/index.html +++ b/docs/en/cowboy/2.8/guide/resp/index.html @@ -361,6 +361,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -371,8 +373,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.8/guide/rest_flowcharts/index.html index 8195ca7d..6490e83f 100644 --- a/docs/en/cowboy/2.8/guide/rest_flowcharts/index.html +++ b/docs/en/cowboy/2.8/guide/rest_flowcharts/index.html @@ -176,6 +176,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -186,8 +188,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/rest_handlers/index.html b/docs/en/cowboy/2.8/guide/rest_handlers/index.html index a3d774f5..78d6b4ef 100644 --- a/docs/en/cowboy/2.8/guide/rest_handlers/index.html +++ b/docs/en/cowboy/2.8/guide/rest_handlers/index.html @@ -277,6 +277,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -287,8 +289,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/rest_principles/index.html b/docs/en/cowboy/2.8/guide/rest_principles/index.html index 3661bc2c..9c175af0 100644 --- a/docs/en/cowboy/2.8/guide/rest_principles/index.html +++ b/docs/en/cowboy/2.8/guide/rest_principles/index.html @@ -150,6 +150,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/routing/index.html b/docs/en/cowboy/2.8/guide/routing/index.html index 6104f983..fdc712be 100644 --- a/docs/en/cowboy/2.8/guide/routing/index.html +++ b/docs/en/cowboy/2.8/guide/routing/index.html @@ -327,6 +327,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -337,8 +339,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/specs/index.html b/docs/en/cowboy/2.8/guide/specs/index.html index a395eade..b987d060 100644 --- a/docs/en/cowboy/2.8/guide/specs/index.html +++ b/docs/en/cowboy/2.8/guide/specs/index.html @@ -493,6 +493,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -503,8 +505,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/static_files/index.html b/docs/en/cowboy/2.8/guide/static_files/index.html index 98bc9576..10fb5014 100644 --- a/docs/en/cowboy/2.8/guide/static_files/index.html +++ b/docs/en/cowboy/2.8/guide/static_files/index.html @@ -213,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -223,8 +225,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/streams/index.html b/docs/en/cowboy/2.8/guide/streams/index.html index c8d0c3bf..d57d27bd 100644 --- a/docs/en/cowboy/2.8/guide/streams/index.html +++ b/docs/en/cowboy/2.8/guide/streams/index.html @@ -137,6 +137,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/ws_handlers/index.html b/docs/en/cowboy/2.8/guide/ws_handlers/index.html index 6e0682de..dbf51ce6 100644 --- a/docs/en/cowboy/2.8/guide/ws_handlers/index.html +++ b/docs/en/cowboy/2.8/guide/ws_handlers/index.html @@ -302,6 +302,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -312,8 +314,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/guide/ws_protocol/index.html b/docs/en/cowboy/2.8/guide/ws_protocol/index.html index 3e27fc6c..222b0433 100644 --- a/docs/en/cowboy/2.8/guide/ws_protocol/index.html +++ b/docs/en/cowboy/2.8/guide/ws_protocol/index.html @@ -134,6 +134,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -144,8 +146,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.8/manual/cowboy.set_env/index.html index 2a002b5e..77908c20 100644 --- a/docs/en/cowboy/2.8/manual/cowboy.set_env/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy.set_env/index.html @@ -149,6 +149,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -159,8 +161,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.8/manual/cowboy.start_clear/index.html index 15d533e9..5e9feb9c 100644 --- a/docs/en/cowboy/2.8/manual/cowboy.start_clear/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy.start_clear/index.html @@ -167,6 +167,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -177,8 +179,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.8/manual/cowboy.start_tls/index.html index f524255d..c53667aa 100644 --- a/docs/en/cowboy/2.8/manual/cowboy.start_tls/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy.start_tls/index.html @@ -172,6 +172,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -182,8 +184,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.8/manual/cowboy.stop_listener/index.html index bea39f16..9af92298 100644 --- a/docs/en/cowboy/2.8/manual/cowboy.stop_listener/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy.stop_listener/index.html @@ -132,6 +132,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -142,8 +144,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy/index.html b/docs/en/cowboy/2.8/manual/cowboy/index.html index 5e6cc335..48c6c0bf 100644 --- a/docs/en/cowboy/2.8/manual/cowboy/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy/index.html @@ -166,6 +166,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -176,8 +178,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_app/index.html b/docs/en/cowboy/2.8/manual/cowboy_app/index.html index 8290f321..a9c9e8d9 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_app/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_app/index.html @@ -177,6 +177,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -187,8 +189,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_compress_h/index.html b/docs/en/cowboy/2.8/manual/cowboy_compress_h/index.html index 9e961431..38521443 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_compress_h/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_compress_h/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.8/manual/cowboy_constraints.int/index.html index 5a6c114a..c30e811d 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_constraints.int/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_constraints.int/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.8/manual/cowboy_constraints.nonempty/index.html index 74f3544c..14ec1952 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_constraints.nonempty/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_constraints.nonempty/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.8/manual/cowboy_constraints/index.html index ec71fc16..0d09a91d 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_constraints/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_constraints/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.8/manual/cowboy_handler.terminate/index.html index a2d21705..a9962609 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_handler.terminate/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_handler.terminate/index.html @@ -144,6 +144,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -154,8 +156,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_handler/index.html b/docs/en/cowboy/2.8/manual/cowboy_handler/index.html index d85a34ad..87d1d51f 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_handler/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_handler/index.html @@ -136,6 +136,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -146,8 +148,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_http/index.html b/docs/en/cowboy/2.8/manual/cowboy_http/index.html index 00404e2c..35817e94 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_http/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_http/index.html @@ -236,6 +236,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -246,8 +248,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_http2/index.html b/docs/en/cowboy/2.8/manual/cowboy_http2/index.html index 278c4fce..eea7e78e 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_http2/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_http2/index.html @@ -260,6 +260,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -270,8 +272,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_loop/index.html b/docs/en/cowboy/2.8/manual/cowboy_loop/index.html index 190d3005..ed5d6904 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_loop/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_loop/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_metrics_h/index.html b/docs/en/cowboy/2.8/manual/cowboy_metrics_h/index.html index 10893ae7..cd1571d9 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_metrics_h/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_metrics_h/index.html @@ -227,6 +227,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -237,8 +239,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.8/manual/cowboy_middleware/index.html index 0cb6eff4..e7ce8f83 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_middleware/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_middleware/index.html @@ -147,6 +147,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -157,8 +159,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.binding/index.html index 39e8dfcf..85361d39 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.binding/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.binding/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.bindings/index.html index 5c360b47..7098bac8 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.bindings/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.bindings/index.html @@ -130,6 +130,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -140,8 +142,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.body_length/index.html index 338819c0..ba9bcd78 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.body_length/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.body_length/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.cast/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.cast/index.html index 001ad0b2..23914751 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.cast/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.cast/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.cert/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.cert/index.html index 78ee7c57..9ad8cf36 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.cert/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.cert/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.delete_resp_header/index.html index b586e99c..36bbcd84 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.delete_resp_header/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.delete_resp_header/index.html @@ -135,6 +135,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -145,8 +147,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.filter_cookies/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.filter_cookies/index.html index 073b880c..d3ac68c5 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.filter_cookies/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.filter_cookies/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.has_body/index.html index 266a3d70..fcf3dbd5 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.has_body/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.has_body/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -138,8 +140,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.has_resp_body/index.html index 669bc8a8..c8fcc8b2 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.has_resp_body/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.has_resp_body/index.html @@ -133,6 +133,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -143,8 +145,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.has_resp_header/index.html index 6a13f8f9..1c614f22 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.has_resp_header/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.has_resp_header/index.html @@ -136,6 +136,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -146,8 +148,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.header/index.html index a3582c6c..13dfaac3 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.header/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.header/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.headers/index.html index e09cad42..e5429fa7 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.headers/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.headers/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.host/index.html index 73e4f898..7a0e6321 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.host/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.host/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.host_info/index.html index 7d76b559..4056368e 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.host_info/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.host_info/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.inform/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.inform/index.html index 2286d26c..4449bc65 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.inform/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.inform/index.html @@ -155,6 +155,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -165,8 +167,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.match_cookies/index.html index f8915dff..8bec8b31 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.match_cookies/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.match_cookies/index.html @@ -158,6 +158,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -168,8 +170,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.match_qs/index.html index 30d051e5..9a82a63e 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.match_qs/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.match_qs/index.html @@ -157,6 +157,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -167,8 +169,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.method/index.html index dc8ac901..0aa1a6b1 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.method/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.method/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.parse_cookies/index.html index a10b7eda..2d94bbef 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.parse_cookies/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.parse_cookies/index.html @@ -156,6 +156,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -166,8 +168,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.parse_header/index.html index ee101649..a0771660 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.parse_header/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.parse_header/index.html @@ -364,6 +364,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -374,8 +376,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.parse_qs/index.html index 77c5f29e..8b7166e4 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.parse_qs/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.parse_qs/index.html @@ -145,6 +145,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -155,8 +157,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.path/index.html index 16ab0616..136a82fb 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.path/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.path/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.path_info/index.html index 863eaffd..6c2e6497 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.path_info/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.path_info/index.html @@ -131,6 +131,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -141,8 +143,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.peer/index.html index a9b17aa0..832f82e2 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.peer/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.peer/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.port/index.html index 42844727..10a12db8 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.port/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.port/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.push/index.html index cbcfaa4b..c8f07fb5 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.push/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.push/index.html @@ -164,6 +164,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -174,8 +176,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.qs/index.html index 4fbb6d0d..b2f8f976 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.qs/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.qs/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.read_and_match_urlencoded_body/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.read_and_match_urlencoded_body/index.html index 32f2099a..8b3218ef 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.read_and_match_urlencoded_body/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.read_and_match_urlencoded_body/index.html @@ -188,6 +188,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -198,8 +200,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.read_body/index.html index 71bcdb63..5c4b9403 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.read_body/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.read_body/index.html @@ -162,6 +162,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -172,8 +174,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.read_part/index.html index f94239af..4d24c79b 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.read_part/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.read_part/index.html @@ -184,6 +184,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -194,8 +196,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.read_part_body/index.html index a5c5aa15..12078a55 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.read_part_body/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.read_part_body/index.html @@ -160,6 +160,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -170,8 +172,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.read_urlencoded_body/index.html index 20d25e37..5a629ef4 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.read_urlencoded_body/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.read_urlencoded_body/index.html @@ -154,6 +154,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -164,8 +166,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.reply/index.html index 78228aa6..c67951e0 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.reply/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.reply/index.html @@ -176,6 +176,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -186,8 +188,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.resp_header/index.html index d97a77c8..a90eabb1 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.resp_header/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.resp_header/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.resp_headers/index.html index aba14651..2ac391c1 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.resp_headers/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.resp_headers/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -138,8 +140,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.scheme/index.html index 643cffc9..85ae2ed8 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.scheme/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.scheme/index.html @@ -142,6 +142,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -152,8 +154,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_body/index.html index e31d4521..9d5b60bb 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_body/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_body/index.html @@ -169,6 +169,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -179,8 +181,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_cookie/index.html index 22c8e9d2..70950f6b 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_cookie/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_cookie/index.html @@ -194,6 +194,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -204,8 +206,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_header/index.html index 63d0e057..077d160d 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_header/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_header/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_headers/index.html index b59156d5..86fcdd98 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_headers/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.set_resp_headers/index.html @@ -141,6 +141,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -151,8 +153,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.sock/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.sock/index.html index af3c8b26..50779be1 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.sock/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.sock/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.stream_body/index.html index f4e3d4bf..984f0a2a 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.stream_body/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.stream_body/index.html @@ -148,6 +148,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -158,8 +160,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.stream_events/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.stream_events/index.html index 6d5cdd98..f4d65c9f 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.stream_events/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.stream_events/index.html @@ -162,6 +162,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -172,8 +174,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.stream_reply/index.html index b6029710..8929600d 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.stream_reply/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.stream_reply/index.html @@ -165,6 +165,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -175,8 +177,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.stream_trailers/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.stream_trailers/index.html index c6f6b7b3..b965cb0f 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.stream_trailers/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.stream_trailers/index.html @@ -145,6 +145,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -155,8 +157,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.uri/index.html index aa63991f..7cebc289 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.uri/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.uri/index.html @@ -196,6 +196,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -206,8 +208,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.8/manual/cowboy_req.version/index.html index 8f180f6b..56029aab 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req.version/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req.version/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_req/index.html b/docs/en/cowboy/2.8/manual/cowboy_req/index.html index ad254363..8836394e 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_req/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_req/index.html @@ -318,6 +318,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -328,8 +330,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_rest/index.html b/docs/en/cowboy/2.8/manual/cowboy_rest/index.html index fb831088..963a7b9a 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_rest/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_rest/index.html @@ -596,6 +596,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -606,8 +608,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.8/manual/cowboy_router.compile/index.html index 84935673..21416eb5 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_router.compile/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_router.compile/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -148,8 +150,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_router/index.html b/docs/en/cowboy/2.8/manual/cowboy_router/index.html index 2cbee0f1..7c0145c2 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_router/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_router/index.html @@ -155,6 +155,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -165,8 +167,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_static/index.html b/docs/en/cowboy/2.8/manual/cowboy_static/index.html index 01191123..97e669fc 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_static/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_static/index.html @@ -213,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -223,8 +225,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_stream/index.html b/docs/en/cowboy/2.8/manual/cowboy_stream/index.html index cf14055b..21cc24e2 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_stream/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_stream/index.html @@ -373,6 +373,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -383,8 +385,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_stream_h/index.html b/docs/en/cowboy/2.8/manual/cowboy_stream_h/index.html index 64768d38..7d4e8d8b 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_stream_h/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_stream_h/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -147,8 +149,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_tracer_h/index.html b/docs/en/cowboy/2.8/manual/cowboy_tracer_h/index.html index f14c95e5..0da2ac57 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_tracer_h/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_tracer_h/index.html @@ -150,6 +150,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -160,8 +162,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.8/manual/cowboy_websocket/index.html index ca30349b..cbd67293 100644 --- a/docs/en/cowboy/2.8/manual/cowboy_websocket/index.html +++ b/docs/en/cowboy/2.8/manual/cowboy_websocket/index.html @@ -298,6 +298,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -308,8 +310,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/http_status_codes/index.html b/docs/en/cowboy/2.8/manual/http_status_codes/index.html index ebad1eeb..52302827 100644 --- a/docs/en/cowboy/2.8/manual/http_status_codes/index.html +++ b/docs/en/cowboy/2.8/manual/http_status_codes/index.html @@ -182,6 +182,8 @@ +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -192,8 +194,6 @@
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.8/manual/index.html b/docs/en/cowboy/2.8/manual/index.html index 974bfc27..46e56a62 100644 --- a/docs/en/cowboy/2.8/manual/index.html +++ b/docs/en/cowboy/2.8/manual/index.html @@ -177,6 +177,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.9
    • +
  • 2.8
  • 2.7
    • @@ -187,8 +189,6 @@ http://www.gnu.org/software/src-highlite -->
  • 2.4
    • -
  • 2.3
    • -

    Like my work? Donate!

    diff --git a/docs/en/cowboy/2.9/guide/constraints.asciidoc b/docs/en/cowboy/2.9/guide/constraints.asciidoc new file mode 100644 index 00000000..6cc10752 --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/constraints/index.html b/docs/en/cowboy/2.9/guide/constraints/index.html new file mode 100644 index 00000000..0f7b5cc6 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/constraints/index.html @@ -0,0 +1,260 @@ + + + + + + + + + + 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:

    + + + + + + + + + +
    ConstraintDescription
    intConverts binary value to integer.
    nonemptyEnsures 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/cookies.asciidoc b/docs/en/cowboy/2.9/guide/cookies.asciidoc new file mode 100644 index 00000000..4825031b --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/cookies/index.html b/docs/en/cowboy/2.9/guide/cookies/index.html new file mode 100644 index 00000000..c2c716fc --- /dev/null +++ b/docs/en/cowboy/2.9/guide/cookies/index.html @@ -0,0 +1,277 @@ + + + + + + + + + + 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/cowboy.sty b/docs/en/cowboy/2.9/guide/cowboy.sty new file mode 100644 index 00000000..d5e0d3be --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/erlang_web.asciidoc b/docs/en/cowboy/2.9/guide/erlang_web.asciidoc new file mode 100644 index 00000000..9517bf70 --- /dev/null +++ b/docs/en/cowboy/2.9/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 ahead of anything else in this respect. 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.9/guide/erlang_web/index.html b/docs/en/cowboy/2.9/guide/erlang_web/index.html new file mode 100644 index 00000000..b11d537c --- /dev/null +++ b/docs/en/cowboy/2.9/guide/erlang_web/index.html @@ -0,0 +1,226 @@ + + + + + + + + + + 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 ahead of anything else in this respect. 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/flow_diagram.asciidoc b/docs/en/cowboy/2.9/guide/flow_diagram.asciidoc new file mode 100644 index 00000000..9eb74667 --- /dev/null +++ b/docs/en/cowboy/2.9/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. +By default, the request process executes the router and then +the 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.9/guide/flow_diagram/index.html b/docs/en/cowboy/2.9/guide/flow_diagram/index.html new file mode 100644 index 00000000..64a2a913 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/flow_diagram/index.html @@ -0,0 +1,204 @@ + + + + + + + + + + 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. By default, the request process executes the router and then the 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/getting_started.asciidoc b/docs/en/cowboy/2.9/guide/getting_started.asciidoc new file mode 100644 index 00000000..7104d9af --- /dev/null +++ b/docs/en/cowboy/2.9/guide/getting_started.asciidoc @@ -0,0 +1,148 @@ +[[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.9.0 + +DEP_PLUGINS = cowboy + +include erlang.mk +---- + +The `DEP_PLUGINS` line tells 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.9/guide/getting_started/index.html b/docs/en/cowboy/2.9/guide/getting_started/index.html new file mode 100644 index 00000000..bd9ca01c --- /dev/null +++ b/docs/en/cowboy/2.9/guide/getting_started/index.html @@ -0,0 +1,278 @@ + + + + + + + + + + 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.9.0
+
+DEP_PLUGINS = cowboy
+
+include erlang.mk
    +
    +

    The DEP_PLUGINS line tells 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/handlers.asciidoc b/docs/en/cowboy/2.9/guide/handlers.asciidoc new file mode 100644 index 00000000..fe6f4623 --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/handlers/index.html b/docs/en/cowboy/2.9/guide/handlers/index.html new file mode 100644 index 00000000..64a8da44 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/handlers/index.html @@ -0,0 +1,231 @@ + + + + + + + + + + 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/http_req_resp.png b/docs/en/cowboy/2.9/guide/http_req_resp.png new file mode 100644 index 00000000..41c17c8a Binary files /dev/null and b/docs/en/cowboy/2.9/guide/http_req_resp.png differ diff --git a/docs/en/cowboy/2.9/guide/http_req_resp.svg b/docs/en/cowboy/2.9/guide/http_req_resp.svg new file mode 100644 index 00000000..acedb152 --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/index.html b/docs/en/cowboy/2.9/guide/index.html new file mode 100644 index 00000000..058d34c4 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/index.html @@ -0,0 +1,251 @@ + + + + + + + + + + Nine Nines: Cowboy User Guide + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    + + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/introduction.asciidoc b/docs/en/cowboy/2.9/guide/introduction.asciidoc new file mode 100644 index 00000000..f81c8727 --- /dev/null +++ b/docs/en/cowboy/2.9/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 22.0 and newer. + +=== License + +Cowboy uses the ISC License. + +---- +Copyright (c) 2011-2019, 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.9/guide/introduction/index.html b/docs/en/cowboy/2.9/guide/introduction/index.html new file mode 100644 index 00000000..4aeadbff --- /dev/null +++ b/docs/en/cowboy/2.9/guide/introduction/index.html @@ -0,0 +1,214 @@ + + + + + + + + + + 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 22.0 and newer.

    +

    License

    +

    Cowboy uses the ISC License.

    +
    Copyright (c) 2011-2019, 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/listeners.asciidoc b/docs/en/cowboy/2.9/guide/listeners.asciidoc new file mode 100644 index 00000000..04169f9a --- /dev/null +++ b/docs/en/cowboy/2.9/guide/listeners.asciidoc @@ -0,0 +1,128 @@ +[[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 set up a custom listener. + +[source,erlang] +---- +start(_Type, _Args) -> + Dispatch = cowboy_router:compile([ + {'_', [{"/", hello_handler, []}]} + ]), + {ok, _} = cowboy:start_tls(my_https_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. + +=== Stopping the listener + +When starting listeners along with the application it is +a good idea to also stop the listener when the application +stops. This can be done by calling `cowboy:stop_listener/1` +in the application's stop function: + +[source,erlang] +---- +stop(_State) -> + ok = cowboy:stop_listener(my_http_listener). +---- + +=== 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.9/guide/listeners/index.html b/docs/en/cowboy/2.9/guide/listeners/index.html new file mode 100644 index 00000000..78a11b3a --- /dev/null +++ b/docs/en/cowboy/2.9/guide/listeners/index.html @@ -0,0 +1,244 @@ + + + + + + + + + + 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 set up a custom listener.

    +
    +
    start(_Type, _Args) ->
+    Dispatch = cowboy_router:compile([
+        {'_', [{"/", hello_handler, []}]}
+    ]),
+    {ok, _} = cowboy:start_tls(my_https_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.

    +

    Stopping the listener

    +

    When starting listeners along with the application it is a good idea to also stop the listener when the application stops. This can be done by calling cowboy:stop_listener/1 in the application's stop function:

    +
    +
    stop(_State) ->
+    ok = cowboy:stop_listener(my_http_listener).
    +
    +

    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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/loop_handlers.asciidoc b/docs/en/cowboy/2.9/guide/loop_handlers.asciidoc new file mode 100644 index 00000000..e5748548 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/loop_handlers.asciidoc @@ -0,0 +1,125 @@ +[[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, but it also applies to any +response that takes a long time to send. + +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 +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 + +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.9/guide/loop_handlers/index.html b/docs/en/cowboy/2.9/guide/loop_handlers/index.html new file mode 100644 index 00000000..d74e509f --- /dev/null +++ b/docs/en/cowboy/2.9/guide/loop_handlers/index.html @@ -0,0 +1,245 @@ + + + + + + + + + + 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, but it also applies to any response that takes a long time to send.

    +

    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 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

    +

    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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/middlewares.asciidoc b/docs/en/cowboy/2.9/guide/middlewares.asciidoc new file mode 100644 index 00000000..e6be30dd --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/middlewares/index.html b/docs/en/cowboy/2.9/guide/middlewares/index.html new file mode 100644 index 00000000..7a7435be --- /dev/null +++ b/docs/en/cowboy/2.9/guide/middlewares/index.html @@ -0,0 +1,212 @@ + + + + + + + + + + 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/migrating_from_1.0.asciidoc b/docs/en/cowboy/2.9/guide/migrating_from_1.0.asciidoc new file mode 100644 index 00000000..4f4ea5bf --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.9/guide/migrating_from_1.0/index.html new file mode 100644 index 00000000..e45e0d6f --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_1.0/index.html @@ -0,0 +1,294 @@ + + + + + + + + + + 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.0.asciidoc b/docs/en/cowboy/2.9/guide/migrating_from_2.0.asciidoc new file mode 100644 index 00000000..c76430c2 --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.9/guide/migrating_from_2.0/index.html new file mode 100644 index 00000000..23ed7606 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.0/index.html @@ -0,0 +1,229 @@ + + + + + + + + + + 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.1.asciidoc b/docs/en/cowboy/2.9/guide/migrating_from_2.1.asciidoc new file mode 100644 index 00000000..3c0681ff --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.1.asciidoc @@ -0,0 +1,107 @@ +[appendix] +== Migrating from Cowboy 2.1 to 2.2 + +Cowboy 2.2 focused on adding features required for writing +gRPC servers and on completing test suites for the core +HTTP RFCs, fixing many bugs along the way. + +=== Features added + +* Add support for sending trailers at the end of response bodies. + Trailers are additional header fields that may be sent after the + body to add more information to the response. Their usage is + required in gRPC servers. They are optional and may be discarded + in other scenarios (for example if the request goes through an + HTTP/1.0 proxy, as HTTP/1.0 does not support trailers). + +* The `max_skip_body_length` option was added to `cowboy_http`. + It controls how much of a request body Cowboy is willing to skip + when the handler did not touch it. If the remaining body size is + too large Cowboy instead closes the connection. It defaults to 1MB. + +* The CONNECT and TRACE methods are now rejected as they are + currently not implemented and must be handled differently than + other methods. They will be implemented in a future release. + +=== New functions + +* The function `stream_trailers/2` has been added. It terminates + a stream and adds trailer fields at the end of the response. A + corresponding stream handler command `{trailers, Trailers}` + has also been added. + +=== Bugs fixed + +* Test suites for the core HTTP RFCs RFC7230, RFC7231 and RFC7540 + have been completed. Many of the bugs listed here were fixed as + a result of this work. + +* Many HTTP/2 edge cases when clients are misbehaving have been + corrected. This includes many cases where the request is malformed + (for example when a pseudo-header is present twice). + +* When the HTTP/2 SETTINGS_INITIAL_WINDOW_SIZE value changes, + Cowboy now properly updates the flow control windows. + +* HTTP/2 could mistakenly log stray messages that actually were + expected. This is no longer the case. + +* We no longer send a GOAWAY frame when the HTTP/2 preface is invalid. + +* Some values in the Req object of pushed requests were in the + wrong type. They are now the expected binary instead of iolist. + +* A response body was sometimes sent in response to HEAD requests + when using HTTP/2. The body is now ignored. + +* The `max_headers` option for `cowboy_http` was not always respected + depending on the contents of the buffer. The limit is now strict. + +* When an early error occurred on the HTTP/1.1 request line, the + partial Req given to stream handlers was missing the `ref` and + `peer` information. This has been corrected. + +* Absolute URIs with a userinfo component, or without an authority + component, are now properly rejected for HTTP/1.0 and HTTP/1.1. + +* Whitespace is no longer allowed in header lines before the colon. + +* 408 responses to HTTP/1.1 requests now properly include a + connection: close header indicating that we are going to + close the connection. This header will also be sent for + other early errors resulting in the closing of the connection. + +* When both the transfer-encoding and content-length headers are + sent in an HTTP/1.1 request, the transfer-encoding now takes + precedence over the content-length header and the latter is + removed from the Req object. + +* A 400 response is now returned when the transfer-encoding + header is invalid or contains any transfer-coding other + than chunked. + +* Invalid chunk sizes are now rejected immediately. + +* Chunk extensions are now limited to 129 characters. They are + not used in practice and are still ignored by Cowboy. The limit + is not configurable. + +* The final chunk was mistakenly sent in responses to HEAD + requests. This is now corrected. + +* `OPTIONS *` requests were broken in Cowboy 2.0. They are now + working again. Both the routing and `cowboy_req:uri/1,2` have + been corrected. + +* 204 responses no longer include a content-length header. + +* A packet could be lost when switching to Websocket or any + other protocol via the `switch_protocol` command. This is + now fixed. + +* A 426 response will now be sent when a handler requires + the client to upgrade to Websocket and the request did not + include the required headers. + +* Both experimental stream handlers `cowboy_metrics_h` and + `cowboy_tracer_h` received a number of fixes and improvements. diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.1/index.html b/docs/en/cowboy/2.9/guide/migrating_from_2.1/index.html new file mode 100644 index 00000000..4b19ea17 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.1/index.html @@ -0,0 +1,240 @@ + + + + + + + + + + Nine Nines: Migrating from Cowboy 2.1 to 2.2 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Cowboy 2.1 to 2.2

    + +

    Cowboy 2.2 focused on adding features required for writing gRPC servers and on completing test suites for the core HTTP RFCs, fixing many bugs along the way.

    +

    Features added

    +
    • Add support for sending trailers at the end of response bodies. Trailers are additional header fields that may be sent after the body to add more information to the response. Their usage is required in gRPC servers. They are optional and may be discarded in other scenarios (for example if the request goes through an HTTP/1.0 proxy, as HTTP/1.0 does not support trailers). +
      • +
    • The max_skip_body_length option was added to cowboy_http. It controls how much of a request body Cowboy is willing to skip when the handler did not touch it. If the remaining body size is too large Cowboy instead closes the connection. It defaults to 1MB. +
      • +
    • The CONNECT and TRACE methods are now rejected as they are currently not implemented and must be handled differently than other methods. They will be implemented in a future release. +
      • +
    +

    New functions

    +
    • The function stream_trailers/2 has been added. It terminates a stream and adds trailer fields at the end of the response. A corresponding stream handler command {trailers, Trailers} has also been added. +
      • +
    +

    Bugs fixed

    +
    • Test suites for the core HTTP RFCs RFC7230, RFC7231 and RFC7540 have been completed. Many of the bugs listed here were fixed as a result of this work. +
      • +
    • Many HTTP/2 edge cases when clients are misbehaving have been corrected. This includes many cases where the request is malformed (for example when a pseudo-header is present twice). +
      • +
    • When the HTTP/2 SETTINGS_INITIAL_WINDOW_SIZE value changes, Cowboy now properly updates the flow control windows. +
      • +
    • HTTP/2 could mistakenly log stray messages that actually were expected. This is no longer the case. +
      • +
    • We no longer send a GOAWAY frame when the HTTP/2 preface is invalid. +
      • +
    • Some values in the Req object of pushed requests were in the wrong type. They are now the expected binary instead of iolist. +
      • +
    • A response body was sometimes sent in response to HEAD requests when using HTTP/2. The body is now ignored. +
      • +
    • The max_headers option for cowboy_http was not always respected depending on the contents of the buffer. The limit is now strict. +
      • +
    • When an early error occurred on the HTTP/1.1 request line, the partial Req given to stream handlers was missing the ref and peer information. This has been corrected. +
      • +
    • Absolute URIs with a userinfo component, or without an authority component, are now properly rejected for HTTP/1.0 and HTTP/1.1. +
      • +
    • Whitespace is no longer allowed in header lines before the colon. +
      • +
    • 408 responses to HTTP/1.1 requests now properly include a connection: close header indicating that we are going to close the connection. This header will also be sent for other early errors resulting in the closing of the connection. +
      • +
    • When both the transfer-encoding and content-length headers are sent in an HTTP/1.1 request, the transfer-encoding now takes precedence over the content-length header and the latter is removed from the Req object. +
      • +
    • A 400 response is now returned when the transfer-encoding header is invalid or contains any transfer-coding other than chunked. +
      • +
    • Invalid chunk sizes are now rejected immediately. +
      • +
    • Chunk extensions are now limited to 129 characters. They are not used in practice and are still ignored by Cowboy. The limit is not configurable. +
      • +
    • The final chunk was mistakenly sent in responses to HEAD requests. This is now corrected. +
      • +
    • OPTIONS * requests were broken in Cowboy 2.0. They are now working again. Both the routing and cowboy_req:uri/1,2 have been corrected. +
      • +
    • 204 responses no longer include a content-length header. +
      • +
    • A packet could be lost when switching to Websocket or any other protocol via the switch_protocol command. This is now fixed. +
      • +
    • A 426 response will now be sent when a handler requires the client to upgrade to Websocket and the request did not include the required headers. +
      • +
    • Both experimental stream handlers cowboy_metrics_h and cowboy_tracer_h received a number of fixes and improvements. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.2.asciidoc b/docs/en/cowboy/2.9/guide/migrating_from_2.2.asciidoc new file mode 100644 index 00000000..dacf790e --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.2.asciidoc @@ -0,0 +1,56 @@ +[appendix] +== Migrating from Cowboy 2.2 to 2.3 + +Cowboy 2.3 focused on making the Cowboy processes behave +properly according to OTP principles. This version is a +very good milestone toward that goal and most of everything +should now work. Release upgrades and a few details will +be improved in future versions. + +=== Features added + +* Add support for all functions from the module `sys`. Note + that Cowboy currently does not implement the `sys` debugging + mechanisms as tracing is recommended instead. + +* Add a `max_frame_size` option for Websocket handlers + to close the connection when the client attempts to + send a frame that's too large. It currently defaults + to `infinity` to avoid breaking existing code but will + be changed in a future version. + +* Update Cowlib to 2.2.1. + +* Add support for the 308 status code and a test suite + for RFC7538 where it is defined. + +=== Bugs fixed + +* Ensure timeout options accept the value `infinity` as + documented. + +* Properly reject HTTP/2 requests with an invalid content-length + header instead of simply crashing. + +* When switching from HTTP/1.1 to Websocket or user protocols + all the messages in the mailbox were flushed. Only messages + specific to `cowboy_http` should now be flushed. + +* Parsing of the x-forwarded-for header has been corrected. + It now supports IPv6 addresses both with and without port. + +* Websocket subprotocol tokens are now parsed in a case + insensitive manner, according to the spec. + +* Cookies without values are now allowed. For example `Cookie: foo`. + +* Colons are now allowed within path segments in routes provided + to `cowboy_router:compile/1` as long as they are not the first + character of the path segment. + +* The `cowboy_req:delete_resp_header/2` function will no longer + crash when no response header was set before calling it. + +* A miscount of the output HTTP/2 flow control window has been + fixed. It prevented sending the response body fully to some + clients. The issue only affected response bodies sent as iolists. diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.2/index.html b/docs/en/cowboy/2.9/guide/migrating_from_2.2/index.html new file mode 100644 index 00000000..d92403ad --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.2/index.html @@ -0,0 +1,212 @@ + + + + + + + + + + Nine Nines: Migrating from Cowboy 2.2 to 2.3 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Cowboy 2.2 to 2.3

    + +

    Cowboy 2.3 focused on making the Cowboy processes behave properly according to OTP principles. This version is a very good milestone toward that goal and most of everything should now work. Release upgrades and a few details will be improved in future versions.

    +

    Features added

    +
    • Add support for all functions from the module sys. Note that Cowboy currently does not implement the sys debugging mechanisms as tracing is recommended instead. +
      • +
    • Add a max_frame_size option for Websocket handlers to close the connection when the client attempts to send a frame that's too large. It currently defaults to infinity to avoid breaking existing code but will be changed in a future version. +
      • +
    • Update Cowlib to 2.2.1. +
      • +
    • Add support for the 308 status code and a test suite for RFC7538 where it is defined. +
      • +
    +

    Bugs fixed

    +
    • Ensure timeout options accept the value infinity as documented. +
      • +
    • Properly reject HTTP/2 requests with an invalid content-length header instead of simply crashing. +
      • +
    • When switching from HTTP/1.1 to Websocket or user protocols all the messages in the mailbox were flushed. Only messages specific to cowboy_http should now be flushed. +
      • +
    • Parsing of the x-forwarded-for header has been corrected. It now supports IPv6 addresses both with and without port. +
      • +
    • Websocket subprotocol tokens are now parsed in a case insensitive manner, according to the spec. +
      • +
    • Cookies without values are now allowed. For example Cookie: foo. +
      • +
    • Colons are now allowed within path segments in routes provided to cowboy_router:compile/1 as long as they are not the first character of the path segment. +
      • +
    • The cowboy_req:delete_resp_header/2 function will no longer crash when no response header was set before calling it. +
      • +
    • A miscount of the output HTTP/2 flow control window has been fixed. It prevented sending the response body fully to some clients. The issue only affected response bodies sent as iolists. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.3.asciidoc b/docs/en/cowboy/2.9/guide/migrating_from_2.3.asciidoc new file mode 100644 index 00000000..6a604f97 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.3.asciidoc @@ -0,0 +1,66 @@ +[appendix] +== Migrating from Cowboy 2.3 to 2.4 + +Cowboy 2.4 focused on improving the HTTP/2 implementation. +All existing tests from RFC7540 and the h2spec test suite +now all pass. Numerous options have been added to control +SETTINGS and related behavior. In addition experimental +support for Websocket over HTTP/2 was added. + +=== Features added + +* Add experimental support for Websocket over HTTP/2. + You can use the `enable_connect_protocol` option to + enable. It implements the following draft: + https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-01 + +* Add options `max_decode_table_size` and + `max_encode_table_size` to restrict the size of the + HPACK compression dictionary. + +* Add option `max_concurrent_streams` to restrict the + number of HTTP/2 streams that can be opened concurrently. + +* Add options `initial_connection_window_size` and + `initial_stream_window_size` to restrict the size of + the HTTP/2 request body buffers for the whole connection + and per stream, respectively. + +* Add options `max_frame_size_received` and + `max_frame_size_sent` to restrict the size of + HTTP/2 frames. + +* Add option `settings_timeout` to reject clients that + did not send a SETTINGS ack. Note that this currently + may only occur at the beginning of the connection. + +* Update Ranch to 1.5.0 + +* Update Cowlib to 2.3.0 + +=== Bugs fixed + +* Fix the END_STREAM flag for informational responses + when using HTTP/2. + +* Receive and ignore HTTP/2 request trailers if any + for HTTP/2 requests. Request trailer information will + be propagated to the user code in a future release. + +* Reject WINDOW_UPDATE frames that are sent after the + client sent an RST_STREAM. Note that Cowboy will not + keep state information about terminated streams + forever and so the behavior might differ depending + on when the stream was reset. + +* Reject streams that depend on themselves. Note that + Cowboy currently does not implement HTTP/2's priority + mechanisms so this issue was harmless. + +* Reject HTTP/2 requests where the body size is different + than the content-length value. Note that due to how Cowboy + works some requests might go through regardless, for + example when the user code does not read the request body. + +* Fix all existing test failures from RFC7540. This was + mostly incorrect test cases or intermittent failures. diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.3/index.html b/docs/en/cowboy/2.9/guide/migrating_from_2.3/index.html new file mode 100644 index 00000000..00c79e8d --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.3/index.html @@ -0,0 +1,214 @@ + + + + + + + + + + Nine Nines: Migrating from Cowboy 2.3 to 2.4 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Cowboy 2.3 to 2.4

    + +

    Cowboy 2.4 focused on improving the HTTP/2 implementation. All existing tests from RFC7540 and the h2spec test suite now all pass. Numerous options have been added to control SETTINGS and related behavior. In addition experimental support for Websocket over HTTP/2 was added.

    +

    Features added

    +
    • Add experimental support for Websocket over HTTP/2. You can use the enable_connect_protocol option to enable. It implements the following draft: https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-01 +
      • +
    • Add options max_decode_table_size and max_encode_table_size to restrict the size of the HPACK compression dictionary. +
      • +
    • Add option max_concurrent_streams to restrict the number of HTTP/2 streams that can be opened concurrently. +
      • +
    • Add options initial_connection_window_size and initial_stream_window_size to restrict the size of the HTTP/2 request body buffers for the whole connection and per stream, respectively. +
      • +
    • Add options max_frame_size_received and max_frame_size_sent to restrict the size of HTTP/2 frames. +
      • +
    • Add option settings_timeout to reject clients that did not send a SETTINGS ack. Note that this currently may only occur at the beginning of the connection. +
      • +
    • Update Ranch to 1.5.0 +
      • +
    • Update Cowlib to 2.3.0 +
      • +
    +

    Bugs fixed

    +
    • Fix the END_STREAM flag for informational responses when using HTTP/2. +
      • +
    • Receive and ignore HTTP/2 request trailers if any for HTTP/2 requests. Request trailer information will be propagated to the user code in a future release. +
      • +
    • Reject WINDOW_UPDATE frames that are sent after the client sent an RST_STREAM. Note that Cowboy will not keep state information about terminated streams forever and so the behavior might differ depending on when the stream was reset. +
      • +
    • Reject streams that depend on themselves. Note that Cowboy currently does not implement HTTP/2's priority mechanisms so this issue was harmless. +
      • +
    • Reject HTTP/2 requests where the body size is different than the content-length value. Note that due to how Cowboy works some requests might go through regardless, for example when the user code does not read the request body. +
      • +
    • Fix all existing test failures from RFC7540. This was mostly incorrect test cases or intermittent failures. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.4.asciidoc b/docs/en/cowboy/2.9/guide/migrating_from_2.4.asciidoc new file mode 100644 index 00000000..3cdeaa54 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.4.asciidoc @@ -0,0 +1,109 @@ +[appendix] +== Migrating from Cowboy 2.4 to 2.5 + +Cowboy 2.5 focused on making the test suites pass. A +variety of new features, fixes and improvements have +also been worked on. + +=== Features added + +* Add option `linger_timeout` to control how long + Cowboy will wait before closing the socket when + shutting down the connection. This helps avoid + the TCP reset problem HTTP/1.1 suffers from. The + default is now 1000 ms. + +* It is now possible to stream a response body + without using chunked transfer-encoding when the + protocol is HTTP/1.1. To enable this behavior, + simply pass the content-length header with the + expected size when initiating the streamed response. + +* Update Ranch to 1.6.2 + +* Update Cowlib to 2.6.0 + +=== Experimental features added + +* Websocket handlers now feature a commands-based interface. + The return value from the callbacks can now take the form + `{Commands, State}` where `Commands` can be frames to be + sent or commands yet to be introduced. New commands will + be available only through this new interface. + +* Add the `{active, boolean()}` Websocket handler command. + It allows disabling reading from the socket when `false` + is returned. `true` reenables reading from the socket. + +* Add the protocol option `logger` that allows configuring + which logger module will be used. The logger module must + follow the interface of the new `logger` module in Erlang/OTP 21, + or be set to `error_logger` to keep the old behavior. A + similar transport option exists in Ranch 1.6; both options + are necessary to override Cowboy's default behavior completely. + +* Add the `{log, Level, Format, Args}` stream handler command. + Making it a command rather than a direct call will simplify + silencing particular log messages. + +=== New functions + +* The function `cowboy_req:stream_events/3` streams one or more + text/event-stream events, encoding them automatically. + +* The functions `cowboy_req:read_and_match_urlencoded_body/2,3` + can be used to read, parse and match application/x-www-form-urlencoded + request bodies, in a similar way to `cowboy_req:match_qs/2`. + +=== Bugs fixed + +* Fix Erlang/OTP 21 warnings. + +* Ensure that the port number is always defined in the + Req object. When it is not provided in the request, + the default port number for the protocol being used + will be set. + +* Ensure stream handlers can run after `cowboy_stream_h`. + +* Honor the SETTINGS_ENABLE_PUSH HTTP/2 setting: don't + send PUSH frames to clients that disabled it. + +* Fix HTTP/2 `settings_timeout` option when the value + is set to `infinity`. + +* HTTP/1.1 responses will no longer include a trailer header + when the request had no te header. + +* HTTP/1.1 204 responses no longer send the transfer-encoding + header when `cowboy_req:stream_reply/2,3` is used to send + a response. + +* Improve HTTP/1.1 keepalive handling to avoid processing + requests that follow the final request that will receive + a response. + +* Improve the validation of HTTP/1.1 absolute-form requests. + +* When the `switch_protocol` is used after a response was + sent, Cowboy will no longer attempt to send the 101 informational + response for the protocol upgrade. This caused a crash of the + connection previously. + +* Errors that occur when a callback returned by + `content_types_provided` does not exist have been improved. + +* Prevent annoying error logs when using sendfile in + Erlang/OTP 20 and lower. + +* Add missing frame types to `websocket_handle`. + +* A test suite has been added for RFC8297 to ensure that + 103 informational responses can be sent. + +* Numerous test cases have been fixed, improved or removed in order + to make the test suites pass. Most of the failures were caused + by broken tests. + +* Some misguiding or incorrect statements in the documentation + have been removed or clarified. diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.4/index.html b/docs/en/cowboy/2.9/guide/migrating_from_2.4/index.html new file mode 100644 index 00000000..345af401 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.4/index.html @@ -0,0 +1,242 @@ + + + + + + + + + + Nine Nines: Migrating from Cowboy 2.4 to 2.5 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Cowboy 2.4 to 2.5

    + +

    Cowboy 2.5 focused on making the test suites pass. A variety of new features, fixes and improvements have also been worked on.

    +

    Features added

    +
    • Add option linger_timeout to control how long Cowboy will wait before closing the socket when shutting down the connection. This helps avoid the TCP reset problem HTTP/1.1 suffers from. The default is now 1000 ms. +
      • +
    • It is now possible to stream a response body without using chunked transfer-encoding when the protocol is HTTP/1.1. To enable this behavior, simply pass the content-length header with the expected size when initiating the streamed response. +
      • +
    • Update Ranch to 1.6.2 +
      • +
    • Update Cowlib to 2.6.0 +
      • +
    +

    Experimental features added

    +
    • Websocket handlers now feature a commands-based interface. The return value from the callbacks can now take the form {Commands, State} where Commands can be frames to be sent or commands yet to be introduced. New commands will be available only through this new interface. +
      • +
    • Add the {active, boolean()} Websocket handler command. It allows disabling reading from the socket when false is returned. true reenables reading from the socket. +
      • +
    • Add the protocol option logger that allows configuring which logger module will be used. The logger module must follow the interface of the new logger module in Erlang/OTP 21, or be set to error_logger to keep the old behavior. A similar transport option exists in Ranch 1.6; both options are necessary to override Cowboy's default behavior completely. +
      • +
    • Add the {log, Level, Format, Args} stream handler command. Making it a command rather than a direct call will simplify silencing particular log messages. +
      • +
    +

    New functions

    +
    • The function cowboy_req:stream_events/3 streams one or more text/event-stream events, encoding them automatically. +
      • +
    • The functions cowboy_req:read_and_match_urlencoded_body/2,3 can be used to read, parse and match application/x-www-form-urlencoded request bodies, in a similar way to cowboy_req:match_qs/2. +
      • +
    +

    Bugs fixed

    +
    • Fix Erlang/OTP 21 warnings. +
      • +
    • Ensure that the port number is always defined in the Req object. When it is not provided in the request, the default port number for the protocol being used will be set. +
      • +
    • Ensure stream handlers can run after cowboy_stream_h. +
      • +
    • Honor the SETTINGS_ENABLE_PUSH HTTP/2 setting: don't send PUSH frames to clients that disabled it. +
      • +
    • Fix HTTP/2 settings_timeout option when the value is set to infinity. +
      • +
    • HTTP/1.1 responses will no longer include a trailer header when the request had no te header. +
      • +
    • HTTP/1.1 204 responses no longer send the transfer-encoding header when cowboy_req:stream_reply/2,3 is used to send a response. +
      • +
    • Improve HTTP/1.1 keepalive handling to avoid processing requests that follow the final request that will receive a response. +
      • +
    • Improve the validation of HTTP/1.1 absolute-form requests. +
      • +
    • When the switch_protocol is used after a response was sent, Cowboy will no longer attempt to send the 101 informational response for the protocol upgrade. This caused a crash of the connection previously. +
      • +
    • Errors that occur when a callback returned by content_types_provided does not exist have been improved. +
      • +
    • Prevent annoying error logs when using sendfile in Erlang/OTP 20 and lower. +
      • +
    • Add missing frame types to websocket_handle. +
      • +
    • A test suite has been added for RFC8297 to ensure that 103 informational responses can be sent. +
      • +
    • Numerous test cases have been fixed, improved or removed in order to make the test suites pass. Most of the failures were caused by broken tests. +
      • +
    • Some misguiding or incorrect statements in the documentation have been removed or clarified. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.5.asciidoc b/docs/en/cowboy/2.9/guide/migrating_from_2.5.asciidoc new file mode 100644 index 00000000..b91b617f --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.5.asciidoc @@ -0,0 +1,148 @@ +[appendix] +== Migrating from Cowboy 2.5 to 2.6 + +Cowboy 2.6 greatly refactored the HTTP/2 code, a large +part of which was moved to Cowlib and is now used by +both the Cowboy server and the Gun client. + +A large number of tickets were also closed which +resulted in many bugs fixed and many features and +options added, although some of them are still +experimental. + +=== Features added + +* Add support for the PROXY protocol header. + It can be enabled via the `proxy_header` option. + The proxy information can then be found under + the `proxy_info` key in the Req object. + +* Allow using sendfile tuples in `cowboy_req:stream_body/3` + and in the data command in stream handlers. The only + caveat is that when using `cowboy_compress_h` the + sendfile tuples may have to be converted to in-memory + data in order to compress them. This is the case for + gzip compression. + +* The stream handlers `cowboy_stream_h` and + `cowboy_compress_h` are now documented. + +* Add the `chunked` option to allow disabling chunked + transfer-encoding for HTTP/1.1 connections. + +* Add the `http10_keepalive` option to allow disabling + keep-alive for HTTP/1.0 connections. + +* Add the `idle_timeout` option for HTTP/2. + +* Add the `sendfile` option to both HTTP/1.1 and HTTP/2. + It allows disabling the sendfile syscall entirely for + all connections. It is recommended to disable sendfile + when using VirtualBox shared folders. + +* Add the `rate_limited/2` callback to REST handlers. + +* Add the `deflate_opts` option to Websocket handlers that + allows configuring deflate options for the + permessage-deflate extension. + +* Add the `charset` option to `cowboy_static`. + +* Add support for the SameSite cookie attribute. + +* Update Ranch to 1.7.0 + +* Update Cowlib to 2.7.0 + +=== Experimental features added + +* Add support for range requests (RFC7233) in REST handlers. + This adds two new callbacks: `ranges_accepted/2` and + `range_satisfiable/2` along with the user-specified + `ProvideRangeCallback/2`. + +* Add automatic handling of range requests to REST handlers + that return the callback `auto` from `ranges_accepted/2`. + Cowboy will call the configured `ProvideCallback` and + then split the ouput automatically for the ranged response. + +* Enable range requests support in `cowboy_static`. + +* Add the `{deflate, boolean()}` Websocket handler + command to disable permessage-deflate compression + temporarily. + +* Add the `compress_threshold` option which allows + configuring how much data must be present in a + response body to compress it. This only applies + to non-streamed bodies at this time. + +* Add the `compress_buffering` option which allows + controlling whether some buffering may be done + when streaming a response body. Change the default + behavior to not buffer to make sure it works by + default in all scenarios. + +* Add the `{set_options, map()}` command to stream + handlers and Websocket handlers. This can be used + to update options on a per-request basis. Allow + overriding the `idle_timeout` option for both + HTTP/1.1 and Websocket, the `cowboy_compress_h` + options for HTTP/1.1 and HTTP/2 and the `chunked` + option for HTTP/1.1. + +=== Bugs fixed + +* Do not send a content-length automatically with + 304 responses. This status code allows a content-length + that corresponds to what would have been sent for a 200 + response, but is never followed by a body. + +* HTTP/2 streams are now terminated once the body + has been sent fully, instead of immediately once + the stop command is returned (by default when the + request process exits). Metrics will therefore + more accurately represent when a stream ended. + +* Terminate connection processes gracefully when the + parent process exists or when sys:terminate/2,3 + is called. + +* Automatically ignore the boundary parameter of multipart + media types when using REST handlers. This is a special + parameter that may change with all requests and cannot + be predicted. + +* Fix parsing of the accept header when it contains charset + parameters. They are case insensitive and will now be + lowercased, like for accept-charset and content-type. + +* Handle the charset parameter using `charsets_provided` + when it is present in the accept header when using + REST handlers. + +* Don't select charsets when the q-value is 0 in REST + handlers. + +* Handle accept-charset headers that include a wildcard + in REST handlers. + +* Only send a charset header when the content-type + negotiated is of type text in REST handlers. + +* Remove the default charset iso-8859-1 from REST + handlers when no other is provided. This has been + removed from the HTTP specifications for a long time. + +* Many cases where a content-type header was sent + unnecessarily in the REST handlers response have + been fixed. + +* Handle error_response commands in `cowboy_metrics_h`. + +* A number of types and function specifications were + fixed or improved. Dialyzer is now run against both + the code and tests to help uncover issues. + +* An undefined `cowboy_router` behavior has been + documented. diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.5/index.html b/docs/en/cowboy/2.9/guide/migrating_from_2.5/index.html new file mode 100644 index 00000000..c5e0bacc --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.5/index.html @@ -0,0 +1,257 @@ + + + + + + + + + + Nine Nines: Migrating from Cowboy 2.5 to 2.6 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Cowboy 2.5 to 2.6

    + +

    Cowboy 2.6 greatly refactored the HTTP/2 code, a large part of which was moved to Cowlib and is now used by both the Cowboy server and the Gun client.

    +

    A large number of tickets were also closed which resulted in many bugs fixed and many features and options added, although some of them are still experimental.

    +

    Features added

    +
    • Add support for the PROXY protocol header. It can be enabled via the proxy_header option. The proxy information can then be found under the proxy_info key in the Req object. +
      • +
    • Allow using sendfile tuples in cowboy_req:stream_body/3 and in the data command in stream handlers. The only caveat is that when using cowboy_compress_h the sendfile tuples may have to be converted to in-memory data in order to compress them. This is the case for gzip compression. +
      • +
    • The stream handlers cowboy_stream_h and cowboy_compress_h are now documented. +
      • +
    • Add the chunked option to allow disabling chunked transfer-encoding for HTTP/1.1 connections. +
      • +
    • Add the http10_keepalive option to allow disabling keep-alive for HTTP/1.0 connections. +
      • +
    • Add the idle_timeout option for HTTP/2. +
      • +
    • Add the sendfile option to both HTTP/1.1 and HTTP/2. It allows disabling the sendfile syscall entirely for all connections. It is recommended to disable sendfile when using VirtualBox shared folders. +
      • +
    • Add the rate_limited/2 callback to REST handlers. +
      • +
    • Add the deflate_opts option to Websocket handlers that allows configuring deflate options for the permessage-deflate extension. +
      • +
    • Add the charset option to cowboy_static. +
      • +
    • Add support for the SameSite cookie attribute. +
      • +
    • Update Ranch to 1.7.0 +
      • +
    • Update Cowlib to 2.7.0 +
      • +
    +

    Experimental features added

    +
    • Add support for range requests (RFC7233) in REST handlers. This adds two new callbacks: ranges_accepted/2 and range_satisfiable/2 along with the user-specified ProvideRangeCallback/2. +
      • +
    • Add automatic handling of range requests to REST handlers that return the callback auto from ranges_accepted/2. Cowboy will call the configured ProvideCallback and then split the ouput automatically for the ranged response. +
      • +
    • Enable range requests support in cowboy_static. +
      • +
    • Add the {deflate, boolean()} Websocket handler command to disable permessage-deflate compression temporarily. +
      • +
    • Add the compress_threshold option which allows configuring how much data must be present in a response body to compress it. This only applies to non-streamed bodies at this time. +
      • +
    • Add the compress_buffering option which allows controlling whether some buffering may be done when streaming a response body. Change the default behavior to not buffer to make sure it works by default in all scenarios. +
      • +
    • Add the {set_options, map()} command to stream handlers and Websocket handlers. This can be used to update options on a per-request basis. Allow overriding the idle_timeout option for both HTTP/1.1 and Websocket, the cowboy_compress_h options for HTTP/1.1 and HTTP/2 and the chunked option for HTTP/1.1. +
      • +
    +

    Bugs fixed

    +
    • Do not send a content-length automatically with 304 responses. This status code allows a content-length that corresponds to what would have been sent for a 200 response, but is never followed by a body. +
      • +
    • HTTP/2 streams are now terminated once the body has been sent fully, instead of immediately once the stop command is returned (by default when the request process exits). Metrics will therefore more accurately represent when a stream ended. +
      • +
    • Terminate connection processes gracefully when the parent process exists or when sys:terminate/2,3 is called. +
      • +
    • Automatically ignore the boundary parameter of multipart media types when using REST handlers. This is a special parameter that may change with all requests and cannot be predicted. +
      • +
    • Fix parsing of the accept header when it contains charset parameters. They are case insensitive and will now be lowercased, like for accept-charset and content-type. +
      • +
    • Handle the charset parameter using charsets_provided when it is present in the accept header when using REST handlers. +
      • +
    • Don't select charsets when the q-value is 0 in REST handlers. +
      • +
    • Handle accept-charset headers that include a wildcard in REST handlers. +
      • +
    • Only send a charset header when the content-type negotiated is of type text in REST handlers. +
      • +
    • Remove the default charset iso-8859-1 from REST handlers when no other is provided. This has been removed from the HTTP specifications for a long time. +
      • +
    • Many cases where a content-type header was sent unnecessarily in the REST handlers response have been fixed. +
      • +
    • Handle error_response commands in cowboy_metrics_h. +
      • +
    • A number of types and function specifications were fixed or improved. Dialyzer is now run against both the code and tests to help uncover issues. +
      • +
    • An undefined cowboy_router behavior has been documented. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.6.asciidoc b/docs/en/cowboy/2.9/guide/migrating_from_2.6.asciidoc new file mode 100644 index 00000000..91d15887 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.6.asciidoc @@ -0,0 +1,224 @@ +[appendix] +== Migrating from Cowboy 2.6 to 2.7 + +Cowboy 2.7 improves the HTTP/2 code with optimizations +around the sending of DATA and WINDOW_UPDATE frames; +graceful shutdown of the connection when the client is +going away; and rate limiting mechanisms. New options +and mechanisms have also been added to control the +amount of memory Cowboy ends up using with both HTTP/1.1 +and HTTP/2. Much, but not all, of this work was done +to address HTTP/2 CVEs about potential denial of service. + +In addition, many of the experimental features introduced +in previous releases have been marked stable and are now +documented. + +Cowboy 2.7 requires Erlang/OTP 20.0 or greater. + +=== Features added + +* Cowboy is now compatible with both Ranch 1.7 and the + upcoming Ranch 2.0. + +* The number of HTTP/2 WINDOW_UPDATE frames Cowboy sends + has been greatly reduced. Cowboy now applies heuristics + to determine whether it is necessary to update the window, + based on the current window size and the amount of data + requested by streams (the `cowboy_req:read_body/2` length + for example). Six new options have been added to control + this behavior: `connection_window_margin_size`, + `connection_window_update_threshold`, + `max_connection_window_size`, `max_stream_window_size`, + `stream_window_margin_size` and + `stream_window_update_threshold`. + +* HTTP/2 connections will now be shut down gracefully + when receiving a GOAWAY frame. Cowboy will simply + wait for existing streams to finish before closing + the connection. + +* Functions that stream the response body now have + backpressure applied. They now wait for a message + to be sent back. The message will be held off when + using HTTP/2 and the buffer sizes exceed either + `max_connection_buffer_size` or `max_stream_buffer_size`. + For HTTP/1.1 the data is sent synchronously and we + rely instead on the TCP backpressure. + +* A new HTTP/2 option `stream_window_data_threshold` + can be used to control how little the DATA frames that + Cowboy sends can get. By default Cowboy will wait for + the window to be large enough to send either everything + queued or to reach the default maximum frame size of + 16384 bytes. + +* A new HTTP/2 option `max_receive_frame_rate` can be + used to control how fast the server is willing to receive + frames. By default it will accept 1000 frames every 10 + seconds. + +* A new HTTP/2 option `max_reset_stream_rate` can be + used to control the rate of errors the server is + willing to accept. By default it will accept 10 + stream resets every 10 seconds. + +* Flow control for incoming data has been implemented + for HTTP/1.1. Cowboy will now wait for the user code + to ask for the request body before reading it from + the socket. The option `initial_stream_flow_size` + controls how much data Cowboy will read without + being asked. + +* The HTTP/1.1 and HTTP/2 option `logger` is now + documented. + +* The Websocket option `validate_utf8` has been + added. It can be used to disable the expensive UTF-8 + validation for incoming text and close frames. + +* The experimental commands based Websocket interface + is now considered stable and has been documented. + The old interface is now deprecated. + +* A new Websocket handler command `shutdown_reason` + can be used to change the normal exit reason of + Websocket processes. By default `normal` is used; + with this command the exit reason can be changed + to `{shutdown, ShutdownReason}`. + +* The experimental stream handlers `cowboy_metrics_h` + and `cowboy_tracer_h` are now considered stable and + have been documented. + +* The stream handler commands `set_options` and `log` + are now considered stable and have been documented. + +* The router is now capable of retrieving dispatch + rules directly from the `persistent_term` storage + (available starting from Erlang/OTP 21.2). + +* Support for the status codes 208 and 508 has been + added. + +* Update Ranch to 1.7.1. + +* Update Cowlib to 2.8.0. + +=== Experimental features added + +* It is now possible to read the response body from any + process, as well as doing any other `cowboy_req` + operations. Since this is not recommended due to + race condition concerns this feature will always + remain experimental. + +=== New functions + +* The function `cowboy_req:filter_cookies/2` has been + added. It can be called before parsing/matching + cookies in order to filter out undesirables. The + main reason for doing this is to avoid most parse + errors that may occur when dealing with Web browsers + (which have a string-based Javascript interface to + cookies that is very permissive of invalid content) + and to be able to recover in other cases. + +* The function `cowboy_req:cast/2` has been added. + It can be used to send events to stream handlers. + +=== Bugs fixed + +* A number of fixes and additions were made to address the + HTTP/2 CVEs CVE-2019-9511 through CVE-2019-9518, except + for CVE-2019-9513 which required no intervention as the + relevant protocol feature is not implemented by Cowboy. + +* The HTTP/2 connection window could become larger than the + protocol allows, leading to errors. This has been corrected. + +* The presence of empty header names in HTTP/2 requests now + results in the request to be rejected. + +* Cowboy will now remove headers specific to HTTP/1.1 + (the hop by hop headers such as connection or upgrade) + when building an HTTP/2 response. + +* A bug in the HTTP/2 code that resulted in the failure to + fully send iolist response bodies has been fixed. Cowboy + would just wait indefinitely in those cases. + +* It was possible for a final empty HTTP/2 DATA frame to get + stuck and never sent when the window reached 0 and the remote + end did not increase the window anymore. This has been + corrected. + +* Cowboy now uses the host header when the HTTP/2 + :authority pseudo header is missing. A common scenario + where this occurs is when proxies translate incoming + HTTP/1.1 requests to HTTP/2. + +* HTTP/1.1 connections are now properly closed when the + user code sends less data than advertised in the response + headers. + +* Cowboy will now close HTTP/1.1 connections immediately when + a header line is missing a colon separator. Previously it + was waiting for more data. + +* It was possible for Cowboy to receive stray timeout messages + for HTTP/1.1 connections, resulting in crashes. The timeout + handling in HTTP/1.1 has been reworked and the issue should + no longer occur. + +* The type for the Req object has been updated to accept + custom fields as was already documented. + +* The authentication scheme returned when parsing the + authorization header is now case insensitive, which + means it will be returned as lowercase. + +* Cowboy no longer discards data that follows a Websocket + upgrade request. Note that the protocol does not allow + sending data before receiving a successful Websocket + upgrade response, so this fix is more out of principle + rather than to fix a real world issue. + +* The `cowboy_static` handler will now properly detect + the type of files that have an uppercase or mixed + extension component. + +* The `cowboy_static` handler is now consistent across all + supported platforms. It now explicitly rejects `path_info` + components that include a forward slash, backward slash + or NUL character. + +* The update to Ranch 1.7.1 fixes an issue with the PROXY + protocol that would cause checksum verification to fail. + +* The HTTP/1.1 error reason for `stream_error` mistakenly + contained an extra element. It has now been removed. + +* The `PartialReq` given to the `early_error` stream handler + callback now includes headers when the protocol is HTTP/2. + +* A bug where the stacktrace was incorrect in error messages + has been fixed. The problem occurred when an exception + occurred in the handler's terminate callback. + +* The REST flowchart for POST, PATCH and PUT has received + a number of fixes and had to be greatly reworked as a + result. When the method is PUT, we do not check for + the location header in the response. When the resource + doesn't exist and the method was PUT the flowchart was + largely incorrect. A 415 response may occur after the + `content_types_accepted` callback and was missing from + the flowchart. + +* The documentation for `content_types_accepted` now + includes the media type wildcard that was previously + missing. + +* The documentation for a type found in `cow_cookie` + was missing. A manual page for `cow_cookie` was added + and can be found in the Cowlib documentation. diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.6/index.html b/docs/en/cowboy/2.9/guide/migrating_from_2.6/index.html new file mode 100644 index 00000000..0b133a53 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.6/index.html @@ -0,0 +1,278 @@ + + + + + + + + + + Nine Nines: Migrating from Cowboy 2.6 to 2.7 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Cowboy 2.6 to 2.7

    + +

    Cowboy 2.7 improves the HTTP/2 code with optimizations around the sending of DATA and WINDOW_UPDATE frames; graceful shutdown of the connection when the client is going away; and rate limiting mechanisms. New options and mechanisms have also been added to control the amount of memory Cowboy ends up using with both HTTP/1.1 and HTTP/2. Much, but not all, of this work was done to address HTTP/2 CVEs about potential denial of service.

    +

    In addition, many of the experimental features introduced in previous releases have been marked stable and are now documented.

    +

    Cowboy 2.7 requires Erlang/OTP 20.0 or greater.

    +

    Features added

    +
    • Cowboy is now compatible with both Ranch 1.7 and the upcoming Ranch 2.0. +
      • +
    • The number of HTTP/2 WINDOW_UPDATE frames Cowboy sends has been greatly reduced. Cowboy now applies heuristics to determine whether it is necessary to update the window, based on the current window size and the amount of data requested by streams (the cowboy_req:read_body/2 length for example). Six new options have been added to control this behavior: connection_window_margin_size, connection_window_update_threshold, max_connection_window_size, max_stream_window_size, stream_window_margin_size and stream_window_update_threshold. +
      • +
    • HTTP/2 connections will now be shut down gracefully when receiving a GOAWAY frame. Cowboy will simply wait for existing streams to finish before closing the connection. +
      • +
    • Functions that stream the response body now have backpressure applied. They now wait for a message to be sent back. The message will be held off when using HTTP/2 and the buffer sizes exceed either max_connection_buffer_size or max_stream_buffer_size. For HTTP/1.1 the data is sent synchronously and we rely instead on the TCP backpressure. +
      • +
    • A new HTTP/2 option stream_window_data_threshold can be used to control how little the DATA frames that Cowboy sends can get. By default Cowboy will wait for the window to be large enough to send either everything queued or to reach the default maximum frame size of 16384 bytes. +
      • +
    • A new HTTP/2 option max_receive_frame_rate can be used to control how fast the server is willing to receive frames. By default it will accept 1000 frames every 10 seconds. +
      • +
    • A new HTTP/2 option max_reset_stream_rate can be used to control the rate of errors the server is willing to accept. By default it will accept 10 stream resets every 10 seconds. +
      • +
    • Flow control for incoming data has been implemented for HTTP/1.1. Cowboy will now wait for the user code to ask for the request body before reading it from the socket. The option initial_stream_flow_size controls how much data Cowboy will read without being asked. +
      • +
    • The HTTP/1.1 and HTTP/2 option logger is now documented. +
      • +
    • The Websocket option validate_utf8 has been added. It can be used to disable the expensive UTF-8 validation for incoming text and close frames. +
      • +
    • The experimental commands based Websocket interface is now considered stable and has been documented. The old interface is now deprecated. +
      • +
    • A new Websocket handler command shutdown_reason can be used to change the normal exit reason of Websocket processes. By default normal is used; with this command the exit reason can be changed to {shutdown, ShutdownReason}. +
      • +
    • The experimental stream handlers cowboy_metrics_h and cowboy_tracer_h are now considered stable and have been documented. +
      • +
    • The stream handler commands set_options and log are now considered stable and have been documented. +
      • +
    • The router is now capable of retrieving dispatch rules directly from the persistent_term storage (available starting from Erlang/OTP 21.2). +
      • +
    • Support for the status codes 208 and 508 has been added. +
      • +
    • Update Ranch to 1.7.1. +
      • +
    • Update Cowlib to 2.8.0. +
      • +
    +

    Experimental features added

    +
    • It is now possible to read the response body from any process, as well as doing any other cowboy_req operations. Since this is not recommended due to race condition concerns this feature will always remain experimental. +
      • +
    +

    New functions

    +
    • The function cowboy_req:filter_cookies/2 has been added. It can be called before parsing/matching cookies in order to filter out undesirables. The main reason for doing this is to avoid most parse errors that may occur when dealing with Web browsers (which have a string-based Javascript interface to cookies that is very permissive of invalid content) and to be able to recover in other cases. +
      • +
    • The function cowboy_req:cast/2 has been added. It can be used to send events to stream handlers. +
      • +
    +

    Bugs fixed

    +
    • A number of fixes and additions were made to address the HTTP/2 CVEs CVE-2019-9511 through CVE-2019-9518, except for CVE-2019-9513 which required no intervention as the relevant protocol feature is not implemented by Cowboy. +
      • +
    • The HTTP/2 connection window could become larger than the protocol allows, leading to errors. This has been corrected. +
      • +
    • The presence of empty header names in HTTP/2 requests now results in the request to be rejected. +
      • +
    • Cowboy will now remove headers specific to HTTP/1.1 (the hop by hop headers such as connection or upgrade) when building an HTTP/2 response. +
      • +
    • A bug in the HTTP/2 code that resulted in the failure to fully send iolist response bodies has been fixed. Cowboy would just wait indefinitely in those cases. +
      • +
    • It was possible for a final empty HTTP/2 DATA frame to get stuck and never sent when the window reached 0 and the remote end did not increase the window anymore. This has been corrected. +
      • +
    • Cowboy now uses the host header when the HTTP/2 :authority pseudo header is missing. A common scenario where this occurs is when proxies translate incoming HTTP/1.1 requests to HTTP/2. +
      • +
    • HTTP/1.1 connections are now properly closed when the user code sends less data than advertised in the response headers. +
      • +
    • Cowboy will now close HTTP/1.1 connections immediately when a header line is missing a colon separator. Previously it was waiting for more data. +
      • +
    • It was possible for Cowboy to receive stray timeout messages for HTTP/1.1 connections, resulting in crashes. The timeout handling in HTTP/1.1 has been reworked and the issue should no longer occur. +
      • +
    • The type for the Req object has been updated to accept custom fields as was already documented. +
      • +
    • The authentication scheme returned when parsing the authorization header is now case insensitive, which means it will be returned as lowercase. +
      • +
    • Cowboy no longer discards data that follows a Websocket upgrade request. Note that the protocol does not allow sending data before receiving a successful Websocket upgrade response, so this fix is more out of principle rather than to fix a real world issue. +
      • +
    • The cowboy_static handler will now properly detect the type of files that have an uppercase or mixed extension component. +
      • +
    • The cowboy_static handler is now consistent across all supported platforms. It now explicitly rejects path_info components that include a forward slash, backward slash or NUL character. +
      • +
    • The update to Ranch 1.7.1 fixes an issue with the PROXY protocol that would cause checksum verification to fail. +
      • +
    • The HTTP/1.1 error reason for stream_error mistakenly contained an extra element. It has now been removed. +
      • +
    • The PartialReq given to the early_error stream handler callback now includes headers when the protocol is HTTP/2. +
      • +
    • A bug where the stacktrace was incorrect in error messages has been fixed. The problem occurred when an exception occurred in the handler's terminate callback. +
      • +
    • The REST flowchart for POST, PATCH and PUT has received a number of fixes and had to be greatly reworked as a result. When the method is PUT, we do not check for the location header in the response. When the resource doesn't exist and the method was PUT the flowchart was largely incorrect. A 415 response may occur after the content_types_accepted callback and was missing from the flowchart. +
      • +
    • The documentation for content_types_accepted now includes the media type wildcard that was previously missing. +
      • +
    • The documentation for a type found in cow_cookie was missing. A manual page for cow_cookie was added and can be found in the Cowlib documentation. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.7.asciidoc b/docs/en/cowboy/2.9/guide/migrating_from_2.7.asciidoc new file mode 100644 index 00000000..1e52130c --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.7.asciidoc @@ -0,0 +1,118 @@ +[appendix] +== Migrating from Cowboy 2.7 to 2.8 + +Cowboy 2.8 contains many optimizations for all +protocols. HTTP/1.1 has received the largest +improvements and Cowboy will now be able to +handle noticeably more requests. Thanks to +the folks at Stressgrid for helping identify that +the performance was lower than it should have been +and for benchmarking my many changes and experiments. + +Cowboy 2.8 also contains a small number of tweaks +and bug fixes. Cowboy 2.8 is the first Cowboy release, +ever, to be consistently green on all tested platforms. +This is mostly due to the reworking of some test cases, +but a few bugs were discovered and fixed in the process. + +Cowboy 2.8 requires Erlang/OTP 22.0 or greater. It may +also work out of the box with Erlang/OTP 21.3 but this +was not tested and is not supported. + +=== Features added + +* Cowboy will now use `active,N` instead of `active,once` + to receive data from the socket. This greatly improves + the performance and allows Cowboy to process more + requests, especially for HTTP/1.1. The `active_n` + protocol option can be configured to change the + `active,N` value. The default is 100 for all protocols. + +* Add a `linger_timeout` option for HTTP/2. The default + is 1000, or one second. This helps ensure that the + final GOAWAY frame will be properly received by clients. + +* The function `cowboy_req:parse_header/2,3` will now + parse the headers `access-control-request-headers`, + `access-control-request-method`, `content-encoding`, + `content-language`, `max-forwards`, `origin`, + `proxy-authorization` and `trailer`. + +* A Performance chapter has been added to the guide. + More content will be added in future releases. + +* Update Cowlib to 2.9.1. + +=== Experimental features added + +* A `protocols` protocol option allows configuring which + protocol will be used for clear listeners. Setting it + to `[http2]` will disable HTTP/1.1 entirely. This feature + will be extended in a future release. + +=== Features modified + +* The default value for HTTP/1.1's `max_keepalive` option + has been increased. It now allows 1000 requests before + gracefully closing the connection. + +* The default value for HTTP/2's `max_received_frame_rate` + option has been increased. It now allows 10000 frames every + 10 seconds. + +* Cowboy will now accept whitespace in cookie names. This + is in line with the recommended parsing algorithm for the + upcoming cookie RFC update, and corresponds to what browsers + are doing. + +=== Bugs fixed + +* The number of Transport:send/2 calls has been optimized + for HTTP/2. Reducing the number of calls has a noticeable + impact on the number of requests that can be processed. + +* Trying to use `cowboy_req:reply/4` with a status code of + 204 or 304 and a non-empty response body will now result + in a crash. Using `cowboy_req:stream_reply/2,3` with 204 + or 304 and then attempting to send a body will also result + in a crash. These status codes disallow response bodies + and trying to send one will break HTTP/1.1 framing. + +* A crash has been fixed related to HTTP/1.1 pipelining. + The bug was most likely introduced in Cowboy 2.6 when + flow control was added for HTTP/1.1 request bodies. + +* The HTTP/1.1 protocol code could get stuck because of flow + control. This has been corrected. + +* A crash has been fixed for HTTP/1.1. It occurred when + a flow control update was requested (such as reading + the request body) after the body was fully read. + +* The timeout was incorrectly reset sometimes when a stream + (a pair of request/response) terminated. This has been + corrected. + +* Handling of hibernation for Websocket has been improved. + Websocket over HTTP/2 now supports hibernating. Stray + messages no longer cancel hibernation. + +* The `cowboy_compress_h` stream handler will now ignore + malformed accept-encoding headers instead of crashing. + +* The manual pages for `cowboy:start_clear(3)` and + `cowboy:start_tls(3)` now mentions that some protocol + options may be documented in the releevant stream + handler. + +* The manual page for `cowboy_req:parse_header(3)` was + corrected. When an unsupported header is given the + function crashes, it does not return an `undefined` tuple. + +* The routing algorithm description in the user guide has + been improved. + +* The test suites are now consistently green on all tested + platforms. Most of the test failures were caused by flaky + tests. Avoiding the use of timeouts fixed most of them. + A small number of tests had to be reworked. diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.7/index.html b/docs/en/cowboy/2.9/guide/migrating_from_2.7/index.html new file mode 100644 index 00000000..87bda460 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.7/index.html @@ -0,0 +1,234 @@ + + + + + + + + + + Nine Nines: Migrating from Cowboy 2.7 to 2.8 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Cowboy 2.7 to 2.8

    + +

    Cowboy 2.8 contains many optimizations for all protocols. HTTP/1.1 has received the largest improvements and Cowboy will now be able to handle noticeably more requests. Thanks to the folks at Stressgrid for helping identify that the performance was lower than it should have been and for benchmarking my many changes and experiments.

    +

    Cowboy 2.8 also contains a small number of tweaks and bug fixes. Cowboy 2.8 is the first Cowboy release, ever, to be consistently green on all tested platforms. This is mostly due to the reworking of some test cases, but a few bugs were discovered and fixed in the process.

    +

    Cowboy 2.8 requires Erlang/OTP 22.0 or greater. It may also work out of the box with Erlang/OTP 21.3 but this was not tested and is not supported.

    +

    Features added

    +
    • Cowboy will now use active,N instead of active,once to receive data from the socket. This greatly improves the performance and allows Cowboy to process more requests, especially for HTTP/1.1. The active_n protocol option can be configured to change the active,N value. The default is 100 for all protocols. +
      • +
    • Add a linger_timeout option for HTTP/2. The default is 1000, or one second. This helps ensure that the final GOAWAY frame will be properly received by clients. +
      • +
    • The function cowboy_req:parse_header/2,3 will now parse the headers access-control-request-headers, access-control-request-method, content-encoding, content-language, max-forwards, origin, proxy-authorization and trailer. +
      • +
    • A Performance chapter has been added to the guide. More content will be added in future releases. +
      • +
    • Update Cowlib to 2.9.1. +
      • +
    +

    Experimental features added

    +
    • A protocols protocol option allows configuring which protocol will be used for clear listeners. Setting it to [http2] will disable HTTP/1.1 entirely. This feature will be extended in a future release. +
      • +
    +

    Features modified

    +
    • The default value for HTTP/1.1's max_keepalive option has been increased. It now allows 1000 requests before gracefully closing the connection. +
      • +
    • The default value for HTTP/2's max_received_frame_rate option has been increased. It now allows 10000 frames every 10 seconds. +
      • +
    • Cowboy will now accept whitespace in cookie names. This is in line with the recommended parsing algorithm for the upcoming cookie RFC update, and corresponds to what browsers are doing. +
      • +
    +

    Bugs fixed

    +
    • The number of Transport:send/2 calls has been optimized for HTTP/2. Reducing the number of calls has a noticeable impact on the number of requests that can be processed. +
      • +
    • Trying to use cowboy_req:reply/4 with a status code of 204 or 304 and a non-empty response body will now result in a crash. Using cowboy_req:stream_reply/2,3 with 204 or 304 and then attempting to send a body will also result in a crash. These status codes disallow response bodies and trying to send one will break HTTP/1.1 framing. +
      • +
    • A crash has been fixed related to HTTP/1.1 pipelining. The bug was most likely introduced in Cowboy 2.6 when flow control was added for HTTP/1.1 request bodies. +
      • +
    • The HTTP/1.1 protocol code could get stuck because of flow control. This has been corrected. +
      • +
    • A crash has been fixed for HTTP/1.1. It occurred when a flow control update was requested (such as reading the request body) after the body was fully read. +
      • +
    • The timeout was incorrectly reset sometimes when a stream (a pair of request/response) terminated. This has been corrected. +
      • +
    • Handling of hibernation for Websocket has been improved. Websocket over HTTP/2 now supports hibernating. Stray messages no longer cancel hibernation. +
      • +
    • The cowboy_compress_h stream handler will now ignore malformed accept-encoding headers instead of crashing. +
      • +
    • The manual pages for cowboy:start_clear(3) and cowboy:start_tls(3) now mentions that some protocol options may be documented in the releevant stream handler. +
      • +
    • The manual page for cowboy_req:parse_header(3) was corrected. When an unsupported header is given the function crashes, it does not return an undefined tuple. +
      • +
    • The routing algorithm description in the user guide has been improved. +
      • +
    • The test suites are now consistently green on all tested platforms. Most of the test failures were caused by flaky tests. Avoiding the use of timeouts fixed most of them. A small number of tests had to be reworked. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.8.asciidoc b/docs/en/cowboy/2.9/guide/migrating_from_2.8.asciidoc new file mode 100644 index 00000000..a3a0e7c2 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.8.asciidoc @@ -0,0 +1,50 @@ +[appendix] +== Migrating from Cowboy 2.8 to 2.9 + +Cowboy 2.9 implements graceful shutdown of connection +processes for both HTTP/1.1 and HTTP/2 connections. + +Cowboy 2.9 is the first release to support the much +awaited Erlang/OTP 24 out of the box. While users that +were using Ranch 2.0 already were ready for OTP 24, +the Ranch version used by Cowboy out of the box was +not compatible and had to be updated. + +Cowboy 2.9 also contains a small number of tweaks +and bug fixes. + +Cowboy 2.9 requires Erlang/OTP 22.0 or greater. + +=== Features added + +* Cowboy will now gracefully shutdown HTTP/1.1 and HTTP/2 + connections when the supervisor asks the connection + process to exit, or when `sys:terminate/2,3` is used. + Two new configuration options were added for HTTP/2 + to determine the timeouts for the graceful shutdown + steps. + +* REST handler `AcceptCallback` can now return `{created, URI}` + or `{see_other, URI}` to determine what response status code + should be sent (typically to differentiate between a new + resource and an update). The return value `{true, URI}` is + now deprecated. + +* Update Ranch to 1.8.0. + +* Update Cowlib to 2.11.0. + +=== Bugs fixed + +* Fix concurrent body streaming getting stuck with HTTP/2. + The alarm could get into blocking state indefinitely + when two or more request processes were streaming bodies. + +* Fix HTTP/2 rate limiting using the wrong default values + in some cases. + +* Don't produce an error report when the request process + exited normally (`normal` or `shutdown` exit reasons). + +* Fix `cowboy_tracer_h` to support trace messages without + timestamps. diff --git a/docs/en/cowboy/2.9/guide/migrating_from_2.8/index.html b/docs/en/cowboy/2.9/guide/migrating_from_2.8/index.html new file mode 100644 index 00000000..45e8ab24 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/migrating_from_2.8/index.html @@ -0,0 +1,205 @@ + + + + + + + + + + Nine Nines: Migrating from Cowboy 2.8 to 2.9 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Cowboy 2.8 to 2.9

    + +

    Cowboy 2.9 implements graceful shutdown of connection processes for both HTTP/1.1 and HTTP/2 connections.

    +

    Cowboy 2.9 is the first release to support the much awaited Erlang/OTP 24 out of the box. While users that were using Ranch 2.0 already were ready for OTP 24, the Ranch version used by Cowboy out of the box was not compatible and had to be updated.

    +

    Cowboy 2.9 also contains a small number of tweaks and bug fixes.

    +

    Cowboy 2.9 requires Erlang/OTP 22.0 or greater.

    +

    Features added

    +
    • Cowboy will now gracefully shutdown HTTP/1.1 and HTTP/2 connections when the supervisor asks the connection process to exit, or when sys:terminate/2,3 is used. Two new configuration options were added for HTTP/2 to determine the timeouts for the graceful shutdown steps. +
      • +
    • REST handler AcceptCallback can now return {created, URI} or {see_other, URI} to determine what response status code should be sent (typically to differentiate between a new resource and an update). The return value {true, URI} is now deprecated. +
      • +
    • Update Ranch to 1.8.0. +
      • +
    • Update Cowlib to 2.11.0. +
      • +
    +

    Bugs fixed

    +
    • Fix concurrent body streaming getting stuck with HTTP/2. The alarm could get into blocking state indefinitely when two or more request processes were streaming bodies. +
      • +
    • Fix HTTP/2 rate limiting using the wrong default values in some cases. +
      • +
    • Don't produce an error report when the request process exited normally (normal or shutdown exit reasons). +
      • +
    • Fix cowboy_tracer_h to support trace messages without timestamps. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/modern_web.asciidoc b/docs/en/cowboy/2.9/guide/modern_web.asciidoc new file mode 100644 index 00000000..48525732 --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/modern_web/index.html b/docs/en/cowboy/2.9/guide/modern_web/index.html new file mode 100644 index 00000000..ab26c974 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/modern_web/index.html @@ -0,0 +1,208 @@ + + + + + + + + + + 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/multipart.asciidoc b/docs/en/cowboy/2.9/guide/multipart.asciidoc new file mode 100644 index 00000000..0825244c --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/multipart/index.html b/docs/en/cowboy/2.9/guide/multipart/index.html new file mode 100644 index 00000000..de5f7536 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/multipart/index.html @@ -0,0 +1,281 @@ + + + + + + + + + + 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/performance.asciidoc b/docs/en/cowboy/2.9/guide/performance.asciidoc new file mode 100644 index 00000000..10031302 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/performance.asciidoc @@ -0,0 +1,29 @@ +[[performance]] +== Performance + +This chapter describes the performance characteristics +of Cowboy and offers suggestions to get the most +performance out of your application. + +=== One process per connection + +The first version of Cowboy featured a single process +per connection, whereas the current version of Cowboy +features one process per connection plus one process +per request. This has a negative impact on performance, +but is necessary in order to provide a common interface +for both HTTP/1.1 and HTTP/2 (as well as future HTTP +versions). + +It is still possible to use a single process per +connection, and avoid the creation of additional +processes for each request, by implementing a +stream handler to process the requests. This can +be done for all requests, or just for a single +endpoint depending on the application's needs. + +Stream handlers provide an asynchronous interface +and must not block, so the implementation will +be very different from normal Cowboy handlers, +but the performance gains are important enough +to justify it in some cases. diff --git a/docs/en/cowboy/2.9/guide/performance/index.html b/docs/en/cowboy/2.9/guide/performance/index.html new file mode 100644 index 00000000..85eaf719 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/performance/index.html @@ -0,0 +1,186 @@ + + + + + + + + + + Nine Nines: Performance + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Performance

    + +

    This chapter describes the performance characteristics of Cowboy and offers suggestions to get the most performance out of your application.

    +

    One process per connection

    +

    The first version of Cowboy featured a single process per connection, whereas the current version of Cowboy features one process per connection plus one process per request. This has a negative impact on performance, but is necessary in order to provide a common interface for both HTTP/1.1 and HTTP/2 (as well as future HTTP versions).

    +

    It is still possible to use a single process per connection, and avoid the creation of additional processes for each request, by implementing a stream handler to process the requests. This can be done for all requests, or just for a single endpoint depending on the application's needs.

    +

    Stream handlers provide an asynchronous interface and must not block, so the implementation will be very different from normal Cowboy handlers, but the performance gains are important enough to justify it in some cases.

    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/req.asciidoc b/docs/en/cowboy/2.9/guide/req.asciidoc new file mode 100644 index 00000000..754e4705 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/req.asciidoc @@ -0,0 +1,367 @@ +[[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`; +the connection `peer` address and port; and the TLS +certificate `cert` when applicable. + +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 is allowed, but extra caution +must be used when modifying existing fields. You can +add as many new fields as necessary, however. Just make +sure to namespace the field names so that no conflict +can occur with future Cowboy updates or with third party +projects. + +=== 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.9/guide/req/index.html b/docs/en/cowboy/2.9/guide/req/index.html new file mode 100644 index 00000000..1ef5aa47 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/req/index.html @@ -0,0 +1,456 @@ + + + + + + + + + + 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; the connection peer address and port; and the TLS certificate cert when applicable.

    +

    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 is allowed, but extra caution must be used when modifying existing fields. You can add as many new fields as necessary, however. Just make sure to namespace the field names so that no conflict can occur with future Cowboy updates or with 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/req_body.asciidoc b/docs/en/cowboy/2.9/guide/req_body.asciidoc new file mode 100644 index 00000000..4906811e --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/req_body/index.html b/docs/en/cowboy/2.9/guide/req_body/index.html new file mode 100644 index 00000000..5dc02bad --- /dev/null +++ b/docs/en/cowboy/2.9/guide/req_body/index.html @@ -0,0 +1,267 @@ + + + + + + + + + + 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/resource_design.asciidoc b/docs/en/cowboy/2.9/guide/resource_design.asciidoc new file mode 100644 index 00000000..954d87d5 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/resource_design.asciidoc @@ -0,0 +1,226 @@ +[[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. + +Can access be rate-limited for authenticated users? Use the +`rate_limited` 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`. For resources that don't implement methods +GET or HEAD, you must still accept at least one media type, +but you can leave the callback as `undefined` since it will +never be called. + +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.9/guide/resource_design/index.html b/docs/en/cowboy/2.9/guide/resource_design/index.html new file mode 100644 index 00000000..b3a4d1ac --- /dev/null +++ b/docs/en/cowboy/2.9/guide/resource_design/index.html @@ -0,0 +1,241 @@ + + + + + + + + + + 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.

    +

    Can access be rate-limited for authenticated users? Use the rate_limited 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. For resources that don't implement methods GET or HEAD, you must still accept at least one media type, but you can leave the callback as undefined since it will never be called.

    +

    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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/resp.asciidoc b/docs/en/cowboy/2.9/guide/resp.asciidoc new file mode 100644 index 00000000..1664aefc --- /dev/null +++ b/docs/en/cowboy/2.9/guide/resp.asciidoc @@ -0,0 +1,368 @@ +[[resp]] +== Sending a response + +The response must be sent using the Req object. + +Cowboy provides two different ways of sending responses: +either directly or by streaming the body. Response headers +and body may be set in advance. The response is sent as +soon as one of the reply or stream reply function is +called. + +Cowboy also provides a simplified interface for sending +files. It can also send only specific parts of a file. + +While only one response is allowed for every request, +HTTP/2 introduced a mechanism that allows the server +to push additional resources related to the response. +This chapter also describes how this feature works in +Cowboy. + +=== Reply + +Cowboy provides three functions for sending the entire reply, +depending on whether you need to set headers and body. In all +cases, Cowboy will add any headers required by the protocol +(for example the date header will always be sent). + +When you need to set only the status code, +use `cowboy_req:reply/2`: + +[source,erlang] +Req = cowboy_req:reply(200, Req0). + +When you need to set response headers at the same time, +use `cowboy_req:reply/3`: + +[source,erlang] +---- +Req = cowboy_req:reply(303, #{ + <<"location">> => <<"https://ninenines.eu">> +}, Req0). +---- + +Note that the header name must always be a lowercase +binary. + +When you also need to set the response body, +use `cowboy_req:reply/4`: + +[source,erlang] +---- +Req = cowboy_req:reply(200, #{ + <<"content-type">> => <<"text/plain">> +}, "Hello world!", Req0). +---- + +You should always set the content-type header when the +response has a body. There is however no need to set +the content-length header; Cowboy does it automatically. + +The response body and the header values must be either +a binary or an iolist. An iolist is a list containing +binaries, characters, strings or other iolists. This +allows you to build a response from different parts +without having to do any concatenation: + +[source,erlang] +---- +Title = "Hello world!", +Body = <<"Hats off!">>, +Req = cowboy_req:reply(200, #{ + <<"content-type">> => <<"text/html">> +}, ["", 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. + +Cowboy also provides a function to send response trailers. +Response trailers are semantically equivalent to the headers +you send in the response, only they are sent at the end. +This is especially useful to attach information to the +response that could not be generated until the response +body was fully generated. + +Trailer fields must be listed in the trailer header. Any +field not listed might be dropped by the client or an intermediary. + +[source,erlang] +---- +Req = cowboy_req:stream_reply(200, #{ + <<"content-type">> => <<"text/html">>, + <<"trailer">> => <<"expires, content-md5">> +}, Req0), + +cowboy_req:stream_body("Hello world!", nofin, Req), +cowboy_req:stream_body("

    Hats off!

    ", nofin, Req), + +cowboy_req:stream_trailers(#{ + <<"expires">> => <<"Sun, 10 Dec 2017 19:13:47 GMT">>, + <<"content-md5">> => <<"c6081d20ff41a42ce17048ed1c0345e2">> +}, Req). +---- + +The stream ends with trailers. It is no longer possible to +send data after sending trailers. You cannot send trailers +after setting the `fin` flag when streaming the body. + +=== Preset response headers + +Cowboy provides functions to set response headers without +immediately sending them. They are stored in the Req object +and sent as part of the response when a reply function is +called. + +To set response headers: + +[source,erlang] +Req = cowboy_req:set_resp_header(<<"allow">>, "GET", Req0). + +Header names must be a lowercase binary. + +Do not use this function for setting cookies. Refer to +the xref:cookies[Cookies] chapter for more information. + +To check if a response header has already been set: + +[source,erlang] +cowboy_req:has_resp_header(<<"allow">>, Req). + +It returns `true` if the header was set, `false` otherwise. + +To delete a response header that was set previously: + +[source,erlang] +Req = cowboy_req:delete_resp_header(<<"allow">>, Req0). + +=== Overriding headers + +As Cowboy provides different ways of setting response +headers and body, clashes may occur, so it's important +to understand what happens when a header is set twice. + +Headers come from five different origins: + +* Protocol-specific headers (for example HTTP/1.1's connection header) +* Other required headers (for example the date header) +* Preset headers +* Headers given to the reply function +* Set-cookie headers + +Cowboy does not allow overriding protocol-specific headers. + +Set-cookie headers will always be appended at the end of +the list of headers before sending the response. + +Headers given to the reply function will always override +preset headers and required headers. If a header is found +in two or three of these, then the one in the reply function +is picked and the others are dropped. + +Similarly, preset headers will always override required +headers. + +To illustrate, look at the following snippet. Cowboy by +default sends the server header with the value "Cowboy". +We can override it: + +[source,erlang] +---- +Req = cowboy_req:reply(200, #{ + <<"server">> => <<"yaws">> +}, Req0). +---- + +=== Preset response body + +Cowboy provides functions to set the response body without +immediately sending it. It is stored in the Req object and +sent when the reply function is called. + +To set the response body: + +[source,erlang] +Req = cowboy_req:set_resp_body("Hello world!", Req0). + +// @todo Yeah we probably should add that function that +// also sets the content-type at the same time... + +To check if a response body has already been set: + +[source,erlang] +cowboy_req:has_resp_body(Req). + +It returns `true` if the body was set and is non-empty, +`false` otherwise. + +// @todo We probably should also have a function that +// properly removes the response body, including any +// content-* headers. + +The preset response body is only sent if the reply function +used is `cowboy_req:reply/2` or `cowboy_req:reply/3`. + +=== Sending files + +Cowboy provides a shortcut for sending files. When +using `cowboy_req:reply/4`, or when presetting the +response header, you can give a `sendfile` tuple to +Cowboy: + +[source,erlang] +{sendfile, Offset, Length, Filename} + +Depending on the values for `Offset` or `Length`, the +entire file may be sent, or just a part of it. + +The length is required even for sending the entire file. +Cowboy sends it in the content-length header. + +To send a file while replying: + +[source,erlang] +---- +Req = cowboy_req:reply(200, #{ + <<"content-type">> => "image/png" +}, {sendfile, 0, 12345, "path/to/logo.png"}, Req0). +---- + +// @todo An example of presetting a file would be useful, +// but let's wait for the function that can set the +// content-type at the same time. + +// @todo What about streaming many files? For example +// it should be possible to build a tar file on the fly +// while still using sendfile. Another example could be +// proper support for multipart byte ranges. Yet another +// example would be automatic concatenation of CSS or JS +// files. + +=== Informational responses + +Cowboy allows you to send informational responses. + +Informational responses are responses that have a status +code between 100 and 199. Any number can be sent before +the proper response. Sending an informational response +does not change the behavior of the proper response, and +clients are expected to ignore any informational response +they do not understand. + +The following snippet sends a 103 informational response +with some headers that are expected to be in the final +response. + +[source,erlang] +---- +Req = cowboy_req:inform(103, #{ + <<"link">> => <<"; rel=preload; as=style, ; 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.9/guide/resp/index.html b/docs/en/cowboy/2.9/guide/resp/index.html new file mode 100644 index 00000000..cbe35b8c --- /dev/null +++ b/docs/en/cowboy/2.9/guide/resp/index.html @@ -0,0 +1,423 @@ + + + + + + + + + + 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.

    +

    Cowboy also provides a function to send response trailers. Response trailers are semantically equivalent to the headers you send in the response, only they are sent at the end. This is especially useful to attach information to the response that could not be generated until the response body was fully generated.

    +

    Trailer fields must be listed in the trailer header. Any field not listed might be dropped by the client or an intermediary.

    +
    +
    Req = cowboy_req:stream_reply(200, #{
+    <<"content-type">> => <<"text/html">>,
+    <<"trailer">> => <<"expires, content-md5">>
+}, Req0),
+
+cowboy_req:stream_body("<html><head>Hello world!</head>", nofin, Req),
+cowboy_req:stream_body("<body><p>Hats off!</p></body></html>", nofin, Req),
+
+cowboy_req:stream_trailers(#{
+    <<"expires">> => <<"Sun, 10 Dec 2017 19:13:47 GMT">>,
+    <<"content-md5">> => <<"c6081d20ff41a42ce17048ed1c0345e2">>
+}, Req).
    +
    +

    The stream ends with trailers. It is no longer possible to send data after sending trailers. You cannot send trailers after setting the fin flag when streaming the body.

    +

    Preset response headers

    +

    Cowboy provides functions to set response headers without immediately sending them. They are stored in the Req object and sent as part of the response when a reply function is called.

    +

    To set response headers:

    +
    +
    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, </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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/rest_cond.png b/docs/en/cowboy/2.9/guide/rest_cond.png new file mode 100644 index 00000000..64cda347 Binary files /dev/null and b/docs/en/cowboy/2.9/guide/rest_cond.png differ diff --git a/docs/en/cowboy/2.9/guide/rest_cond.svg b/docs/en/cowboy/2.9/guide/rest_cond.svg new file mode 100644 index 00000000..542ae17d --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/rest_conneg.png b/docs/en/cowboy/2.9/guide/rest_conneg.png new file mode 100644 index 00000000..65ecdcf3 Binary files /dev/null and b/docs/en/cowboy/2.9/guide/rest_conneg.png differ diff --git a/docs/en/cowboy/2.9/guide/rest_conneg.svg b/docs/en/cowboy/2.9/guide/rest_conneg.svg new file mode 100644 index 00000000..247567a0 --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/rest_delete.png b/docs/en/cowboy/2.9/guide/rest_delete.png new file mode 100644 index 00000000..56a861c0 Binary files /dev/null and b/docs/en/cowboy/2.9/guide/rest_delete.png differ diff --git a/docs/en/cowboy/2.9/guide/rest_delete.svg b/docs/en/cowboy/2.9/guide/rest_delete.svg new file mode 100644 index 00000000..2f5513cd --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/rest_flowcharts.asciidoc b/docs/en/cowboy/2.9/guide/rest_flowcharts.asciidoc new file mode 100644 index 00000000..308a919e --- /dev/null +++ b/docs/en/cowboy/2.9/guide/rest_flowcharts.asciidoc @@ -0,0 +1,249 @@ +[[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. The star next +to values indicate that the value is descriptive rather than exact. + +=== 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.9/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.9/guide/rest_flowcharts/index.html new file mode 100644 index 00000000..c55c2847 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/rest_flowcharts/index.html @@ -0,0 +1,238 @@ + + + + + + + + + + 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. The star next to values indicate that the value is descriptive rather than exact.

    +

    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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/rest_get_head.png b/docs/en/cowboy/2.9/guide/rest_get_head.png new file mode 100644 index 00000000..211ab603 Binary files /dev/null and b/docs/en/cowboy/2.9/guide/rest_get_head.png differ diff --git a/docs/en/cowboy/2.9/guide/rest_get_head.svg b/docs/en/cowboy/2.9/guide/rest_get_head.svg new file mode 100644 index 00000000..92030cf3 --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/rest_handlers.asciidoc b/docs/en/cowboy/2.9/guide/rest_handlers.asciidoc new file mode 100644 index 00000000..baf8e6a2 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/rest_handlers.asciidoc @@ -0,0 +1,139 @@ +[[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` +| rate_limited | `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.9/guide/rest_handlers/index.html b/docs/en/cowboy/2.9/guide/rest_handlers/index.html new file mode 100644 index 00000000..62ed425e --- /dev/null +++ b/docs/en/cowboy/2.9/guide/rest_handlers/index.html @@ -0,0 +1,339 @@ + + + + + + + + + + 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 nameDefault value
    allowed_methods[<<"GET">>, <<"HEAD">>, <<"OPTIONS">>]
    allow_missing_posttrue
    charsets_providedskip
    content_types_acceptednone
    content_types_provided[{{ <<"text">>, <<"html">>, '*'}, to_html}]
    delete_completedtrue
    delete_resourcefalse
    expiresundefined
    forbiddenfalse
    generate_etagundefined
    is_authorizedtrue
    is_conflictfalse
    known_methods[<<"GET">>, <<"HEAD">>, <<"POST">>, <<"PUT">>, <<"PATCH">>, <<"DELETE">>, <<"OPTIONS">>]
    languages_providedskip
    last_modifiedundefined
    malformed_requestfalse
    moved_permanentlyfalse
    moved_temporarilyfalse
    multiple_choicesfalse
    optionsok
    previously_existedfalse
    rate_limitedfalse
    resource_existstrue
    service_availabletrue
    uri_too_longfalse
    valid_content_headerstrue
    valid_entity_lengthtrue
    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:

    + + + + + + + + + + + + +
    KeyDetails
    media_typeThe content-type negotiated for the response entity.
    languageThe language negotiated for the response entity.
    charsetThe 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 nameDetails
    content-languageLanguage used in the response body
    content-typeMedia type and charset of the response body
    etagEtag of the resource
    expiresExpiration date of the resource
    last-modifiedLast modification date for the resource
    locationRelative or absolute URI to the requested resource
    varyList of headers that may change the representation of the resource
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/rest_options.png b/docs/en/cowboy/2.9/guide/rest_options.png new file mode 100644 index 00000000..90fd6f06 Binary files /dev/null and b/docs/en/cowboy/2.9/guide/rest_options.png differ diff --git a/docs/en/cowboy/2.9/guide/rest_options.svg b/docs/en/cowboy/2.9/guide/rest_options.svg new file mode 100644 index 00000000..496c050c --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/rest_principles.asciidoc b/docs/en/cowboy/2.9/guide/rest_principles.asciidoc new file mode 100644 index 00000000..66939cb7 --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/rest_principles/index.html b/docs/en/cowboy/2.9/guide/rest_principles/index.html new file mode 100644 index 00000000..93450c69 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/rest_principles/index.html @@ -0,0 +1,212 @@ + + + + + + + + + + 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/rest_put_post_patch.png b/docs/en/cowboy/2.9/guide/rest_put_post_patch.png new file mode 100644 index 00000000..d287036c Binary files /dev/null and b/docs/en/cowboy/2.9/guide/rest_put_post_patch.png differ diff --git a/docs/en/cowboy/2.9/guide/rest_put_post_patch.svg b/docs/en/cowboy/2.9/guide/rest_put_post_patch.svg new file mode 100644 index 00000000..4562722a --- /dev/null +++ b/docs/en/cowboy/2.9/guide/rest_put_post_patch.svg @@ -0,0 +1,3143 @@ + + + + + + + + + + + + + + + + + + + + + + + + + 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 + false + + + + + + + + + true* + false + + 301 moved permanently + + + + + + + + + + moved_temporarily + true* + false + + 307 moved temporarily + + 400 bad request + + + + + allow_missing_post + + + + + + method is PUT + + + + + + is_conflict + true + + 409 conflict + + + + + + content_types_accepted + + AcceptCallback + + + + + + + + + + new resource? + + + + + + + + + + new resource? + + 201 created + + 303 see other + + + + + + method is PUT? + + + + + + + + + + + has resp body? + + + + + + + + + + multiple_choices + false + + 300 multiple choices + + 200 OK + 204 no content + true + + + + + true + + moved_permanently + + 410 gone + false + false + + + + + true + + + + + true, URI* + + + + + true + false + true + true + false + true + false + true + false + false + + true + + + + + false + + + + + + + + + + 404 not found + + + + + + allow_missing_post + + method is POST? + false + true + false + true + + has resp location? + false + true + + 415 unsupported media type + not accepted* + + moved_permanently + + 301 moved permanently + true* + false + + + + + false + + diff --git a/docs/en/cowboy/2.9/guide/rest_start.png b/docs/en/cowboy/2.9/guide/rest_start.png new file mode 100644 index 00000000..4c230a02 Binary files /dev/null and b/docs/en/cowboy/2.9/guide/rest_start.png differ diff --git a/docs/en/cowboy/2.9/guide/rest_start.svg b/docs/en/cowboy/2.9/guide/rest_start.svg new file mode 100644 index 00000000..6f1dd871 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/rest_start.svg @@ -0,0 +1,1656 @@ + + + + + + + + + + + + + + + + + + + + + + + + + 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 + + + + + + + + + + + rate_limited + ... + true + false + true* + + 429 too many requests + + diff --git a/docs/en/cowboy/2.9/guide/routing.asciidoc b/docs/en/cowboy/2.9/guide/routing.asciidoc new file mode 100644 index 00000000..37d3e5aa --- /dev/null +++ b/docs/en/cowboy/2.9/guide/routing.asciidoc @@ -0,0 +1,271 @@ +[[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. + +Cowboy routes requests using the following algorithm: + +* If no configured host matches the request URI, a 400 response + is returned. + +* Otherwise, the first configured host that matches the request + URI will be used. Only the paths configured for this host will + be considered. + +* If none of the configured paths found in the previous step + match the request URI, a 404 response is returned. + +* Otherwise, the handler and its initial state are added to the + environment and the request continues to be processed. + +NOTE: It is possible to run into a situation where two hosts match a +request URI, but only the paths on the second host match the +request URI. In this case the expected result is a 404 response +because the only paths used during routing are the paths from +the first configured host that matches the request URI. + +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]]". + +While Cowboy does not reject multiple brackets in a route, +the behavior may be undefined if the route is under-specified. +For example, this route requires constraints to determine what +is a chapter and what is a page, since they are both optional: + +[source,erlang] +PathMatch = "/book/[:chapter]/[:page]". + +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, TransOpts, ProtoOpts +cowboy:start_clear(my_http_listener, + [{port, 8080}], + #{env => #{dispatch => Dispatch}} +). +---- + +=== Using persistent_term + +The routes can be stored in `persistent_term` starting from +Erlang/OTP 21.2. This may give a performance improvement when +there are a large number of routes. + +To use this functionality you need to compile the routes, +store them in `persistent_term` and then inform Cowboy: + +[source,erlang] +---- +Dispatch = cowboy_router:compile([ + {'_', [{'_', my_handler, #{}}]} +]), +persistent_term:put(my_app_dispatch, Dispatch), +cowboy:start_clear(my_http_listener, + [{port, 8080}], + #{env => #{dispatch => {persistent_term, my_app_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. + +When using `persistent_term` there is no need to call this function, +you can simply put the new routes in the storage. diff --git a/docs/en/cowboy/2.9/guide/routing/index.html b/docs/en/cowboy/2.9/guide/routing/index.html new file mode 100644 index 00000000..7ff7a416 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/routing/index.html @@ -0,0 +1,389 @@ + + + + + + + + + + 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.

    +

    Cowboy routes requests using the following algorithm:

    +
    • If no configured host matches the request URI, a 400 response is returned. +
      • +
    • Otherwise, the first configured host that matches the request URI will be used. Only the paths configured for this host will be considered. +
      • +
    • If none of the configured paths found in the previous step match the request URI, a 404 response is returned. +
      • +
    • Otherwise, the handler and its initial state are added to the environment and the request continues to be processed. +
      • +
    +

    NOTE: It is possible to run into a situation where two hosts match a request URI, but only the paths on the second host match the request URI. In this case the expected result is a 404 response because the only paths used during routing are the paths from the first configured host that matches the request URI.

    +

    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]]".
    +
    +

    While Cowboy does not reject multiple brackets in a route, the behavior may be undefined if the route is under-specified. For example, this route requires constraints to determine what is a chapter and what is a page, since they are both optional:

    +
    +
    PathMatch = "/book/[:chapter]/[:page]".
    +
    +

    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, TransOpts, ProtoOpts
+cowboy:start_clear(my_http_listener,
+    [{port, 8080}],
+    #{env => #{dispatch => Dispatch}}
+).
    +
    +

    Using persistent_term

    +

    The routes can be stored in persistent_term starting from Erlang/OTP 21.2. This may give a performance improvement when there are a large number of routes.

    +

    To use this functionality you need to compile the routes, store them in persistent_term and then inform Cowboy:

    +
    +
    Dispatch = cowboy_router:compile([
+    {'_', [{'_', my_handler, #{}}]}
+]),
+persistent_term:put(my_app_dispatch, Dispatch),
+cowboy:start_clear(my_http_listener,
+    [{port, 8080}],
+    #{env => #{dispatch => {persistent_term, my_app_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.

    +

    When using persistent_term there is no need to call this function, you can simply put the new routes in the storage.

    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/specs.asciidoc b/docs/en/cowboy/2.9/guide/specs.asciidoc new file mode 100644 index 00000000..14736b3e --- /dev/null +++ b/docs/en/cowboy/2.9/guide/specs.asciidoc @@ -0,0 +1,215 @@ +[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 +* https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt[PROXY]: The PROXY protocol +* 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/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://tools.ietf.org/html/rfc8288[RFC 8288]: Web Linking +* https://tools.ietf.org/html/rfc8297[RFC 8297]: An HTTP Status Code for Indicating Hints +* https://tools.ietf.org/html/rfc8336[RFC 8336]: The ORIGIN HTTP/2 Frame +* https://tools.ietf.org/html/rfc8441[RFC 8441]: Bootstrapping WebSockets with HTTP/2 +* https://tools.ietf.org/html/rfc8470[RFC 8470]: Using Early Data in HTTP +* https://tools.ietf.org/html/rfc8473[RFC 8473]: Token Binding over HTTP +* https://tools.ietf.org/html/rfc8586[RFC 8586]: Loop Detection in Content Delivery Networks (CDNs) +* https://tools.ietf.org/html/rfc8594[RFC 8594]: The Sunset HTTP Header Field +* https://tools.ietf.org/html/rfc8673[RFC 8673]: HTTP Random Access and Live Content +* https://tools.ietf.org/html/rfc8674[RFC 8674]: The "safe" HTTP Preference +* https://tools.ietf.org/html/rfc8740[RFC 8740]: Using TLS 1.3 with HTTP/2 +* https://tools.ietf.org/html/rfc8941[RFC 8941]: Structured Field Values for HTTP +* https://tools.ietf.org/html/rfc8942[RFC 8942]: HTTP Client Hints +* https://www.w3.org/TR/trace-context/[Trace Context]: Trace Context +* https://www.w3.org/TR/webmention/[Webmention]: Webmention + +==== Upcoming + +* https://www.w3.org/TR/clear-site-data/[Clear Site Data] +* 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/rfc5829[RFC 5829]: Link Relation Types for Simple Version Navigation between Web Resources +* https://tools.ietf.org/html/rfc6657[RFC 6657]: Update to MIME regarding "charset" Parameter Handling in Textual Media Types +* 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 +* https://tools.ietf.org/html/rfc8631[RFC 8631]: Link Relation Types for Web Services +* 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) +* https://tools.ietf.org/html/rfc8565[RFC 8565]: Hypertext Jeopardy Protocol (HTJP/1.0) +* 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 +* https://tools.ietf.org/html/rfc8615[RFC 8615]: Well-Known URIs +* 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 +* https://tools.ietf.org/html/rfc8607[RFC 8607]: Calendaring Extensions to WebDAV (CalDAV): Managed Attachments + +=== 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 +* https://tools.ietf.org/html/rfc8323[RFC 8323]: CoAP over TCP, TLS, and WebSockets +* https://tools.ietf.org/html/rfc8516[RFC 8516]: "Too Many Requests" Response Code for CoAP +* https://tools.ietf.org/html/rfc8613[RFC 8613]: Object Security for Constrained RESTful Environments +* https://tools.ietf.org/html/rfc8710[RFC 8710]: Multipart Content-Format for CoAP +* https://tools.ietf.org/html/rfc8768[RFC 8768]: CoAP Hop-Limit Option diff --git a/docs/en/cowboy/2.9/guide/specs/index.html b/docs/en/cowboy/2.9/guide/specs/index.html new file mode 100644 index 00000000..3d8d4a77 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/specs/index.html @@ -0,0 +1,559 @@ + + + + + + + + + + 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 +
      • +
    • PROXY: The PROXY protocol +
      • +
    • 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 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 +
      • +
    • RFC 8288: Web Linking +
      • +
    • RFC 8297: An HTTP Status Code for Indicating Hints +
      • +
    • RFC 8336: The ORIGIN HTTP/2 Frame +
      • +
    • RFC 8441: Bootstrapping WebSockets with HTTP/2 +
      • +
    • RFC 8470: Using Early Data in HTTP +
      • +
    • RFC 8473: Token Binding over HTTP +
      • +
    • RFC 8586: Loop Detection in Content Delivery Networks (CDNs) +
      • +
    • RFC 8594: The Sunset HTTP Header Field +
      • +
    • RFC 8673: HTTP Random Access and Live Content +
      • +
    • RFC 8674: The "safe" HTTP Preference +
      • +
    • RFC 8740: Using TLS 1.3 with HTTP/2 +
      • +
    • RFC 8941: Structured Field Values for HTTP +
      • +
    • RFC 8942: HTTP Client Hints +
      • +
    • Trace Context: Trace Context +
      • +
    • 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) +
      • +
    • RFC 8565: Hypertext Jeopardy Protocol (HTJP/1.0) +
      • +
    • 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 +
      • +
    • RFC 8607: Calendaring Extensions to WebDAV (CalDAV): Managed Attachments +
      • +
    +

    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 +
      • +
    • RFC 8323: CoAP over TCP, TLS, and WebSockets +
      • +
    • RFC 8516: "Too Many Requests" Response Code for CoAP +
      • +
    • RFC 8613: Object Security for Constrained RESTful Environments +
      • +
    • RFC 8710: Multipart Content-Format for CoAP +
      • +
    • RFC 8768: CoAP Hop-Limit Option +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/static_files.asciidoc b/docs/en/cowboy/2.9/guide/static_files.asciidoc new file mode 100644 index 00000000..5af911be --- /dev/null +++ b/docs/en/cowboy/2.9/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 the application's +private directory (e.g. `my_app/priv`). + +The following rule will serve any file found in the `my_app` +application's private directory in the `my_app/priv/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.9/guide/static_files/index.html b/docs/en/cowboy/2.9/guide/static_files/index.html new file mode 100644 index 00000000..5e834248 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/static_files/index.html @@ -0,0 +1,275 @@ + + + + + + + + + + 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 the application's private directory (e.g. my_app/priv).

    +

    The following rule will serve any file found in the my_app application's private directory in the my_app/priv/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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/streams.asciidoc b/docs/en/cowboy/2.9/guide/streams.asciidoc new file mode 100644 index 00000000..0ac84cec --- /dev/null +++ b/docs/en/cowboy/2.9/guide/streams.asciidoc @@ -0,0 +1,75 @@ +[[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 + +link:man:cowboy_stream(3)[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 four handlers. + +link:man:cowboy_stream_h(3)[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. + +link:man:cowboy_compress_h(3)[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. + +link:man:cowboy_metrics_h(3)[cowboy_metrics_h] gathers +metrics about a stream then passes them to a configurable +function. It is not enabled by default. + +link:man:cowboy_tracer_h(3)[cowboy_tracer_h] can be used to +conditionally trace streams based on the contents of the +request or its origin. Trace events are passed to a +configurable function. It is not enabled by default. diff --git a/docs/en/cowboy/2.9/guide/streams/index.html b/docs/en/cowboy/2.9/guide/streams/index.html new file mode 100644 index 00000000..1b4afacb --- /dev/null +++ b/docs/en/cowboy/2.9/guide/streams/index.html @@ -0,0 +1,199 @@ + + + + + + + + + + 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 four 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_metrics_h gathers metrics about a stream then passes them to a configurable function. It is not enabled by default.

    +

    cowboy_tracer_h can be used to conditionally trace streams based on the contents of the request or its origin. Trace events are passed to a configurable function. It is not enabled by default.

    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/ws_handlers.asciidoc b/docs/en/cowboy/2.9/guide/ws_handlers.asciidoc new file mode 100644 index 00000000..5cfdcb16 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/ws_handlers.asciidoc @@ -0,0 +1,292 @@ +[[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) -> + {[{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) -> + {[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) -> + {[{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 the frame to be sent: + +[source,erlang] +---- +websocket_info(_Info, State) -> + {[{text, <<"Hello!">>}], State}. +---- + +You can send frames of any type: text, binary, ping, pong +or close frames. + +You can send many frames at the same time: + +[source,erlang] +---- +websocket_info(_Info, State) -> + {[ + {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`. + +=== Limiting frame sizes + +Cowboy accepts frames of any size by default. You should +limit the size depending on what your handler may handle. +You can do this via the `init/2` callback: + +[source,erlang] +---- +init(Req, State) -> + {cowboy_websocket, Req, State, #{ + max_frame_size => 8000000}}. +---- + +The lack of limit is historical. A future version of +Cowboy will have a more reasonable default. + +=== Saving memory + +The Websocket connection process can be set to hibernate +after the callback returns. + +Simply add an `hibernate` field to the returned tuple: + +[source,erlang] +---- +websocket_init(State) -> + {[], State, hibernate}. + +websocket_handle(_Frame, State) -> + {[], State, hibernate}. + +websocket_info(_Info, State) -> + {[{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. + +The following example sends a close frame with a reason message: + +[source,erlang] +---- +websocket_info(_Info, State) -> + {[{close, 1000, <<"some-reason">>}], State}. +---- diff --git a/docs/en/cowboy/2.9/guide/ws_handlers/index.html b/docs/en/cowboy/2.9/guide/ws_handlers/index.html new file mode 100644 index 00000000..af1a4833 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/ws_handlers/index.html @@ -0,0 +1,364 @@ + + + + + + + + + + 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) ->
+    {[{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) ->
+    {[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) ->
+    {[{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 the frame to be sent:

    +
    +
    websocket_info(_Info, State) ->
+    {[{text, <<"Hello!">>}], State}.
    +
    +

    You can send frames of any type: text, binary, ping, pong or close frames.

    +

    You can send many frames at the same time:

    +
    +
    websocket_info(_Info, State) ->
+    {[
+        {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.

    +

    Limiting frame sizes

    +

    Cowboy accepts frames of any size by default. You should limit the size depending on what your handler may handle. You can do this via the init/2 callback:

    +
    +
    init(Req, State) ->
+    {cowboy_websocket, Req, State, #{
+        max_frame_size => 8000000}}.
    +
    +

    The lack of limit is historical. A future version of Cowboy will have a more reasonable default.

    +

    Saving memory

    +

    The Websocket connection process can be set to hibernate after the callback returns.

    +

    Simply add an hibernate field to the returned tuple:

    +
    +
    websocket_init(State) ->
+    {[], State, hibernate}.
+
+websocket_handle(_Frame, State) ->
+    {[], State, hibernate}.
+
+websocket_info(_Info, State) ->
+    {[{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.

    +

    The following example sends a close frame with a reason message:

    +
    +
    websocket_info(_Info, State) ->
+    {[{close, 1000, <<"some-reason">>}], State}.
    +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/guide/ws_protocol.asciidoc b/docs/en/cowboy/2.9/guide/ws_protocol.asciidoc new file mode 100644 index 00000000..8fa0673d --- /dev/null +++ b/docs/en/cowboy/2.9/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.9/guide/ws_protocol/index.html b/docs/en/cowboy/2.9/guide/ws_protocol/index.html new file mode 100644 index 00000000..8fe83802 --- /dev/null +++ b/docs/en/cowboy/2.9/guide/ws_protocol/index.html @@ -0,0 +1,196 @@ + + + + + + + + + + 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.9 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.9/manual/cowboy.set_env/index.html new file mode 100644 index 00000000..39ce7c5a --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy.set_env/index.html @@ -0,0 +1,211 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.9/manual/cowboy.start_clear/index.html new file mode 100644 index 00000000..88625836 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy.start_clear/index.html @@ -0,0 +1,229 @@ + + + + + + + + + + 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). Stream handlers such as cowboy_stream_h(3) (which is enabled by default) may also define options.

    +
    +
    +

    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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.9/manual/cowboy.start_tls/index.html new file mode 100644 index 00000000..1e2a602e --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy.start_tls/index.html @@ -0,0 +1,234 @@ + + + + + + + + + + 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). Stream handlers such as cowboy_stream_h(3) (which is enabled by default) may also define options.

    +
    +
    +

    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},
+    {certfile, "path/to/cert.pem"}
+], #{
+    env => #{dispatch => Dispatch}
+}).
    +
    +
    Start a listener on a random port
    +
    +
    Name = example,
+
+{ok, _} = cowboy:start_tls(Name, [
+    {certfile, "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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.9/manual/cowboy.stop_listener/index.html new file mode 100644 index 00000000..0500a38c --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy.stop_listener/index.html @@ -0,0 +1,194 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy/index.html b/docs/en/cowboy/2.9/manual/cowboy/index.html new file mode 100644 index 00000000..be8ff315 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy/index.html @@ -0,0 +1,228 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_app/index.html b/docs/en/cowboy/2.9/manual/cowboy_app/index.html new file mode 100644 index 00000000..87941e87 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_app/index.html @@ -0,0 +1,239 @@ + + + + + + + + + + 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:

    + +

    Stream 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_compress_h/index.html b/docs/en/cowboy/2.9/manual/cowboy_compress_h/index.html new file mode 100644 index 00000000..7796fe4a --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_compress_h/index.html @@ -0,0 +1,195 @@ + + + + + + + + + + Nine Nines: cowboy_compress_h(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowboy_compress_h(3)

    + +

    Name

    +

    cowboy_compress_h - Compress stream handler

    +

    Description

    +

    The module cowboy_compress_h compresses response bodies automatically when the client supports it. It will not try to compress responses that already have a content encoding.

    +

    Normal responses will only be compressed when their size is lower than the configured threshold. Streamed responses are always compressed, including when the sendfile command is used. Because the file must be read in memory to be compressed, this module is not suitable for automatically compressing large files.

    +

    Options

    +
    +
    opts() :: #{
+    compress_buffering => boolean(),
+    compress_threshold => non_neg_integer()
+}
    +
    +

    Configuration for the compress stream handler.

    +

    The default value is given next to the option name:

    +
    compress_buffering (false)
    +

    Whether the output will be buffered. By default no buffering is done to provide maximum compatibility at the cost of a lower compression rate.

    +

    This option can be updated at any time using the set_options stream handler command.

    +
    +
    compress_threshold (300)
    +

    How large the response body must be to be compressed when the response isn't streamed.

    +

    This option can be updated at any time using the set_options stream handler command.

    +
    +
    +

    Events

    +

    The compress stream handler does not produce any event.

    +

    Changelog

    +
    • 2.6: The options compress_buffering and compress_threshold were added. +
      • +
    • 2.0: Module introduced. +
      • +
    +

    See also

    +

    cowboy(7), cowboy_stream(3), cowboy_metrics_h(3), cowboy_stream_h(3), cowboy_tracer_h(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.9/manual/cowboy_constraints.int/index.html new file mode 100644 index 00000000..f2b6f1f0 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_constraints.int/index.html @@ -0,0 +1,204 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.9/manual/cowboy_constraints.nonempty/index.html new file mode 100644 index 00000000..6b393c0b --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_constraints.nonempty/index.html @@ -0,0 +1,203 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.9/manual/cowboy_constraints/index.html new file mode 100644 index 00000000..2a6155a8 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_constraints/index.html @@ -0,0 +1,195 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.9/manual/cowboy_handler.terminate/index.html new file mode 100644 index 00000000..e3869917 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_handler.terminate/index.html @@ -0,0 +1,206 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_handler/index.html b/docs/en/cowboy/2.9/manual/cowboy_handler/index.html new file mode 100644 index 00000000..99710c7f --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_handler/index.html @@ -0,0 +1,198 @@ + + + + + + + + + + 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.

    +
    +
    +

    Exports

    +

    The following function should be called by modules implementing custom handlers to execute the optional terminate callback:

    + +

    See also

    +

    cowboy(7)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_http/index.html b/docs/en/cowboy/2.9/manual/cowboy_http/index.html new file mode 100644 index 00000000..179fd113 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_http/index.html @@ -0,0 +1,298 @@ + + + + + + + + + + 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() :: #{
+    active_n                 => pos_integer(),
+    chunked                  => boolean(),
+    connection_type          => worker | supervisor,
+    http10_keepalive         => boolean(),
+    idle_timeout             => timeout(),
+    inactivity_timeout       => timeout(),
+    initial_stream_flow_size => non_neg_integer(),
+    linger_timeout           => timeout(),
+    logger                   => module(),
+    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(),
+    max_skip_body_length     => non_neg_integer(),
+    proxy_header             => boolean(),
+    request_timeout          => timeout(),
+    sendfile                 => boolean(),
+    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:

    +
    active_n (100)
    +

    The number of packets Cowboy will request from the socket at once. This can be used to tweak the performance of the server. Higher values reduce the number of times Cowboy need to request more packets from the port driver at the expense of potentially higher memory being used.

    +
    +
    chunked (true)
    +

    Whether chunked transfer-encoding is enabled for HTTP/1.1 connections. Note that a response streamed to the client without the chunked transfer-encoding and without a content-length header will result in the connection being closed at the end of the response body.

    +

    This option can be updated at any time using the set_options stream handler command.

    +
    +
    connection_type (supervisor)
    +

    Whether the connection process also acts as a supervisor.

    +
    +
    http10_keepalive (true)
    +

    Whether keep-alive is enabled for HTTP/1.0 connections.

    +
    +
    idle_timeout (60000)
    +

    Time in ms with no data received before Cowboy closes the connection.

    +

    This option can be updated at any time using the set_options stream handler command.

    +
    +
    inactivity_timeout (300000)
    +

    Time in ms with nothing received at all before Cowboy closes the connection.

    +
    +
    initial_stream_flow_size (65535)
    +

    Amount of data in bytes Cowboy will read from the socket right after a request was fully received. This is a soft limit.

    +
    +
    linger_timeout (1000)
    +

    Time in ms that Cowboy will wait when closing the connection. This is necessary to avoid the TCP reset problem as described in the section 6.6 of RFC7230.

    +
    +
    logger (error_logger)
    +

    The module that will be used to write log messages.

    +
    +
    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 (1000)
    +

    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.

    +
    +
    max_skip_body_length (1000000)
    +

    Maximum length Cowboy is willing to skip when the user code did not read the body fully. When the remaining length is too large or unknown Cowboy will close the connection.

    +
    +
    proxy_header (false)
    +

    Whether incoming connections have a PROXY protocol header. The proxy information will be passed forward via the proxy_header key of the Req object.

    +
    +
    request_timeout (5000)
    +

    Time in ms with no requests before Cowboy closes the connection.

    +
    +
    sendfile (true)
    +

    Whether the sendfile syscall may be used. It can be useful to disable it on systems where the syscall has a buggy implementation, for example under VirtualBox when using shared folders.

    +
    +
    stream_handlers ([cowboy_stream_h])
    +

    Ordered list of stream handlers that will handle all stream events.

    +
    +
    +

    Changelog

    +
    • 2.8: The active_n option was added. +
      • +
    • 2.7: The initial_stream_flow_size and logger options were added. +
      • +
    • 2.6: The chunked, http10_keepalive, proxy_header and sendfile options were added. +
      • +
    • 2.5: The linger_timeout option was added. +
      • +
    • 2.2: The max_skip_body_length option was added. +
      • +
    • 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_http2/index.html b/docs/en/cowboy/2.9/manual/cowboy_http2/index.html new file mode 100644 index 00000000..c0c7b67f --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_http2/index.html @@ -0,0 +1,332 @@ + + + + + + + + + + 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() :: #{
+    active_n                       => pos_integer(),
+    connection_type                => worker | supervisor,
+    connection_window_margin_size  => 0..16#7fffffff,
+    connection_window_update_threshold => 0..16#7fffffff,
+    enable_connect_protocol        => boolean(),
+    goaway_initial_timeout         => timeout(),
+    goaway_complete_timeout        => timeout(),
+    idle_timeout                   => timeout(),
+    inactivity_timeout             => timeout(),
+    initial_connection_window_size => 65535..16#7fffffff,
+    initial_stream_window_size     => 0..16#7fffffff,
+    linger_timeout                 => timeout(),
+    logger                         => module(),
+    max_concurrent_streams         => non_neg_integer() | infinity,
+    max_connection_buffer_size     => non_neg_integer(),
+    max_connection_window_size     => 0..16#7fffffff,
+    max_decode_table_size          => non_neg_integer(),
+    max_encode_table_size          => non_neg_integer(),
+    max_frame_size_received        => 16384..16777215,
+    max_frame_size_sent            => 16384..16777215 | infinity,
+    max_received_frame_rate        => {pos_integer(), timeout()},
+    max_reset_stream_rate          => {pos_integer(), timeout()},
+    max_stream_buffer_size         => non_neg_integer(),
+    max_stream_window_size         => 0..16#7fffffff,
+    preface_timeout                => timeout(),
+    proxy_header                   => boolean(),
+    sendfile                       => boolean(),
+    settings_timeout               => timeout(),
+    stream_handlers                => [module()],
+    stream_window_data_threshold   => 0..16#7fffffff,
+    stream_window_margin_size      => 0..16#7fffffff,
+    stream_window_update_threshold => 0..16#7fffffff
+}
    +
    +

    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:

    +
    active_n (100)
    +

    The number of packets Cowboy will request from the socket at once. This can be used to tweak the performance of the server. Higher values reduce the number of times Cowboy need to request more packets from the port driver at the expense of potentially higher memory being used.

    +
    +
    connection_type (supervisor)
    +

    Whether the connection process also acts as a supervisor.

    +
    +
    connection_window_margin_size (65535)
    +

    Extra amount in bytes to be added to the window size when updating the connection window. This is used to ensure that there is always some space available in the window.

    +
    +
    connection_window_update_threshold (163840)
    +

    The connection window will only get updated when its size becomes lower than this threshold, in bytes. This is to avoid sending too many WINDOW_UPDATE frames.

    +
    +
    enable_connect_protocol (false)
    +

    Whether to enable the extended CONNECT method to allow protocols like Websocket to be used over an HTTP/2 stream. This option is experimental and disabled by default.

    +
    +
    goaway_initial_timeout (1000)
    +

    Time in ms to wait for any in-flight stream creations before stopping to accept new streams on an existing connection during a graceful shutdown.

    +
    +
    goaway_complete_timeout (3000)
    +

    Time in ms to wait for ongoing streams to complete before closing the connection during a graceful shutdown.

    +
    +
    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.

    +
    +
    initial_connection_window_size (65535)
    +

    Initial window size in bytes for the connection. This is the total amount of data (from request bodies for example) that may be buffered by the connection across all streams before the user code explicitly requests it.

    +

    Note that this value cannot be lower than the default.

    +
    +
    initial_stream_window_size (65535)
    +

    Initial window size in bytes for new streams. This is the total amount of data (from request bodies for example) that may be buffered by a single stream before the user code explicitly requests it.

    +
    +
    linger_timeout (1000)
    +

    Time in ms that Cowboy will wait when closing the connection. This is necessary to avoid the TCP reset problem as described in the section 6.6 of RFC7230. In HTTP/2's case the GOAWAY message might also be lost when closing the connection immediately.

    +
    +
    logger (error_logger)
    +

    The module that will be used to write log messages.

    +
    +
    max_concurrent_streams (infinity)
    +

    Maximum number of concurrent streams allowed on the connection.

    +
    +
    max_connection_buffer_size (16000000)
    +

    Maximum size of all stream buffers for this connection, in bytes. This is a soft limit used to apply backpressure to handlers that send data faster than the HTTP/2 connection allows.

    +
    +
    max_connection_window_size (16#7fffffff)
    +

    Maximum connection window size in bytes. This is used as an upper bound when calculating the window size, either when reading the request body or receiving said body.

    +
    +
    max_decode_table_size (4096)
    +

    Maximum header table size in bytes used by the decoder. This is the value advertised to the client. The client can then choose a header table size equal or lower to the advertised value.

    +
    +
    max_encode_table_size (4096)
    +

    Maximum header table size in bytes used by the encoder. The server will compare this value to what the client advertises and choose the smallest one as the encoder's header table size.

    +
    +
    max_frame_size_received (16384)
    +

    Maximum size in bytes of the frames received by the server. This value is advertised to the remote endpoint which can then decide to use any value lower or equal for its frame sizes.

    +
    +
    max_frame_size_sent (infinity)
    +

    Maximum size in bytes of the frames sent by the server. This option allows setting an upper limit to the frame sizes instead of blindly following the client's advertised maximum.

    +

    Note that actual frame sizes may be lower than the limit when there is not enough space left in the flow control window.

    +
    +
    max_received_frame_rate ({10000, 10000})
    +

    Maximum frame rate allowed per connection. The rate is expressed as a tuple {NumFrames, TimeMs} indicating how many frames are allowed over the given time period. This is similar to a supervisor restart intensity/period.

    +
    +
    max_reset_stream_rate ({10, 10000})
    +

    Maximum reset stream rate per connection. This can be used to protect against misbehaving or malicious peers that do not follow the protocol, leading to the server resetting streams, by limiting the number of streams that can be reset over a certain time period. The rate is expressed as a tuple {NumResets, TimeMs}. This is similar to a supervisor restart intensity/period.

    +
    +
    max_stream_buffer_size (8000000)
    +

    Maximum stream buffer size in bytes. This is a soft limit used to apply backpressure to handlers that send data faster than the HTTP/2 connection allows.

    +
    +
    max_stream_window_size (16#7fffffff)
    +

    Maximum stream window size in bytes. This is used as an upper bound when calculating the window size, either when reading the request body or receiving said body.

    +
    +
    preface_timeout (5000)
    +

    Time in ms Cowboy is willing to wait for the connection preface.

    +
    +
    proxy_header (false)
    +

    Whether incoming connections have a PROXY protocol header. The proxy information will be passed forward via the proxy_header key of the Req object.

    +
    +
    sendfile (true)
    +

    Whether the sendfile syscall may be used. It can be useful to disable it on systems where the syscall has a buggy implementation, for example under VirtualBox when using shared folders.

    +
    +
    settings_timeout (5000)
    +

    Time in ms Cowboy is willing to wait for a SETTINGS ack.

    +
    +
    stream_handlers ([cowboy_stream_h])
    +

    Ordered list of stream handlers that will handle all stream events.

    +
    +
    stream_window_data_threshold (16384)
    +

    Window threshold in bytes below which Cowboy will not attempt to send data, with one exception. When Cowboy has data to send and the window is high enough, Cowboy will always send the data, regardless of this option.

    +
    +
    stream_window_margin_size (65535)
    +

    Extra amount in bytes to be added to the window size when updating a stream's window. This is used to ensure that there is always some space available in the window.

    +
    +
    stream_window_update_threshold (163840)
    +

    A stream's window will only get updated when its size becomes lower than this threshold, in bytes. This is to avoid sending too many WINDOW_UPDATE frames.

    +
    +
    +

    Changelog

    +
    • 2.9: The goaway_initial_timeout and goaway_complete_timeout options were added. +
      • +
    • 2.8: The active_n option was added. +
      • +
    • 2.8: The linger_timeout option was added. +
      • +
    • 2.8: The max_received_frame_rate default value has been multiplied by 10 as the default was too low. +
      • +
    • 2.7: Add the options connection_window_margin_size, connection_window_update_threshold, max_connection_window_size, max_stream_window_size, stream_window_margin_size and stream_window_update_threshold to configure behavior on sending WINDOW_UPDATE frames; max_connection_buffer_size and max_stream_buffer_size to apply backpressure when sending data too fast; max_received_frame_rate and max_reset_stream_rate to protect against various flood scenarios; and stream_window_data_threshold to control how small the DATA frames that Cowboy sends can get. +
      • +
    • 2.7: The logger option was added. +
      • +
    • 2.6: The proxy_header and sendfile options were added. +
      • +
    • 2.4: Add the options initial_connection_window_size, initial_stream_window_size, max_concurrent_streams, max_decode_table_size, max_encode_table_size, max_frame_size_received, max_frame_size_sent and settings_timeout to configure HTTP/2 SETTINGS and related behavior. +
      • +
    • 2.4: Add the experimental option enable_connect_protocol. +
      • +
    • 2.0: Protocol introduced. +
      • +
    +

    See also

    +

    cowboy(7), cowboy_http(3), cowboy_websocket(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_loop/index.html b/docs/en/cowboy/2.9/manual/cowboy_loop/index.html new file mode 100644 index 00000000..a55095d0 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_loop/index.html @@ -0,0 +1,212 @@ + + + + + + + + + + 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.

    +
    +
    +

    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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_metrics_h/index.html b/docs/en/cowboy/2.9/manual/cowboy_metrics_h/index.html new file mode 100644 index 00000000..760f7c8a --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_metrics_h/index.html @@ -0,0 +1,289 @@ + + + + + + + + + + Nine Nines: cowboy_metrics_h(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowboy_metrics_h(3)

    + +

    Name

    +

    cowboy_metrics_h - Metrics stream handler

    +

    Description

    +

    The module cowboy_metrics_h gathers metrics and other information about a stream. It then calls the configured callback with this data.

    +

    Types

    +

    metrics()

    +
    +
    metrics() :: #{
+    %% The identifier for this listener.
+    ref := ranch:ref(),
+
+    %% The pid for this connection.
+    pid := pid(),
+
+    %% The streamid also indicates the total number of requests on
+    %% this connection (StreamID div 2 + 1).
+    streamid := cowboy_stream:streamid(),
+
+    %% The terminate reason is always useful.
+    reason := cowboy_stream:reason(),
+
+    %% A filtered Req object or a partial Req object
+    %% depending on how far the request got to.
+    req => cowboy_req:req(),
+    partial_req => cowboy_stream:partial_req(),
+
+    %% Response status.
+    resp_status := cowboy:http_status(),
+
+    %% Filtered response headers.
+    resp_headers := cowboy:http_headers(),
+
+    %% Start/end of the processing of the request.
+    %%
+    %% This represents the time from this stream handler's init
+    %% to terminate.
+    req_start => integer(),
+    req_end => integer(),
+
+    %% Start/end of the receiving of the request body.
+    %% Begins when the first packet has been received.
+    req_body_start => integer(),
+    req_body_end => integer(),
+
+    %% Start/end of the sending of the response.
+    %% Begins when we send the headers and ends on the final
+    %% packet of the response body. If everything is sent at
+    %% once these values are identical.
+    resp_start => integer(),
+    resp_end => integer(),
+
+    %% For early errors all we get is the time we received it.
+    early_error_time => integer(),
+
+    %% Start/end of spawned processes. This is where most of
+    %% the user code lies, excluding stream handlers. On a
+    %% default Cowboy configuration there should be only one
+    %% process: the request process.
+    procs => ProcMetrics,
+
+    %% Informational responses sent before the final response.
+    informational => [InformationalMetrics],
+
+    %% Length of the request and response bodies. This does
+    %% not include the framing.
+    req_body_length => non_neg_integer(),
+    resp_body_length => non_neg_integer(),
+
+    %% Additional metadata set by the user.
+    user_data => map()
+}
+
+InformationalMetrics :: #{
+    %% Informational response status.
+    status := cowboy:http_status(),
+
+    %% Headers sent with the informational response.
+    headers := cowboy:http_headers(),
+
+    %% Time when the informational response was sent.
+    time := integer()
+}
+
+ProcMetrics :: #{pid() => #{
+    %% Time at which the process spawned.
+    spawn := integer(),
+
+    %% Time at which the process exited.
+    exit => integer(),
+
+    %% Reason for the process exit.
+    reason => any()
+}}
    +
    +

    Metrics given to the callback function.

    +

    Depending on the life of the stream the metrics may include more or less information.

    +

    The set_options command can be used to add additional metadata in the user_data metric. This can be used for example to add the handler module which was selected by the router. The option to be set is metrics_user_data. It takes a map which will be merged in the existing user_data map.

    +

    Options

    +
    +
    opts() :: #{
+    metrics_callback => fun((metrics()) -> any()),
+    metrics_req_filter => fun((cowboy_req:req()) -> map()),
+    metrics_resp_headers_filter => fun((cowboy:http_headers()) -> cowboy:http_headers())
+}
    +
    +

    Configuration for the metrics stream handler.

    +
    metrics_callback - mandatory
    +

    The function that will be called upon completion of the stream. It only takes a single argument, the metrics().

    +
    +
    metrics_req_filter
    +

    A function applied to the Req to compact it and only keep required information. By default no filtering is done.

    +
    +
    metrics_resp_headers_filter
    +

    A function applied to the response headers to filter them and only keep required information. By default no filtering is done.

    +
    +
    +

    Events

    +

    The metrics stream handler does not produce any event.

    +

    Changelog

    +
    • 2.7: Module introduced. +
      • +
    +

    See also

    +

    cowboy(7), cowboy_stream(3), cowboy_compress_h(3), cowboy_stream_h(3), cowboy_tracer_h(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.9/manual/cowboy_middleware/index.html new file mode 100644 index 00000000..d90b6def --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_middleware/index.html @@ -0,0 +1,209 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.binding/index.html new file mode 100644 index 00000000..f492981b --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.binding/index.html @@ -0,0 +1,212 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.bindings/index.html new file mode 100644 index 00000000..cd6773a8 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.bindings/index.html @@ -0,0 +1,192 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.body_length/index.html new file mode 100644 index 00000000..e33f40ee --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.body_length/index.html @@ -0,0 +1,193 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.cast/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.cast/index.html new file mode 100644 index 00000000..36c8ff9d --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.cast/index.html @@ -0,0 +1,204 @@ + + + + + + + + + + Nine Nines: cowboy_req:cast(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowboy_req:cast(3)

    + +

    Name

    +

    cowboy_req:cast - Cast a stream handler event

    +

    Description

    +
    +
    cast(Event :: any(), Req :: cowboy_req:req()) -> ok
    +
    +

    Cast a stream handler event.

    +

    The event will be passed to stream handlers through the info/3 callback.

    +

    Arguments

    +
    Event
    +

    The event to be sent to stream handlers.

    +
    +
    Req
    +

    The Req object.

    +
    +
    +

    Return value

    +

    The atom ok is always returned. It can be safely ignored.

    +

    Changelog

    +
    • 2.7: Function introduced. +
      • +
    +

    Examples

    +
    Increase the HTTP/1.1 idle timeout
    +
    +
    cowboy_req:cast({set_options, #{
+    idle_timeout => 3600000
+}}, Req).
    +
    +
    Add user data to metrics
    +
    cowboy_req:cast({set_options, #{
+    metrics_user_data => #{handler => ?MODULE}
+}}, Req).
    +
    Enable compression buffering
    +
    cowboy_req:cast({set_options, #{
+    compress_buffering => true
+}}, Req).
    +

    See also

    +

    cowboy_req(3), cowboy_stream(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.cert/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.cert/index.html new file mode 100644 index 00000000..ea9e5c93 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.cert/index.html @@ -0,0 +1,212 @@ + + + + + + + + + + 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},
+    {certfile, "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.1: 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.delete_resp_header/index.html new file mode 100644 index 00000000..2ecd3985 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.delete_resp_header/index.html @@ -0,0 +1,197 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.filter_cookies/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.filter_cookies/index.html new file mode 100644 index 00000000..4405fa05 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.filter_cookies/index.html @@ -0,0 +1,200 @@ + + + + + + + + + + Nine Nines: cowboy_req:filter_cookies(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowboy_req:filter_cookies(3)

    + +

    Name

    +

    cowboy_req:filter_cookies - Filter cookie headers

    +

    Description

    +
    +
    filter_cookies(Names, Req) -> Req
+
+Names :: [atom() | binary()]
    +
    +

    Filter cookie headers.

    +

    This function is meant to be used before attempting to parse or match cookies in order to remove cookies that are not relevant and are potentially malformed. Because Cowboy by default crashes on malformed cookies, this function allows processing requests that would otherwise result in a 400 error.

    +

    Malformed cookies are unfortunately fairly common due to the string-based interface provided by browsers and this function provides a middle ground between Cowboy's strict behavior and chaotic real world use cases.

    +

    Note that there may still be crashes even after filtering cookies because this function does not correct malformed values. Cookies that have malformed values should probably be unset in an error response or in a redirect.

    +

    This function can be called even if there are no cookies in the request.

    +

    Arguments

    +
    Names
    +

    The cookies that should be kept.

    +
    +
    Req
    +

    The Req object.

    +
    +
    +

    Return value

    +

    The Req object is returned with its cookie header value filtered.

    +

    Changelog

    +
    • 2.7: Function introduced. +
      • +
    +

    Examples

    +
    Filter then parse cookies
    +
    +
    Req = cowboy_req:filter_cookies([session_id, token], Req0),
+Cookies = cowboy_req:parse_cookies(Req).
    +
    +

    See also

    +

    cowboy_req(3), cowboy_req:parse_cookies(3), cowboy_req:match_cookies(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.has_body/index.html new file mode 100644 index 00000000..e37528ac --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.has_body/index.html @@ -0,0 +1,190 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.has_resp_body/index.html new file mode 100644 index 00000000..f8636d87 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.has_resp_body/index.html @@ -0,0 +1,195 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.has_resp_header/index.html new file mode 100644 index 00000000..16b57153 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.has_resp_header/index.html @@ -0,0 +1,198 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.header/index.html new file mode 100644 index 00000000..ac1d8e16 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.header/index.html @@ -0,0 +1,219 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.headers/index.html new file mode 100644 index 00000000..6538178d --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.headers/index.html @@ -0,0 +1,199 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.host/index.html new file mode 100644 index 00000000..862e5048 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.host/index.html @@ -0,0 +1,199 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.host_info/index.html new file mode 100644 index 00000000..6085f257 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.host_info/index.html @@ -0,0 +1,193 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.inform/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.inform/index.html new file mode 100644 index 00000000..a49f03a4 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.inform/index.html @@ -0,0 +1,217 @@ + + + + + + + + + + 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.1: 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, "
+        "</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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.match_cookies/index.html new file mode 100644 index 00000000..326a1878 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.match_cookies/index.html @@ -0,0 +1,220 @@ + + + + + + + + + + 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.

    +

    This function will crash on invalid cookie data. How to handle this is explained in details in the manual page for cowboy_req:parse_cookies(3).

    +

    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:filter_cookies(3), cowboy_req:parse_cookies(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.match_qs/index.html new file mode 100644 index 00000000..7c9c0bfd --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.match_qs/index.html @@ -0,0 +1,219 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.method/index.html new file mode 100644 index 00000000..b0579b59 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.method/index.html @@ -0,0 +1,210 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.parse_cookies/index.html new file mode 100644 index 00000000..f5334c49 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.parse_cookies/index.html @@ -0,0 +1,218 @@ + + + + + + + + + + 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 or empty, [] is returned.

    +

    This function will crash on invalid cookie data. Because invalid cookies are fairly common when dealing with browsers (because of the string interface that the Javascript API provides), it is recommended to filter the cookie header value before attempting to parse it. This can be accomplished by calling the function cowboy_req:filter_cookies(3) first. This does not guarantee that parsing succeeds. If it still fails it is recommended to send an error response or redirect with instructions to delete the relevant cookies:

    +
    Recover from cookie parsing errors
    +
    +
    Req1 = cowboy_req:filter_cookies([session_id, token], Req0),
+try cowboy_req:parse_cookies(Req1) of
+    Cookies ->
+        do_something(Req1, Cookies)
+catch _:_ ->
+    %% We can't parse the cookies we need, unset them
+    %% otherwise the browser will continue sending them.
+    Req2 = cowboy_req:set_resp_cookie(<<"session_id">>,
+        <<>>, Req1, #{max_age => 0}),
+    Req = cowboy_req:set_resp_cookie(<<"token">>,
+        <<>>, Req2, #{max_age => 0}),
+    cowboy_req:reply(500, Req)
+end.
    +
    +

    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:filter_cookies(3), cowboy_req:match_cookies(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.parse_header/index.html new file mode 100644 index 00000000..c51a9590 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.parse_header/index.html @@ -0,0 +1,426 @@ + + + + + + + + + + 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
    +
    +
    access-control-request-headers
    +
    +
    parse_header(<<"access-control-request-headers">>, Req)
+    -> [Header]
+
+Header :: binary()   %% case insensitive
    +
    +
    access-control-request-method
    +
    +
    parse_header(<<"access-control-request-method">>)
+    -> Method
+
+Method :: binary()   %% case sensitive
    +
    +
    authorization and proxy-authorization
    +
    +
    parse_header(<<"authorization">>, Req)
+    -> {basic, Username :: binary(), Password :: binary()}
+     | {bearer, Token :: binary()}
+     | {digest, [{Key :: binary(), Value :: binary()}]}
    +
    + +
    content-encoding and content-language
    +
    +
    parse_header(Name, Req) -> [Value]
+
+Name  :: <<"content-encoding">>
+       | <<"content-language">>
+Value :: binary()                 %% case insensitive
    +
    +
    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()
    +
    +
    max-forwards
    +
    +
    parse_header(<<"max-forwards">>, Req) -> non_neg_integer()
    +
    +
    origin
    +
    +
    parse_header(<<"origin">>, Req)
+    -> [{Scheme, Host, Port} | GUID]
+
+Scheme :: <<"http">> | <<"https">>
+Host   :: binary()                   %% case insensitive
+Port   :: 0..65535
+GUID   :: reference()
    +
    +

    Cowboy generates a reference in place of a GUID when the URI uses an unsupported uri-scheme or is not an absolute URI.

    +
    +
    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
    +
    +
    trailer
    +
    +
    parse_header(Name, Req) -> [Header]
+
+Header :: binary()   %% case insensitive
    +
    +
    x-forwarded-for
    +
    +
    parse_header(<<"x-forwarded-for">>, Req) -> [Token]
+
+Token :: binary()                   %% case sensitive
    +
    +

    This function will crash when attempting to parse a header Cowboy does not currently understand.

    +

    Changelog

    +
    • 2.8: The function now parses access-control-request-headers, access-control-request-method, content-encoding, content-language, max-forwards, origin, proxy-authorization and trailer. +
      • +
    • 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.parse_qs/index.html new file mode 100644 index 00000000..a8bca2aa --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.parse_qs/index.html @@ -0,0 +1,207 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.path/index.html new file mode 100644 index 00000000..4ce6ce8b --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.path/index.html @@ -0,0 +1,199 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.path_info/index.html new file mode 100644 index 00000000..bbf77a3d --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.path_info/index.html @@ -0,0 +1,193 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.peer/index.html new file mode 100644 index 00000000..d43da9cb --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.peer/index.html @@ -0,0 +1,203 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.port/index.html new file mode 100644 index 00000000..6127d164 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.port/index.html @@ -0,0 +1,200 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.push/index.html new file mode 100644 index 00000000..57a42455 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.push/index.html @@ -0,0 +1,226 @@ + + + + + + + + + + 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.

    +

    Note that clients may cancel the push or ignore it entirely. For example browsers may ignore the resource when the connection is not considered secure.

    +

    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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.qs/index.html new file mode 100644 index 00000000..3d2957fd --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.qs/index.html @@ -0,0 +1,199 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.read_and_match_urlencoded_body/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.read_and_match_urlencoded_body/index.html new file mode 100644 index 00000000..c9fa0c0d --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.read_and_match_urlencoded_body/index.html @@ -0,0 +1,250 @@ + + + + + + + + + + Nine Nines: cowboy_req:read_and_match_urlencoded_body(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowboy_req:read_and_match_urlencoded_body(3)

    + +

    Name

    +

    cowboy_req:read_and_match_urlencoded_body - Read, parse and match a urlencoded request body against constraints

    +

    Description

    +
    +
    read_and_match_urlencoded_body(Fields, Req)
+    -> read_and_match_urlencoded_body(Fields, Req, #{})
+
+read_and_match_urlencoded_body(Fields, Req, Opts)
+    -> {ok, Body, Req}
+
+Fields :: cowboy:fields()
+Req    :: cowboy_req:req()
+Opts   :: cowboy_req:read_body_opts()
+Body   :: #{atom() => any()}
    +
    +

    Read, parse and match a urlencoded request body against constraints.

    +

    This function reads the request body and parses it as application/x-www-form-urlencoded. It then applies the given field constraints to the urlencoded data and returns the result as a map.

    +

    The urlencoded media type is used by Web browsers when submitting HTML forms using the POST method.

    +

    Cowboy will only return the 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.

    +

    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

    +
    Fields
    +

    Fields to retrieve from the urlencoded body.

    +

    See cowboy(3) for a complete description.

    +
    +
    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.

    +

    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.

    +

    The Req object returned in the tuple must be used from 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.5: Function introduced. +
      • +
    +

    Examples

    +
    Match fields
    +
    +
    %% ID and Lang are binaries.
+#{id := ID, lang := Lang}
+    = cowboy_req:read_and_match_urlencoded_body(
+        [id, lang], Req).
    +
    +
    Match fields and apply constraints
    +
    +
    %% ID is an integer and Lang a non-empty binary.
+#{id := ID, lang := Lang}
+    = cowboy_req:read_and_match_urlencoded_body(
+        [{id, int}, {lang, nonempty}], Req).
    +
    +
    Match fields with default values
    +
    +
    #{lang := Lang}
+    = cowboy_req:read_and_match_urlencoded_body(
+        [{lang, [], <<"en-US">>}], Req).
    +
    +
    Allow large urlencoded bodies
    +
    +
    {ok, Body, Req} = cowboy_req:read_and_match_urlencoded_body(
+    Fields, 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(3), cowboy_req:read_part_body(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.read_body/index.html new file mode 100644 index 00000000..62bbd0f7 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.read_body/index.html @@ -0,0 +1,224 @@ + + + + + + + + + + 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 from 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_and_match_urlencoded_body(3), cowboy_req:read_part(3), cowboy_req:read_part_body(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.read_part/index.html new file mode 100644 index 00000000..7f20075a --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.read_part/index.html @@ -0,0 +1,246 @@ + + + + + + + + + + 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 from 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_and_match_urlencoded_body(3), cowboy_req:read_part_body(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.read_part_body/index.html new file mode 100644 index 00000000..9e4ea25f --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.read_part_body/index.html @@ -0,0 +1,222 @@ + + + + + + + + + + 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 from 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_and_match_urlencoded_body(3), cowboy_req:read_part(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.read_urlencoded_body/index.html new file mode 100644 index 00000000..0a7adffa --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.read_urlencoded_body/index.html @@ -0,0 +1,216 @@ + + + + + + + + + + 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 from 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_and_match_urlencoded_body(3), cowboy_req:read_part(3), cowboy_req:read_part_body(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.reply/index.html new file mode 100644 index 00000000..5e912a23 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.reply/index.html @@ -0,0 +1,238 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.resp_header/index.html new file mode 100644 index 00000000..f5ed1d15 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.resp_header/index.html @@ -0,0 +1,210 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.resp_headers/index.html new file mode 100644 index 00000000..5a247c4a --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.resp_headers/index.html @@ -0,0 +1,190 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.scheme/index.html new file mode 100644 index 00000000..7b0e0481 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.scheme/index.html @@ -0,0 +1,204 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_body/index.html new file mode 100644 index 00000000..877274ee --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_body/index.html @@ -0,0 +1,231 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_cookie/index.html new file mode 100644 index 00000000..0e7751ac --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_cookie/index.html @@ -0,0 +1,256 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_header/index.html new file mode 100644 index 00000000..dcce952d --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_header/index.html @@ -0,0 +1,212 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_headers/index.html new file mode 100644 index 00000000..3fbe9be4 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_headers/index.html @@ -0,0 +1,203 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.sock/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.sock/index.html new file mode 100644 index 00000000..dfe3ae65 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.sock/index.html @@ -0,0 +1,199 @@ + + + + + + + + + + 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.1: 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.stream_body/index.html new file mode 100644 index 00000000..eaa80555 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.stream_body/index.html @@ -0,0 +1,210 @@ + + + + + + + + + + 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  :: cowboy_req:resp_body()
+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) or be a call to the cowboy_req:stream_trailers(3) function.

    +

    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.6: The Data argument can now be a sendfile tuple. +
      • +
    • 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_req:stream_events(3), cowboy_req:stream_trailers(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.stream_events/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.stream_events/index.html new file mode 100644 index 00000000..f6555378 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.stream_events/index.html @@ -0,0 +1,224 @@ + + + + + + + + + + Nine Nines: cowboy_req:stream_events(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowboy_req:stream_events(3)

    + +

    Name

    +

    cowboy_req:stream_events - Stream events

    +

    Description

    +
    +
    stream_events(Events, IsFin, Req :: cowboy_req:req()) -> ok
+
+Events :: Event | [Event]
+IsFin  :: fin | nofin
+
+Event  :: #{
+    comment => iodata(),
+    data    => iodata(),
+    event   => iodata() | atom(),
+    id      => iodata(),
+    retry   => non_neg_integer()
+}
    +
    +

    Stream events.

    +

    This function should only be used for text/event-stream responses when using server-sent events. Cowboy will automatically encode the given events to their text representation.

    +

    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) or be a call to the cowboy_req:stream_trailers(3) function.

    +

    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

    +
    Events
    +

    Events to be sent. All fields are optional.

    +
    +
    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.5: Function introduced. +
      • +
    +

    Examples

    +
    Stream events
    +
    +
    Req = cowboy_req:stream_reply(200, #{
+    <<"content-type">> => <<"text/event-stream">>
+}, Req0),
+cowboy_req:stream_events(#{
+    id => <<"comment-123">>,
+    event => <<"add_comment">>,
+    data => <<"Hello,\n\nI noticed something wrong in ...">>
+}, nofin, Req),
+timer:sleep(1000),
+cowboy_req:stream_events(#{
+    event => <<"debug">>,
+    data => io_lib:format("An error occurred: ~p~n", [Error])
+}, fin, Req).
    +
    +

    See also

    +

    cowboy_req(3), cowboy_req:stream_reply(3), cowboy_req:stream_body(3), cowboy_req:stream_trailers(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.stream_reply/index.html new file mode 100644 index 00000000..6d65d32f --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.stream_reply/index.html @@ -0,0 +1,227 @@ + + + + + + + + + + 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 and optionally cowboy_req:stream_trailers(3) to send response trailer field values.

    +

    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, if the content-length response header is set the body will be sent without chunked 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:stream_events(3), cowboy_req:stream_trailers(3), cowboy_req:push(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.stream_trailers/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.stream_trailers/index.html new file mode 100644 index 00000000..241a5d7e --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.stream_trailers/index.html @@ -0,0 +1,207 @@ + + + + + + + + + + Nine Nines: cowboy_req:stream_trailers(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowboy_req:stream_trailers(3)

    + +

    Name

    +

    cowboy_req:stream_trailers - Send the response trailers

    +

    Description

    +
    +
    stream_trailers(Trailers, Req :: cowboy_req:req()) -> ok
+
+Trailers :: cowboy:http_headers()
    +
    +

    Send the response trailers and terminate the stream.

    +

    This function can only be called once, after initiating a response using cowboy_req:stream_reply(3) and sending zero or more body chunks using cowboy_req:stream_body(3) with the nofin argument set. The function stream_trailers/2 implies fin and automatically terminate the response.

    +

    You must list all field names sent in trailers in the trailer header, otherwise they might be dropped by intermediaries or clients.

    +

    Arguments

    +
    Trailers
    +

    Trailer field values to be sent.

    +
    +
    Req
    +

    The Req object.

    +
    +
    +

    Return value

    +

    The atom ok is always returned. It can be safely ignored.

    +

    Changelog

    +
    • 2.2: Function introduced. +
      • +
    +

    Examples

    +
    Stream a response body with trailers
    +
    +
    Req = cowboy_req:stream_reply(200, #{
+    <<"content-type">> => <<"text/plain">>,
+    <<"trailer">> => <<"expires, content-md5">>
+}, Req0),
+cowboy_req:stream_body(<<"Hello\n">>, nofin, Req),
+timer:sleep(1000),
+cowboy_req:stream_body(<<"World!\n">>, nofin, Req).
+cowboy_req:stream_trailers(#{
+    <<"expires">> => <<"Sun, 10 Dec 2017 19:13:47 GMT">>,
+    <<"content-md5">> => <<"fbf68a8e34b2ded53bba54e68794b4fe">>
+}, Req).
    +
    +

    See also

    +

    cowboy_req(3), cowboy_req:stream_reply(3), cowboy_req:stream_body(3), cowboy_req:stream_events(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.uri/index.html new file mode 100644 index 00000000..5e688dc5 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.uri/index.html @@ -0,0 +1,258 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.9/manual/cowboy_req.version/index.html new file mode 100644 index 00000000..f08c7a4b --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req.version/index.html @@ -0,0 +1,199 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_req/index.html b/docs/en/cowboy/2.9/manual/cowboy_req/index.html new file mode 100644 index 00000000..f599d784 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_req/index.html @@ -0,0 +1,380 @@ + + + + + + + + + + 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:

    + + + + + + + + + + + + + + + + + + + + +
    TypeName patternReturn type
    accessno verb, parse_*, match_*Value
    questionhas_*boolean()
    modificationset_*Req
    actionany other verbok | {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:

    + +

    Stream handlers:

    + +

    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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_rest/index.html b/docs/en/cowboy/2.9/manual/cowboy_rest/index.html new file mode 100644 index 00000000..f7ef8e98 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_rest/index.html @@ -0,0 +1,664 @@ + + + + + + + + + + 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.

    +
    +
    +

    REST callbacks

    +

    AcceptCallback

    +
    +
    AcceptCallback(Req, State) -> {Result, Req, State}
+
+Result  :: true
+         | {created, URI :: iodata()}
+         | {see_other, 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 {created, URI} or {see_other, URI} with URI the new location.

    +

    The see_other tuple will redirect the client to the new location automatically.

    +

    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
+}
    +
    +

    Note that Cowboy will only append the charset to the content-type header of the response if the media type is text.

    +

    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.

    +

    The special value '*' can be used to accept any media type.

    + + + +

    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.

    +

    When a charset is given in the media type parameters in the accept header, Cowboy will do some additional checks to confirm that it can use this charset. When the wildcard is used then Cowboy will immediately call charsets_provided to confirm the charset is acceptable. If the callback is undefined Cowboy assumes any charset is acceptable. When the wildcard is not used and the charset given in the accept header matches one of the configured media types Cowboy will use that charset and skip the charsets_provided step entirely.

    +

    Cowboy will add the negotiated media_type to the Req object after this step completes:

    +
    +
    req() :: #{
+    media_type => ParsedMime
+}
    +
    + +

    Cowboy may also add the negotiated charset to the Req object after this step completes:

    +
    +
    req() :: #{
+    charset => binary()  %% lowercase; case insensitive
+}
    +
    +

    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.

    +

    Note that when replying manually in this callback you should either call cowboy_req:reply/4 or remove the response body that Cowboy sets to avoid surprises.

    +

    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.

    + +

    rate_limited

    +
    +
    rate_limited(Req, State) -> {Result, Req, State}
+
+Result     :: false | {true, RetryAfter}
+RetryAfter :: non_neg_integer() | calendar:datetime()
+Default  - false
    +
    +

    Return whether the user is rate limited.

    +

    This function can be used to temporarily restrict access to a resource when the user has issued too many requests.

    +

    When the resource is rate limited the RetryAfter value will be sent in the retry-after header for the 429 Too Many Requests response. It indicates when the resource will become available again and can be specified as a number of seconds in the future or a specific date/time.

    +

    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. It's also useful to note that some standard headers also do not need to be listed here, like the authorization header.

    +

    Changelog

    +
    • 2.9: An AcceptCallback can now return {created, URI} or {see_other, URI}. The return value {true, URI} is deprecated. +
      • +
    • 2.7: The media type wildcard in content_types_accepted is now documented. +
      • +
    • 2.6: The callback rate_limited was added. +
      • +
    • 2.1: The switch_handler return value was added. +
      • +
    • 1.0: Behavior introduced. +
      • +
    +

    See also

    +

    cowboy(7), cowboy_handler(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.9/manual/cowboy_router.compile/index.html new file mode 100644 index 00000000..d3a616fd --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_router.compile/index.html @@ -0,0 +1,200 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_router/index.html b/docs/en/cowboy/2.9/manual/cowboy_router/index.html new file mode 100644 index 00000000..0a168a56 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_router/index.html @@ -0,0 +1,217 @@ + + + + + + + + + + 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. The environment can contain the rules directly or a tuple {persistent_term, Key}, in which case Cowboy will call persistent_term:get(Key) to retrieve the dispatch rules.

    +

    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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_static/index.html b/docs/en/cowboy/2.9/manual/cowboy_static/index.html new file mode 100644 index 00000000..3155d1cf --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_static/index.html @@ -0,0 +1,275 @@ + + + + + + + + + + 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      :: [Charset | Etag | Mimetypes]
+
+Charset    :: {charset, module(), function()}
+            | {charset, binary()}
+
+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 not send a charset with the response. You can provide a specific charset that will be used for all files using the text media type, or provide a module and function that will be called when needed:

    +
    +
    detect_charset(Path :: binary()) -> Charset :: binary()
    +
    +

    A charset must always be returned even if it doesn't make sense considering the media type of the file. A good default is <<"utf-8">>.

    +

    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

    +
    • 2.6: The charset extra option was added. +
      • +
    • 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_stream/index.html b/docs/en/cowboy/2.9/manual/cowboy_stream/index.html new file mode 100644 index 00000000..9d7d6ead --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_stream/index.html @@ -0,0 +1,435 @@ + + + + + + + + + + Nine Nines: cowboy_stream(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowboy_stream(3)

    + +

    Name

    +

    cowboy_stream - 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 discard 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:

    +

    inform

    +

    Send an informational response to the client.

    +
    +
    {inform, cowboy:http_status(), cowboy:http_headers()}
    +
    +

    Any number of informational responses may be sent, but only until the final response is sent.

    +

    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.

    +

    Note that in Cowboy it is the cowboy_req module that sets the date and server headers. When using the command directly those headers will not be added.

    +

    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 or a trailer command is returned.

    +

    Note that in Cowboy it is the cowboy_req module that sets the date and server headers. When using the command directly those headers will not be added.

    +

    data

    +

    Send data to the client.

    +
    +
    {data, fin(), cowboy_req:resp_body()}
    +
    +

    trailers

    +

    Send response trailers to the client.

    +
    +
    {trailers, cowboy:http_headers()}
    +
    +

    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.

    +

    Note that the 101 informational response will not be sent after a final response.

    +

    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.

    +

    log

    +

    Log a message.

    +
    +
    {log, logger:level(), io:format(), list()}
    +
    +

    This command can be used to log a message using the configured logger module.

    +

    set_options

    +

    Set protocol options.

    +
    +
    {set_options, map()}
    +
    +

    This can also be used to override stream handler options. For example this is supported by cowboy_compress_h(3).

    +

    Not all options can be overriden. Please consult the relevant option's documentation for details.

    +

    Predefined events

    +

    Cowboy will forward all messages sent to the stream to the info/3 callback. To send a message to a stream, the function cowboy_req:cast(3) can be used.

    +

    Cowboy will also forward the exit signals for the processes that the stream spawned.

    +

    When Cowboy needs to send a response it will trigger an event that looks exactly like the corresponding command. This event must be returned to be processed by Cowboy (which is done automatically when using cowboy_stream_h(3)).

    +

    Cowboy may trigger the following events on its own, regardless of the stream handlers configured: inform (to send a 101 informational response when upgrading to HTTP/2 or Websocket), response, headers, data and switch_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() | {exit, any()}, 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.7: The log and set_options commands were introduced. +
      • +
    • 2.6: The data command can now contain a sendfile tuple. +
      • +
    • 2.6: The {stop, {exit, any()}, HumanReadable} terminate reason was added. +
      • +
    • 2.2: The trailers command was introduced. +
      • +
    • 2.0: Module introduced. +
      • +
    +

    See also

    +

    cowboy(7), cowboy_http(3), cowboy_http2(3), cowboy_req:cast(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_stream_h/index.html b/docs/en/cowboy/2.9/manual/cowboy_stream_h/index.html new file mode 100644 index 00000000..44663bd9 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_stream_h/index.html @@ -0,0 +1,199 @@ + + + + + + + + + + Nine Nines: cowboy_stream_h(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowboy_stream_h(3)

    + +

    Name

    +

    cowboy_stream_h - Default stream handler

    +

    Description

    +

    The module cowboy_stream_h is Cowboy's default stream handler and defines much of its behavior. It is responsible for managing the request process, sending it the request body and translating its messages into commands that Cowboy understands.

    +

    Options

    +
    +
    opts() :: #{
+    env              => cowboy_middleware:env(),
+    middlewares      => [module()],
+    shutdown_timeout => timeout()
+}
    +
    +

    Configuration for the default stream handler.

    +

    The default value is given next to the option name:

    +
    env (#{})
    +

    Middleware environment.

    +
    +
    middlewares ([cowboy_router, cowboy_handler])
    +

    Middlewares to run for every request.

    +
    +
    shutdown_timeout (5000)
    +

    Time in ms Cowboy will wait for child processes to shut down before killing them.

    +
    +
    +

    Events

    +

    The default stream handler spawns the request process and receives its exit signal when it terminates. It will stop the stream once its receives it.

    + + +

    In addition it returns a command for any event message looking like one of the following commands: inform, response, headers, data, trailers, push, switch_protocol. This is what allows the request process to send a response.

    + +

    Because this stream handler converts events from the request process into commands, other stream handlers may not work properly if they are executed

    +

    Changelog

    +
    • 2.0: Module introduced. +
      • +
    +

    See also

    +

    cowboy(7), cowboy_stream(3), cowboy_compress_h(3), cowboy_metrics_h(3), cowboy_tracer_h(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_tracer_h/index.html b/docs/en/cowboy/2.9/manual/cowboy_tracer_h/index.html new file mode 100644 index 00000000..db6768e2 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_tracer_h/index.html @@ -0,0 +1,212 @@ + + + + + + + + + + Nine Nines: cowboy_tracer_h(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowboy_tracer_h(3)

    + +

    Name

    +

    cowboy_tracer_h - Tracer stream handler

    +

    Description

    +

    The module cowboy_tracer_h can be used to conditionally trace streams based on information found in the request. Trace messages are given to the configured callback.

    +

    Options

    +
    +
    opts() :: #{
+    tracer_callback    => Callback,
+    tracer_flags       => [atom()],
+    tracer_match_specs => [MatchSpec]
+}
+
+Callback :: fun((init | terminate | tuple(), State) -> State)
+
+MatchSpec :: MatchPredicate
+           | {method, binary()}
+           | {host, binary()}
+           | {path, binary()}
+           | {path_start, binary()}
+           | {header, binary()}
+           | {header, binary(), binary()}
+           | {peer_ip, inet:ip_address()}
+
+MatchPredicate :: fun((cowboy_stream:streamid(),
+                       cowboy_req:req(),
+                       cowboy:opts()) -> boolean())
+}
    +
    +

    Configuration for the tracer stream handler.

    +

    This module will not set trace patterns. Those must be set by the user directly, either from the callback's init or, preferably, in advance.

    +
    tracer_callback
    +

    The function that will be called for each trace events. It will also be called before any trace event with an argument init, and when the stream is terminated with an argument terminate.

    +

    This option is required for tracing to be enabled. The tracer stream handler does nothing otherwise.

    +
    +
    tracer_flags
    +

    Trace flags to enable. See the documentation of erlang:trace/3 for details. Note that all trace flags are allowed except for the tracer flag.

    +
    +
    tracer_match_specs
    +

    A list of match conditions that must all be fulfilled for the stream to be traced. Cowboy will compare these with the information found in the request and only enable tracing if all matches succeed.

    +

    This option is required for tracing to be enabled. The tracer stream handler does nothing otherwise.

    +
    +
    +

    Events

    +

    The tracer stream handler does not produce any event.

    +

    Changelog

    +
    • 2.7: Module introduced. +
      • +
    +

    See also

    +

    cowboy(7), cowboy_stream(3), cowboy_compress_h(3), cowboy_metrics_h(3), cowboy_stream_h(3)

    + + + + + + +
    + +
    + + +

    + Cowboy + 2.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.9/manual/cowboy_websocket/index.html new file mode 100644 index 00000000..c0fcbb6e --- /dev/null +++ b/docs/en/cowboy/2.9/manual/cowboy_websocket/index.html @@ -0,0 +1,360 @@ + + + + + + + + + + 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    :: ping | pong | {text | binary | ping | pong, binary()}
+Info       :: any()
+
+CallResult :: {commands(), State}
+            | {commands(), State, hibernate}
+            | Deprecated
+
+Deprecated :: {ok, State}
+            | {ok, State, hibernate}
+            | {reply, OutFrame | [OutFrame], State}
+            | {reply, OutFrame | [OutFrame], State, hibernate}
+            | {stop, State}
+OutFrame   :: cow_ws:frame()                    %% see types below
+
+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, including close frames to terminate the connection; enable/disable active mode; enable/disable compression for subsequent frames; or change Websocket options.

    +

    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.

    +
    +
    {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

    +

    commands()

    +
    +
    commands() :: [Command]
+
+Command :: {active, boolean()}
+         | {deflate, boolean()}
+         | {set_options, #{idle_timeout => timeout()}}
+         | {shutdown_reason, any()}
+         | Frame :: cow_ws:frame()
    +
    +

    Commands that may be returned from Websocket callbacks.

    +

    The following commands are defined:

    +
    active
    +

    Whether to disable or enable reading from the socket. This can be used to apply flow control to a Websocket connection.

    +
    +
    deflate
    +

    Whether the subsequent frames should be compressed. Has no effect on connections that did not negotiate compression.

    +
    +
    set_options
    +

    Set Websocket options. Currently only the option idle_timeout may be updated from a Websocket handler.

    +
    +
    shutdown_reason
    +

    Change the shutdown reason. The Websocket process will exit with reason normal by default. This command can be used to exit with reason {shutdown, ShutdownReason} under normal conditions. This command has no effect when the Websocket process exits abnormally, for example following a crash in a handler callback.

    +
    +
    Frame
    +

    Send the corresponding Websocket frame.

    +
    +
    +

    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() :: #{
+    active_n       => pos_integer(),
+    compress       => boolean(),
+    deflate_opts   => cow_ws:deflate_opts()
+    idle_timeout   => timeout(),
+    max_frame_size => non_neg_integer() | infinity,
+    req_filter     => fun((cowboy_req:req()) -> map()),
+    validate_utf8  => boolean()
+}
    +
    +

    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:

    +
    active_n (100)
    +

    The number of packets Cowboy will request from the socket at once. This can be used to tweak the performance of the server. Higher values reduce the number of times Cowboy need to request more packets from the port driver at the expense of potentially higher memory being used.

    +

    This option does not apply to Websocket over HTTP/2.

    +
    +
    compress (false)
    +

    Whether to enable the Websocket frame compression extension. Frames will only be compressed for the clients that support this extension.

    +
    +
    deflate_opts (#{})
    +

    Configuration for the permessage-deflate Websocket extension. Allows configuring both the negotiated options and the zlib compression options. The defaults optimize the compression at the expense of some memory and CPU.

    +
    +
    idle_timeout (60000)
    +

    Time in milliseconds that Cowboy will keep the connection open without receiving anything from the client.

    +

    This option can be updated at any time using the set_options command.

    +
    +
    max_frame_size (infinity)
    +

    Maximum frame size in bytes allowed by this Websocket handler. Cowboy will close the connection when a client attempts to send a frame that goes over this limit. For fragmented frames this applies to the size of the reconstituted frame.

    +
    +
    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.

    +
    +
    validate_utf8 (true)
    +

    Whether Cowboy should verify that the payload of text and close frames is valid UTF-8. This is required by the protocol specification but in some cases it may be more interesting to disable it in order to save resources.

    +

    Note that binary frames do not have this UTF-8 requirement and are what should be used under normal circumstances if necessary.

    +
    +
    +

    Changelog

    +
    • 2.8: The active_n option was added. +
      • +
    • 2.7: The commands based interface has been documented. The old interface is now deprecated. +
      • +
    • 2.7: The command shutdown_reason was introduced. +
      • +
    • 2.7: The option validate_utf8 has been added. +
      • +
    • 2.6: Deflate options can now be configured via deflate_opts. +
      • +
    • 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/http_status_codes/index.html b/docs/en/cowboy/2.9/manual/http_status_codes/index.html new file mode 100644 index 00000000..598fa2ee --- /dev/null +++ b/docs/en/cowboy/2.9/manual/http_status_codes/index.html @@ -0,0 +1,244 @@ + + + + + + + + + + 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.9/manual/index.html b/docs/en/cowboy/2.9/manual/index.html new file mode 100644 index 00000000..ae42d1a3 --- /dev/null +++ b/docs/en/cowboy/2.9/manual/index.html @@ -0,0 +1,239 @@ + + + + + + + + + + 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:

    + +

    Stream 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.9 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowlib/2.10/manual/cow_cookie.cookie/index.html b/docs/en/cowlib/2.10/manual/cow_cookie.cookie/index.html index efe5007b..327e5655 100644 --- a/docs/en/cowlib/2.10/manual/cow_cookie.cookie/index.html +++ b/docs/en/cowlib/2.10/manual/cow_cookie.cookie/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.10/manual/cow_cookie.parse_cookie/index.html b/docs/en/cowlib/2.10/manual/cow_cookie.parse_cookie/index.html index 2ae54bd4..a74ae562 100644 --- a/docs/en/cowlib/2.10/manual/cow_cookie.parse_cookie/index.html +++ b/docs/en/cowlib/2.10/manual/cow_cookie.parse_cookie/index.html @@ -130,6 +130,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.10/manual/cow_cookie.parse_set_cookie/index.html b/docs/en/cowlib/2.10/manual/cow_cookie.parse_set_cookie/index.html index 6b567160..6a0eb0cb 100644 --- a/docs/en/cowlib/2.10/manual/cow_cookie.parse_set_cookie/index.html +++ b/docs/en/cowlib/2.10/manual/cow_cookie.parse_set_cookie/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.10/manual/cow_cookie.setcookie/index.html b/docs/en/cowlib/2.10/manual/cow_cookie.setcookie/index.html index f7bae2f8..64446f7e 100644 --- a/docs/en/cowlib/2.10/manual/cow_cookie.setcookie/index.html +++ b/docs/en/cowlib/2.10/manual/cow_cookie.setcookie/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.10/manual/cow_cookie/index.html b/docs/en/cowlib/2.10/manual/cow_cookie/index.html index 8f2674cd..351c5aa4 100644 --- a/docs/en/cowlib/2.10/manual/cow_cookie/index.html +++ b/docs/en/cowlib/2.10/manual/cow_cookie/index.html @@ -172,6 +172,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.10/manual/cowlib_app/index.html b/docs/en/cowlib/2.10/manual/cowlib_app/index.html index e5046781..d36ae646 100644 --- a/docs/en/cowlib/2.10/manual/cowlib_app/index.html +++ b/docs/en/cowlib/2.10/manual/cowlib_app/index.html @@ -119,6 +119,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.10/manual/index.html b/docs/en/cowlib/2.10/manual/index.html index 595b7d44..6b73cbd2 100644 --- a/docs/en/cowlib/2.10/manual/index.html +++ b/docs/en/cowlib/2.10/manual/index.html @@ -119,6 +119,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.11/manual/cow_cookie.cookie/index.html b/docs/en/cowlib/2.11/manual/cow_cookie.cookie/index.html new file mode 100644 index 00000000..a1cacbad --- /dev/null +++ b/docs/en/cowlib/2.11/manual/cow_cookie.cookie/index.html @@ -0,0 +1,186 @@ + + + + + + + + + + Nine Nines: cow_cookie:cookie(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cow_cookie:cookie(3)

    + +

    Name

    +

    cow_cookie:cookie - Generate a cookie header

    +

    Description

    +
    +
    cookie(Cookies) -> iolist()
+
+Cookies :: [{Name :: iodata(), Value :: iodata()}]
    +
    +

    Generate a cookie header.

    +

    Arguments

    +
    Cookies
    +

    A list of pairs of cookie name and value.

    +
    +
    +

    Return value

    +

    An iolist with the generated cookie header value.

    +

    Changelog

    +
    • 2.9: Function introduced. +
      • +
    +

    Examples

    +
    Generate a cookie header
    +
    +
    Cookie = cow_cookie:cookie([{<<"sessionid">>, ID}]).
    +
    +

    See also

    +

    cow_cookie(3), cow_cookie:parse_cookie(3), cow_cookie:parse_set_cookie(3), cow_cookie:setcookie(3)

    + + + + + + +
    + +
    + + +

    + Cowlib + 2.11 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowlib/2.11/manual/cow_cookie.parse_cookie/index.html b/docs/en/cowlib/2.11/manual/cow_cookie.parse_cookie/index.html new file mode 100644 index 00000000..638401a5 --- /dev/null +++ b/docs/en/cowlib/2.11/manual/cow_cookie.parse_cookie/index.html @@ -0,0 +1,188 @@ + + + + + + + + + + Nine Nines: cow_cookie:parse_cookie(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cow_cookie:parse_cookie(3)

    + +

    Name

    +

    cow_cookie:parse_cookie - Parse a cookie header

    +

    Description

    +
    +
    parse_cookie(Cookie :: binary())
+    -> [{binary(), binary()}]
    +
    +

    Parse a cookie header.

    +

    Arguments

    +
    Cookie
    +

    The cookie header value.

    +
    +
    +

    Return value

    +

    A list of cookie name/value pairs is returned on success.

    +

    An exception is thrown in the event of a parse error.

    +

    Changelog

    +
    • 2.9: Fixes to the parser may lead to potential incompatibilities. A cookie name starting with $ is no longer ignored. A cookie without a = will be parsed as the value of the cookie named <<>> (empty name). +
      • +
    • 1.0: Function introduced. +
      • +
    +

    Examples

    +
    Parse a cookie header
    +
    +
    Cookies = cow_cookie:parse_cookie(CookieHd).
    +
    +

    See also

    +

    cow_cookie(3), cow_cookie:parse_set_cookie(3), cow_cookie:cookie(3), cow_cookie:setcookie(3)

    + + + + + + +
    + +
    + + +

    + Cowlib + 2.11 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowlib/2.11/manual/cow_cookie.parse_set_cookie/index.html b/docs/en/cowlib/2.11/manual/cow_cookie.parse_set_cookie/index.html new file mode 100644 index 00000000..6bc4ff21 --- /dev/null +++ b/docs/en/cowlib/2.11/manual/cow_cookie.parse_set_cookie/index.html @@ -0,0 +1,195 @@ + + + + + + + + + + Nine Nines: cow_cookie:parse_set_cookie(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cow_cookie:parse_set_cookie(3)

    + +

    Name

    +

    cow_cookie:parse_set_cookie - Parse a set-cookie header

    +

    Description

    +
    +
    parse_set_cookie(SetCookie :: binary())
+    -> {ok, Name, Value, Attrs} | ignore
+
+Name  :: binary()
+Value :: binary()
+Attrs :: cow_cookie:cookie_attrs()
    +
    +

    Parse a set-cookie header.

    +

    Arguments

    +
    SetCookie
    +

    The set-cookie header value.

    +
    +
    +

    Return value

    +

    An ok tuple with the cookie name, value and attributes is returned on success.

    +

    An atom ignore is returned when the cookie has both an empty name and an empty value, and must be ignored.

    +

    Changelog

    +
    • 2.9: Function introduced. +
      • +
    +

    Examples

    +
    Parse a cookie header
    +
    +
    case cow_cookie:parse_set_cookie(SetCookieHd) of
+    {ok, Name, Value, Attrs} ->
+        cookie_engine_set_cookie(Name, Value, Attrs);
+    ignore ->
+        do_nothing()
+end.
    +
    +

    See also

    +

    cow_cookie(3), cow_cookie:parse_cookie(3), cow_cookie:cookie(3), cow_cookie:setcookie(3)

    + + + + + + +
    + +
    + + +

    + Cowlib + 2.11 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowlib/2.11/manual/cow_cookie.setcookie/index.html b/docs/en/cowlib/2.11/manual/cow_cookie.setcookie/index.html new file mode 100644 index 00000000..6fc5ede5 --- /dev/null +++ b/docs/en/cowlib/2.11/manual/cow_cookie.setcookie/index.html @@ -0,0 +1,196 @@ + + + + + + + + + + Nine Nines: cow_cookie:setcookie(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cow_cookie:setcookie(3)

    + +

    Name

    +

    cow_cookie:setcookie - Generate a set-cookie header

    +

    Description

    +
    +
    setcookie(Name  :: iodata(),
+          Value :: iodata(),
+          Opts  :: cow_cookie:cookie_opts())
+    -> iolist()
    +
    +

    Generate a set-cookie header.

    +

    Arguments

    +
    Name
    +

    Cookie name.

    +
    +
    Value
    +

    Cookie value.

    +
    +
    Opts
    +

    Options added to the set-cookie header as attributes.

    +
    +
    +

    Return value

    +

    An iolist with the generated set-cookie header value.

    +

    Changelog

    +
    • 1.0: Function introduced. +
      • +
    +

    Examples

    +
    Generate a set-cookie header
    +
    +
    SetCookie = cow_cookie:setcookie(<<"sessionid">>, ID, #{
+    http_only => true,
+    secure    => true
+}).
    +
    +

    See also

    +

    cow_cookie(3), cow_cookie:parse_cookie(3), cow_cookie:parse_set_cookie(3), cow_cookie:cookie(3)

    + + + + + + +
    + +
    + + +

    + Cowlib + 2.11 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowlib/2.11/manual/cow_cookie/index.html b/docs/en/cowlib/2.11/manual/cow_cookie/index.html new file mode 100644 index 00000000..4c463ba3 --- /dev/null +++ b/docs/en/cowlib/2.11/manual/cow_cookie/index.html @@ -0,0 +1,230 @@ + + + + + + + + + + Nine Nines: cow_cookie(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cow_cookie(3)

    + +

    Name

    +

    cow_cookie - Cookies

    +

    Description

    +

    The module cow_cookie provides functions for parsing and manipulating cookie headers.

    +

    Exports

    + +

    Types

    +

    cookie_attrs()

    +
    +
    cookie_attrs() :: #{
+    expires => calendar:datetime(),
+    max_age => calendar:datetime(),
+    domain => binary(),
+    path => binary(),
+    secure => true,
+    http_only => true,
+    same_site => strict | lax | none
+}
    +
    +

    Cookie attributes parsed from the set-cookie header. The attributes must be passed as-is to a cookie store engine for processing, along with the cookie name and value. More information about the attributes can be found in RFC 6265.

    +

    cookie_opts()

    +
    +
    cookie_opts() :: #{
+    domain    => binary(),
+    http_only => boolean(),
+    max_age   => non_neg_integer(),
+    path      => binary(),
+    same_site => strict | lax | none,
+    secure    => boolean()
+}
    +
    +

    Options for the set-cookie header. They are added to the header as attributes. More information about the options can be found in RFC 6265.

    +

    The following options are defined:

    +
    domain
    +

    Hosts to which the cookie will be sent. By default it will only be sent to the origin server.

    +
    +
    http_only
    +

    Whether the cookie should be restricted to HTTP requests, or it should also be exposed to other APIs, for example Javascript. By default there are no restrictions.

    +
    +
    max_age
    +

    Maximum lifetime of the cookie, in seconds. By default the cookie is kept for the duration of the session.

    +
    +
    path
    +

    Path to which the cookie will be sent. By default it will be sent to the current "directory" of the effective request URI.

    +
    +
    same_site
    +

    Whether the cookie should be sent along with cross-site requests. This attribute is currently non-standard but is in the process of being standardized. Please refer to the RFC 6265 (bis) draft for details.

    +

    The default value for this attribute may vary depending on user agent and configuration. Browsers are known to be more strict over TCP compared to TLS.

    +
    +
    secure
    +

    Whether the cookie should be sent only on secure channels (for example TLS). Note that this does not guarantee the integrity of the cookie, only its confidentiality during transfer. By default there are no restrictions.

    +
    +
    +

    Changelog

    +
    • 2.10: The same_site attribute and option may now be set to none. +
      • +
    • 2.9: The cookie_attrs type was added. +
      • +
    • 1.0: Module introduced. +
      • +
    +

    See also

    +

    cowlib(7), RFC 6265

    + + + + + + +
    + +
    + + +

    + Cowlib + 2.11 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowlib/2.11/manual/cowlib_app/index.html b/docs/en/cowlib/2.11/manual/cowlib_app/index.html new file mode 100644 index 00000000..3dcb6019 --- /dev/null +++ b/docs/en/cowlib/2.11/manual/cowlib_app/index.html @@ -0,0 +1,177 @@ + + + + + + + + + + Nine Nines: cowlib(7) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowlib(7)

    + +

    Name

    +

    cowlib - Support library for manipulating Web protocols

    +

    Description

    +

    Cowlib provides libraries for parsing and building messages for various Web protocols, including HTTP/1.1, HTTP/2 and Websocket.

    +

    It is optimized for completeness rather than speed. No value is ignored, they are all returned.

    +

    Modules

    + +

    Dependencies

    +
    • crypto - Crypto functions +
      • +
    +

    All these applications must be started before the cowlib application. To start Cowlib and all dependencies at once:

    +
    +
    {ok, _} = application:ensure_all_started(cowlib).
    +
    +

    Environment

    +

    The cowlib application does not define any application environment configuration parameters.

    +

    See also

    +

    cowboy(7), gun(7)

    + + + + + + +
    + +
    + + +

    + Cowlib + 2.11 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowlib/2.11/manual/index.html b/docs/en/cowlib/2.11/manual/index.html new file mode 100644 index 00000000..86854efa --- /dev/null +++ b/docs/en/cowlib/2.11/manual/index.html @@ -0,0 +1,177 @@ + + + + + + + + + + Nine Nines: Cowlib Function Reference + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Cowlib Function Reference

    + +

    Name

    +

    cowlib - Support library for manipulating Web protocols

    +

    Description

    +

    Cowlib provides libraries for parsing and building messages for various Web protocols, including HTTP/1.1, HTTP/2 and Websocket.

    +

    It is optimized for completeness rather than speed. No value is ignored, they are all returned.

    +

    Modules

    + +

    Dependencies

    +
    • crypto - Crypto functions +
      • +
    +

    All these applications must be started before the cowlib application. To start Cowlib and all dependencies at once:

    +
    +
    {ok, _} = application:ensure_all_started(cowlib).
    +
    +

    Environment

    +

    The cowlib application does not define any application environment configuration parameters.

    +

    See also

    +

    cowboy(7), gun(7)

    + + + + + + +
    + +
    + + +

    + Cowlib + 2.11 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowlib/2.8/manual/cow_cookie.parse_cookie/index.html b/docs/en/cowlib/2.8/manual/cow_cookie.parse_cookie/index.html index ff63219c..6ace7b8c 100644 --- a/docs/en/cowlib/2.8/manual/cow_cookie.parse_cookie/index.html +++ b/docs/en/cowlib/2.8/manual/cow_cookie.parse_cookie/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.8/manual/cow_cookie.setcookie/index.html b/docs/en/cowlib/2.8/manual/cow_cookie.setcookie/index.html index 583a59d4..b3dc96c0 100644 --- a/docs/en/cowlib/2.8/manual/cow_cookie.setcookie/index.html +++ b/docs/en/cowlib/2.8/manual/cow_cookie.setcookie/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.8/manual/cow_cookie/index.html b/docs/en/cowlib/2.8/manual/cow_cookie/index.html index d2b38825..b53b81a6 100644 --- a/docs/en/cowlib/2.8/manual/cow_cookie/index.html +++ b/docs/en/cowlib/2.8/manual/cow_cookie/index.html @@ -143,6 +143,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.8/manual/cowlib_app/index.html b/docs/en/cowlib/2.8/manual/cowlib_app/index.html index 7b81913e..d858ff6c 100644 --- a/docs/en/cowlib/2.8/manual/cowlib_app/index.html +++ b/docs/en/cowlib/2.8/manual/cowlib_app/index.html @@ -119,6 +119,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.8/manual/index.html b/docs/en/cowlib/2.8/manual/index.html index ca73082e..e5621264 100644 --- a/docs/en/cowlib/2.8/manual/index.html +++ b/docs/en/cowlib/2.8/manual/index.html @@ -119,6 +119,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.9/manual/cow_cookie.cookie/index.html b/docs/en/cowlib/2.9/manual/cow_cookie.cookie/index.html index 99c5d67e..6eb75007 100644 --- a/docs/en/cowlib/2.9/manual/cow_cookie.cookie/index.html +++ b/docs/en/cowlib/2.9/manual/cow_cookie.cookie/index.html @@ -128,6 +128,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.9/manual/cow_cookie.parse_cookie/index.html b/docs/en/cowlib/2.9/manual/cow_cookie.parse_cookie/index.html index e47312f9..2208572b 100644 --- a/docs/en/cowlib/2.9/manual/cow_cookie.parse_cookie/index.html +++ b/docs/en/cowlib/2.9/manual/cow_cookie.parse_cookie/index.html @@ -130,6 +130,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.9/manual/cow_cookie.parse_set_cookie/index.html b/docs/en/cowlib/2.9/manual/cow_cookie.parse_set_cookie/index.html index bb074f88..acfb90c3 100644 --- a/docs/en/cowlib/2.9/manual/cow_cookie.parse_set_cookie/index.html +++ b/docs/en/cowlib/2.9/manual/cow_cookie.parse_set_cookie/index.html @@ -137,6 +137,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.9/manual/cow_cookie.setcookie/index.html b/docs/en/cowlib/2.9/manual/cow_cookie.setcookie/index.html index ebf16f1b..41872f4b 100644 --- a/docs/en/cowlib/2.9/manual/cow_cookie.setcookie/index.html +++ b/docs/en/cowlib/2.9/manual/cow_cookie.setcookie/index.html @@ -138,6 +138,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.9/manual/cow_cookie/index.html b/docs/en/cowlib/2.9/manual/cow_cookie/index.html index 467f99d7..fc6314f0 100644 --- a/docs/en/cowlib/2.9/manual/cow_cookie/index.html +++ b/docs/en/cowlib/2.9/manual/cow_cookie/index.html @@ -169,6 +169,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.9/manual/cowlib_app/index.html b/docs/en/cowlib/2.9/manual/cowlib_app/index.html index 6f1d6d1a..2220f00f 100644 --- a/docs/en/cowlib/2.9/manual/cowlib_app/index.html +++ b/docs/en/cowlib/2.9/manual/cowlib_app/index.html @@ -119,6 +119,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/cowlib/2.9/manual/index.html b/docs/en/cowlib/2.9/manual/index.html index 70c8c3d5..2bf5152c 100644 --- a/docs/en/cowlib/2.9/manual/index.html +++ b/docs/en/cowlib/2.9/manual/index.html @@ -119,6 +119,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.11
    • +
  • 2.10
  • 2.9
    • diff --git a/docs/en/gun/2.0/guide/migrating_from_1.3.asciidoc b/docs/en/gun/2.0/guide/migrating_from_1.3.asciidoc index 220d4482..2ad4a808 100644 --- a/docs/en/gun/2.0/guide/migrating_from_1.3.asciidoc +++ b/docs/en/gun/2.0/guide/migrating_from_1.3.asciidoc @@ -184,7 +184,7 @@ Gun 2.0 requires Erlang/OTP 22.0 or greater. * The functions `gun:request/4,5,6` have been replaced with `gun:headers/4,5` and `gun:request/5,6`. This provides a cleaner separation between requests that are followed by - a body and those that don't. + a body and those that aren't. * The function `gun:ws_send/2` has been replaced with the function `gun:ws_send/3`. The stream reference for the diff --git a/docs/en/gun/2.0/guide/migrating_from_1.3/index.html b/docs/en/gun/2.0/guide/migrating_from_1.3/index.html index 74a42b9d..cfd61c66 100644 --- a/docs/en/gun/2.0/guide/migrating_from_1.3/index.html +++ b/docs/en/gun/2.0/guide/migrating_from_1.3/index.html @@ -139,7 +139,7 @@
  • Requests may now include the tunnel option to send the request on a specific tunnel.
    • -
  • The functions gun:request/4,5,6 have been replaced with gun:headers/4,5 and gun:request/5,6. This provides a cleaner separation between requests that are followed by a body and those that don't. +
  • The functions gun:request/4,5,6 have been replaced with gun:headers/4,5 and gun:request/5,6. This provides a cleaner separation between requests that are followed by a body and those that aren't.
  • The function gun:ws_send/2 has been replaced with the function gun:ws_send/3. The stream reference for the corresponding Websocket upgrade request must now be given.
    • diff --git a/docs/en/gun/2.0/manual/gun_up/index.html b/docs/en/gun/2.0/manual/gun_up/index.html index f06ada2a..64a8cb6e 100644 --- a/docs/en/gun/2.0/manual/gun_up/index.html +++ b/docs/en/gun/2.0/manual/gun_up/index.html @@ -72,7 +72,7 @@ http://www.gnu.org/software/src-highlite --> 
    {gun_up, ConnPid, Protocol}
 
 ConnPid  :: pid()
-Protocol :: http | http2 | socks
    +Protocol :: http | http2 | raw | socks

    The connection is up.

    This message informs the owner process that the connection or reconnection completed.

    diff --git a/docs/en/ranch/1.4/guide/embedded.asciidoc b/docs/en/ranch/1.4/guide/embedded.asciidoc deleted file mode 100644 index 55c018b1..00000000 --- a/docs/en/ranch/1.4/guide/embedded.asciidoc +++ /dev/null @@ -1,48 +0,0 @@ -== Embedded mode - -Embedded mode allows you to insert Ranch listeners directly -in your supervision tree. This allows for greater fault tolerance -control by permitting the shutdown of a listener due to the -failure of another part of the application and vice versa. - -=== Embedding - -To embed Ranch in your application you can simply add the child specs -to your supervision tree. This can all be done in the `init/1` function -of one of your application supervisors. - -Ranch requires at the minimum two kinds of child specs for embedding. -First, you need to add `ranch_sup` to your supervision tree, only once, -regardless of the number of listeners you will use. Then you need to -add the child specs for each listener. - -Ranch has a convenience function for getting the listeners child specs -called `ranch:child_spec/5`, that works like `ranch:start_listener/5`, -except that it doesn't start anything, it only returns child specs. - -As for `ranch_sup`, the child spec is simple enough to not require a -convenience function. - -The following example adds both `ranch_sup` and one listener to another -application's supervision tree. - -.Embed Ranch directly in your supervision tree - -[source,erlang] ----- -init([]) -> - RanchSupSpec = {ranch_sup, {ranch_sup, start_link, []}, - permanent, 5000, supervisor, [ranch_sup]}, - ListenerSpec = ranch:child_spec(echo, 100, - ranch_tcp, [{port, 5555}], - echo_protocol, [] - ), - {ok, {{one_for_one, 10, 10}, [RanchSupSpec, ListenerSpec]}}. ----- - -Remember, you can add as many listener child specs as needed, but only -one `ranch_sup` spec! - -It is recommended that your architecture makes sure that all listeners -are restarted if `ranch_sup` fails. See the Ranch internals chapter for -more details on how Ranch does it. diff --git a/docs/en/ranch/1.4/guide/embedded/index.html b/docs/en/ranch/1.4/guide/embedded/index.html deleted file mode 100644 index a510f990..00000000 --- a/docs/en/ranch/1.4/guide/embedded/index.html +++ /dev/null @@ -1,202 +0,0 @@ - - - - - - - - - - Nine Nines: Embedded mode - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    Embedded mode

    - -

    Embedded mode allows you to insert Ranch listeners directly in your supervision tree. This allows for greater fault tolerance control by permitting the shutdown of a listener due to the failure of another part of the application and vice versa.

    -

    Embedding

    -

    To embed Ranch in your application you can simply add the child specs to your supervision tree. This can all be done in the init/1 function of one of your application supervisors.

    -

    Ranch requires at the minimum two kinds of child specs for embedding. First, you need to add ranch_sup to your supervision tree, only once, regardless of the number of listeners you will use. Then you need to add the child specs for each listener.

    -

    Ranch has a convenience function for getting the listeners child specs called ranch:child_spec/5, that works like ranch:start_listener/5, except that it doesn't start anything, it only returns child specs.

    -

    As for ranch_sup, the child spec is simple enough to not require a convenience function.

    -

    The following example adds both ranch_sup and one listener to another application's supervision tree.

    -
    Embed Ranch directly in your supervision tree
    -
    -
    init([]) ->
-	RanchSupSpec = {ranch_sup, {ranch_sup, start_link, []},
-		permanent, 5000, supervisor, [ranch_sup]},
-	ListenerSpec = ranch:child_spec(echo, 100,
-		ranch_tcp, [{port, 5555}],
-		echo_protocol, []
-	),
-	{ok, {{one_for_one, 10, 10}, [RanchSupSpec, ListenerSpec]}}.
    -
    -

    Remember, you can add as many listener child specs as needed, but only one ranch_sup spec!

    -

    It is recommended that your architecture makes sure that all listeners are restarted if ranch_sup fails. See the Ranch internals chapter for more details on how Ranch does it.

    - - - - - - - - - - - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - - User Guide -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/guide/index.html b/docs/en/ranch/1.4/guide/index.html deleted file mode 100644 index d0659f1f..00000000 --- a/docs/en/ranch/1.4/guide/index.html +++ /dev/null @@ -1,174 +0,0 @@ - - - - - - - - - - Nine Nines: Ranch User Guide - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    Ranch User Guide

    - - - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - - User Guide -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/guide/internals.asciidoc b/docs/en/ranch/1.4/guide/internals.asciidoc deleted file mode 100644 index c5bde58f..00000000 --- a/docs/en/ranch/1.4/guide/internals.asciidoc +++ /dev/null @@ -1,94 +0,0 @@ -== Internals - -This chapter may not apply to embedded Ranch as embedding allows you -to use an architecture specific to your application, which may or may -not be compatible with the description of the Ranch application. - -Note that for everything related to efficiency and performance, -you should perform the benchmarks yourself to get the numbers that -matter to you. Generic benchmarks found on the web may or may not -be of use to you, you can never know until you benchmark your own -system. - -=== Architecture - -Ranch is an OTP application. - -Like all OTP applications, Ranch has a top supervisor. It is responsible -for supervising the `ranch_server` process and all the listeners that -will be started. - -The `ranch_server` gen_server is a central process keeping track of the -listeners and their acceptors. It does so through the use of a public ets -table called `ranch_server`. The table is owned by the top supervisor -to improve fault tolerance. This way if the `ranch_server` gen_server -fails, it doesn't lose any information and the restarted process can -continue as if nothing happened. - -Ranch uses a custom supervisor for managing connections. This supervisor -keeps track of the number of connections and handles connection limits -directly. While it is heavily optimized to perform the task of creating -connection processes for accepted connections, it is still following the -OTP principles and the usual `sys` and `supervisor` calls will work on -it as expected. - -Listeners are grouped into the `ranch_listener_sup` supervisor and -consist of three kinds of processes: the listener gen_server, the -acceptor processes and the connection processes, both grouped under -their own supervisor. All of these processes are registered to the -`ranch_server` gen_server with varying amount of information. - -All socket operations, including listening for connections, go through -transport handlers. Accepted connections are given to the protocol handler. -Transport handlers are simple callback modules for performing operations on -sockets. Protocol handlers start a new process, which receives socket -ownership, with no requirements on how the code should be written inside -that new process. - -=== Number of acceptors - -The second argument to `ranch:start_listener/5` is the number of -processes that will be accepting connections. Care should be taken -when choosing this number. - -First of all, it should not be confused with the maximum number -of connections. Acceptor processes are only used for accepting and -have nothing else in common with connection processes. Therefore -there is nothing to be gained from setting this number too high, -in fact it can slow everything else down. - -Second, this number should be high enough to allow Ranch to accept -connections concurrently. But the number of cores available doesn't -seem to be the only factor for choosing this number, as we can -observe faster accepts if we have more acceptors than cores. It -might be entirely dependent on the protocol, however. - -Our observations suggest that using 100 acceptors on modern hardware -is a good solution, as it's big enough to always have acceptors ready -and it's low enough that it doesn't have a negative impact on the -system's performances. - -=== Platform-specific TCP features - -Some socket options are platform-specific and not supported by `inet`. -They can be of interest because they generally are related to -optimizations provided by the underlying OS. They can still be enabled -thanks to the `raw` option, for which we will see an example. - -One of these features is `TCP_DEFER_ACCEPT` on Linux. It is a simplified -accept mechanism which will wait for application data to come in before -handing out the connection to the Erlang process. - -This is especially useful if you expect many connections to be mostly -idle, perhaps part of a connection pool. They can be handled by the -kernel directly until they send any real data, instead of allocating -resources to idle connections. - -To enable this mechanism, the following option can be used. - -.Using raw transport options - -[source,erlang] -{raw, 6, 9, << 30:32/native >>} - -It means go on layer 6, turn on option 9 with the given integer parameter. diff --git a/docs/en/ranch/1.4/guide/internals/index.html b/docs/en/ranch/1.4/guide/internals/index.html deleted file mode 100644 index 354c8aac..00000000 --- a/docs/en/ranch/1.4/guide/internals/index.html +++ /dev/null @@ -1,202 +0,0 @@ - - - - - - - - - - Nine Nines: Internals - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    Internals

    - -

    This chapter may not apply to embedded Ranch as embedding allows you to use an architecture specific to your application, which may or may not be compatible with the description of the Ranch application.

    -

    Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system.

    -

    Architecture

    -

    Ranch is an OTP application.

    -

    Like all OTP applications, Ranch has a top supervisor. It is responsible for supervising the ranch_server process and all the listeners that will be started.

    -

    The ranch_server gen_server is a central process keeping track of the listeners and their acceptors. It does so through the use of a public ets table called ranch_server. The table is owned by the top supervisor to improve fault tolerance. This way if the ranch_server gen_server fails, it doesn't lose any information and the restarted process can continue as if nothing happened.

    -

    Ranch uses a custom supervisor for managing connections. This supervisor keeps track of the number of connections and handles connection limits directly. While it is heavily optimized to perform the task of creating connection processes for accepted connections, it is still following the OTP principles and the usual sys and supervisor calls will work on it as expected.

    -

    Listeners are grouped into the ranch_listener_sup supervisor and consist of three kinds of processes: the listener gen_server, the acceptor processes and the connection processes, both grouped under their own supervisor. All of these processes are registered to the ranch_server gen_server with varying amount of information.

    -

    All socket operations, including listening for connections, go through transport handlers. Accepted connections are given to the protocol handler. Transport handlers are simple callback modules for performing operations on sockets. Protocol handlers start a new process, which receives socket ownership, with no requirements on how the code should be written inside that new process.

    -

    Number of acceptors

    -

    The second argument to ranch:start_listener/5 is the number of processes that will be accepting connections. Care should be taken when choosing this number.

    -

    First of all, it should not be confused with the maximum number of connections. Acceptor processes are only used for accepting and have nothing else in common with connection processes. Therefore there is nothing to be gained from setting this number too high, in fact it can slow everything else down.

    -

    Second, this number should be high enough to allow Ranch to accept connections concurrently. But the number of cores available doesn't seem to be the only factor for choosing this number, as we can observe faster accepts if we have more acceptors than cores. It might be entirely dependent on the protocol, however.

    -

    Our observations suggest that using 100 acceptors on modern hardware is a good solution, as it's big enough to always have acceptors ready and it's low enough that it doesn't have a negative impact on the system's performances.

    -

    Platform-specific TCP features

    -

    Some socket options are platform-specific and not supported by inet. They can be of interest because they generally are related to optimizations provided by the underlying OS. They can still be enabled thanks to the raw option, for which we will see an example.

    -

    One of these features is TCP_DEFER_ACCEPT on Linux. It is a simplified accept mechanism which will wait for application data to come in before handing out the connection to the Erlang process.

    -

    This is especially useful if you expect many connections to be mostly idle, perhaps part of a connection pool. They can be handled by the kernel directly until they send any real data, instead of allocating resources to idle connections.

    -

    To enable this mechanism, the following option can be used.

    -
    Using raw transport options
    -
    -
    {raw, 6, 9, << 30:32/native >>}
    -
    -

    It means go on layer 6, turn on option 9 with the given integer parameter.

    - - - - - - - - - - - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - - User Guide -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/guide/introduction.asciidoc b/docs/en/ranch/1.4/guide/introduction.asciidoc deleted file mode 100644 index ac27862e..00000000 --- a/docs/en/ranch/1.4/guide/introduction.asciidoc +++ /dev/null @@ -1,28 +0,0 @@ -== Introduction - -Ranch is a socket acceptor pool for TCP protocols. - -Ranch aims to provide everything you need to accept TCP connections -with a small code base and low latency while being easy to use directly -as an application or to embed into your own. - -=== Prerequisites - -It is assumed the developer already knows Erlang and has some experience -with socket programming and TCP protocols. - -=== Supported platforms - -Ranch is tested and supported on Linux, FreeBSD, OSX and Windows. - -Ranch is developed for Erlang/OTP R16B+. - -There are known issues with the SSL application found in Erlang/OTP -18.3.2 and 18.3.3. These versions are therefore not supported. - -Ranch may be compiled on earlier Erlang versions with small source code -modifications but there is no guarantee that it will work as expected. - -=== Versioning - -Ranch uses http://semver.org/[Semantic Versioning 2.0.0] diff --git a/docs/en/ranch/1.4/guide/introduction/index.html b/docs/en/ranch/1.4/guide/introduction/index.html deleted file mode 100644 index 91b491af..00000000 --- a/docs/en/ranch/1.4/guide/introduction/index.html +++ /dev/null @@ -1,186 +0,0 @@ - - - - - - - - - - Nine Nines: Introduction - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    Introduction

    - -

    Ranch is a socket acceptor pool for TCP protocols.

    -

    Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own.

    -

    Prerequisites

    -

    It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols.

    -

    Supported platforms

    -

    Ranch is tested and supported on Linux, FreeBSD, OSX and Windows.

    -

    Ranch is developed for Erlang/OTP R16B+.

    -

    There are known issues with the SSL application found in Erlang/OTP 18.3.2 and 18.3.3. These versions are therefore not supported.

    -

    Ranch may be compiled on earlier Erlang versions with small source code modifications but there is no guarantee that it will work as expected.

    -

    Versioning

    -

    Ranch uses Semantic Versioning 2.0.0

    - - - - - - - - - - - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - - User Guide -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/guide/listeners.asciidoc b/docs/en/ranch/1.4/guide/listeners.asciidoc deleted file mode 100644 index 97afa223..00000000 --- a/docs/en/ranch/1.4/guide/listeners.asciidoc +++ /dev/null @@ -1,320 +0,0 @@ -== Listeners - -A listener is a set of processes whose role is to listen on a port -for new connections. It manages a pool of acceptor processes, each -of them indefinitely accepting connections. When it does, it starts -a new process executing the protocol handler code. All the socket -programming is abstracted through the use of transport handlers. - -The listener takes care of supervising all the acceptor and connection -processes, allowing developers to focus on building their application. - -=== Starting a listener - -Ranch does nothing by default. It is up to the application developer -to request that Ranch listens for connections. - -A listener can be started and stopped at will. - -When starting a listener, a number of different settings are required: - -* A name to identify it locally and be able to interact with it. -* The number of acceptors in the pool. -* A transport handler and its associated options. -* A protocol handler and its associated options. - -Ranch includes both TCP and SSL transport handlers, respectively -`ranch_tcp` and `ranch_ssl`. - -A listener can be started by calling the `ranch:start_listener/5` -function. Before doing so however, you must ensure that the `ranch` -application is started. - -.Starting the Ranch application - -[source,erlang] -ok = application:start(ranch). - -You are then ready to start a listener. Let's call it `tcp_echo`. It will -have a pool of 100 acceptors, use a TCP transport and forward connections -to the `echo_protocol` handler. - -.Starting a listener for TCP connections on port 5555 - -[source,erlang] -{ok, _} = ranch:start_listener(tcp_echo, - ranch_tcp, [{port, 5555}], - echo_protocol, [] -). - -You can try this out by compiling and running the `tcp_echo` example in the -examples directory. To do so, open a shell in the 'examples/tcp_echo/' -directory and run the following command: - -.Building and starting a Ranch example - -[source,bash] -$ make run - -You can then connect to it using telnet and see the echo server reply -everything you send to it. Then when you're done testing, you can use -the `Ctrl+]` key to escape to the telnet command line and type -`quit` to exit. - -.Connecting to the example listener with telnet - -[source,bash] ----- -$ telnet localhost 5555 -Trying 127.0.0.1... -Connected to localhost. -Escape character is '^]'. -Hello! -Hello! -It works! -It works! -^] - -telnet> quit -Connection closed. ----- - -=== Stopping a listener - -All you need to stop a Ranch listener is to call the -`ranch:stop_listener/1` function with the listener's name -as argument. In the previous section we started the listener -named `tcp_echo`. We can now stop it. - -.Stopping a listener - -[source,erlang] -ranch:stop_listener(tcp_echo). - -=== Default transport options - -By default the socket will be set to return `binary` data, with the -options `{active, false}`, `{packet, raw}`, `{reuseaddr, true}` set. -These values can't be overriden when starting the listener, but -they can be overriden using `Transport:setopts/2` in the protocol. - -It will also set `{backlog, 1024}` and `{nodelay, true}`, which -can be overriden at listener startup. - -=== Listening on a random port - -You do not have to specify a specific port to listen on. If you give -the port number 0, or if you omit the port number entirely, Ranch will -start listening on a random port. - -You can retrieve this port number by calling `ranch:get_port/1`. The -argument is the name of the listener you gave in `ranch:start_listener/5`. - -.Starting a listener for TCP connections on a random port - -[source,erlang] -{ok, _} = ranch:start_listener(tcp_echo, - ranch_tcp, [{port, 0}], - echo_protocol, [] -). -Port = ranch:get_port(tcp_echo). - -=== Listening on privileged ports - -Some systems limit access to ports below 1024 for security reasons. -This can easily be identified by an `{error, eacces}` error when trying -to open a listening socket on such a port. - -The methods for listening on privileged ports vary between systems, -please refer to your system's documentation for more information. - -We recommend the use of port rewriting for systems with a single server, -and load balancing for systems with multiple servers. Documenting these -solutions is however out of the scope of this guide. - -=== Accepting connections on an existing socket - -If you want to accept connections on an existing socket, you can use the -`socket` transport option, which should just be the relevant data returned -from the connect function for the transport or the underlying socket library -(`gen_tcp:connect`, `ssl:connect`). The accept function will then be -called on the passed in socket. You should connect the socket in -`{active, false}` mode, as well. - -Note, however, that because of a bug in SSL, you cannot change ownership of an -SSL listen socket prior to R16. Ranch will catch the error thrown, but the -owner of the SSL socket will remain as whatever process created the socket. -However, this will not affect accept behaviour unless the owner process dies, -in which case the socket is closed. Therefore, to use this feature with SSL -with an erlang release prior to R16, ensure that the SSL socket is opened in a -persistant process. - -=== Limiting the number of concurrent connections - -The `max_connections` transport option allows you to limit the number -of concurrent connections. It defaults to 1024. Its purpose is to -prevent your system from being overloaded and ensuring all the -connections are handled optimally. - -.Customizing the maximum number of concurrent connections - -[source,erlang] -{ok, _} = ranch:start_listener(tcp_echo, - ranch_tcp, [{port, 5555}, {max_connections, 100}], - echo_protocol, [] -). - -You can disable this limit by setting its value to the atom `infinity`. - -.Disabling the limit for the number of connections - -[source,erlang] -{ok, _} = ranch:start_listener(tcp_echo, - ranch_tcp, [{port, 5555}, {max_connections, infinity}], - echo_protocol, [] -). - -The maximum number of connections is a soft limit. In practice, it -can reach `max_connections` + the number of acceptors. - -When the maximum number of connections is reached, Ranch will stop -accepting connections. This will not result in further connections -being rejected, as the kernel option allows queueing incoming -connections. The size of this queue is determined by the `backlog` -option and defaults to 1024. Ranch does not know about the number -of connections that are in the backlog. - -You may not always want connections to be counted when checking for -`max_connections`. For example you might have a protocol where both -short-lived and long-lived connections are possible. If the long-lived -connections are mostly waiting for messages, then they don't consume -much resources and can safely be removed from the count. - -To remove the connection from the count, you must call the -`ranch:remove_connection/1` from within the connection process, -with the name of the listener as the only argument. - -.Removing a connection from the count of connections - -[source,erlang] -ranch:remove_connection(Ref). - -As seen in the chapter covering protocols, this pid is received as the -first argument of the protocol's `start_link/4` callback. - -You can modify the `max_connections` value on a running listener by -using the `ranch:set_max_connections/2` function, with the name of the -listener as first argument and the new value as the second. - -.Upgrading the maximum number of connections - -[source,erlang] -ranch:set_max_connections(tcp_echo, MaxConns). - -The change will occur immediately. - -=== Customizing the number of acceptor processes - -By default Ranch will use 10 acceptor processes. Their role is -to accept connections and spawn a connection process for every -new connection. - -This number can be tweaked to improve performance. A good -number is typically between 10 or 100 acceptors. You must -measure to find the best value for your application. - -.Specifying a custom number of acceptor processes - -[source,erlang] -{ok, _} = ranch:start_listener(tcp_echo, - ranch_tcp, [{port, 5555}, {num_acceptors, 42}], - echo_protocol, [] -). - -=== When running out of file descriptors - -Operating systems have limits on the number of sockets -which can be opened by applications. When this maximum is -reached the listener can no longer accept new connections. The -accept rate of the listener will be automatically reduced, and a -warning message will be logged. - ----- -=ERROR REPORT==== 13-Jan-2016::12:24:38 === -Ranch acceptor reducing accept rate: out of file descriptors ----- - -If you notice messages like this you should increase the number -of file-descriptors which can be opened by your application. How -this should be done is operating-system dependent. Please consult -the documentation of your operating system. - -=== Using a supervisor for connection processes - -Ranch allows you to define the type of process that will be used -for the connection processes. By default it expects a `worker`. -When the `connection_type` configuration value is set to `supervisor`, -Ranch will consider that the connection process it manages is a -supervisor and will reflect that in its supervision tree. - -Connection processes of type `supervisor` can either handle the -socket directly or through one of their children. In the latter -case the start function for the connection process must return -two pids: the pid of the supervisor you created (that will be -supervised) and the pid of the protocol handling process (that -will receive the socket). - -Instead of returning `{ok, ConnPid}`, simply return -`{ok, SupPid, ConnPid}`. - -It is very important that the connection process be created -under the supervisor process so that everything works as intended. -If not, you will most likely experience issues when the supervised -process is stopped. - -=== Upgrading - -Ranch allows you to upgrade the protocol options. This takes effect -immediately and for all subsequent connections. - -To upgrade the protocol options, call `ranch:set_protocol_options/2` -with the name of the listener as first argument and the new options -as the second. - -.Upgrading the protocol options - -[source,erlang] -ranch:set_protocol_options(tcp_echo, NewOpts). - -All future connections will use the new options. - -You can also retrieve the current options similarly by -calling `ranch:get_protocol_options/1`. - -.Retrieving the current protocol options - -[source,erlang] -Opts = ranch:get_protocol_options(tcp_echo). - -=== Obtaining information about listeners - -Ranch provides two functions for retrieving information about the -listeners, for reporting and diagnostic purposes. - -The `ranch:info/0` function will return detailed information -about all listeners. - -.Retrieving detailed information -[source,erlang] -ranch:info(). - -The `ranch:procs/2` function will return all acceptor or listener -processes for a given listener. - -.Get all acceptor processes -[source,erlang] -ranch:procs(tcp_echo, acceptors). - -.Get all connection processes -[source,erlang] -ranch:procs(tcp_echo, connections). diff --git a/docs/en/ranch/1.4/guide/listeners/index.html b/docs/en/ranch/1.4/guide/listeners/index.html deleted file mode 100644 index 58d7b8d6..00000000 --- a/docs/en/ranch/1.4/guide/listeners/index.html +++ /dev/null @@ -1,385 +0,0 @@ - - - - - - - - - - Nine Nines: Listeners - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    Listeners

    - -

    A listener is a set of processes whose role is to listen on a port for new connections. It manages a pool of acceptor processes, each of them indefinitely accepting connections. When it does, it starts a new process executing the protocol handler code. All the socket programming is abstracted through the use of transport handlers.

    -

    The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application.

    -

    Starting a listener

    -

    Ranch does nothing by default. It is up to the application developer to request that Ranch listens for connections.

    -

    A listener can be started and stopped at will.

    -

    When starting a listener, a number of different settings are required:

    -
    • A name to identify it locally and be able to interact with it. -
      • -
    • The number of acceptors in the pool. -
      • -
    • A transport handler and its associated options. -
      • -
    • A protocol handler and its associated options. -
      • -
    -

    Ranch includes both TCP and SSL transport handlers, respectively ranch_tcp and ranch_ssl.

    -

    A listener can be started by calling the ranch:start_listener/5 function. Before doing so however, you must ensure that the ranch application is started.

    -
    Starting the Ranch application
    -
    -
    ok = application:start(ranch).
    -
    -

    You are then ready to start a listener. Let's call it tcp_echo. It will have a pool of 100 acceptors, use a TCP transport and forward connections to the echo_protocol handler.

    -
    Starting a listener for TCP connections on port 5555
    -
    -
    {ok, _} = ranch:start_listener(tcp_echo,
-	ranch_tcp, [{port, 5555}],
-	echo_protocol, []
-).
    -
    -

    You can try this out by compiling and running the tcp_echo example in the examples directory. To do so, open a shell in the examples/tcp_echo/ directory and run the following command:

    -
    Building and starting a Ranch example
    -
    -
    $ make run
    -
    -

    You can then connect to it using telnet and see the echo server reply everything you send to it. Then when you're done testing, you can use the Ctrl+] key to escape to the telnet command line and type quit to exit.

    -
    Connecting to the example listener with telnet
    -
    -
    $ telnet localhost 5555
-Trying 127.0.0.1...
-Connected to localhost.
-Escape character is '^]'.
-Hello!
-Hello!
-It works!
-It works!
-^]
-
-telnet> quit
-Connection closed.
    -
    -

    Stopping a listener

    -

    All you need to stop a Ranch listener is to call the ranch:stop_listener/1 function with the listener's name as argument. In the previous section we started the listener named tcp_echo. We can now stop it.

    -
    Stopping a listener
    -
    -
    ranch:stop_listener(tcp_echo).
    -
    -

    Default transport options

    -

    By default the socket will be set to return binary data, with the options {active, false}, {packet, raw}, {reuseaddr, true} set. These values can't be overriden when starting the listener, but they can be overriden using Transport:setopts/2 in the protocol.

    -

    It will also set {backlog, 1024} and {nodelay, true}, which can be overriden at listener startup.

    -

    Listening on a random port

    -

    You do not have to specify a specific port to listen on. If you give the port number 0, or if you omit the port number entirely, Ranch will start listening on a random port.

    -

    You can retrieve this port number by calling ranch:get_port/1. The argument is the name of the listener you gave in ranch:start_listener/5.

    -
    Starting a listener for TCP connections on a random port
    -
    -
    {ok, _} = ranch:start_listener(tcp_echo,
-	ranch_tcp, [{port, 0}],
-	echo_protocol, []
-).
-Port = ranch:get_port(tcp_echo).
    -
    -

    Listening on privileged ports

    -

    Some systems limit access to ports below 1024 for security reasons. This can easily be identified by an {error, eacces} error when trying to open a listening socket on such a port.

    -

    The methods for listening on privileged ports vary between systems, please refer to your system's documentation for more information.

    -

    We recommend the use of port rewriting for systems with a single server, and load balancing for systems with multiple servers. Documenting these solutions is however out of the scope of this guide.

    -

    Accepting connections on an existing socket

    -

    If you want to accept connections on an existing socket, you can use the socket transport option, which should just be the relevant data returned from the connect function for the transport or the underlying socket library (gen_tcp:connect, ssl:connect). The accept function will then be called on the passed in socket. You should connect the socket in {active, false} mode, as well.

    -

    Note, however, that because of a bug in SSL, you cannot change ownership of an SSL listen socket prior to R16. Ranch will catch the error thrown, but the owner of the SSL socket will remain as whatever process created the socket. However, this will not affect accept behaviour unless the owner process dies, in which case the socket is closed. Therefore, to use this feature with SSL with an erlang release prior to R16, ensure that the SSL socket is opened in a persistant process.

    -

    Limiting the number of concurrent connections

    -

    The max_connections transport option allows you to limit the number of concurrent connections. It defaults to 1024. Its purpose is to prevent your system from being overloaded and ensuring all the connections are handled optimally.

    -
    Customizing the maximum number of concurrent connections
    -
    -
    {ok, _} = ranch:start_listener(tcp_echo,
-	ranch_tcp, [{port, 5555}, {max_connections, 100}],
-	echo_protocol, []
-).
    -
    -

    You can disable this limit by setting its value to the atom infinity.

    -
    Disabling the limit for the number of connections
    -
    -
    {ok, _} = ranch:start_listener(tcp_echo,
-	ranch_tcp, [{port, 5555}, {max_connections, infinity}],
-	echo_protocol, []
-).
    -
    -

    The maximum number of connections is a soft limit. In practice, it can reach max_connections + the number of acceptors.

    -

    When the maximum number of connections is reached, Ranch will stop accepting connections. This will not result in further connections being rejected, as the kernel option allows queueing incoming connections. The size of this queue is determined by the backlog option and defaults to 1024. Ranch does not know about the number of connections that are in the backlog.

    -

    You may not always want connections to be counted when checking for max_connections. For example you might have a protocol where both short-lived and long-lived connections are possible. If the long-lived connections are mostly waiting for messages, then they don't consume much resources and can safely be removed from the count.

    -

    To remove the connection from the count, you must call the ranch:remove_connection/1 from within the connection process, with the name of the listener as the only argument.

    -
    Removing a connection from the count of connections
    -
    -
    ranch:remove_connection(Ref).
    -
    -

    As seen in the chapter covering protocols, this pid is received as the first argument of the protocol's start_link/4 callback.

    -

    You can modify the max_connections value on a running listener by using the ranch:set_max_connections/2 function, with the name of the listener as first argument and the new value as the second.

    -
    Upgrading the maximum number of connections
    -
    -
    ranch:set_max_connections(tcp_echo, MaxConns).
    -
    -

    The change will occur immediately.

    -

    Customizing the number of acceptor processes

    -

    By default Ranch will use 10 acceptor processes. Their role is to accept connections and spawn a connection process for every new connection.

    -

    This number can be tweaked to improve performance. A good number is typically between 10 or 100 acceptors. You must measure to find the best value for your application.

    -
    Specifying a custom number of acceptor processes
    -
    -
    {ok, _} = ranch:start_listener(tcp_echo,
-	ranch_tcp, [{port, 5555}, {num_acceptors, 42}],
-	echo_protocol, []
-).
    -
    -

    When running out of file descriptors

    -

    Operating systems have limits on the number of sockets which can be opened by applications. When this maximum is reached the listener can no longer accept new connections. The accept rate of the listener will be automatically reduced, and a warning message will be logged.

    -
    =ERROR REPORT==== 13-Jan-2016::12:24:38 ===
-Ranch acceptor reducing accept rate: out of file descriptors
    -

    If you notice messages like this you should increase the number of file-descriptors which can be opened by your application. How this should be done is operating-system dependent. Please consult the documentation of your operating system.

    -

    Using a supervisor for connection processes

    -

    Ranch allows you to define the type of process that will be used for the connection processes. By default it expects a worker. When the connection_type configuration value is set to supervisor, Ranch will consider that the connection process it manages is a supervisor and will reflect that in its supervision tree.

    -

    Connection processes of type supervisor can either handle the socket directly or through one of their children. In the latter case the start function for the connection process must return two pids: the pid of the supervisor you created (that will be supervised) and the pid of the protocol handling process (that will receive the socket).

    -

    Instead of returning {ok, ConnPid}, simply return {ok, SupPid, ConnPid}.

    -

    It is very important that the connection process be created under the supervisor process so that everything works as intended. If not, you will most likely experience issues when the supervised process is stopped.

    -

    Upgrading

    -

    Ranch allows you to upgrade the protocol options. This takes effect immediately and for all subsequent connections.

    -

    To upgrade the protocol options, call ranch:set_protocol_options/2 with the name of the listener as first argument and the new options as the second.

    -
    Upgrading the protocol options
    -
    -
    ranch:set_protocol_options(tcp_echo, NewOpts).
    -
    -

    All future connections will use the new options.

    -

    You can also retrieve the current options similarly by calling ranch:get_protocol_options/1.

    -
    Retrieving the current protocol options
    -
    -
    Opts = ranch:get_protocol_options(tcp_echo).
    -
    -

    Obtaining information about listeners

    -

    Ranch provides two functions for retrieving information about the listeners, for reporting and diagnostic purposes.

    -

    The ranch:info/0 function will return detailed information about all listeners.

    -
    Retrieving detailed information
    -
    -
    ranch:info().
    -
    -

    The ranch:procs/2 function will return all acceptor or listener processes for a given listener.

    -
    Get all acceptor processes
    -
    -
    ranch:procs(tcp_echo, acceptors).
    -
    -
    Get all connection processes
    -
    -
    ranch:procs(tcp_echo, connections).
    -
    - - - - - - - - - - - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - - User Guide -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/guide/parsers.asciidoc b/docs/en/ranch/1.4/guide/parsers.asciidoc deleted file mode 100644 index 9eacbfa9..00000000 --- a/docs/en/ranch/1.4/guide/parsers.asciidoc +++ /dev/null @@ -1,92 +0,0 @@ -== Writing parsers - -There are three kinds of protocols: - -* Text protocols -* Schema-less binary protocols -* Schema-based binary protocols - -This chapter introduces the first two kinds. It will not cover -more advanced topics such as continuations or parser generators. - -This chapter isn't specifically about Ranch, we assume here that -you know how to read data from the socket. The data you read and -the data that hasn't been parsed is saved in a buffer. Every -time you read from the socket, the data read is appended to the -buffer. What happens next depends on the kind of protocol. We -will only cover the first two. - -=== Parsing text - -Text protocols are generally line based. This means that we can't -do anything with them until we receive the full line. - -A simple way to get a full line is to use `binary:split/{2,3}`. - -.Using binary:split/2 to get a line of input - -[source,erlang] -case binary:split(Buffer, <<"\n">>) of - [_] -> - get_more_data(Buffer); - [Line, Rest] -> - handle_line(Line, Rest) -end. - -In the above example, we can have two results. Either there was -a line break in the buffer and we get it split into two parts, -the line and the rest of the buffer; or there was no line break -in the buffer and we need to get more data from the socket. - -Next, we need to parse the line. The simplest way is to again -split, here on space. The difference is that we want to split -on all spaces character, as we want to tokenize the whole string. - -.Using binary:split/3 to split text - -[source,erlang] -case binary:split(Line, <<" ">>, [global]) of - [<<"HELLO">>] -> - be_polite(); - [<<"AUTH">>, User, Password] -> - authenticate_user(User, Password); - [<<"QUIT">>, Reason] -> - quit(Reason) - %% ... -end. - -Pretty simple, right? Match on the command name, get the rest -of the tokens in variables and call the respective functions. - -After doing this, you will want to check if there is another -line in the buffer, and handle it immediately if any. -Otherwise wait for more data. - -=== Parsing binary - -Binary protocols can be more varied, although most of them are -pretty similar. The first four bytes of a frame tend to be -the size of the frame, which is followed by a certain number -of bytes for the type of frame and then various parameters. - -Sometimes the size of the frame includes the first four bytes, -sometimes not. Other times this size is encoded over two bytes. -And even other times little-endian is used instead of big-endian. - -The general idea stays the same though. - -.Using binary pattern matching to split frames - -[source,erlang] -<< Size:32, _/bits >> = Buffer, -case Buffer of - << Frame:Size/binary, Rest/bits >> -> - handle_frame(Frame, Rest); - _ -> - get_more_data(Buffer) -end. - -You will then need to parse this frame using binary pattern -matching, and handle it. Then you will want to check if there -is another frame fully received in the buffer, and handle it -immediately if any. Otherwise wait for more data. diff --git a/docs/en/ranch/1.4/guide/parsers/index.html b/docs/en/ranch/1.4/guide/parsers/index.html deleted file mode 100644 index b533cde8..00000000 --- a/docs/en/ranch/1.4/guide/parsers/index.html +++ /dev/null @@ -1,241 +0,0 @@ - - - - - - - - - - Nine Nines: Writing parsers - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    Writing parsers

    - -

    There are three kinds of protocols:

    -
    • Text protocols -
      • -
    • Schema-less binary protocols -
      • -
    • Schema-based binary protocols -
      • -
    -

    This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators.

    -

    This chapter isn't specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn't been parsed is saved in a buffer. Every time you read from the socket, the data read is appended to the buffer. What happens next depends on the kind of protocol. We will only cover the first two.

    -

    Parsing text

    -

    Text protocols are generally line based. This means that we can't do anything with them until we receive the full line.

    -

    A simple way to get a full line is to use binary:split/{2,3}.

    -
    Using binary:split/2 to get a line of input
    -
    -
    case binary:split(Buffer, <<"\n">>) of
-	[_] ->
-		get_more_data(Buffer);
-	[Line, Rest] ->
-		handle_line(Line, Rest)
-end.
    -
    -

    In the above example, we can have two results. Either there was a line break in the buffer and we get it split into two parts, the line and the rest of the buffer; or there was no line break in the buffer and we need to get more data from the socket.

    -

    Next, we need to parse the line. The simplest way is to again split, here on space. The difference is that we want to split on all spaces character, as we want to tokenize the whole string.

    -
    Using binary:split/3 to split text
    -
    -
    case binary:split(Line, <<" ">>, [global]) of
-	[<<"HELLO">>] ->
-		be_polite();
-	[<<"AUTH">>, User, Password] ->
-		authenticate_user(User, Password);
-	[<<"QUIT">>, Reason] ->
-		quit(Reason)
-	%% ...
-end.
    -
    -

    Pretty simple, right? Match on the command name, get the rest of the tokens in variables and call the respective functions.

    -

    After doing this, you will want to check if there is another line in the buffer, and handle it immediately if any. Otherwise wait for more data.

    -

    Parsing binary

    -

    Binary protocols can be more varied, although most of them are pretty similar. The first four bytes of a frame tend to be the size of the frame, which is followed by a certain number of bytes for the type of frame and then various parameters.

    -

    Sometimes the size of the frame includes the first four bytes, sometimes not. Other times this size is encoded over two bytes. And even other times little-endian is used instead of big-endian.

    -

    The general idea stays the same though.

    -
    Using binary pattern matching to split frames
    -
    -
    << Size:32, _/bits >> = Buffer,
-case Buffer of
-	<< Frame:Size/binary, Rest/bits >> ->
-		handle_frame(Frame, Rest);
-	_ ->
-		get_more_data(Buffer)
-end.
    -
    -

    You will then need to parse this frame using binary pattern matching, and handle it. Then you will want to check if there is another frame fully received in the buffer, and handle it immediately if any. Otherwise wait for more data.

    - - - - - - - - - - - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - - User Guide -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/guide/protocols.asciidoc b/docs/en/ranch/1.4/guide/protocols.asciidoc deleted file mode 100644 index b9a31f27..00000000 --- a/docs/en/ranch/1.4/guide/protocols.asciidoc +++ /dev/null @@ -1,99 +0,0 @@ -== Protocols - -A protocol handler starts a connection process and defines the -protocol logic executed in this process. - -=== Writing a protocol handler - -All protocol handlers must implement the `ranch_protocol` behavior -which defines a single callback, `start_link/4`. This callback is -responsible for spawning a new process for handling the connection. -It receives four arguments: the name of the listener, the socket, the -transport handler being used and the protocol options defined in -the call to `ranch:start_listener/5`. This callback must -return `{ok, Pid}`, with `Pid` the pid of the new process. - -The newly started process can then freely initialize itself. However, -it must call `ranch:accept_ack/1` before doing any socket operation. -This will ensure the connection process is the owner of the socket. -It expects the listener's name as argument. - -.Acknowledge accepting the socket - -[source,erlang] -ok = ranch:accept_ack(Ref). - -If your protocol code requires specific socket options, you should -set them while initializing your connection process, after -calling `ranch:accept_ack/1`. You can use `Transport:setopts/2` -for that purpose. - -Following is the complete protocol code for the example found -in `examples/tcp_echo/`. - -.Protocol module that echoes everything it receives - -[source,erlang] ----- --module(echo_protocol). --behaviour(ranch_protocol). - --export([start_link/4]). --export([init/4]). - -start_link(Ref, Socket, Transport, Opts) -> - Pid = spawn_link(?MODULE, init, [Ref, Socket, Transport, Opts]), - {ok, Pid}. - -init(Ref, Socket, Transport, _Opts = []) -> - ok = ranch:accept_ack(Ref), - loop(Socket, Transport). - -loop(Socket, Transport) -> - case Transport:recv(Socket, 0, 5000) of - {ok, Data} -> - Transport:send(Socket, Data), - loop(Socket, Transport); - _ -> - ok = Transport:close(Socket) - end. ----- - -=== Using gen_server - -Special processes like the ones that use the `gen_server` or `gen_fsm` -behaviours have the particularity of having their `start_link` call not -return until the `init` function returns. This is problematic, because -you won't be able to call `ranch:accept_ack/1` from the `init` callback -as this would cause a deadlock to happen. - -Use the `gen_server:enter_loop/3` function. It allows you to start your process -normally (although it must be started with `proc_lib` like all special -processes), then perform any needed operations before falling back into -the normal `gen_server` execution loop. - -.Use a gen_server for protocol handling - -[source,erlang] ----- --module(my_protocol). --behaviour(gen_server). --behaviour(ranch_protocol). - --export([start_link/4]). --export([init/1]). -%% Exports of other gen_server callbacks here. - -start_link(Ref, Socket, Transport, Opts) -> - {ok, proc_lib:spawn_link(?MODULE, init, [{Ref, Socket, Transport, Opts}])}. - -init({Ref, Socket, Transport, _Opts = []}) -> - %% Perform any required state initialization here. - ok = ranch:accept_ack(Ref), - ok = Transport:setopts(Socket, [{active, once}]), - gen_server:enter_loop(?MODULE, [], {state, Socket, Transport}). - -%% Other gen_server callbacks here. ----- - -Check the `tcp_reverse` example for a complete example. diff --git a/docs/en/ranch/1.4/guide/protocols/index.html b/docs/en/ranch/1.4/guide/protocols/index.html deleted file mode 100644 index db0ed1bd..00000000 --- a/docs/en/ranch/1.4/guide/protocols/index.html +++ /dev/null @@ -1,248 +0,0 @@ - - - - - - - - - - Nine Nines: Protocols - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    Protocols

    - -

    A protocol handler starts a connection process and defines the protocol logic executed in this process.

    -

    Writing a protocol handler

    -

    All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/4. This callback is responsible for spawning a new process for handling the connection. It receives four arguments: the name of the listener, the socket, the transport handler being used and the protocol options defined in the call to ranch:start_listener/5. This callback must return {ok, Pid}, with Pid the pid of the new process.

    -

    The newly started process can then freely initialize itself. However, it must call ranch:accept_ack/1 before doing any socket operation. This will ensure the connection process is the owner of the socket. It expects the listener's name as argument.

    -
    Acknowledge accepting the socket
    -
    -
    ok = ranch:accept_ack(Ref).
    -
    -

    If your protocol code requires specific socket options, you should set them while initializing your connection process, after calling ranch:accept_ack/1. You can use Transport:setopts/2 for that purpose.

    -

    Following is the complete protocol code for the example found in examples/tcp_echo/.

    -
    Protocol module that echoes everything it receives
    -
    -
    -module(echo_protocol).
--behaviour(ranch_protocol).
-
--export([start_link/4]).
--export([init/4]).
-
-start_link(Ref, Socket, Transport, Opts) ->
-	Pid = spawn_link(?MODULE, init, [Ref, Socket, Transport, Opts]),
-	{ok, Pid}.
-
-init(Ref, Socket, Transport, _Opts = []) ->
-	ok = ranch:accept_ack(Ref),
-	loop(Socket, Transport).
-
-loop(Socket, Transport) ->
-	case Transport:recv(Socket, 0, 5000) of
-		{ok, Data} ->
-			Transport:send(Socket, Data),
-			loop(Socket, Transport);
-		_ ->
-			ok = Transport:close(Socket)
-	end.
    -
    -

    Using gen_server

    -

    Special processes like the ones that use the gen_server or gen_fsm behaviours have the particularity of having their start_link call not return until the init function returns. This is problematic, because you won't be able to call ranch:accept_ack/1 from the init callback as this would cause a deadlock to happen.

    -

    Use the gen_server:enter_loop/3 function. It allows you to start your process normally (although it must be started with proc_lib like all special processes), then perform any needed operations before falling back into the normal gen_server execution loop.

    -
    Use a gen_server for protocol handling
    -
    -
    -module(my_protocol).
--behaviour(gen_server).
--behaviour(ranch_protocol).
-
--export([start_link/4]).
--export([init/1]).
-%% Exports of other gen_server callbacks here.
-
-start_link(Ref, Socket, Transport, Opts) ->
-	{ok, proc_lib:spawn_link(?MODULE, init, [{Ref, Socket, Transport, Opts}])}.
-
-init({Ref, Socket, Transport, _Opts = []}) ->
-	%% Perform any required state initialization here.
-	ok = ranch:accept_ack(Ref),
-	ok = Transport:setopts(Socket, [{active, once}]),
-	gen_server:enter_loop(?MODULE, [], {state, Socket, Transport}).
-
-%% Other gen_server callbacks here.
    -
    -

    Check the tcp_reverse example for a complete example.

    - - - - - - - - - - - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - - User Guide -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/guide/ssl_auth.asciidoc b/docs/en/ranch/1.4/guide/ssl_auth.asciidoc deleted file mode 100644 index de16107a..00000000 --- a/docs/en/ranch/1.4/guide/ssl_auth.asciidoc +++ /dev/null @@ -1,120 +0,0 @@ -== SSL client authentication - -=== Purpose - -SSL client authentication is a mechanism allowing applications to -identify certificates. This allows your application to make sure that -the client is an authorized certificate, but makes no claim about -whether the user can be trusted. This can be combined with a password -based authentication to attain greater security. - -The server only needs to retain the certificate serial number and -the certificate issuer to authenticate the certificate. Together, -they can be used to uniquely identify a certicate. - -As Ranch allows the same protocol code to be used for both SSL and -non-SSL transports, you need to make sure you are in an SSL context -before attempting to perform an SSL client authentication. This -can be done by checking the return value of `Transport:name/0`. - -=== Obtaining client certificates - -You can obtain client certificates from various sources. You can -generate them yourself, or you can use a service like CAcert.org -which allows you to generate client and server certificates for -free. - -Following are the steps you need to take to create a CAcert.org -account, generate a certificate and install it in your favorite -browser. - -* Open http://cacert.org in your favorite browser -* Root Certificate link: install both certificates -* Join (Register an account) -* Verify your account (check your email inbox!) -* Log in -* Client Certificates: New -* Follow instructions to create the certificate -* Install the certificate in your browser - -You can optionally save the certificate for later use, for example -to extract the `IssuerID` information as will be detailed later on. - -=== Transport configuration - -The SSL transport does not request a client certificate by default. -You need to specify the `{verify, verify_peer}` option when starting -the listener to enable this behavior. - -.Configure a listener for SSL authentication - -[source,erlang] -{ok, _} = ranch:start_listener(my_ssl, - ranch_ssl, [ - {port, SSLPort}, - {certfile, PathToCertfile}, - {cacertfile, PathToCACertfile}, - {verify, verify_peer} - ], - my_protocol, [] -). - -In this example we set the required `port` and `certfile`, but also -the `cacertfile` containing the CACert.org root certificate, and -the option to request the client certificate. - -If you enable the `{verify, verify_peer}` option and the client does -not have a client certificate configured for your domain, then no -certificate will be sent. This allows you to use SSL for more than -just authenticated clients. - -=== Authentication - -To authenticate users, you must first save the certificate information -required. If you have your users' certificate files, you can simply -load the certificate and retrieve the information directly. - -.Retrieve the issuer ID from a certificate - -[source,erlang] ----- -certfile_to_issuer_id(Filename) -> - {ok, Data} = file:read_file(Filename), - [{'Certificate', Cert, not_encrypted}] = public_key:pem_decode(Data), - {ok, IssuerID} = public_key:pkix_issuer_id(Cert, self), - IssuerID. ----- - -The `IssuerID` variable contains both the certificate serial number -and the certificate issuer stored in a tuple, so this value alone can -be used to uniquely identify the user certificate. You can save this -value in a database, a configuration file or any other place where an -Erlang term can be stored and retrieved. - -To retrieve the `IssuerID` from a running connection, you need to first -retrieve the client certificate and then extract this information from -it. Ranch does not provide a function to retrieve the client certificate. -Instead you can use the `ssl:peercert/1` function. Once you have the -certificate, you can again use the `public_key:pkix_issuer_id/2` to -extract the `IssuerID` value. - -The following function returns the `IssuerID` or `false` if no client -certificate was found. This snippet is intended to be used from your -protocol code. - -.Retrieve the issuer ID from the certificate for the current connection - -[source,erlang] ----- -socket_to_issuer_id(Socket) -> - case ssl:peercert(Socket) of - {error, no_peercert} -> - false; - {ok, Cert} -> - {ok, IssuerID} = public_key:pkix_issuer_id(Cert, self), - IssuerID - end. ----- - -You then only need to match the `IssuerID` value to authenticate the -user. diff --git a/docs/en/ranch/1.4/guide/ssl_auth/index.html b/docs/en/ranch/1.4/guide/ssl_auth/index.html deleted file mode 100644 index 4b0d53a8..00000000 --- a/docs/en/ranch/1.4/guide/ssl_auth/index.html +++ /dev/null @@ -1,254 +0,0 @@ - - - - - - - - - - Nine Nines: SSL client authentication - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    SSL client authentication

    - -

    Purpose

    -

    SSL client authentication is a mechanism allowing applications to identify certificates. This allows your application to make sure that the client is an authorized certificate, but makes no claim about whether the user can be trusted. This can be combined with a password based authentication to attain greater security.

    -

    The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate.

    -

    As Ranch allows the same protocol code to be used for both SSL and non-SSL transports, you need to make sure you are in an SSL context before attempting to perform an SSL client authentication. This can be done by checking the return value of Transport:name/0.

    -

    Obtaining client certificates

    -

    You can obtain client certificates from various sources. You can generate them yourself, or you can use a service like CAcert.org which allows you to generate client and server certificates for free.

    -

    Following are the steps you need to take to create a CAcert.org account, generate a certificate and install it in your favorite browser.

    -
    • Open http://cacert.org in your favorite browser -
      • -
    • Root Certificate link: install both certificates -
      • -
    • Join (Register an account) -
      • -
    • Verify your account (check your email inbox!) -
      • -
    • Log in -
      • -
    • Client Certificates: New -
      • -
    • Follow instructions to create the certificate -
      • -
    • Install the certificate in your browser -
      • -
    -

    You can optionally save the certificate for later use, for example to extract the IssuerID information as will be detailed later on.

    -

    Transport configuration

    -

    The SSL transport does not request a client certificate by default. You need to specify the {verify, verify_peer} option when starting the listener to enable this behavior.

    -
    Configure a listener for SSL authentication
    -
    -
    {ok, _} = ranch:start_listener(my_ssl,
-	ranch_ssl, [
-		{port, SSLPort},
-		{certfile, PathToCertfile},
-		{cacertfile, PathToCACertfile},
-		{verify, verify_peer}
-	],
-	my_protocol, []
-).
    -
    -

    In this example we set the required port and certfile, but also the cacertfile containing the CACert.org root certificate, and the option to request the client certificate.

    -

    If you enable the {verify, verify_peer} option and the client does not have a client certificate configured for your domain, then no certificate will be sent. This allows you to use SSL for more than just authenticated clients.

    -

    Authentication

    -

    To authenticate users, you must first save the certificate information required. If you have your users' certificate files, you can simply load the certificate and retrieve the information directly.

    -
    Retrieve the issuer ID from a certificate
    -
    -
    certfile_to_issuer_id(Filename) ->
-	{ok, Data} = file:read_file(Filename),
-	[{'Certificate', Cert, not_encrypted}] = public_key:pem_decode(Data),
-	{ok, IssuerID} = public_key:pkix_issuer_id(Cert, self),
-	IssuerID.
    -
    -

    The IssuerID variable contains both the certificate serial number and the certificate issuer stored in a tuple, so this value alone can be used to uniquely identify the user certificate. You can save this value in a database, a configuration file or any other place where an Erlang term can be stored and retrieved.

    -

    To retrieve the IssuerID from a running connection, you need to first retrieve the client certificate and then extract this information from it. Ranch does not provide a function to retrieve the client certificate. Instead you can use the ssl:peercert/1 function. Once you have the certificate, you can again use the public_key:pkix_issuer_id/2 to extract the IssuerID value.

    -

    The following function returns the IssuerID or false if no client certificate was found. This snippet is intended to be used from your protocol code.

    -
    Retrieve the issuer ID from the certificate for the current connection
    -
    -
    socket_to_issuer_id(Socket) ->
-	case ssl:peercert(Socket) of
-		{error, no_peercert} ->
-			false;
-		{ok, Cert} ->
-			{ok, IssuerID} = public_key:pkix_issuer_id(Cert, self),
-			IssuerID
-	end.
    -
    -

    You then only need to match the IssuerID value to authenticate the user.

    - - - - - - - - - - - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - - User Guide -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/guide/transports.asciidoc b/docs/en/ranch/1.4/guide/transports.asciidoc deleted file mode 100644 index f5bb17eb..00000000 --- a/docs/en/ranch/1.4/guide/transports.asciidoc +++ /dev/null @@ -1,161 +0,0 @@ -== Transports - -A transport defines the interface to interact with a socket. - -Transports can be used for connecting, listening and accepting -connections, but also for receiving and sending data. Both -passive and active mode are supported, although all sockets -are initialized as passive. - -=== TCP transport - -The TCP transport is a thin wrapper around `gen_tcp`. - -=== SSL transport - -The SSL transport is a thin wrapper around `ssl`. - -Ranch depends on `ssl` by default so any necessary -dependencies will start when Ranch is started. It is -possible to remove the dependency when the SSL transport -will not be used. Refer to your release build tool's -documentation for more information. - -When embedding Ranch listeners that have an SSL transport, -your application must depend on the `ssl` application for -proper behavior. - -=== Sending and receiving data - -This section assumes that `Transport` is a valid transport handler -(like `ranch_tcp` or `ranch_ssl`) and `Socket` is a connected -socket obtained through the listener. - -You can send data to a socket by calling the `Transport:send/2` -function. The data can be given as `iodata()`, which is defined as -`binary() | iolist()`. All the following calls will work: - -.Sending data to the socket - -[source,erlang] ----- -Transport:send(Socket, <<"Ranch is cool!">>). -Transport:send(Socket, "Ranch is cool!"). -Transport:send(Socket, ["Ranch", ["is", "cool!"]]). -Transport:send(Socket, ["Ranch", [<<"is">>, "cool!"]]). ----- - -You can receive data either in passive or in active mode. Passive mode -means that you will perform a blocking `Transport:recv/3` call, while -active mode means that you will receive the data as a message. - -By default, all data will be received as binary. It is possible to -receive data as strings, although this is not recommended as binaries -are a more efficient construct, especially for binary protocols. - -Receiving data using passive mode requires a single function call. The -first argument is the socket, and the third argument is a timeout duration -before the call returns with `{error, timeout}`. - -The second argument is the amount of data in bytes that we want to receive. -The function will wait for data until it has received exactly this amount. -If you are not expecting a precise size, you can specify 0 which will make -this call return as soon as data was read, regardless of its size. - -.Receiving data from the socket in passive mode - -[source,erlang] -{ok, Data} = Transport:recv(Socket, 0, 5000). - -Active mode requires you to inform the socket that you want to receive -data as a message and to write the code to actually receive it. - -There are two kinds of active modes: `{active, once}` and -`{active, true}`. The first will send a single message before going -back to passive mode; the second will send messages indefinitely. -We recommend not using the `{active, true}` mode as it could quickly -flood your process mailbox. It's better to keep the data in the socket -and read it only when required. - -Three different messages can be received: - -* `{OK, Socket, Data}` -* `{Closed, Socket}` -* `{Error, Socket, Reason}` - -The value of `OK`, `Closed` and `Error` can be different -depending on the transport being used. To be able to properly match -on them you must first call the `Transport:messages/0` function. - -.Retrieving the transport's active message identifiers - -[source,erlang] -{OK, Closed, Error} = Transport:messages(). - -To start receiving messages you will need to call the `Transport:setopts/2` -function, and do so every time you want to receive data. - -.Receiving messages from the socket in active mode - -[source,erlang] ----- -{OK, Closed, Error} = Transport:messages(), -Transport:setopts(Socket, [{active, once}]), -receive - {OK, Socket, Data} -> - io:format("data received: ~p~n", [Data]); - {Closed, Socket} -> - io:format("socket got closed!~n"); - {Error, Socket, Reason} -> - io:format("error happened: ~p~n", [Reason]) -end. ----- - -You can easily integrate active sockets with existing Erlang code as all -you really need is just a few more clauses when receiving messages. - -=== Sending files - -As in the previous section it is assumed `Transport` is a valid transport -handler and `Socket` is a connected socket obtained through the listener. - -To send a whole file, with name `Filename`, over a socket: - -.Sending a file by filename - -[source,erlang] -{ok, SentBytes} = Transport:sendfile(Socket, Filename). - -Or part of a file, with `Offset` greater than or equal to 0, `Bytes` number of -bytes and chunks of size `ChunkSize`: - -.Sending part of a file by filename in chunks - -[source,erlang] -Opts = [{chunk_size, ChunkSize}], -{ok, SentBytes} = Transport:sendfile(Socket, Filename, Offset, Bytes, Opts). - -To improve efficiency when sending multiple parts of the same file it is also -possible to use a file descriptor opened in raw mode: - -.Sending a file opened in raw mode - -[source,erlang] -{ok, RawFile} = file:open(Filename, [raw, read, binary]), -{ok, SentBytes} = Transport:sendfile(Socket, RawFile, Offset, Bytes, Opts). - -=== Writing a transport handler - -A transport handler is a module implementing the `ranch_transport` behavior. -It defines a certain number of callbacks that must be written in order to -allow transparent usage of the transport handler. - -The behavior doesn't define the socket options available when opening a -socket. These do not need to be common to all transports as it's easy enough -to write different initialization functions for the different transports that -will be used. With one exception though. The `setopts/2` function *must* -implement the `{active, once}` and the `{active, true}` options. - -If the transport handler doesn't have a native implementation of `sendfile/5` a -fallback is available, `ranch_transport:sendfile/6`. The extra first argument -is the transport's module. See `ranch_ssl` for an example. diff --git a/docs/en/ranch/1.4/guide/transports/index.html b/docs/en/ranch/1.4/guide/transports/index.html deleted file mode 100644 index d910929d..00000000 --- a/docs/en/ranch/1.4/guide/transports/index.html +++ /dev/null @@ -1,279 +0,0 @@ - - - - - - - - - - Nine Nines: Transports - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    Transports

    - -

    A transport defines the interface to interact with a socket.

    -

    Transports can be used for connecting, listening and accepting connections, but also for receiving and sending data. Both passive and active mode are supported, although all sockets are initialized as passive.

    -

    TCP transport

    -

    The TCP transport is a thin wrapper around gen_tcp.

    -

    SSL transport

    -

    The SSL transport is a thin wrapper around ssl.

    -

    Ranch depends on ssl by default so any necessary dependencies will start when Ranch is started. It is possible to remove the dependency when the SSL transport will not be used. Refer to your release build tool's documentation for more information.

    -

    When embedding Ranch listeners that have an SSL transport, your application must depend on the ssl application for proper behavior.

    -

    Sending and receiving data

    -

    This section assumes that Transport is a valid transport handler (like ranch_tcp or ranch_ssl) and Socket is a connected socket obtained through the listener.

    -

    You can send data to a socket by calling the Transport:send/2 function. The data can be given as iodata(), which is defined as binary() | iolist(). All the following calls will work:

    -
    Sending data to the socket
    -
    -
    Transport:send(Socket, <<"Ranch is cool!">>).
-Transport:send(Socket, "Ranch is cool!").
-Transport:send(Socket, ["Ranch", ["is", "cool!"]]).
-Transport:send(Socket, ["Ranch", [<<"is">>, "cool!"]]).
    -
    -

    You can receive data either in passive or in active mode. Passive mode means that you will perform a blocking Transport:recv/3 call, while active mode means that you will receive the data as a message.

    -

    By default, all data will be received as binary. It is possible to receive data as strings, although this is not recommended as binaries are a more efficient construct, especially for binary protocols.

    -

    Receiving data using passive mode requires a single function call. The first argument is the socket, and the third argument is a timeout duration before the call returns with {error, timeout}.

    -

    The second argument is the amount of data in bytes that we want to receive. The function will wait for data until it has received exactly this amount. If you are not expecting a precise size, you can specify 0 which will make this call return as soon as data was read, regardless of its size.

    -
    Receiving data from the socket in passive mode
    -
    -
    {ok, Data} = Transport:recv(Socket, 0, 5000).
    -
    -

    Active mode requires you to inform the socket that you want to receive data as a message and to write the code to actually receive it.

    -

    There are two kinds of active modes: {active, once} and {active, true}. The first will send a single message before going back to passive mode; the second will send messages indefinitely. We recommend not using the {active, true} mode as it could quickly flood your process mailbox. It's better to keep the data in the socket and read it only when required.

    -

    Three different messages can be received:

    -
    • {OK, Socket, Data} -
      • -
    • {Closed, Socket} -
      • -
    • {Error, Socket, Reason} -
      • -
    -

    The value of OK, Closed and Error can be different depending on the transport being used. To be able to properly match on them you must first call the Transport:messages/0 function.

    -
    Retrieving the transport's active message identifiers
    -
    -
    {OK, Closed, Error} = Transport:messages().
    -
    -

    To start receiving messages you will need to call the Transport:setopts/2 function, and do so every time you want to receive data.

    -
    Receiving messages from the socket in active mode
    -
    -
    {OK, Closed, Error} = Transport:messages(),
-Transport:setopts(Socket, [{active, once}]),
-receive
-	{OK, Socket, Data} ->
-		io:format("data received: ~p~n", [Data]);
-	{Closed, Socket} ->
-		io:format("socket got closed!~n");
-	{Error, Socket, Reason} ->
-		io:format("error happened: ~p~n", [Reason])
-end.
    -
    -

    You can easily integrate active sockets with existing Erlang code as all you really need is just a few more clauses when receiving messages.

    -

    Sending files

    -

    As in the previous section it is assumed Transport is a valid transport handler and Socket is a connected socket obtained through the listener.

    -

    To send a whole file, with name Filename, over a socket:

    -
    Sending a file by filename
    -
    -
    {ok, SentBytes} = Transport:sendfile(Socket, Filename).
    -
    -

    Or part of a file, with Offset greater than or equal to 0, Bytes number of bytes and chunks of size ChunkSize:

    -
    Sending part of a file by filename in chunks
    -
    -
    Opts = [{chunk_size, ChunkSize}],
-{ok, SentBytes} = Transport:sendfile(Socket, Filename, Offset, Bytes, Opts).
    -
    -

    To improve efficiency when sending multiple parts of the same file it is also possible to use a file descriptor opened in raw mode:

    -
    Sending a file opened in raw mode
    -
    -
    {ok, RawFile} = file:open(Filename, [raw, read, binary]),
-{ok, SentBytes} = Transport:sendfile(Socket, RawFile, Offset, Bytes, Opts).
    -
    -

    Writing a transport handler

    -

    A transport handler is a module implementing the ranch_transport behavior. It defines a certain number of callbacks that must be written in order to allow transparent usage of the transport handler.

    -

    The behavior doesn't define the socket options available when opening a socket. These do not need to be common to all transports as it's easy enough to write different initialization functions for the different transports that will be used. With one exception though. The setopts/2 function must implement the {active, once} and the {active, true} options.

    -

    If the transport handler doesn't have a native implementation of sendfile/5 a fallback is available, ranch_transport:sendfile/6. The extra first argument is the transport's module. See ranch_ssl for an example.

    - - - - - - - - - - - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - - User Guide -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/manual/index.html b/docs/en/ranch/1.4/manual/index.html deleted file mode 100644 index f8c5aa74..00000000 --- a/docs/en/ranch/1.4/manual/index.html +++ /dev/null @@ -1,170 +0,0 @@ - - - - - - - - - - Nine Nines: Ranch Function Reference - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    Ranch Function Reference

    - - - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - Function Reference - -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/manual/ranch/index.html b/docs/en/ranch/1.4/manual/ranch/index.html deleted file mode 100644 index 7a2cb741..00000000 --- a/docs/en/ranch/1.4/manual/ranch/index.html +++ /dev/null @@ -1,382 +0,0 @@ - - - - - - - - - - Nine Nines: ranch(3) - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    ranch(3)

    - -

    Name

    -

    ranch - socket acceptor pool

    -

    Description

    -

    The ranch module provides functions for starting and manipulating Ranch listeners.

    -

    Types

    -

    max_conns() = non_neg_integer() | infinity

    -

    Maximum number of connections allowed on this listener.

    -

    This is a soft limit. The actual number of connections might be slightly above the limit due to concurrency when accepting new connections. Some connections may also be removed from this count explicitly by the user code.

    -

    opt()

    -
    -
    opt() = {ack_timeout, timeout()}
-	| {connection_type, worker | supervisor}
-	| {max_connections, max_conns()}
-	| {num_acceptors, pos_integer()}
-	| {shutdown, timeout() | brutal_kill}
-	| {socket, any()}
    -
    -

    Ranch-specific transport options.

    -

    These options are not passed on to the transports. They are used by Ranch while setting up the listeners.

    -

    ref() = any()

    -

    Unique name used to refer to a listener.

    -

    Option descriptions

    -

    None of the options are required.

    -
    ack_timeout (5000)
    -

    Maximum allowed time for the ranch:accept_ack/1 call to finish.

    -
    -
    connection_type (worker)
    -

    Type of process that will handle the connection.

    -
    -
    max_connections (1024)
    -

    Maximum number of active connections. Soft limit. Using infinity will disable the limit entirely.

    -
    -
    num_acceptors (10)
    -

    Number of processes that accept connections.

    -
    -
    shutdown (5000)
    -

    Maximum allowed time for children to stop on listener shutdown.

    -
    -
    socket
    -

    Listening socket opened externally to be used instead of calling Transport:listen/1.

    -
    -
    -

    Exports

    -

    accept_ack(Ref) -> ok

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    -

    Acknowledge that the connection is accepted.

    -

    This function MUST be used by a connection process to inform Ranch that it initialized properly and let it perform any additional operations before the socket can be safely used.

    -

    child_spec(Ref, NumAcceptors, Transport, TransOpts, Protocol, ProtoOpts) -> supervisor:child_spec()

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    NumAcceptors = non_neg_integer()
    -

    Number of acceptor processes.

    -
    -
    Transport = module()
    -

    Transport module.

    -
    -
    TransOpts = any()
    -

    Transport options.

    -
    -
    Protocol = module()
    -

    Protocol module.

    -
    -
    ProtoOpts = any()
    -

    Protocol options.

    -
    -
    -

    Return child specifications for a new listener.

    -

    This function can be used to embed a listener directly in an application instead of letting Ranch handle it.

    -

    get_addr(Ref) -> {IP, Port}

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    IP = inet:ip_address()
    -

    IP of the interface used by this listener.

    -
    -
    Port = inet:port_number()
    -

    Port number used by this listener.

    -
    -
    -

    Return the IP address and port for the given listener.

    -

    get_max_connections(Ref) -> MaxConns

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    MaxConns = max_conns()
    -

    Current maximum number of connections.

    -
    -
    -

    Return the max number of connections allowed for the given listener.

    -

    get_port(Ref) -> Port

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    Port = inet:port_number()
    -

    Port number used by this listener.

    -
    -
    -

    Return the port for the given listener.

    -

    get_protocol_options(Ref) -> ProtoOpts

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    ProtoOpts = any()
    -

    Current protocol options.

    -
    -
    -

    Return the protocol options set for the given listener.

    -

    info() -> [{Ref, [{Key, Value}]}]

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    Key = atom()
    -

    Information key.

    -
    -
    Value = any()
    -

    Information value.

    -
    -
    -

    Return detailed information about all Ranch listeners.

    -

    The following keys are defined:

    -
    pid
    -

    Pid of the listener's top-level supervisor.

    -
    -
    ip
    -

    Interface Ranch listens on.

    -
    -
    port
    -

    Port number Ranch listens on.

    -
    -
    num_acceptors
    -

    Number of acceptor processes.

    -
    -
    max_connections
    -

    Maximum number of connections.

    -
    -
    active_connections
    -

    Number of active connections.

    -
    -
    all_connections
    -

    Number of connections, including those removed from the count.

    -
    -
    transport
    -

    Transport module.

    -
    -
    transport_options
    -

    Transport options.

    -
    -
    protocol
    -

    Protocol module.

    -
    -
    protocol_options
    -

    Protocol options.

    -
    -
    -

    procs(Ref, acceptors | connections) -> [pid()]

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    -

    Return all acceptor or connection processes for one listener.

    -

    remove_connection(Ref) -> ok

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    -

    Do not count this connection when limiting the number of connections.

    -

    You can use this function for long-running connection processes which spend most of their time idling rather than consuming resources. This allows Ranch to accept a lot more connections without sacrificing the latency of the system.

    -

    This function may only be called from a connection process.

    -

    set_max_connections(Ref, MaxConns) -> ok

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    MaxConns = max_conns()
    -

    New maximum number of connections.

    -
    -
    -

    Set the max number of connections for the given listener.

    -

    The change will be applied immediately. If the new value is smaller than the previous one, Ranch will not kill the extra connections, but will wait for them to terminate properly.

    -

    set_protocol_options(Ref, ProtoOpts) -> ok

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    ProtoOpts = any()
    -

    New protocol options.

    -
    -
    -

    Set the protocol options for the given listener.

    -

    The change will be applied immediately for all new connections. Old connections will not receive the new options.

    -

    start_listener(Ref, NumAcceptors, Transport, TransOpts, Protocol, ProtoOpts) -> {ok, pid()} | {error, badarg}

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    NumAcceptors = non_neg_integer()
    -

    Number of acceptor processes.

    -
    -
    Transport = module()
    -

    Transport module.

    -
    -
    TransOpts = any()
    -

    Transport options.

    -
    -
    Protocol = module()
    -

    Protocol module.

    -
    -
    ProtoOpts = any()
    -

    Protocol options.

    -
    -
    -

    Start listening for connections using the given transport and protocol. Returns the pid for this listener's supervisor.

    -

    There are additional transport options that apply regardless of transport. They allow configuring how the connections are supervised, rate limited and more. Please consult the previous section for more details.

    -

    stop_listener(Ref) -> ok | {error, not_found}

    -
    Ref = ref()
    -

    Listener name.

    -
    -
    -

    Stop the given listener.

    -

    The listener is stopped gracefully, first by closing the listening port, then by stopping the connection processes. These processes are stopped according to the shutdown transport option, which may be set to brutally kill all connection processes or give them some time to stop properly.

    -

    This function does not return until the listener is completely stopped.

    - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - Function Reference - -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/manual/ranch_app/index.html b/docs/en/ranch/1.4/manual/ranch_app/index.html deleted file mode 100644 index b0f12daf..00000000 --- a/docs/en/ranch/1.4/manual/ranch_app/index.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - - - - Nine Nines: ranch(7) - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    ranch(7)

    - -

    Name

    -

    ranch - Socket acceptor pool for TCP protocols.

    -

    Dependencies

    -

    The ranch application depends on the ssl application to start. It is used for handling secure connections, when the transport is ranch_ssl. It can be disabled if SSL is not used.

    -

    Environment

    -

    The ranch application defines one application environment configuration parameter.

    -
    profile (false)
    -

    When enabled, Ranch will start eprof profiling automatically.

    -
    -
    -

    You can use the ranch_app:profile_output/0 function to stop profiling and output the results to the files procs.profile and total.profile. Do not use in production.

    - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - Function Reference - -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/manual/ranch_protocol/index.html b/docs/en/ranch/1.4/manual/ranch_protocol/index.html deleted file mode 100644 index d536f100..00000000 --- a/docs/en/ranch/1.4/manual/ranch_protocol/index.html +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - - - - Nine Nines: ranch_protocol(3) - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    ranch_protocol(3)

    - -

    Name

    -

    ranch_protocol - behaviour for protocol modules

    -

    Description

    -

    The ranch_protocol behaviour defines the interface used by Ranch protocols.

    -

    Types

    -

    None.

    -

    Callbacks

    -

    start_link(Ref, Socket, Transport, ProtoOpts) -> {ok, pid()} | {ok, pid(), pid()}

    -
    Ref = ranch:ref()
    -

    Listener name.

    -
    -
    Socket = any()
    -

    Socket for this connection.

    -
    -
    Transport = module()
    -

    Transport module for this socket.

    -
    -
    ProtoOpts = any()
    -

    Protocol options.

    -
    -
    -

    Start a new connection process for the given socket.

    -

    The only purpose of this callback is to start a process that will handle the socket. It must spawn the process, link and then return the new pid. This function will always be called from inside a supervisor.

    -

    This callback can also return two pids. The first pid is the pid of the process that will be supervised. The second pid is the pid of the process that will receive ownership of the socket. This second process must be a child of the first. This form is only available when connection_type is set to supervisor.

    -

    If any other value is returned, the supervisor will close the socket and assume no process has been started.

    -

    Do not perform any operations in this callback, as this would block the supervisor responsible for starting connection processes and degrade performance severely.

    - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - Function Reference - -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/manual/ranch_ssl/index.html b/docs/en/ranch/1.4/manual/ranch_ssl/index.html deleted file mode 100644 index 86b23fbf..00000000 --- a/docs/en/ranch/1.4/manual/ranch_ssl/index.html +++ /dev/null @@ -1,324 +0,0 @@ - - - - - - - - - - Nine Nines: ranch_ssl(3) - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    ranch_ssl(3)

    - -

    Name

    -

    ranch_ssl - SSL transport module

    -

    Description

    -

    The ranch_ssl module implements an SSL Ranch transport.

    -

    Types

    -

    ssl_opt()

    -
    -
    ssl_opt() = {alpn_preferred_protocols, [binary()]}
-	| {beast_mitigation, one_n_minus_one | zero_n | disabled}
-	| {cacertfile, string()}
-	| {cacerts, [public_key:der_encoded()]}
-	| {cert, public_key:der_encoded()}
-	| {certfile, string()}
-	| {ciphers, [ssl:erl_cipher_suite()] | string()}
-	| {client_renegotiation, boolean()}
-	| {crl_cache, {module(), {internal | any(), list()}}}
-	| {crl_check, boolean() | peer | best_effort}
-	| {depth, 0..255}
-	| {dh, public_key:der_encoded()}
-	| {dhfile, string()}
-	| {fail_if_no_peer_cert, boolean()}
-	| {hibernate_after, integer() | undefined}
-	| {honor_cipher_order, boolean()}
-	| {key, {'RSAPrivateKey' | 'DSAPrivateKey' | 'PrivateKeyInfo', public_key:der_encoded()}}
-	| {keyfile, string()}
-	| {log_alert, boolean()}
-	| {next_protocols_advertised, [binary()]}
-	| {padding_check, boolean()}
-	| {partial_chain, fun(([public_key:der_encoded()]) -> {trusted_ca, public_key:der_encoded()} | unknown_ca)}
-	| {password, string()}
-	| {psk_identity, string()}
-	| {reuse_session, fun()}
-	| {reuse_sessions, boolean()}
-	| {secure_renegotiate, boolean()}
-	| {signature_algs, [{atom(), atom()}]}
-	| {sni_fun, fun()}
-	| {sni_hosts, [{string(), ssl_opt()}]}
-	| {user_lookup_fun, {fun(), any()}}
-	| {v2_hello_compatible, boolean()}
-	| {verify, ssl:verify_type()}
-	| {verify_fun, {fun(), any()}}
-	| {versions, [atom()]}.
    -
    -

    SSL-specific listen options.

    -

    opt() = ranch_tcp:opt() | ssl_opt()

    -

    Listen options.

    -

    opts() = [opt()]

    -

    List of listen options.

    -

    Option descriptions

    -

    Specifying a certificate is mandatory, either through the cert or the certfile option. None of the other options are required.

    -

    The default value is given next to the option name.

    -
    alpn_preferred_protocols
    -

    Perform Application-Layer Protocol Negotiation with the given list of preferred protocols.

    -
    -
    beast_mitigation
    -

    Change the BEAST mitigation strategy for SSL-3.0 and TLS-1.0 to interoperate with legacy software.

    -
    -
    cacertfile
    -

    Path to PEM encoded trusted certificates file used to verify peer certificates.

    -
    -
    cacerts
    -

    List of DER encoded trusted certificates.

    -
    -
    cert
    -

    DER encoded user certificate.

    -
    -
    certfile
    -

    Path to the PEM encoded user certificate file. May also contain the private key.

    -
    -
    ciphers
    -

    List of ciphers that clients are allowed to use.

    -
    -
    client_renegotiation (true)
    -

    Whether to allow client-initiated renegotiation.

    -
    -
    crl_cache ({ssl_crl_cache, {internal, []}})
    -

    Customize the module used to cache Certificate Revocation Lists.

    -
    -
    crl_check (false)
    -

    Whether to perform CRL check on all certificates in the chain during validation.

    -
    -
    depth (1)
    -

    Maximum of intermediate certificates allowed in the certification path.

    -
    -
    dh
    -

    DER encoded Diffie-Hellman parameters.

    -
    -
    dhfile
    -

    Path to the PEM encoded Diffie-Hellman parameters file.

    -
    -
    fail_if_no_peer_cert (false)
    -

    Whether to refuse the connection if the client sends an empty certificate.

    -
    -
    hibernate_after (undefined)
    -

    Time in ms after which SSL socket processes go into hibernation to reduce memory usage.

    -
    -
    honor_cipher_order (false)
    -

    If true, use the server's preference for cipher selection. If false, use the client's preference.

    -
    -
    key
    -

    DER encoded user private key.

    -
    -
    keyfile
    -

    Path to the PEM encoded private key file, if different than the certfile.

    -
    -
    log_alert (true)
    -

    If false, error reports will not be displayed.

    -
    -
    next_protocols_advertised
    -

    List of protocols to send to the client if it supports the Next Protocol extension.

    -
    -
    nodelay (true)
    -

    Whether to enable TCP_NODELAY.

    -
    -
    padding_check
    -

    Allow disabling the block cipher padding check for TLS-1.0 to be able to interoperate with legacy software.

    -
    -
    partial_chain
    -

    Claim an intermediate CA in the chain as trusted.

    -
    -
    password
    -

    Password to the private key file, if password protected.

    -
    -
    psk_identity
    -

    Provide the given PSK identity hint to the client during the handshake.

    -
    -
    reuse_session
    -

    Custom policy to decide whether a session should be reused.

    -
    -
    reuse_sessions (false)
    -

    Whether to allow session reuse.

    -
    -
    secure_renegotiate (false)
    -

    Whether to reject renegotiation attempts that do not conform to RFC5746.

    -
    -
    signature_algs
    -

    The TLS signature algorithm extension may be used, from TLS 1.2, to negotiate which signature algorithm to use during the TLS handshake.

    -
    -
    sni_fun
    -

    Function called when the client requests a host using Server Name Indication. Returns options to apply.

    -
    -
    sni_hosts
    -

    Options to apply for the host that matches what the client requested with Server Name Indication.

    -
    -
    user_lookup_fun
    -

    Function called to determine the shared secret when using PSK, or provide parameters when using SRP.

    -
    -
    v2_hello_compatible
    -

    Accept clients that send hello messages in SSL-2.0 format while offering supported SSL/TLS versions.

    -
    -
    verify (verify_none)
    -

    Use verify_peer to request a certificate from the client.

    -
    -
    verify_fun
    -

    Custom policy to decide whether a client certificate is valid.

    -
    -
    versions
    -

    TLS protocol versions that will be supported.

    -
    -
    -

    Note that the client will not send a certificate unless the value for the verify option is set to verify_peer. This means that the fail_if_no_peer_cert only apply when combined with the verify option. The verify_fun option allows greater control over the client certificate validation.

    -

    The options sni_fun and sni_hosts are mutually exclusive.

    -

    Exports

    -

    None.

    - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - Function Reference - -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/manual/ranch_tcp/index.html b/docs/en/ranch/1.4/manual/ranch_tcp/index.html deleted file mode 100644 index 3a409a8c..00000000 --- a/docs/en/ranch/1.4/manual/ranch_tcp/index.html +++ /dev/null @@ -1,277 +0,0 @@ - - - - - - - - - - Nine Nines: ranch_tcp(3) - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    ranch_tcp(3)

    - -

    Name

    -

    ranch_tcp - TCP transport module

    -

    Description

    -

    The ranch_tcp module implements a TCP Ranch transport.

    -

    Note that due to bugs in OTP up to at least R16B02, it is recommended to disable async threads when using the sendfile function of this transport, as it can make the threads stuck indefinitely.

    -

    Types

    -

    opt()

    -
    -
    opt() = {backlog, non_neg_integer()}
-	| {buffer, non_neg_integer()}
-	| {delay_send, boolean()}
-	| {dontroute, boolean()}
-	| {exit_on_close, boolean()}
-	| {fd, non_neg_integer()}
-	| {high_msgq_watermark, non_neg_integer()}
-	| {high_watermark, non_neg_integer()}
-	| inet
-	| inet6
-	| {ip, inet:ip_address()}
-	| {ipv6_v6only, boolean()}
-	| {keepalive, boolean()}
-	| {linger, {boolean(), non_neg_integer()}}
-	| {low_msgq_watermark, non_neg_integer()}
-	| {low_watermark, non_neg_integer()}
-	| {nodelay, boolean()}
-	| {port, inet:port_number()}
-	| {priority, integer()}
-	| {raw, non_neg_integer(), non_neg_integer(), binary()}
-	| {recbuf, non_neg_integer()}
-	| {send_timeout, timeout()}
-	| {send_timeout_close, boolean()}
-	| {sndbuf, non_neg_integer()}
-	| {tos, integer()}
    -
    -

    Listen options.

    -

    This does not represent the entirety of the options that can be set on the socket, but only the options that may be set independently of protocol implementation.

    -

    opts() = [opt()]

    -

    List of listen options.

    -

    Option descriptions

    -

    None of the options are required.

    -

    Please consult the gen_tcp and inet manuals for a more thorough description of these options. This manual only aims to provide a short description along with what the defaults are. Defaults may be different in Ranch compared to gen_tcp. Defaults are given next to the option name.

    -
    backlog (1024)
    -

    Max length of the queue of pending connections.

    -
    -
    buffer
    -

    Size of the buffer used by the Erlang driver. Default is system-dependent.

    -
    -
    delay_send (false)
    -

    Always queue packets before sending, to send fewer, larger packets over the network.

    -
    -
    dontroute (false)
    -

    Don't send via a gateway, only send to directly connected hosts.

    -
    -
    exit_on_close (true)
    -

    Disable to allow sending data after a close has been detected.

    -
    -
    fd
    -

    File descriptor of the socket, if it was opened externally.

    -
    -
    high_msgq_watermark (8192)
    -

    Limit in the amount of data in the socket message queue before the socket queue becomes busy.

    -
    -
    high_watermark (8192)
    -

    Limit in the amount of data in the ERTS socket implementation's queue before the socket becomes busy.

    -
    -
    inet
    -

    Set up the socket for IPv4.

    -
    -
    inet6
    -

    Set up the socket for IPv6.

    -
    -
    ip
    -

    Interface to listen on. Listen on all interfaces by default.

    -
    -
    ipv6_v6only (false)
    -

    Listen on IPv4 and IPv6 (false) or only on IPv6 (true). Use with inet6.

    -
    -
    keepalive (false)
    -

    Enable sending of keep-alive messages.

    -
    -
    linger ({false, 0})
    -

    Whether to wait and how long to flush data sent before closing the socket.

    -
    -
    low_msgq_watermark (4096)
    -

    Amount of data in the socket message queue before the socket queue leaves busy state.

    -
    -
    low_watermark (4096)
    -

    Amount of data in the ERTS socket implementation's queue before the socket leaves busy state.

    -
    -
    nodelay (true)
    -

    Whether to enable TCP_NODELAY.

    -
    -
    port (0)
    -

    TCP port number to listen on. 0 means a random port will be used.

    -
    -
    priority (0)
    -

    Priority value for all packets to be sent by this socket.

    -
    -
    recbuf
    -

    Minimum size of the socket's receive buffer. Default is system-dependent.

    -
    -
    send_timeout (30000)
    -

    How long the send call may wait for confirmation before returning.

    -
    -
    send_timeout_close (true)
    -

    Whether to close the socket when the confirmation wasn't received.

    -
    -
    sndbuf
    -

    Minimum size of the socket's send buffer. Default is system-dependent.

    -
    -
    tos
    -

    Value for the IP_TOS IP level option. Use with caution.

    -
    -
    -

    In addition, the raw option can be used to set system-specific options by specifying the protocol level, the option number and the actual option value specified as a binary. This option is not portable. Use with caution.

    -

    Exports

    -

    None.

    - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - Function Reference - -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.4/manual/ranch_transport/index.html b/docs/en/ranch/1.4/manual/ranch_transport/index.html deleted file mode 100644 index b7318620..00000000 --- a/docs/en/ranch/1.4/manual/ranch_transport/index.html +++ /dev/null @@ -1,348 +0,0 @@ - - - - - - - - - - Nine Nines: ranch_transport(3) - - - - - - - - - - - - - - -
    -
    -
    -
    -

    99s

    -
    -
    - -
    - -
      -
    • - Github -
      • -
    • - -
      • -
    -
    -
    -
    -
    - - -
    - -
    -
    -
    -
    - -

    ranch_transport(3)

    - -

    Name

    -

    ranch_transport - behaviour for transport modules

    -

    Description

    -

    The ranch_transport behaviour defines the interface used by Ranch transports.

    -

    Types

    -

    sendfile_opts() = [{chunk_size, non_neg_integer()}]

    -

    Options used by the sendfile function and callbacks.

    -

    Allows configuring the chunk size, in bytes. Defaults to 8191 bytes.

    -

    Callbacks

    -

    accept(LSocket, Timeout) -> {ok, CSocket} | {error, closed | timeout | atom()}

    -
    LSocket = CSocket = any()
    -

    Listening socket.

    -
    -
    Timeout = timeout()
    -

    Accept timeout.

    -
    -
    -

    Accept a connection on the given listening socket.

    -

    The accept_ack callback will be used to initialize the socket after accepting the connection. This is most useful when the transport is not raw TCP, like with SSL for example.

    -

    accept_ack(CSocket, Timeout) -> ok

    -
    CSocket = any()
    -

    Socket for this connection.

    -
    -
    Timeout = timeout()
    -

    Ack timeout.

    -
    -
    -

    Perform post-accept initialization of the connection.

    -

    This function will be called by connection processes before performing any socket operation. It allows transports that require extra initialization to perform their task and make the socket ready to use.

    -

    close(Socket) -> ok

    -
    Socket = any()
    -

    Socket opened with listen/1 or accept/2.

    -
    -
    -

    Close the given socket.

    -

    controlling_process(Socket, Pid) -> ok | {error, closed | not_owner | atom()}

    -
    Socket = any()
    -

    Socket opened with listen/1 or accept/2.

    -
    -
    Pid = pid()
    -

    Pid of the new owner of the socket.

    -
    -
    -

    Change the controlling process for the given socket.

    -

    The controlling process is the process that is allowed to perform operations on the socket, and that will receive messages from the socket when active mode is used. When the controlling process dies, the socket is closed.

    -

    listen(TransOpts) -> {ok, LSocket} | {error, atom()}

    -
    TransOpts = any()
    -

    Transport options.

    -
    -
    LSocket = any()
    -

    Listening socket.

    -
    -
    -

    Listen for connections on the given port.

    -

    The port is given as part of the transport options under the key port. Any other option is transport dependent.

    -

    The socket returned by this call can then be used to accept connections. It is not possible to send or receive data from the listening socket.

    -

    messages() -> {OK, Closed, Error}

    -
    OK = Closed = Error = atom()
    -

    Tuple names.

    -
    -
    -

    Return the atoms used to identify messages sent in active mode.

    -

    name() -> Name

    -
    Name = atom()
    -

    Transport module name.

    -
    -
    -

    Return the name of the transport.

    -

    peername(CSocket) -> {ok, {IP, Port}} | {error, atom()}

    -
    CSocket = any()
    -

    Socket for this connection.

    -
    -
    IP = inet:ip_address()
    -

    IP of the remote endpoint.

    -
    -
    Port = inet:port_number()
    -

    Port of the remote endpoint.

    -
    -
    -

    Return the IP and port of the remote endpoint.

    -

    recv(CSocket, Length, Timeout) -> {ok, Packet} | {error, closed | timeout | atom()}

    -
    CSocket = any()
    -

    Socket for this connection.

    -
    -
    Length = non_neg_integer()
    -

    Requested length.

    -
    -
    Timeout = timeout()
    -

    Receive timeout.

    -
    -
    Packet = iodata() | any()
    -

    Data received.

    -
    -
    -

    Receive data from the given socket when in passive mode.

    -

    Trying to receive data from a socket that is in active mode will return an error.

    -

    A length of 0 will return any data available on the socket.

    -

    While it is possible to use the timeout value infinity, this is highly discouraged as this could cause your process to get stuck waiting for data that will never come. This may happen when a socket becomes half-open due to a crash of the remote endpoint. Wi-Fi going down is another common culprit of this issue.

    -

    send(CSocket, Packet) -> ok | {error, atom()}

    -
    CSocket = any()
    -

    Socket for this connection.

    -
    -
    Packet = iodata()
    -

    Data to be sent.

    -
    -
    -

    Send data to the given socket.

    -

    sendfile(CSocket, File) -> sendfile(CSocket, File, 0, 0, [])

    -

    Alias of ranch_transport:sendfile/5.

    -

    sendfile(CSocket, File, Offset, Bytes) -> sendfile(CSocket, File, Offset, Bytes, [])

    -

    Alias of ranch_transport:sendfile/5.

    -

    sendfile(CSocket, File, Offset, Bytes, SfOpts) -> {ok, SentBytes} | {error, atom()}

    -
    CSocket = any()
    -

    Socket for this connection.

    -
    -
    File = file:filename_all() | file:fd()
    -

    Filename or file descriptor for the file to be sent.

    -
    -
    Offset = non_neg_integer()
    -

    Begin sending at this position in the file.

    -
    -
    Bytes = non_neg_integer()
    -

    Send this many bytes.

    -
    -
    SentBytes = non_neg_integer()
    -

    This many bytes were sent.

    -
    -
    SfOpts = sendfile_opts()
    -

    Sendfile options.

    -
    -
    -

    Send data from a file to the given socket.

    -

    The file may be sent full or in parts, and may be specified by its filename or by an already open file descriptor.

    -

    Transports that manipulate TCP directly may use the file:sendfile/{2,4,5} function, which calls the sendfile syscall where applicable (on Linux, for example). Other transports can use the sendfile/6 function exported from this module.

    -

    setopts(CSocket, SockOpts) -> ok | {error, atom()}

    -
    CSocket = any()
    -

    Socket for this connection.

    -
    -
    SockOpts = any()
    -

    Socket options.

    -
    -
    -

    Change options for the given socket.

    -

    This is mainly useful for switching to active or passive mode or to set protocol-specific options.

    -

    shutdown(CSocket, How) -> ok | {error, atom()}

    -
    CSocket = any()
    -

    Socket for this connection.

    -
    -
    How = read | write | read_write
    -

    Which side(s) of the socket to close.

    -
    -
    -

    Immediately close the socket in one or two directions.

    -

    sockname(Socket) -> {ok, {IP, Port}} | {error, atom()}

    -
    Socket = any()
    -

    Socket opened with listen/1 or accept/2.

    -
    -
    IP = inet:ip_address()
    -

    IP of the local endpoint.

    -
    -
    Port = inet:port_number()
    -

    Port of the local endpoint.

    -
    -
    -

    Return the IP and port of the local endpoint.

    -

    Exports

    -

    sendfile(Transport, CSocket, File, Offset, Bytes, SfOpts) -> {ok, SentBytes} | {error, atom()}

    -
    Transport = module()
    -

    Transport module for this socket.

    -
    -
    CSocket = any()
    -

    Socket for this connection.

    -
    -
    File = file:filename_all() | file:fd()
    -

    Filename or file descriptor for the file to be sent.

    -
    -
    Offset = non_neg_integer()
    -

    Begin sending at this position in the file.

    -
    -
    Bytes = non_neg_integer()
    -

    Send this many bytes.

    -
    -
    SentBytes = non_neg_integer()
    -

    This many bytes were sent.

    -
    -
    SfOpts = sendfile_opts()
    -

    Sendfile options.

    -
    -
    -

    Send data from a file to the given socket.

    -

    This function emulates the function file:sendfile/{2,4,5} and may be used when transports are not manipulating TCP directly.

    - - - - - - -
    - -
    - - -

    - Ranch - 1.4 - Function Reference - -

    - - - -

    Navigation

    - -

    Version select

    - - -

    Like my work? Donate!

    -

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    -
    - - - - - - - - - -

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    - - - -
    -
    -
    -
    - - - - - - - - - diff --git a/docs/en/ranch/1.5/guide/embedded/index.html b/docs/en/ranch/1.5/guide/embedded/index.html index 87f2fd3c..92bce4ec 100644 --- a/docs/en/ranch/1.5/guide/embedded/index.html +++ b/docs/en/ranch/1.5/guide/embedded/index.html @@ -144,14 +144,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/guide/index.html b/docs/en/ranch/1.5/guide/index.html index abe45e70..d9046ef3 100644 --- a/docs/en/ranch/1.5/guide/index.html +++ b/docs/en/ranch/1.5/guide/index.html @@ -116,14 +116,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/guide/internals/index.html b/docs/en/ranch/1.5/guide/internals/index.html index 27e483f7..57e244db 100644 --- a/docs/en/ranch/1.5/guide/internals/index.html +++ b/docs/en/ranch/1.5/guide/internals/index.html @@ -144,14 +144,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/guide/introduction/index.html b/docs/en/ranch/1.5/guide/introduction/index.html index 797135fa..d5a2af7e 100644 --- a/docs/en/ranch/1.5/guide/introduction/index.html +++ b/docs/en/ranch/1.5/guide/introduction/index.html @@ -128,14 +128,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/guide/listeners/index.html b/docs/en/ranch/1.5/guide/listeners/index.html index 77f26316..6a8330a6 100644 --- a/docs/en/ranch/1.5/guide/listeners/index.html +++ b/docs/en/ranch/1.5/guide/listeners/index.html @@ -327,14 +327,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/guide/parsers/index.html b/docs/en/ranch/1.5/guide/parsers/index.html index f120e03a..7dfa3675 100644 --- a/docs/en/ranch/1.5/guide/parsers/index.html +++ b/docs/en/ranch/1.5/guide/parsers/index.html @@ -183,14 +183,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/guide/protocols/index.html b/docs/en/ranch/1.5/guide/protocols/index.html index 1ccfd5de..dcba343e 100644 --- a/docs/en/ranch/1.5/guide/protocols/index.html +++ b/docs/en/ranch/1.5/guide/protocols/index.html @@ -190,14 +190,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/guide/ssl_auth/index.html b/docs/en/ranch/1.5/guide/ssl_auth/index.html index faf14231..317953d4 100644 --- a/docs/en/ranch/1.5/guide/ssl_auth/index.html +++ b/docs/en/ranch/1.5/guide/ssl_auth/index.html @@ -196,14 +196,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/guide/transports/index.html b/docs/en/ranch/1.5/guide/transports/index.html index 84f25c16..edaf0cd4 100644 --- a/docs/en/ranch/1.5/guide/transports/index.html +++ b/docs/en/ranch/1.5/guide/transports/index.html @@ -221,14 +221,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/manual/index.html b/docs/en/ranch/1.5/manual/index.html index 40e5f88b..34b26786 100644 --- a/docs/en/ranch/1.5/manual/index.html +++ b/docs/en/ranch/1.5/manual/index.html @@ -112,14 +112,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/manual/ranch/index.html b/docs/en/ranch/1.5/manual/ranch/index.html index 0b7691d7..d4f19adb 100644 --- a/docs/en/ranch/1.5/manual/ranch/index.html +++ b/docs/en/ranch/1.5/manual/ranch/index.html @@ -324,14 +324,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/manual/ranch_app/index.html b/docs/en/ranch/1.5/manual/ranch_app/index.html index 9e6be26e..74797ea0 100644 --- a/docs/en/ranch/1.5/manual/ranch_app/index.html +++ b/docs/en/ranch/1.5/manual/ranch_app/index.html @@ -110,14 +110,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/manual/ranch_protocol/index.html b/docs/en/ranch/1.5/manual/ranch_protocol/index.html index 982d3b3b..d4ed8a92 100644 --- a/docs/en/ranch/1.5/manual/ranch_protocol/index.html +++ b/docs/en/ranch/1.5/manual/ranch_protocol/index.html @@ -125,14 +125,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/manual/ranch_ssl/index.html b/docs/en/ranch/1.5/manual/ranch_ssl/index.html index 7c361102..2e732ec8 100644 --- a/docs/en/ranch/1.5/manual/ranch_ssl/index.html +++ b/docs/en/ranch/1.5/manual/ranch_ssl/index.html @@ -266,14 +266,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/manual/ranch_tcp/index.html b/docs/en/ranch/1.5/manual/ranch_tcp/index.html index fb2b1667..6f5113bc 100644 --- a/docs/en/ranch/1.5/manual/ranch_tcp/index.html +++ b/docs/en/ranch/1.5/manual/ranch_tcp/index.html @@ -219,14 +219,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.5/manual/ranch_transport/index.html b/docs/en/ranch/1.5/manual/ranch_transport/index.html index ae45786a..a5057cfa 100644 --- a/docs/en/ranch/1.5/manual/ranch_transport/index.html +++ b/docs/en/ranch/1.5/manual/ranch_transport/index.html @@ -323,14 +323,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/embedded/index.html b/docs/en/ranch/1.6/guide/embedded/index.html index 0f2f0fc5..c4c06ce5 100644 --- a/docs/en/ranch/1.6/guide/embedded/index.html +++ b/docs/en/ranch/1.6/guide/embedded/index.html @@ -144,14 +144,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/index.html b/docs/en/ranch/1.6/guide/index.html index 97427b53..0709c58a 100644 --- a/docs/en/ranch/1.6/guide/index.html +++ b/docs/en/ranch/1.6/guide/index.html @@ -131,14 +131,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/internals/index.html b/docs/en/ranch/1.6/guide/internals/index.html index 49de2a00..6f81096b 100644 --- a/docs/en/ranch/1.6/guide/internals/index.html +++ b/docs/en/ranch/1.6/guide/internals/index.html @@ -148,14 +148,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/introduction/index.html b/docs/en/ranch/1.6/guide/introduction/index.html index 04b0280b..09bf2d5b 100644 --- a/docs/en/ranch/1.6/guide/introduction/index.html +++ b/docs/en/ranch/1.6/guide/introduction/index.html @@ -128,14 +128,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/listeners/index.html b/docs/en/ranch/1.6/guide/listeners/index.html index 4b6ec9ab..68bcbe3e 100644 --- a/docs/en/ranch/1.6/guide/listeners/index.html +++ b/docs/en/ranch/1.6/guide/listeners/index.html @@ -363,14 +363,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/migrating_from_1.5/index.html b/docs/en/ranch/1.6/guide/migrating_from_1.5/index.html index efe83dc0..4f3d4f52 100644 --- a/docs/en/ranch/1.6/guide/migrating_from_1.5/index.html +++ b/docs/en/ranch/1.6/guide/migrating_from_1.5/index.html @@ -163,14 +163,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/migrating_from_1.6/index.html b/docs/en/ranch/1.6/guide/migrating_from_1.6/index.html index 6b08997b..749ac6eb 100644 --- a/docs/en/ranch/1.6/guide/migrating_from_1.6/index.html +++ b/docs/en/ranch/1.6/guide/migrating_from_1.6/index.html @@ -126,14 +126,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/migrating_from_1.x/index.html b/docs/en/ranch/1.6/guide/migrating_from_1.x/index.html index 8cc76c00..8364a90f 100644 --- a/docs/en/ranch/1.6/guide/migrating_from_1.x/index.html +++ b/docs/en/ranch/1.6/guide/migrating_from_1.x/index.html @@ -216,14 +216,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/parsers/index.html b/docs/en/ranch/1.6/guide/parsers/index.html index 80946740..627d524b 100644 --- a/docs/en/ranch/1.6/guide/parsers/index.html +++ b/docs/en/ranch/1.6/guide/parsers/index.html @@ -183,14 +183,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/protocols/index.html b/docs/en/ranch/1.6/guide/protocols/index.html index bba86d75..4939bfdf 100644 --- a/docs/en/ranch/1.6/guide/protocols/index.html +++ b/docs/en/ranch/1.6/guide/protocols/index.html @@ -190,14 +190,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/ssl_auth/index.html b/docs/en/ranch/1.6/guide/ssl_auth/index.html index 75dbccac..058a22b3 100644 --- a/docs/en/ranch/1.6/guide/ssl_auth/index.html +++ b/docs/en/ranch/1.6/guide/ssl_auth/index.html @@ -196,14 +196,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/transports/index.html b/docs/en/ranch/1.6/guide/transports/index.html index d5cfc3f3..ab24caec 100644 --- a/docs/en/ranch/1.6/guide/transports/index.html +++ b/docs/en/ranch/1.6/guide/transports/index.html @@ -230,14 +230,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/guide/upcoming_2.0_changes/index.html b/docs/en/ranch/1.6/guide/upcoming_2.0_changes/index.html index 37e3ecfc..007b4b6f 100644 --- a/docs/en/ranch/1.6/guide/upcoming_2.0_changes/index.html +++ b/docs/en/ranch/1.6/guide/upcoming_2.0_changes/index.html @@ -137,14 +137,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/index.html b/docs/en/ranch/1.6/manual/index.html index 7bea4b7c..d9b2ad1d 100644 --- a/docs/en/ranch/1.6/manual/index.html +++ b/docs/en/ranch/1.6/manual/index.html @@ -141,14 +141,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.child_spec/index.html b/docs/en/ranch/1.6/manual/ranch.child_spec/index.html index fdcc3917..686de6a3 100644 --- a/docs/en/ranch/1.6/manual/ranch.child_spec/index.html +++ b/docs/en/ranch/1.6/manual/ranch.child_spec/index.html @@ -161,14 +161,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.get_addr/index.html b/docs/en/ranch/1.6/manual/ranch.get_addr/index.html index 2eb6a4aa..ed9ef2fb 100644 --- a/docs/en/ranch/1.6/manual/ranch.get_addr/index.html +++ b/docs/en/ranch/1.6/manual/ranch.get_addr/index.html @@ -129,14 +129,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.get_max_connections/index.html b/docs/en/ranch/1.6/manual/ranch.get_max_connections/index.html index 5a947ab5..340305de 100644 --- a/docs/en/ranch/1.6/manual/ranch.get_max_connections/index.html +++ b/docs/en/ranch/1.6/manual/ranch.get_max_connections/index.html @@ -127,14 +127,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.get_port/index.html b/docs/en/ranch/1.6/manual/ranch.get_port/index.html index f7881318..aead1e9c 100644 --- a/docs/en/ranch/1.6/manual/ranch.get_port/index.html +++ b/docs/en/ranch/1.6/manual/ranch.get_port/index.html @@ -128,14 +128,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.get_protocol_options/index.html b/docs/en/ranch/1.6/manual/ranch.get_protocol_options/index.html index ce284b93..efd2a073 100644 --- a/docs/en/ranch/1.6/manual/ranch.get_protocol_options/index.html +++ b/docs/en/ranch/1.6/manual/ranch.get_protocol_options/index.html @@ -127,14 +127,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.get_status/index.html b/docs/en/ranch/1.6/manual/ranch.get_status/index.html index 84db922a..bff164d4 100644 --- a/docs/en/ranch/1.6/manual/ranch.get_status/index.html +++ b/docs/en/ranch/1.6/manual/ranch.get_status/index.html @@ -130,14 +130,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.get_transport_options/index.html b/docs/en/ranch/1.6/manual/ranch.get_transport_options/index.html index a8487bcf..0b8bc9a8 100644 --- a/docs/en/ranch/1.6/manual/ranch.get_transport_options/index.html +++ b/docs/en/ranch/1.6/manual/ranch.get_transport_options/index.html @@ -127,14 +127,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.handshake/index.html b/docs/en/ranch/1.6/manual/ranch.handshake/index.html index 8b7e4fde..cb0631b5 100644 --- a/docs/en/ranch/1.6/manual/ranch.handshake/index.html +++ b/docs/en/ranch/1.6/manual/ranch.handshake/index.html @@ -150,14 +150,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.info/index.html b/docs/en/ranch/1.6/manual/ranch.info/index.html index 04b3d7f7..9363446d 100644 --- a/docs/en/ranch/1.6/manual/ranch.info/index.html +++ b/docs/en/ranch/1.6/manual/ranch.info/index.html @@ -175,14 +175,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.procs/index.html b/docs/en/ranch/1.6/manual/ranch.procs/index.html index 6e408705..41cade9b 100644 --- a/docs/en/ranch/1.6/manual/ranch.procs/index.html +++ b/docs/en/ranch/1.6/manual/ranch.procs/index.html @@ -138,14 +138,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.remove_connection/index.html b/docs/en/ranch/1.6/manual/ranch.remove_connection/index.html index d48df6fd..9ce3b568 100644 --- a/docs/en/ranch/1.6/manual/ranch.remove_connection/index.html +++ b/docs/en/ranch/1.6/manual/ranch.remove_connection/index.html @@ -128,14 +128,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.resume_listener/index.html b/docs/en/ranch/1.6/manual/ranch.resume_listener/index.html index a41912de..bab4fc9f 100644 --- a/docs/en/ranch/1.6/manual/ranch.resume_listener/index.html +++ b/docs/en/ranch/1.6/manual/ranch.resume_listener/index.html @@ -134,14 +134,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.set_max_connections/index.html b/docs/en/ranch/1.6/manual/ranch.set_max_connections/index.html index 53560457..866e7010 100644 --- a/docs/en/ranch/1.6/manual/ranch.set_max_connections/index.html +++ b/docs/en/ranch/1.6/manual/ranch.set_max_connections/index.html @@ -132,14 +132,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.set_protocol_options/index.html b/docs/en/ranch/1.6/manual/ranch.set_protocol_options/index.html index 8460b4bc..1dc723e1 100644 --- a/docs/en/ranch/1.6/manual/ranch.set_protocol_options/index.html +++ b/docs/en/ranch/1.6/manual/ranch.set_protocol_options/index.html @@ -132,14 +132,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.set_transport_options/index.html b/docs/en/ranch/1.6/manual/ranch.set_transport_options/index.html index 154a947b..41ec2431 100644 --- a/docs/en/ranch/1.6/manual/ranch.set_transport_options/index.html +++ b/docs/en/ranch/1.6/manual/ranch.set_transport_options/index.html @@ -137,14 +137,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.start_listener/index.html b/docs/en/ranch/1.6/manual/ranch.start_listener/index.html index fdeaf569..1024db56 100644 --- a/docs/en/ranch/1.6/manual/ranch.start_listener/index.html +++ b/docs/en/ranch/1.6/manual/ranch.start_listener/index.html @@ -186,14 +186,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.stop_listener/index.html b/docs/en/ranch/1.6/manual/ranch.stop_listener/index.html index 02384014..17dc1ba5 100644 --- a/docs/en/ranch/1.6/manual/ranch.stop_listener/index.html +++ b/docs/en/ranch/1.6/manual/ranch.stop_listener/index.html @@ -131,14 +131,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.suspend_listener/index.html b/docs/en/ranch/1.6/manual/ranch.suspend_listener/index.html index 08892a30..147a6ba3 100644 --- a/docs/en/ranch/1.6/manual/ranch.suspend_listener/index.html +++ b/docs/en/ranch/1.6/manual/ranch.suspend_listener/index.html @@ -135,14 +135,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch.wait_for_connections/index.html b/docs/en/ranch/1.6/manual/ranch.wait_for_connections/index.html index d5a2fcad..f38e6c82 100644 --- a/docs/en/ranch/1.6/manual/ranch.wait_for_connections/index.html +++ b/docs/en/ranch/1.6/manual/ranch.wait_for_connections/index.html @@ -155,14 +155,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch/index.html b/docs/en/ranch/1.6/manual/ranch/index.html index 6b6d5d91..1ffd585f 100644 --- a/docs/en/ranch/1.6/manual/ranch/index.html +++ b/docs/en/ranch/1.6/manual/ranch/index.html @@ -238,14 +238,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch_app/index.html b/docs/en/ranch/1.6/manual/ranch_app/index.html index 2e48a05f..c8acc2e0 100644 --- a/docs/en/ranch/1.6/manual/ranch_app/index.html +++ b/docs/en/ranch/1.6/manual/ranch_app/index.html @@ -141,14 +141,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch_protocol/index.html b/docs/en/ranch/1.6/manual/ranch_protocol/index.html index 835da7c7..e97c765e 100644 --- a/docs/en/ranch/1.6/manual/ranch_protocol/index.html +++ b/docs/en/ranch/1.6/manual/ranch_protocol/index.html @@ -127,14 +127,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch_ssl/index.html b/docs/en/ranch/1.6/manual/ranch_ssl/index.html index 9346d466..c9ddbcdd 100644 --- a/docs/en/ranch/1.6/manual/ranch_ssl/index.html +++ b/docs/en/ranch/1.6/manual/ranch_ssl/index.html @@ -279,14 +279,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch_tcp/index.html b/docs/en/ranch/1.6/manual/ranch_tcp/index.html index 12c5932f..eb34b470 100644 --- a/docs/en/ranch/1.6/manual/ranch_tcp/index.html +++ b/docs/en/ranch/1.6/manual/ranch_tcp/index.html @@ -226,14 +226,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch_transport.sendfile/index.html b/docs/en/ranch/1.6/manual/ranch_transport.sendfile/index.html index 6d30c2e0..870c5616 100644 --- a/docs/en/ranch/1.6/manual/ranch_transport.sendfile/index.html +++ b/docs/en/ranch/1.6/manual/ranch_transport.sendfile/index.html @@ -162,14 +162,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.6/manual/ranch_transport/index.html b/docs/en/ranch/1.6/manual/ranch_transport/index.html index 014c489f..b5995224 100644 --- a/docs/en/ranch/1.6/manual/ranch_transport/index.html +++ b/docs/en/ranch/1.6/manual/ranch_transport/index.html @@ -327,14 +327,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/embedded/index.html b/docs/en/ranch/1.7/guide/embedded/index.html index ac531b73..2b7e5a77 100644 --- a/docs/en/ranch/1.7/guide/embedded/index.html +++ b/docs/en/ranch/1.7/guide/embedded/index.html @@ -144,14 +144,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/index.html b/docs/en/ranch/1.7/guide/index.html index 951cfca0..747923c4 100644 --- a/docs/en/ranch/1.7/guide/index.html +++ b/docs/en/ranch/1.7/guide/index.html @@ -133,14 +133,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/internals/index.html b/docs/en/ranch/1.7/guide/internals/index.html index 7b486899..7584b9c1 100644 --- a/docs/en/ranch/1.7/guide/internals/index.html +++ b/docs/en/ranch/1.7/guide/internals/index.html @@ -148,14 +148,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/introduction/index.html b/docs/en/ranch/1.7/guide/introduction/index.html index 9ba66e04..f5f99166 100644 --- a/docs/en/ranch/1.7/guide/introduction/index.html +++ b/docs/en/ranch/1.7/guide/introduction/index.html @@ -127,14 +127,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/listeners/index.html b/docs/en/ranch/1.7/guide/listeners/index.html index e2da11d5..15f0979d 100644 --- a/docs/en/ranch/1.7/guide/listeners/index.html +++ b/docs/en/ranch/1.7/guide/listeners/index.html @@ -363,14 +363,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/migrating_from_1.5/index.html b/docs/en/ranch/1.7/guide/migrating_from_1.5/index.html index d701fbf5..2b9cb65c 100644 --- a/docs/en/ranch/1.7/guide/migrating_from_1.5/index.html +++ b/docs/en/ranch/1.7/guide/migrating_from_1.5/index.html @@ -163,14 +163,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/migrating_from_1.6/index.html b/docs/en/ranch/1.7/guide/migrating_from_1.6/index.html index b07aa68d..94d71407 100644 --- a/docs/en/ranch/1.7/guide/migrating_from_1.6/index.html +++ b/docs/en/ranch/1.7/guide/migrating_from_1.6/index.html @@ -143,14 +143,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/migrating_from_1.7/index.html b/docs/en/ranch/1.7/guide/migrating_from_1.7/index.html index 32cd783c..b88e54d4 100644 --- a/docs/en/ranch/1.7/guide/migrating_from_1.7/index.html +++ b/docs/en/ranch/1.7/guide/migrating_from_1.7/index.html @@ -125,14 +125,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/migrating_from_1.x/index.html b/docs/en/ranch/1.7/guide/migrating_from_1.x/index.html index 36747e4c..17bb5aac 100644 --- a/docs/en/ranch/1.7/guide/migrating_from_1.x/index.html +++ b/docs/en/ranch/1.7/guide/migrating_from_1.x/index.html @@ -216,14 +216,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/parsers/index.html b/docs/en/ranch/1.7/guide/parsers/index.html index dbacf921..78a49adc 100644 --- a/docs/en/ranch/1.7/guide/parsers/index.html +++ b/docs/en/ranch/1.7/guide/parsers/index.html @@ -183,14 +183,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/protocols/index.html b/docs/en/ranch/1.7/guide/protocols/index.html index 63a92582..93e8e08a 100644 --- a/docs/en/ranch/1.7/guide/protocols/index.html +++ b/docs/en/ranch/1.7/guide/protocols/index.html @@ -190,14 +190,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/ssl_auth/index.html b/docs/en/ranch/1.7/guide/ssl_auth/index.html index 3f982950..6b5601b2 100644 --- a/docs/en/ranch/1.7/guide/ssl_auth/index.html +++ b/docs/en/ranch/1.7/guide/ssl_auth/index.html @@ -196,14 +196,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/transports/index.html b/docs/en/ranch/1.7/guide/transports/index.html index dbcdff8f..110de678 100644 --- a/docs/en/ranch/1.7/guide/transports/index.html +++ b/docs/en/ranch/1.7/guide/transports/index.html @@ -230,14 +230,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/guide/upcoming_2.0_changes/index.html b/docs/en/ranch/1.7/guide/upcoming_2.0_changes/index.html index d44f8ad2..d6378b69 100644 --- a/docs/en/ranch/1.7/guide/upcoming_2.0_changes/index.html +++ b/docs/en/ranch/1.7/guide/upcoming_2.0_changes/index.html @@ -137,14 +137,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/index.html b/docs/en/ranch/1.7/manual/index.html index 565ab309..ef95ccba 100644 --- a/docs/en/ranch/1.7/manual/index.html +++ b/docs/en/ranch/1.7/manual/index.html @@ -143,14 +143,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.child_spec/index.html b/docs/en/ranch/1.7/manual/ranch.child_spec/index.html index bd044260..adb5f09d 100644 --- a/docs/en/ranch/1.7/manual/ranch.child_spec/index.html +++ b/docs/en/ranch/1.7/manual/ranch.child_spec/index.html @@ -161,14 +161,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.get_addr/index.html b/docs/en/ranch/1.7/manual/ranch.get_addr/index.html index 45312bfc..76bce6c0 100644 --- a/docs/en/ranch/1.7/manual/ranch.get_addr/index.html +++ b/docs/en/ranch/1.7/manual/ranch.get_addr/index.html @@ -129,14 +129,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.get_max_connections/index.html b/docs/en/ranch/1.7/manual/ranch.get_max_connections/index.html index 60032724..3d224ad6 100644 --- a/docs/en/ranch/1.7/manual/ranch.get_max_connections/index.html +++ b/docs/en/ranch/1.7/manual/ranch.get_max_connections/index.html @@ -127,14 +127,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.get_port/index.html b/docs/en/ranch/1.7/manual/ranch.get_port/index.html index 3a2fd42c..fdd4ccc1 100644 --- a/docs/en/ranch/1.7/manual/ranch.get_port/index.html +++ b/docs/en/ranch/1.7/manual/ranch.get_port/index.html @@ -128,14 +128,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.get_protocol_options/index.html b/docs/en/ranch/1.7/manual/ranch.get_protocol_options/index.html index 1ce38f12..56aa1927 100644 --- a/docs/en/ranch/1.7/manual/ranch.get_protocol_options/index.html +++ b/docs/en/ranch/1.7/manual/ranch.get_protocol_options/index.html @@ -127,14 +127,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.get_status/index.html b/docs/en/ranch/1.7/manual/ranch.get_status/index.html index 7e88c096..bd793db6 100644 --- a/docs/en/ranch/1.7/manual/ranch.get_status/index.html +++ b/docs/en/ranch/1.7/manual/ranch.get_status/index.html @@ -130,14 +130,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.get_transport_options/index.html b/docs/en/ranch/1.7/manual/ranch.get_transport_options/index.html index ba09d481..4d3c3549 100644 --- a/docs/en/ranch/1.7/manual/ranch.get_transport_options/index.html +++ b/docs/en/ranch/1.7/manual/ranch.get_transport_options/index.html @@ -127,14 +127,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.handshake/index.html b/docs/en/ranch/1.7/manual/ranch.handshake/index.html index 637ea1c3..1fae618b 100644 --- a/docs/en/ranch/1.7/manual/ranch.handshake/index.html +++ b/docs/en/ranch/1.7/manual/ranch.handshake/index.html @@ -150,14 +150,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.info/index.html b/docs/en/ranch/1.7/manual/ranch.info/index.html index 3509c3ba..2d4823fc 100644 --- a/docs/en/ranch/1.7/manual/ranch.info/index.html +++ b/docs/en/ranch/1.7/manual/ranch.info/index.html @@ -175,14 +175,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.procs/index.html b/docs/en/ranch/1.7/manual/ranch.procs/index.html index 842efa69..6c8e9034 100644 --- a/docs/en/ranch/1.7/manual/ranch.procs/index.html +++ b/docs/en/ranch/1.7/manual/ranch.procs/index.html @@ -138,14 +138,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.recv_proxy_header/index.html b/docs/en/ranch/1.7/manual/ranch.recv_proxy_header/index.html index 7bd22ba0..96c75337 100644 --- a/docs/en/ranch/1.7/manual/ranch.recv_proxy_header/index.html +++ b/docs/en/ranch/1.7/manual/ranch.recv_proxy_header/index.html @@ -148,14 +148,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.remove_connection/index.html b/docs/en/ranch/1.7/manual/ranch.remove_connection/index.html index fd3f4145..9652c8f9 100644 --- a/docs/en/ranch/1.7/manual/ranch.remove_connection/index.html +++ b/docs/en/ranch/1.7/manual/ranch.remove_connection/index.html @@ -128,14 +128,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.resume_listener/index.html b/docs/en/ranch/1.7/manual/ranch.resume_listener/index.html index 3b4c08af..bdf1da3a 100644 --- a/docs/en/ranch/1.7/manual/ranch.resume_listener/index.html +++ b/docs/en/ranch/1.7/manual/ranch.resume_listener/index.html @@ -134,14 +134,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.set_max_connections/index.html b/docs/en/ranch/1.7/manual/ranch.set_max_connections/index.html index 86747914..479ea53d 100644 --- a/docs/en/ranch/1.7/manual/ranch.set_max_connections/index.html +++ b/docs/en/ranch/1.7/manual/ranch.set_max_connections/index.html @@ -132,14 +132,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.set_protocol_options/index.html b/docs/en/ranch/1.7/manual/ranch.set_protocol_options/index.html index d023ee06..59c46623 100644 --- a/docs/en/ranch/1.7/manual/ranch.set_protocol_options/index.html +++ b/docs/en/ranch/1.7/manual/ranch.set_protocol_options/index.html @@ -132,14 +132,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.set_transport_options/index.html b/docs/en/ranch/1.7/manual/ranch.set_transport_options/index.html index 486b38c9..ca1d12f0 100644 --- a/docs/en/ranch/1.7/manual/ranch.set_transport_options/index.html +++ b/docs/en/ranch/1.7/manual/ranch.set_transport_options/index.html @@ -137,14 +137,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.start_listener/index.html b/docs/en/ranch/1.7/manual/ranch.start_listener/index.html index a7f84420..c9dd2bff 100644 --- a/docs/en/ranch/1.7/manual/ranch.start_listener/index.html +++ b/docs/en/ranch/1.7/manual/ranch.start_listener/index.html @@ -186,14 +186,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.stop_listener/index.html b/docs/en/ranch/1.7/manual/ranch.stop_listener/index.html index 20a45e1f..3ff73f48 100644 --- a/docs/en/ranch/1.7/manual/ranch.stop_listener/index.html +++ b/docs/en/ranch/1.7/manual/ranch.stop_listener/index.html @@ -131,14 +131,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.suspend_listener/index.html b/docs/en/ranch/1.7/manual/ranch.suspend_listener/index.html index db81988f..cc9262ce 100644 --- a/docs/en/ranch/1.7/manual/ranch.suspend_listener/index.html +++ b/docs/en/ranch/1.7/manual/ranch.suspend_listener/index.html @@ -135,14 +135,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch.wait_for_connections/index.html b/docs/en/ranch/1.7/manual/ranch.wait_for_connections/index.html index 47bdde6f..919c1c35 100644 --- a/docs/en/ranch/1.7/manual/ranch.wait_for_connections/index.html +++ b/docs/en/ranch/1.7/manual/ranch.wait_for_connections/index.html @@ -155,14 +155,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch/index.html b/docs/en/ranch/1.7/manual/ranch/index.html index 111ddc3a..cbdf432c 100644 --- a/docs/en/ranch/1.7/manual/ranch/index.html +++ b/docs/en/ranch/1.7/manual/ranch/index.html @@ -240,14 +240,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch_app/index.html b/docs/en/ranch/1.7/manual/ranch_app/index.html index 9152d14b..f58475f7 100644 --- a/docs/en/ranch/1.7/manual/ranch_app/index.html +++ b/docs/en/ranch/1.7/manual/ranch_app/index.html @@ -143,14 +143,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch_protocol/index.html b/docs/en/ranch/1.7/manual/ranch_protocol/index.html index da1d6a4a..a52f14bb 100644 --- a/docs/en/ranch/1.7/manual/ranch_protocol/index.html +++ b/docs/en/ranch/1.7/manual/ranch_protocol/index.html @@ -127,14 +127,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch_proxy_header.header/index.html b/docs/en/ranch/1.7/manual/ranch_proxy_header.header/index.html index 3a7c3d8d..60ef4508 100644 --- a/docs/en/ranch/1.7/manual/ranch_proxy_header.header/index.html +++ b/docs/en/ranch/1.7/manual/ranch_proxy_header.header/index.html @@ -162,14 +162,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch_proxy_header.parse/index.html b/docs/en/ranch/1.7/manual/ranch_proxy_header.parse/index.html index 65085f88..52c8f30b 100644 --- a/docs/en/ranch/1.7/manual/ranch_proxy_header.parse/index.html +++ b/docs/en/ranch/1.7/manual/ranch_proxy_header.parse/index.html @@ -133,14 +133,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch_proxy_header/index.html b/docs/en/ranch/1.7/manual/ranch_proxy_header/index.html index 9ff845ee..ad564bf8 100644 --- a/docs/en/ranch/1.7/manual/ranch_proxy_header/index.html +++ b/docs/en/ranch/1.7/manual/ranch_proxy_header/index.html @@ -216,14 +216,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch_ssl/index.html b/docs/en/ranch/1.7/manual/ranch_ssl/index.html index 1d8f308d..d470490d 100644 --- a/docs/en/ranch/1.7/manual/ranch_ssl/index.html +++ b/docs/en/ranch/1.7/manual/ranch_ssl/index.html @@ -279,14 +279,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch_tcp/index.html b/docs/en/ranch/1.7/manual/ranch_tcp/index.html index eeee21d0..41b43189 100644 --- a/docs/en/ranch/1.7/manual/ranch_tcp/index.html +++ b/docs/en/ranch/1.7/manual/ranch_tcp/index.html @@ -226,14 +226,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch_transport.sendfile/index.html b/docs/en/ranch/1.7/manual/ranch_transport.sendfile/index.html index e29578a5..1c2b1e9c 100644 --- a/docs/en/ranch/1.7/manual/ranch_transport.sendfile/index.html +++ b/docs/en/ranch/1.7/manual/ranch_transport.sendfile/index.html @@ -162,14 +162,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.7/manual/ranch_transport/index.html b/docs/en/ranch/1.7/manual/ranch_transport/index.html index 17823b41..c03e5d3d 100644 --- a/docs/en/ranch/1.7/manual/ranch_transport/index.html +++ b/docs/en/ranch/1.7/manual/ranch_transport/index.html @@ -327,14 +327,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/1.8/guide/embedded.asciidoc b/docs/en/ranch/1.8/guide/embedded.asciidoc new file mode 100644 index 00000000..55c018b1 --- /dev/null +++ b/docs/en/ranch/1.8/guide/embedded.asciidoc @@ -0,0 +1,48 @@ +== Embedded mode + +Embedded mode allows you to insert Ranch listeners directly +in your supervision tree. This allows for greater fault tolerance +control by permitting the shutdown of a listener due to the +failure of another part of the application and vice versa. + +=== Embedding + +To embed Ranch in your application you can simply add the child specs +to your supervision tree. This can all be done in the `init/1` function +of one of your application supervisors. + +Ranch requires at the minimum two kinds of child specs for embedding. +First, you need to add `ranch_sup` to your supervision tree, only once, +regardless of the number of listeners you will use. Then you need to +add the child specs for each listener. + +Ranch has a convenience function for getting the listeners child specs +called `ranch:child_spec/5`, that works like `ranch:start_listener/5`, +except that it doesn't start anything, it only returns child specs. + +As for `ranch_sup`, the child spec is simple enough to not require a +convenience function. + +The following example adds both `ranch_sup` and one listener to another +application's supervision tree. + +.Embed Ranch directly in your supervision tree + +[source,erlang] +---- +init([]) -> + RanchSupSpec = {ranch_sup, {ranch_sup, start_link, []}, + permanent, 5000, supervisor, [ranch_sup]}, + ListenerSpec = ranch:child_spec(echo, 100, + ranch_tcp, [{port, 5555}], + echo_protocol, [] + ), + {ok, {{one_for_one, 10, 10}, [RanchSupSpec, ListenerSpec]}}. +---- + +Remember, you can add as many listener child specs as needed, but only +one `ranch_sup` spec! + +It is recommended that your architecture makes sure that all listeners +are restarted if `ranch_sup` fails. See the Ranch internals chapter for +more details on how Ranch does it. diff --git a/docs/en/ranch/1.8/guide/embedded/index.html b/docs/en/ranch/1.8/guide/embedded/index.html new file mode 100644 index 00000000..f217a78c --- /dev/null +++ b/docs/en/ranch/1.8/guide/embedded/index.html @@ -0,0 +1,202 @@ + + + + + + + + + + Nine Nines: Embedded mode + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Embedded mode

    + +

    Embedded mode allows you to insert Ranch listeners directly in your supervision tree. This allows for greater fault tolerance control by permitting the shutdown of a listener due to the failure of another part of the application and vice versa.

    +

    Embedding

    +

    To embed Ranch in your application you can simply add the child specs to your supervision tree. This can all be done in the init/1 function of one of your application supervisors.

    +

    Ranch requires at the minimum two kinds of child specs for embedding. First, you need to add ranch_sup to your supervision tree, only once, regardless of the number of listeners you will use. Then you need to add the child specs for each listener.

    +

    Ranch has a convenience function for getting the listeners child specs called ranch:child_spec/5, that works like ranch:start_listener/5, except that it doesn't start anything, it only returns child specs.

    +

    As for ranch_sup, the child spec is simple enough to not require a convenience function.

    +

    The following example adds both ranch_sup and one listener to another application's supervision tree.

    +
    Embed Ranch directly in your supervision tree
    +
    +
    init([]) ->
+	RanchSupSpec = {ranch_sup, {ranch_sup, start_link, []},
+		permanent, 5000, supervisor, [ranch_sup]},
+	ListenerSpec = ranch:child_spec(echo, 100,
+		ranch_tcp, [{port, 5555}],
+		echo_protocol, []
+	),
+	{ok, {{one_for_one, 10, 10}, [RanchSupSpec, ListenerSpec]}}.
    +
    +

    Remember, you can add as many listener child specs as needed, but only one ranch_sup spec!

    +

    It is recommended that your architecture makes sure that all listeners are restarted if ranch_sup fails. See the Ranch internals chapter for more details on how Ranch does it.

    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/index.html b/docs/en/ranch/1.8/guide/index.html new file mode 100644 index 00000000..9760e234 --- /dev/null +++ b/docs/en/ranch/1.8/guide/index.html @@ -0,0 +1,191 @@ + + + + + + + + + + Nine Nines: Ranch User Guide + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    + + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/internals.asciidoc b/docs/en/ranch/1.8/guide/internals.asciidoc new file mode 100644 index 00000000..c5bde58f --- /dev/null +++ b/docs/en/ranch/1.8/guide/internals.asciidoc @@ -0,0 +1,94 @@ +== Internals + +This chapter may not apply to embedded Ranch as embedding allows you +to use an architecture specific to your application, which may or may +not be compatible with the description of the Ranch application. + +Note that for everything related to efficiency and performance, +you should perform the benchmarks yourself to get the numbers that +matter to you. Generic benchmarks found on the web may or may not +be of use to you, you can never know until you benchmark your own +system. + +=== Architecture + +Ranch is an OTP application. + +Like all OTP applications, Ranch has a top supervisor. It is responsible +for supervising the `ranch_server` process and all the listeners that +will be started. + +The `ranch_server` gen_server is a central process keeping track of the +listeners and their acceptors. It does so through the use of a public ets +table called `ranch_server`. The table is owned by the top supervisor +to improve fault tolerance. This way if the `ranch_server` gen_server +fails, it doesn't lose any information and the restarted process can +continue as if nothing happened. + +Ranch uses a custom supervisor for managing connections. This supervisor +keeps track of the number of connections and handles connection limits +directly. While it is heavily optimized to perform the task of creating +connection processes for accepted connections, it is still following the +OTP principles and the usual `sys` and `supervisor` calls will work on +it as expected. + +Listeners are grouped into the `ranch_listener_sup` supervisor and +consist of three kinds of processes: the listener gen_server, the +acceptor processes and the connection processes, both grouped under +their own supervisor. All of these processes are registered to the +`ranch_server` gen_server with varying amount of information. + +All socket operations, including listening for connections, go through +transport handlers. Accepted connections are given to the protocol handler. +Transport handlers are simple callback modules for performing operations on +sockets. Protocol handlers start a new process, which receives socket +ownership, with no requirements on how the code should be written inside +that new process. + +=== Number of acceptors + +The second argument to `ranch:start_listener/5` is the number of +processes that will be accepting connections. Care should be taken +when choosing this number. + +First of all, it should not be confused with the maximum number +of connections. Acceptor processes are only used for accepting and +have nothing else in common with connection processes. Therefore +there is nothing to be gained from setting this number too high, +in fact it can slow everything else down. + +Second, this number should be high enough to allow Ranch to accept +connections concurrently. But the number of cores available doesn't +seem to be the only factor for choosing this number, as we can +observe faster accepts if we have more acceptors than cores. It +might be entirely dependent on the protocol, however. + +Our observations suggest that using 100 acceptors on modern hardware +is a good solution, as it's big enough to always have acceptors ready +and it's low enough that it doesn't have a negative impact on the +system's performances. + +=== Platform-specific TCP features + +Some socket options are platform-specific and not supported by `inet`. +They can be of interest because they generally are related to +optimizations provided by the underlying OS. They can still be enabled +thanks to the `raw` option, for which we will see an example. + +One of these features is `TCP_DEFER_ACCEPT` on Linux. It is a simplified +accept mechanism which will wait for application data to come in before +handing out the connection to the Erlang process. + +This is especially useful if you expect many connections to be mostly +idle, perhaps part of a connection pool. They can be handled by the +kernel directly until they send any real data, instead of allocating +resources to idle connections. + +To enable this mechanism, the following option can be used. + +.Using raw transport options + +[source,erlang] +{raw, 6, 9, << 30:32/native >>} + +It means go on layer 6, turn on option 9 with the given integer parameter. diff --git a/docs/en/ranch/1.8/guide/internals/index.html b/docs/en/ranch/1.8/guide/internals/index.html new file mode 100644 index 00000000..1fe14387 --- /dev/null +++ b/docs/en/ranch/1.8/guide/internals/index.html @@ -0,0 +1,206 @@ + + + + + + + + + + Nine Nines: Internals + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Internals

    + +

    This chapter may not apply to embedded Ranch as embedding allows you to use an architecture specific to your application, which may or may not be compatible with the description of the Ranch application.

    +

    Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system.

    +

    Architecture

    +

    Ranch is an OTP application.

    +

    Like all OTP applications, Ranch has a top supervisor. It is responsible for supervising the ranch_server process and all the listeners that will be started.

    +

    The ranch_server gen_server is a central process keeping track of the listeners and their acceptors. It does so through the use of a public ets table called ranch_server. The table is owned by the top supervisor to improve fault tolerance. This way if the ranch_server gen_server fails, it doesn't lose any information and the restarted process can continue as if nothing happened.

    +

    Ranch uses a custom supervisor for managing connections. This supervisor keeps track of the number of connections and handles connection limits directly. While it is heavily optimized to perform the task of creating connection processes for accepted connections, it is still following the OTP principles and the usual sys and supervisor calls will work on it as expected.

    +

    Listeners are grouped into the ranch_listener_sup supervisor and consist of three kinds of processes: the listener gen_server, the acceptor processes and the connection processes, both grouped under their own supervisor. All of these processes are registered to the ranch_server gen_server with varying amount of information.

    +

    All socket operations, including listening for connections, go through transport handlers. Accepted connections are given to the protocol handler. Transport handlers are simple callback modules for performing operations on sockets. Protocol handlers start a new process, which receives socket ownership, with no requirements on how the code should be written inside that new process.

    +

    Number of acceptors

    +

    The second argument to ranch:start_listener/5 is the number of processes that will be accepting connections. Care should be taken when choosing this number.

    +

    First of all, it should not be confused with the maximum number of connections. Acceptor processes are only used for accepting and have nothing else in common with connection processes. Therefore there is nothing to be gained from setting this number too high, in fact it can slow everything else down.

    +

    Second, this number should be high enough to allow Ranch to accept connections concurrently. But the number of cores available doesn't seem to be the only factor for choosing this number, as we can observe faster accepts if we have more acceptors than cores. It might be entirely dependent on the protocol, however.

    +

    Our observations suggest that using 100 acceptors on modern hardware is a good solution, as it's big enough to always have acceptors ready and it's low enough that it doesn't have a negative impact on the system's performances.

    +

    Platform-specific TCP features

    +

    Some socket options are platform-specific and not supported by inet. They can be of interest because they generally are related to optimizations provided by the underlying OS. They can still be enabled thanks to the raw option, for which we will see an example.

    +

    One of these features is TCP_DEFER_ACCEPT on Linux. It is a simplified accept mechanism which will wait for application data to come in before handing out the connection to the Erlang process.

    +

    This is especially useful if you expect many connections to be mostly idle, perhaps part of a connection pool. They can be handled by the kernel directly until they send any real data, instead of allocating resources to idle connections.

    +

    To enable this mechanism, the following option can be used.

    +
    Using raw transport options
    +
    +
    {raw, 6, 9, << 30:32/native >>}
    +
    +

    It means go on layer 6, turn on option 9 with the given integer parameter.

    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/introduction.asciidoc b/docs/en/ranch/1.8/guide/introduction.asciidoc new file mode 100644 index 00000000..16449217 --- /dev/null +++ b/docs/en/ranch/1.8/guide/introduction.asciidoc @@ -0,0 +1,25 @@ +== Introduction + +Ranch is a socket acceptor pool for TCP protocols. + +Ranch aims to provide everything you need to accept TCP connections +with a small code base and low latency while being easy to use directly +as an application or to embed into your own. + +=== Prerequisites + +It is assumed the developer already knows Erlang and has some experience +with socket programming and TCP protocols. + +=== Supported platforms + +Ranch is tested and supported on Linux, FreeBSD, OSX and Windows. + +Ranch is developed for Erlang/OTP 19+. + +Ranch may be compiled on earlier Erlang versions with small source code +modifications but there is no guarantee that it will work as expected. + +=== Versioning + +Ranch uses http://semver.org/[Semantic Versioning 2.0.0] diff --git a/docs/en/ranch/1.8/guide/introduction/index.html b/docs/en/ranch/1.8/guide/introduction/index.html new file mode 100644 index 00000000..a7ae89f8 --- /dev/null +++ b/docs/en/ranch/1.8/guide/introduction/index.html @@ -0,0 +1,185 @@ + + + + + + + + + + Nine Nines: Introduction + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Introduction

    + +

    Ranch is a socket acceptor pool for TCP protocols.

    +

    Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own.

    +

    Prerequisites

    +

    It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols.

    +

    Supported platforms

    +

    Ranch is tested and supported on Linux, FreeBSD, OSX and Windows.

    +

    Ranch is developed for Erlang/OTP 19+.

    +

    Ranch may be compiled on earlier Erlang versions with small source code modifications but there is no guarantee that it will work as expected.

    +

    Versioning

    +

    Ranch uses Semantic Versioning 2.0.0

    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/listeners.asciidoc b/docs/en/ranch/1.8/guide/listeners.asciidoc new file mode 100644 index 00000000..e8ca6949 --- /dev/null +++ b/docs/en/ranch/1.8/guide/listeners.asciidoc @@ -0,0 +1,364 @@ +== Listeners + +A listener is a set of processes whose role is to listen on a port +for new connections. It manages a pool of acceptor processes, each +of them indefinitely accepting connections. When it does, it starts +a new process executing the protocol handler code. All the socket +programming is abstracted through the use of transport handlers. + +The listener takes care of supervising all the acceptor and connection +processes, allowing developers to focus on building their application. + +=== Starting a listener + +Ranch does nothing by default. It is up to the application developer +to request that Ranch listens for connections. + +A listener can be started and stopped at will. + +When starting a listener, a number of different settings are required: + +* A name to identify it locally and be able to interact with it. +* The number of acceptors in the pool. +* A transport handler and its associated options. +* A protocol handler and its associated options. + +Ranch includes both TCP and SSL transport handlers, respectively +`ranch_tcp` and `ranch_ssl`. + +A listener can be started by calling the `ranch:start_listener/5` +function. Before doing so however, you must ensure that the `ranch` +application is started. + +.Starting the Ranch application + +[source,erlang] +ok = application:start(ranch). + +You are then ready to start a listener. Let's call it `tcp_echo`. It will +have a pool of 100 acceptors, use a TCP transport and forward connections +to the `echo_protocol` handler. + +.Starting a listener for TCP connections on port 5555 + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, [{port, 5555}], + echo_protocol, [] +). + +You can try this out by compiling and running the `tcp_echo` example in the +examples directory. To do so, open a shell in the 'examples/tcp_echo/' +directory and run the following command: + +.Building and starting a Ranch example + +[source,bash] +$ make run + +You can then connect to it using telnet and see the echo server reply +everything you send to it. Then when you're done testing, you can use +the `Ctrl+]` key to escape to the telnet command line and type +`quit` to exit. + +.Connecting to the example listener with telnet + +[source,bash] +---- +$ telnet localhost 5555 +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +Hello! +Hello! +It works! +It works! +^] + +telnet> quit +Connection closed. +---- + +=== Stopping a listener + +All you need to stop a Ranch listener is to call the +`ranch:stop_listener/1` function with the listener's name +as argument. In the previous section we started the listener +named `tcp_echo`. We can now stop it. + +.Stopping a listener + +[source,erlang] +ranch:stop_listener(tcp_echo). + +=== Suspending and resuming a listener + +Listeners can be suspended and resumed by calling +`ranch:suspend_listener/1` and `ranch:resume_listener/1`, +respectively, with the name of the listener as argument. + +Suspending a listener will cause it to stop listening and not accept +new connections, but existing connection processes will not be stopped. + +.Suspending a listener + +[source,erlang] +ranch:suspend_listener(tcp_echo). + +Resuming a listener will cause it to start listening and accept new +connections again. +It is worth mentioning, however, that if the listener is configured +to listen on a random port, it will listen on a different port than +before it was suspended. + +.Resuming a listener + +[source,erlang] +ranch:resume_listener(tcp_echo). + +Whether a listener is currently running or suspended can be queried +by calling `ranch:get_status/1` with the listener name as argument. + +=== Default transport options + +By default the socket will be set to return `binary` data, with the +options `{active, false}`, `{packet, raw}`, `{reuseaddr, true}` set. +These values can't be overriden when starting the listener, but +they can be overriden using `Transport:setopts/2` in the protocol. + +It will also set `{backlog, 1024}` and `{nodelay, true}`, which +can be overriden at listener startup. + +=== Listening on a random port + +You do not have to specify a specific port to listen on. If you give +the port number 0, or if you omit the port number entirely, Ranch will +start listening on a random port. + +You can retrieve this port number by calling `ranch:get_port/1`. The +argument is the name of the listener you gave in `ranch:start_listener/5`. + +.Starting a listener for TCP connections on a random port + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, [{port, 0}], + echo_protocol, [] +). +Port = ranch:get_port(tcp_echo). + +=== Listening on privileged ports + +Some systems limit access to ports below 1024 for security reasons. +This can easily be identified by an `{error, eacces}` error when trying +to open a listening socket on such a port. + +The methods for listening on privileged ports vary between systems, +please refer to your system's documentation for more information. + +We recommend the use of port rewriting for systems with a single server, +and load balancing for systems with multiple servers. Documenting these +solutions is however out of the scope of this guide. + +=== Accepting connections on an existing socket + +If you want to accept connections on an existing socket, you can use the +`socket` transport option, which should just be the relevant data returned +from the connect function for the transport or the underlying socket library +(`gen_tcp:connect`, `ssl:connect`). The accept function will then be +called on the passed in socket. You should connect the socket in +`{active, false}` mode, as well. + +=== Limiting the number of concurrent connections + +The `max_connections` transport option allows you to limit the number +of concurrent connections. It defaults to 1024. Its purpose is to +prevent your system from being overloaded and ensuring all the +connections are handled optimally. + +.Customizing the maximum number of concurrent connections + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, [{port, 5555}, {max_connections, 100}], + echo_protocol, [] +). + +You can disable this limit by setting its value to the atom `infinity`. + +.Disabling the limit for the number of connections + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, [{port, 5555}, {max_connections, infinity}], + echo_protocol, [] +). + +The maximum number of connections is a soft limit. In practice, it +can reach `max_connections` + the number of acceptors. + +When the maximum number of connections is reached, Ranch will stop +accepting connections. This will not result in further connections +being rejected, as the kernel option allows queueing incoming +connections. The size of this queue is determined by the `backlog` +option and defaults to 1024. Ranch does not know about the number +of connections that are in the backlog. + +You may not always want connections to be counted when checking for +`max_connections`. For example you might have a protocol where both +short-lived and long-lived connections are possible. If the long-lived +connections are mostly waiting for messages, then they don't consume +much resources and can safely be removed from the count. + +To remove the connection from the count, you must call the +`ranch:remove_connection/1` from within the connection process, +with the name of the listener as the only argument. + +.Removing a connection from the count of connections + +[source,erlang] +ranch:remove_connection(Ref). + +As seen in the chapter covering protocols, this pid is received as the +first argument of the protocol's `start_link/4` callback. + +You can modify the `max_connections` value on a running listener by +using the `ranch:set_max_connections/2` function, with the name of the +listener as first argument and the new value as the second. + +.Upgrading the maximum number of connections + +[source,erlang] +ranch:set_max_connections(tcp_echo, MaxConns). + +The change will occur immediately. + +=== Customizing the number of acceptor processes + +By default Ranch will use 10 acceptor processes. Their role is +to accept connections and spawn a connection process for every +new connection. + +This number can be tweaked to improve performance. A good +number is typically between 10 or 100 acceptors. You must +measure to find the best value for your application. + +.Specifying a custom number of acceptor processes + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, [{port, 5555}, {num_acceptors, 42}], + echo_protocol, [] +). + +=== When running out of file descriptors + +Operating systems have limits on the number of sockets +which can be opened by applications. When this maximum is +reached the listener can no longer accept new connections. The +accept rate of the listener will be automatically reduced, and a +warning message will be logged. + +---- +=ERROR REPORT==== 13-Jan-2016::12:24:38 === +Ranch acceptor reducing accept rate: out of file descriptors +---- + +If you notice messages like this you should increase the number +of file-descriptors which can be opened by your application. How +this should be done is operating-system dependent. Please consult +the documentation of your operating system. + +=== Using a supervisor for connection processes + +Ranch allows you to define the type of process that will be used +for the connection processes. By default it expects a `worker`. +When the `connection_type` configuration value is set to `supervisor`, +Ranch will consider that the connection process it manages is a +supervisor and will reflect that in its supervision tree. + +Connection processes of type `supervisor` can either handle the +socket directly or through one of their children. In the latter +case the start function for the connection process must return +two pids: the pid of the supervisor you created (that will be +supervised) and the pid of the protocol handling process (that +will receive the socket). + +Instead of returning `{ok, ConnPid}`, simply return +`{ok, SupPid, ConnPid}`. + +It is very important that the connection process be created +under the supervisor process so that everything works as intended. +If not, you will most likely experience issues when the supervised +process is stopped. + +=== Upgrading + +Ranch allows you to upgrade the protocol options. This takes effect +immediately and for all subsequent connections. + +To upgrade the protocol options, call `ranch:set_protocol_options/2` +with the name of the listener as first argument and the new options +as the second. + +.Upgrading the protocol options + +[source,erlang] +ranch:set_protocol_options(tcp_echo, NewOpts). + +All future connections will use the new options. + +You can also retrieve the current options similarly by +calling `ranch:get_protocol_options/1`. + +.Retrieving the current protocol options + +[source,erlang] +Opts = ranch:get_protocol_options(tcp_echo). + +=== Changing transport options + +Ranch allows you to change the transport options of a listener, for +example to make it listen on a different port. + +To change transport options, the listener has to be suspended first. +Then you are allowed to change the transport options by calling +`ranch:set_transport_options/2` with the listener name and the new +transport options as arguments. +After that, you can resume the listener. + +.Changing the transport options + +[source,erlang] +ranch:set_transport_options(tcp_echo, NewOpts). + +You can retrieve the current transport options by calling +`ranch:get_transport_options/1`. + +.Retrieving the current transport options + +[source,erlang] +Opts = ranch:get_transport_options(tcp_echo). + +=== Obtaining information about listeners + +Ranch provides two functions for retrieving information about the +listeners, for reporting and diagnostic purposes. + +The `ranch:info/0` function will return detailed information +about all listeners. + +.Retrieving detailed information +[source,erlang] +ranch:info(). + +The `ranch:procs/2` function will return all acceptor or listener +processes for a given listener. + +.Get all acceptor processes +[source,erlang] +ranch:procs(tcp_echo, acceptors). + +.Get all connection processes +[source,erlang] +ranch:procs(tcp_echo, connections). diff --git a/docs/en/ranch/1.8/guide/listeners/index.html b/docs/en/ranch/1.8/guide/listeners/index.html new file mode 100644 index 00000000..7614cbd3 --- /dev/null +++ b/docs/en/ranch/1.8/guide/listeners/index.html @@ -0,0 +1,421 @@ + + + + + + + + + + Nine Nines: Listeners + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Listeners

    + +

    A listener is a set of processes whose role is to listen on a port for new connections. It manages a pool of acceptor processes, each of them indefinitely accepting connections. When it does, it starts a new process executing the protocol handler code. All the socket programming is abstracted through the use of transport handlers.

    +

    The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application.

    +

    Starting a listener

    +

    Ranch does nothing by default. It is up to the application developer to request that Ranch listens for connections.

    +

    A listener can be started and stopped at will.

    +

    When starting a listener, a number of different settings are required:

    +
    • A name to identify it locally and be able to interact with it. +
      • +
    • The number of acceptors in the pool. +
      • +
    • A transport handler and its associated options. +
      • +
    • A protocol handler and its associated options. +
      • +
    +

    Ranch includes both TCP and SSL transport handlers, respectively ranch_tcp and ranch_ssl.

    +

    A listener can be started by calling the ranch:start_listener/5 function. Before doing so however, you must ensure that the ranch application is started.

    +
    Starting the Ranch application
    +
    +
    ok = application:start(ranch).
    +
    +

    You are then ready to start a listener. Let's call it tcp_echo. It will have a pool of 100 acceptors, use a TCP transport and forward connections to the echo_protocol handler.

    +
    Starting a listener for TCP connections on port 5555
    +
    +
    {ok, _} = ranch:start_listener(tcp_echo,
+	ranch_tcp, [{port, 5555}],
+	echo_protocol, []
+).
    +
    +

    You can try this out by compiling and running the tcp_echo example in the examples directory. To do so, open a shell in the examples/tcp_echo/ directory and run the following command:

    +
    Building and starting a Ranch example
    +
    +
    $ make run
    +
    +

    You can then connect to it using telnet and see the echo server reply everything you send to it. Then when you're done testing, you can use the Ctrl+] key to escape to the telnet command line and type quit to exit.

    +
    Connecting to the example listener with telnet
    +
    +
    $ telnet localhost 5555
+Trying 127.0.0.1...
+Connected to localhost.
+Escape character is '^]'.
+Hello!
+Hello!
+It works!
+It works!
+^]
+
+telnet> quit
+Connection closed.
    +
    +

    Stopping a listener

    +

    All you need to stop a Ranch listener is to call the ranch:stop_listener/1 function with the listener's name as argument. In the previous section we started the listener named tcp_echo. We can now stop it.

    +
    Stopping a listener
    +
    +
    ranch:stop_listener(tcp_echo).
    +
    +

    Suspending and resuming a listener

    +

    Listeners can be suspended and resumed by calling ranch:suspend_listener/1 and ranch:resume_listener/1, respectively, with the name of the listener as argument.

    +

    Suspending a listener will cause it to stop listening and not accept new connections, but existing connection processes will not be stopped.

    +
    Suspending a listener
    +
    +
    ranch:suspend_listener(tcp_echo).
    +
    +

    Resuming a listener will cause it to start listening and accept new connections again. It is worth mentioning, however, that if the listener is configured to listen on a random port, it will listen on a different port than before it was suspended.

    +
    Resuming a listener
    +
    +
    ranch:resume_listener(tcp_echo).
    +
    +

    Whether a listener is currently running or suspended can be queried by calling ranch:get_status/1 with the listener name as argument.

    +

    Default transport options

    +

    By default the socket will be set to return binary data, with the options {active, false}, {packet, raw}, {reuseaddr, true} set. These values can't be overriden when starting the listener, but they can be overriden using Transport:setopts/2 in the protocol.

    +

    It will also set {backlog, 1024} and {nodelay, true}, which can be overriden at listener startup.

    +

    Listening on a random port

    +

    You do not have to specify a specific port to listen on. If you give the port number 0, or if you omit the port number entirely, Ranch will start listening on a random port.

    +

    You can retrieve this port number by calling ranch:get_port/1. The argument is the name of the listener you gave in ranch:start_listener/5.

    +
    Starting a listener for TCP connections on a random port
    +
    +
    {ok, _} = ranch:start_listener(tcp_echo,
+	ranch_tcp, [{port, 0}],
+	echo_protocol, []
+).
+Port = ranch:get_port(tcp_echo).
    +
    +

    Listening on privileged ports

    +

    Some systems limit access to ports below 1024 for security reasons. This can easily be identified by an {error, eacces} error when trying to open a listening socket on such a port.

    +

    The methods for listening on privileged ports vary between systems, please refer to your system's documentation for more information.

    +

    We recommend the use of port rewriting for systems with a single server, and load balancing for systems with multiple servers. Documenting these solutions is however out of the scope of this guide.

    +

    Accepting connections on an existing socket

    +

    If you want to accept connections on an existing socket, you can use the socket transport option, which should just be the relevant data returned from the connect function for the transport or the underlying socket library (gen_tcp:connect, ssl:connect). The accept function will then be called on the passed in socket. You should connect the socket in {active, false} mode, as well.

    +

    Limiting the number of concurrent connections

    +

    The max_connections transport option allows you to limit the number of concurrent connections. It defaults to 1024. Its purpose is to prevent your system from being overloaded and ensuring all the connections are handled optimally.

    +
    Customizing the maximum number of concurrent connections
    +
    +
    {ok, _} = ranch:start_listener(tcp_echo,
+	ranch_tcp, [{port, 5555}, {max_connections, 100}],
+	echo_protocol, []
+).
    +
    +

    You can disable this limit by setting its value to the atom infinity.

    +
    Disabling the limit for the number of connections
    +
    +
    {ok, _} = ranch:start_listener(tcp_echo,
+	ranch_tcp, [{port, 5555}, {max_connections, infinity}],
+	echo_protocol, []
+).
    +
    +

    The maximum number of connections is a soft limit. In practice, it can reach max_connections + the number of acceptors.

    +

    When the maximum number of connections is reached, Ranch will stop accepting connections. This will not result in further connections being rejected, as the kernel option allows queueing incoming connections. The size of this queue is determined by the backlog option and defaults to 1024. Ranch does not know about the number of connections that are in the backlog.

    +

    You may not always want connections to be counted when checking for max_connections. For example you might have a protocol where both short-lived and long-lived connections are possible. If the long-lived connections are mostly waiting for messages, then they don't consume much resources and can safely be removed from the count.

    +

    To remove the connection from the count, you must call the ranch:remove_connection/1 from within the connection process, with the name of the listener as the only argument.

    +
    Removing a connection from the count of connections
    +
    +
    ranch:remove_connection(Ref).
    +
    +

    As seen in the chapter covering protocols, this pid is received as the first argument of the protocol's start_link/4 callback.

    +

    You can modify the max_connections value on a running listener by using the ranch:set_max_connections/2 function, with the name of the listener as first argument and the new value as the second.

    +
    Upgrading the maximum number of connections
    +
    +
    ranch:set_max_connections(tcp_echo, MaxConns).
    +
    +

    The change will occur immediately.

    +

    Customizing the number of acceptor processes

    +

    By default Ranch will use 10 acceptor processes. Their role is to accept connections and spawn a connection process for every new connection.

    +

    This number can be tweaked to improve performance. A good number is typically between 10 or 100 acceptors. You must measure to find the best value for your application.

    +
    Specifying a custom number of acceptor processes
    +
    +
    {ok, _} = ranch:start_listener(tcp_echo,
+	ranch_tcp, [{port, 5555}, {num_acceptors, 42}],
+	echo_protocol, []
+).
    +
    +

    When running out of file descriptors

    +

    Operating systems have limits on the number of sockets which can be opened by applications. When this maximum is reached the listener can no longer accept new connections. The accept rate of the listener will be automatically reduced, and a warning message will be logged.

    +
    =ERROR REPORT==== 13-Jan-2016::12:24:38 ===
+Ranch acceptor reducing accept rate: out of file descriptors
    +

    If you notice messages like this you should increase the number of file-descriptors which can be opened by your application. How this should be done is operating-system dependent. Please consult the documentation of your operating system.

    +

    Using a supervisor for connection processes

    +

    Ranch allows you to define the type of process that will be used for the connection processes. By default it expects a worker. When the connection_type configuration value is set to supervisor, Ranch will consider that the connection process it manages is a supervisor and will reflect that in its supervision tree.

    +

    Connection processes of type supervisor can either handle the socket directly or through one of their children. In the latter case the start function for the connection process must return two pids: the pid of the supervisor you created (that will be supervised) and the pid of the protocol handling process (that will receive the socket).

    +

    Instead of returning {ok, ConnPid}, simply return {ok, SupPid, ConnPid}.

    +

    It is very important that the connection process be created under the supervisor process so that everything works as intended. If not, you will most likely experience issues when the supervised process is stopped.

    +

    Upgrading

    +

    Ranch allows you to upgrade the protocol options. This takes effect immediately and for all subsequent connections.

    +

    To upgrade the protocol options, call ranch:set_protocol_options/2 with the name of the listener as first argument and the new options as the second.

    +
    Upgrading the protocol options
    +
    +
    ranch:set_protocol_options(tcp_echo, NewOpts).
    +
    +

    All future connections will use the new options.

    +

    You can also retrieve the current options similarly by calling ranch:get_protocol_options/1.

    +
    Retrieving the current protocol options
    +
    +
    Opts = ranch:get_protocol_options(tcp_echo).
    +
    +

    Changing transport options

    +

    Ranch allows you to change the transport options of a listener, for example to make it listen on a different port.

    +

    To change transport options, the listener has to be suspended first. Then you are allowed to change the transport options by calling ranch:set_transport_options/2 with the listener name and the new transport options as arguments. After that, you can resume the listener.

    +
    Changing the transport options
    +
    +
    ranch:set_transport_options(tcp_echo, NewOpts).
    +
    +

    You can retrieve the current transport options by calling ranch:get_transport_options/1.

    +
    Retrieving the current transport options
    +
    +
    Opts = ranch:get_transport_options(tcp_echo).
    +
    +

    Obtaining information about listeners

    +

    Ranch provides two functions for retrieving information about the listeners, for reporting and diagnostic purposes.

    +

    The ranch:info/0 function will return detailed information about all listeners.

    +
    Retrieving detailed information
    +
    +
    ranch:info().
    +
    +

    The ranch:procs/2 function will return all acceptor or listener processes for a given listener.

    +
    Get all acceptor processes
    +
    +
    ranch:procs(tcp_echo, acceptors).
    +
    +
    Get all connection processes
    +
    +
    ranch:procs(tcp_echo, connections).
    +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/migrating_from_1.5.asciidoc b/docs/en/ranch/1.8/guide/migrating_from_1.5.asciidoc new file mode 100644 index 00000000..a454f932 --- /dev/null +++ b/docs/en/ranch/1.8/guide/migrating_from_1.5.asciidoc @@ -0,0 +1,76 @@ +[appendix] +== Migrating from Ranch 1.5 to 1.6 + +Ranch 1.6 added the ability to suspend and resume listeners. +It also deprecates a number of features and add interfaces +that will be used in Ranch 2.0. + +Ranch 1.6 is compatible with Erlang/OTP 18.0 onward. Support +for older releases has been removed. + +=== Features added + +* Listeners can now be suspended/resumed without stopping existing + connection processes. This effectively closes the listening socket + and stops the acceptor processes. + +* Transport options can now be updated for suspended listeners. + +* The `Socket` argument given when the protocol starts has been + deprecated. In Ranch 2.0 the socket will be obtainable only + by calling `ranch:handshake/1,2`. + +* Ranch-specific transport options and socket options are now + better separated. When passing Ranch-specific transport options, + Ranch now expects to receive a map, in which case socket + options are passed in the `socket_opts` value. When there + are only socket options they can be passed to Ranch directly + as a convenience. + +* Any future transport option will only be added to the map + type. This includes transport options added in this release. + +* The transport option `ack_timeout` was renamed to `handshake_timeout` + in the map type. + +* The `cacerts` socket option is now silenced in error logs + just like the `certs` and `key` options. + +* The manual has been heavily updated and now features one + manual page per function and module, complete with a per-function + changelog, examples and more. + +=== Experimental features added + +* It is now possible to configure the restart intensity for + `ranch_sup` using the OTP application environment. This + feature will remain undocumented unless there is popular + demand for it. + +* Add the transport option `logger` that allows configuring + which logger module will be used. The logger module must + follow the interface of the new `logger` module in Erlang/OTP 21, + or be set to `error_logger` to keep the old behavior. + +=== Changed behaviors + +* Transport modules must now implement `Transport:handshake/2,3` + which deprecates and will replace `Transport:accept_ack/1` in + Ranch 2.0. It returns a new socket and can therefore be used + for implementing TLS upgrade mechanisms. + +=== New functions + +* The functions `ranch:suspend_listener/1` and `ranch:resume_listener/1` + were added. In addition the function `ranch:get_state/1` can be used + to obtain the running state of a listener. + +* A function `ranch:wait_for_connections/3` was added. + +* A function `ranch:handshake/1,2` was added to replace the + function `ranch:accept_ack/1`. + +=== Bugs fixed + +* The specs for the function `Transport:sendfile/2,4,5` have been + corrected. The type used for the filename was too restricting. diff --git a/docs/en/ranch/1.8/guide/migrating_from_1.5/index.html b/docs/en/ranch/1.8/guide/migrating_from_1.5/index.html new file mode 100644 index 00000000..db170a9d --- /dev/null +++ b/docs/en/ranch/1.8/guide/migrating_from_1.5/index.html @@ -0,0 +1,221 @@ + + + + + + + + + + Nine Nines: Migrating from Ranch 1.5 to 1.6 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Ranch 1.5 to 1.6

    + +

    Ranch 1.6 added the ability to suspend and resume listeners. It also deprecates a number of features and add interfaces that will be used in Ranch 2.0.

    +

    Ranch 1.6 is compatible with Erlang/OTP 18.0 onward. Support for older releases has been removed.

    +

    Features added

    +
    • Listeners can now be suspended/resumed without stopping existing connection processes. This effectively closes the listening socket and stops the acceptor processes. +
      • +
    • Transport options can now be updated for suspended listeners. +
      • +
    • The Socket argument given when the protocol starts has been deprecated. In Ranch 2.0 the socket will be obtainable only by calling ranch:handshake/1,2. +
      • +
    • Ranch-specific transport options and socket options are now better separated. When passing Ranch-specific transport options, Ranch now expects to receive a map, in which case socket options are passed in the socket_opts value. When there are only socket options they can be passed to Ranch directly as a convenience. +
      • +
    • Any future transport option will only be added to the map type. This includes transport options added in this release. +
      • +
    • The transport option ack_timeout was renamed to handshake_timeout in the map type. +
      • +
    • The cacerts socket option is now silenced in error logs just like the certs and key options. +
      • +
    • The manual has been heavily updated and now features one manual page per function and module, complete with a per-function changelog, examples and more. +
      • +
    +

    Experimental features added

    +
    • It is now possible to configure the restart intensity for ranch_sup using the OTP application environment. This feature will remain undocumented unless there is popular demand for it. +
      • +
    • Add the transport option logger that allows configuring which logger module will be used. The logger module must follow the interface of the new logger module in Erlang/OTP 21, or be set to error_logger to keep the old behavior. +
      • +
    +

    Changed behaviors

    +
    • Transport modules must now implement Transport:handshake/2,3 which deprecates and will replace Transport:accept_ack/1 in Ranch 2.0. It returns a new socket and can therefore be used for implementing TLS upgrade mechanisms. +
      • +
    +

    New functions

    +
    • The functions ranch:suspend_listener/1 and ranch:resume_listener/1 were added. In addition the function ranch:get_state/1 can be used to obtain the running state of a listener. +
      • +
    • A function ranch:wait_for_connections/3 was added. +
      • +
    • A function ranch:handshake/1,2 was added to replace the function ranch:accept_ack/1. +
      • +
    +

    Bugs fixed

    +
    • The specs for the function Transport:sendfile/2,4,5 have been corrected. The type used for the filename was too restricting. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/migrating_from_1.6.asciidoc b/docs/en/ranch/1.8/guide/migrating_from_1.6.asciidoc new file mode 100644 index 00000000..f0c32e88 --- /dev/null +++ b/docs/en/ranch/1.8/guide/migrating_from_1.6.asciidoc @@ -0,0 +1,46 @@ +[appendix] +== Migrating from Ranch 1.6 to 1.7 + +Ranch 1.7 adds built-in support for the PROXY protocol. + +The PROXY protocol is a simple and efficient way for proxies +to transmit information about the client. + +While a third-party library already existed, it was not +entirely compatible with the Ranch interface, in particular +when socket active mode was involved. This new implementation +fixes that and supports the full protocol with as little +overhead as possible compared to normal operations: just one +extra function call. + +Ranch 1.7 is compatible with Erlang/OTP 19.0 onward. Support +for Erlang/OTP 18 has been removed. + +=== Features added + +* Full support for the PROXY protocol was added. + +=== New functions + +* Add the function `ranch:recv_proxy_header/2` to receive + the PROXY protocol header and parse it. It must be called + before `ranch:handshake/1,2`. + +* Add the functions `ranch_proxy_header:parse/1` and + `ranch_proxy_header:header/1,2` to parse and build a + PROXY protocol header, respectively. + +=== Bugs fixed + +* Fix a race condition when the listener is restarted + after `ranch_listener_sup` crashes. This resulted in + the original options being used even if the options + were updated at runtime. + +* Make the acceptors exit instead of crash when the + listening socket has been closed to prevent + unnecessary logs. + +* Fix an issue where listener information would not get + cleaned up when an embedded listener was stopped. This + was fixed in Ranch 1.6.2. diff --git a/docs/en/ranch/1.8/guide/migrating_from_1.6/index.html b/docs/en/ranch/1.8/guide/migrating_from_1.6/index.html new file mode 100644 index 00000000..9d2c5e17 --- /dev/null +++ b/docs/en/ranch/1.8/guide/migrating_from_1.6/index.html @@ -0,0 +1,201 @@ + + + + + + + + + + Nine Nines: Migrating from Ranch 1.6 to 1.7 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Ranch 1.6 to 1.7

    + +

    Ranch 1.7 adds built-in support for the PROXY protocol.

    +

    The PROXY protocol is a simple and efficient way for proxies to transmit information about the client.

    +

    While a third-party library already existed, it was not entirely compatible with the Ranch interface, in particular when socket active mode was involved. This new implementation fixes that and supports the full protocol with as little overhead as possible compared to normal operations: just one extra function call.

    +

    Ranch 1.7 is compatible with Erlang/OTP 19.0 onward. Support for Erlang/OTP 18 has been removed.

    +

    Features added

    +
    • Full support for the PROXY protocol was added. +
      • +
    +

    New functions

    +
    • Add the function ranch:recv_proxy_header/2 to receive the PROXY protocol header and parse it. It must be called before ranch:handshake/1,2. +
      • +
    • Add the functions ranch_proxy_header:parse/1 and ranch_proxy_header:header/1,2 to parse and build a PROXY protocol header, respectively. +
      • +
    +

    Bugs fixed

    +
    • Fix a race condition when the listener is restarted after ranch_listener_sup crashes. This resulted in the original options being used even if the options were updated at runtime. +
      • +
    • Make the acceptors exit instead of crash when the listening socket has been closed to prevent unnecessary logs. +
      • +
    • Fix an issue where listener information would not get cleaned up when an embedded listener was stopped. This was fixed in Ranch 1.6.2. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/migrating_from_1.7.asciidoc b/docs/en/ranch/1.8/guide/migrating_from_1.7.asciidoc new file mode 100644 index 00000000..b337f953 --- /dev/null +++ b/docs/en/ranch/1.8/guide/migrating_from_1.7.asciidoc @@ -0,0 +1,15 @@ +[appendix] +== Migrating from Ranch 1.7 to 1.8 + +Ranch 1.8 is a compatibility update for Erlang/OTP 24. + +Ranch 1.8 is compatible with Erlang/OTP 21.0 onward. Support +for Erlang/OTP 19 and 20 has been removed. + +=== Bugs fixed + +* An issue with the PROXY protocol was fixed in Ranch 1.7.1. + The wrong CRC32 algorithm was used and would cause + checksum verification to fail when used. The configuration + value when building PROXY headers has been changed to + `crc32c` to reflect the correct algorithm. diff --git a/docs/en/ranch/1.8/guide/migrating_from_1.7/index.html b/docs/en/ranch/1.8/guide/migrating_from_1.7/index.html new file mode 100644 index 00000000..1aa9376c --- /dev/null +++ b/docs/en/ranch/1.8/guide/migrating_from_1.7/index.html @@ -0,0 +1,185 @@ + + + + + + + + + + Nine Nines: Migrating from Ranch 1.7 to 1.8 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Ranch 1.7 to 1.8

    + +

    Ranch 1.8 is a compatibility update for Erlang/OTP 24.

    +

    Ranch 1.8 is compatible with Erlang/OTP 21.0 onward. Support for Erlang/OTP 19 and 20 has been removed.

    +

    Bugs fixed

    +
    • An issue with the PROXY protocol was fixed in Ranch 1.7.1. The wrong CRC32 algorithm was used and would cause checksum verification to fail when used. The configuration value when building PROXY headers has been changed to crc32c to reflect the correct algorithm. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/migrating_from_1.x.asciidoc b/docs/en/ranch/1.8/guide/migrating_from_1.x.asciidoc new file mode 100644 index 00000000..44babf17 --- /dev/null +++ b/docs/en/ranch/1.8/guide/migrating_from_1.x.asciidoc @@ -0,0 +1,70 @@ +[appendix] +== Migrating from Ranch 1.x + +The changelog for Ranch releases before 1.6 can be found +in this section. + +=== 1.5.0 + +* Add transport functions getopts/2, getstat/1 and getstat/2 +* Fix ranch:info/0 and ranch:procs/2 in embedded mode +* Prevent ranch_conns_sup from stopping on unexpected messages + +=== 1.4.0 + +* Add new transport option num_acceptor +* Deprecate ranch:start_listener/6 in favor of start_listener/5 +* Deprecate ranch:child_spec/6 in favor of child_spec/5 + +=== 1.3.0 + +The version numbers 1.3.1 and 1.3.2 were later made to fix +small mistakes made during the 1.3.0 release process. They +do not include code changes. + +* Tested with OTP R16B+ on Linux, FreeBSD, OSX and Windows +* Add ssl to the list of dependencies +* Add ranch:info/0 and ranch:procs/2 to retrieve Ranch state information +* Allow configuring a listener with only SNI, without a default certificate +* Blacklist transport options instead of whitelist +** Unknown options are now allowed, but will result in a Dialyzer warning +* Add many transport options typespecs and documentation +* Don't silently drop the accept rate when running out of fds +* Prevent a race condition when stopping listeners +* Improve reporting for common errors, for example eaddrinuse +* Fix double removal of connections bug +** The number of active connections should now be exact +* Fix stuck acceptor bug when controlling_socket returned errors +* Numerous documentation and examples improvements + +=== 1.2.1 + +* Fix bug preventing node shutdown when SSL is used with OTP 17.1+ +* Tune restart intensity in all supervisors + +=== 1.2.0 + +* Allow the supervised process and the process owning the socket to be different +* Add many transport options (please refer to the documentation) +* Add function ranch:get_addr/1 to retrieve both IP and port of listener +* Don't pass Ranch-specific options down to transports +** Should make Dialyzer happy in user projects +** New types ranch:opt(), ranch_tcp:opt(), ranch_ssl:ssl_opt() and ranch_ssl:opt() +* Fix crash when filtering unknown options out +* Print a warning for each option filtered out +* Handle Transport:controlling_socket/2 errors and close the socket +* Handle Protocol:start_link/4 crashes to avoid killing all active connections +* Use Asciidoc for documentation +* Test Ranch across 14 Erlang versions on CircleCI +* Improve and document test suites with recent ct_helper improvements +* Fix a number of intermittent test issues + +=== 1.1.0 + +* Add Transport:secure/0 +* Add SSL partial_chain option +* Stop reporting errors on {error, closed} in accept_ack + +=== 1.0.0 + +* Initial release diff --git a/docs/en/ranch/1.8/guide/migrating_from_1.x/index.html b/docs/en/ranch/1.8/guide/migrating_from_1.x/index.html new file mode 100644 index 00000000..ba0cbeb5 --- /dev/null +++ b/docs/en/ranch/1.8/guide/migrating_from_1.x/index.html @@ -0,0 +1,274 @@ + + + + + + + + + + Nine Nines: Migrating from Ranch 1.x + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Migrating from Ranch 1.x

    + +

    The changelog for Ranch releases before 1.6 can be found in this section.

    +

    1.5.0

    +
    • Add transport functions getopts/2, getstat/1 and getstat/2 +
      • +
    • Fix ranch:info/0 and ranch:procs/2 in embedded mode +
      • +
    • Prevent ranch_conns_sup from stopping on unexpected messages +
      • +
    +

    1.4.0

    +
    • Add new transport option num_acceptor +
      • +
    • Deprecate ranch:start_listener/6 in favor of start_listener/5 +
      • +
    • Deprecate ranch:child_spec/6 in favor of child_spec/5 +
      • +
    +

    1.3.0

    +

    The version numbers 1.3.1 and 1.3.2 were later made to fix small mistakes made during the 1.3.0 release process. They do not include code changes.

    +
    • Tested with OTP R16B+ on Linux, FreeBSD, OSX and Windows +
      • +
    • Add ssl to the list of dependencies +
      • +
    • Add ranch:info/0 and ranch:procs/2 to retrieve Ranch state information +
      • +
    • Allow configuring a listener with only SNI, without a default certificate +
      • +
    • Blacklist transport options instead of whitelist +
      • Unknown options are now allowed, but will result in a Dialyzer warning +
        • +
      +
      • +
    • Add many transport options typespecs and documentation +
      • +
    • Don't silently drop the accept rate when running out of fds +
      • +
    • Prevent a race condition when stopping listeners +
      • +
    • Improve reporting for common errors, for example eaddrinuse +
      • +
    • Fix double removal of connections bug +
      • The number of active connections should now be exact +
        • +
      +
      • +
    • Fix stuck acceptor bug when controlling_socket returned errors +
      • +
    • Numerous documentation and examples improvements +
      • +
    +

    1.2.1

    +
    • Fix bug preventing node shutdown when SSL is used with OTP 17.1+ +
      • +
    • Tune restart intensity in all supervisors +
      • +
    +

    1.2.0

    +
    • Allow the supervised process and the process owning the socket to be different +
      • +
    • Add many transport options (please refer to the documentation) +
      • +
    • Add function ranch:get_addr/1 to retrieve both IP and port of listener +
      • +
    • Don't pass Ranch-specific options down to transports +
      • Should make Dialyzer happy in user projects +
        • +
      • New types ranch:opt(), ranch_tcp:opt(), ranch_ssl:ssl_opt() and ranch_ssl:opt() +
        • +
      +
      • +
    • Fix crash when filtering unknown options out +
      • +
    • Print a warning for each option filtered out +
      • +
    • Handle Transport:controlling_socket/2 errors and close the socket +
      • +
    • Handle Protocol:start_link/4 crashes to avoid killing all active connections +
      • +
    • Use Asciidoc for documentation +
      • +
    • Test Ranch across 14 Erlang versions on CircleCI +
      • +
    • Improve and document test suites with recent ct_helper improvements +
      • +
    • Fix a number of intermittent test issues +
      • +
    +

    1.1.0

    +
    • Add Transport:secure/0 +
      • +
    • Add SSL partial_chain option +
      • +
    • Stop reporting errors on {error, closed} in accept_ack +
      • +
    +

    1.0.0

    +
    • Initial release +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/parsers.asciidoc b/docs/en/ranch/1.8/guide/parsers.asciidoc new file mode 100644 index 00000000..7a9c5a53 --- /dev/null +++ b/docs/en/ranch/1.8/guide/parsers.asciidoc @@ -0,0 +1,92 @@ +== Writing parsers + +There are three kinds of protocols: + +* Text protocols +* Schema-less binary protocols +* Schema-based binary protocols + +This chapter introduces the first two kinds. It will not cover +more advanced topics such as continuations or parser generators. + +This chapter isn't specifically about Ranch, we assume here that +you know how to read data from the socket. The data you read and +the data that hasn't been parsed is saved in a buffer. Every +time you read from the socket, the data read is appended to the +buffer. What happens next depends on the kind of protocol. We +will only cover the first two. + +=== Parsing text + +Text protocols are generally line based. This means that we can't +do anything with them until we receive the full line. + +A simple way to get a full line is to use `binary:split/2,3`. + +.Using binary:split/2 to get a line of input + +[source,erlang] +case binary:split(Buffer, <<"\n">>) of + [_] -> + get_more_data(Buffer); + [Line, Rest] -> + handle_line(Line, Rest) +end. + +In the above example, we can have two results. Either there was +a line break in the buffer and we get it split into two parts, +the line and the rest of the buffer; or there was no line break +in the buffer and we need to get more data from the socket. + +Next, we need to parse the line. The simplest way is to again +split, here on space. The difference is that we want to split +on all spaces character, as we want to tokenize the whole string. + +.Using binary:split/3 to split text + +[source,erlang] +case binary:split(Line, <<" ">>, [global]) of + [<<"HELLO">>] -> + be_polite(); + [<<"AUTH">>, User, Password] -> + authenticate_user(User, Password); + [<<"QUIT">>, Reason] -> + quit(Reason) + %% ... +end. + +Pretty simple, right? Match on the command name, get the rest +of the tokens in variables and call the respective functions. + +After doing this, you will want to check if there is another +line in the buffer, and handle it immediately if any. +Otherwise wait for more data. + +=== Parsing binary + +Binary protocols can be more varied, although most of them are +pretty similar. The first four bytes of a frame tend to be +the size of the frame, which is followed by a certain number +of bytes for the type of frame and then various parameters. + +Sometimes the size of the frame includes the first four bytes, +sometimes not. Other times this size is encoded over two bytes. +And even other times little-endian is used instead of big-endian. + +The general idea stays the same though. + +.Using binary pattern matching to split frames + +[source,erlang] +<< Size:32, _/bits >> = Buffer, +case Buffer of + << Frame:Size/binary, Rest/bits >> -> + handle_frame(Frame, Rest); + _ -> + get_more_data(Buffer) +end. + +You will then need to parse this frame using binary pattern +matching, and handle it. Then you will want to check if there +is another frame fully received in the buffer, and handle it +immediately if any. Otherwise wait for more data. diff --git a/docs/en/ranch/1.8/guide/parsers/index.html b/docs/en/ranch/1.8/guide/parsers/index.html new file mode 100644 index 00000000..6bb5cde8 --- /dev/null +++ b/docs/en/ranch/1.8/guide/parsers/index.html @@ -0,0 +1,241 @@ + + + + + + + + + + Nine Nines: Writing parsers + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Writing parsers

    + +

    There are three kinds of protocols:

    +
    • Text protocols +
      • +
    • Schema-less binary protocols +
      • +
    • Schema-based binary protocols +
      • +
    +

    This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators.

    +

    This chapter isn't specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn't been parsed is saved in a buffer. Every time you read from the socket, the data read is appended to the buffer. What happens next depends on the kind of protocol. We will only cover the first two.

    +

    Parsing text

    +

    Text protocols are generally line based. This means that we can't do anything with them until we receive the full line.

    +

    A simple way to get a full line is to use binary:split/2,3.

    +
    Using binary:split/2 to get a line of input
    +
    +
    case binary:split(Buffer, <<"\n">>) of
+	[_] ->
+		get_more_data(Buffer);
+	[Line, Rest] ->
+		handle_line(Line, Rest)
+end.
    +
    +

    In the above example, we can have two results. Either there was a line break in the buffer and we get it split into two parts, the line and the rest of the buffer; or there was no line break in the buffer and we need to get more data from the socket.

    +

    Next, we need to parse the line. The simplest way is to again split, here on space. The difference is that we want to split on all spaces character, as we want to tokenize the whole string.

    +
    Using binary:split/3 to split text
    +
    +
    case binary:split(Line, <<" ">>, [global]) of
+	[<<"HELLO">>] ->
+		be_polite();
+	[<<"AUTH">>, User, Password] ->
+		authenticate_user(User, Password);
+	[<<"QUIT">>, Reason] ->
+		quit(Reason)
+	%% ...
+end.
    +
    +

    Pretty simple, right? Match on the command name, get the rest of the tokens in variables and call the respective functions.

    +

    After doing this, you will want to check if there is another line in the buffer, and handle it immediately if any. Otherwise wait for more data.

    +

    Parsing binary

    +

    Binary protocols can be more varied, although most of them are pretty similar. The first four bytes of a frame tend to be the size of the frame, which is followed by a certain number of bytes for the type of frame and then various parameters.

    +

    Sometimes the size of the frame includes the first four bytes, sometimes not. Other times this size is encoded over two bytes. And even other times little-endian is used instead of big-endian.

    +

    The general idea stays the same though.

    +
    Using binary pattern matching to split frames
    +
    +
    << Size:32, _/bits >> = Buffer,
+case Buffer of
+	<< Frame:Size/binary, Rest/bits >> ->
+		handle_frame(Frame, Rest);
+	_ ->
+		get_more_data(Buffer)
+end.
    +
    +

    You will then need to parse this frame using binary pattern matching, and handle it. Then you will want to check if there is another frame fully received in the buffer, and handle it immediately if any. Otherwise wait for more data.

    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/protocols.asciidoc b/docs/en/ranch/1.8/guide/protocols.asciidoc new file mode 100644 index 00000000..8f77ef49 --- /dev/null +++ b/docs/en/ranch/1.8/guide/protocols.asciidoc @@ -0,0 +1,99 @@ +== Protocols + +A protocol handler starts a connection process and defines the +protocol logic executed in this process. + +=== Writing a protocol handler + +All protocol handlers must implement the `ranch_protocol` behavior +which defines a single callback, `start_link/4`. This callback is +responsible for spawning a new process for handling the connection. +It receives four arguments: the name of the listener, the socket, the +transport handler being used and the protocol options defined in +the call to `ranch:start_listener/5`. This callback must +return `{ok, Pid}`, with `Pid` the pid of the new process. + +The newly started process can then freely initialize itself. However, +it must call `ranch:handshake/1,2` before doing any socket operation. +This will ensure the connection process is the owner of the socket. +It expects the listener's name as argument. + +.Perform the socket handshake + +[source,erlang] +{ok, Socket} = ranch:handshake(Ref). + +If your protocol code requires specific socket options, you should +set them while initializing your connection process, after +calling `ranch:handshake/1,2`. You can use `Transport:setopts/2` +for that purpose. + +Following is the complete protocol code for the example found +in `examples/tcp_echo/`. + +.Protocol module that echoes everything it receives + +[source,erlang] +---- +-module(echo_protocol). +-behaviour(ranch_protocol). + +-export([start_link/4]). +-export([init/3]). + +start_link(Ref, _Socket, Transport, Opts) -> + Pid = spawn_link(?MODULE, init, [Ref, Transport, Opts]), + {ok, Pid}. + +init(Ref, Transport, _Opts = []) -> + {ok, Socket} = ranch:handshake(Ref), + loop(Socket, Transport). + +loop(Socket, Transport) -> + case Transport:recv(Socket, 0, 5000) of + {ok, Data} -> + Transport:send(Socket, Data), + loop(Socket, Transport); + _ -> + ok = Transport:close(Socket) + end. +---- + +=== Using gen_statem + +Special processes like the ones that use the `gen_statem` or `gen_server` +behaviours have the particularity of having their `start_link` call not +return until the `init` function returns. This is problematic, because +you won't be able to call `ranch:handshake/1,2` from the `init` callback +as this would cause a deadlock to happen. + +Use the `gen_statem:enter_loop/4` function. It allows you to start your process +normally (although it must be started with `proc_lib` like all special +processes), then perform any needed operations before falling back into +the normal `gen_statem` execution loop. + +.Use a gen_statem for protocol handling + +[source,erlang] +---- +-module(my_protocol). +-behaviour(gen_statem). +-behaviour(ranch_protocol). + +-export([start_link/4]). +-export([init/1]). +%% Exports of other gen_statem callbacks here. + +start_link(Ref, _Socket, Transport, Opts) -> + {ok, proc_lib:spawn_link(?MODULE, init, [{Ref, Transport, Opts}])}. + +init({Ref, Transport, _Opts = []}) -> + %% Perform any required state initialization here. + {ok, Socket} = ranch:handshake(Ref), + ok = Transport:setopts(Socket, [{active, once}]), + gen_statem:enter_loop(?MODULE, [], state_name, {state_data, Socket, Transport}). + +%% Other gen_statem callbacks here. +---- + +Check the `tcp_reverse` example for a complete example. diff --git a/docs/en/ranch/1.8/guide/protocols/index.html b/docs/en/ranch/1.8/guide/protocols/index.html new file mode 100644 index 00000000..427423c2 --- /dev/null +++ b/docs/en/ranch/1.8/guide/protocols/index.html @@ -0,0 +1,248 @@ + + + + + + + + + + Nine Nines: Protocols + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Protocols

    + +

    A protocol handler starts a connection process and defines the protocol logic executed in this process.

    +

    Writing a protocol handler

    +

    All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/4. This callback is responsible for spawning a new process for handling the connection. It receives four arguments: the name of the listener, the socket, the transport handler being used and the protocol options defined in the call to ranch:start_listener/5. This callback must return {ok, Pid}, with Pid the pid of the new process.

    +

    The newly started process can then freely initialize itself. However, it must call ranch:handshake/1,2 before doing any socket operation. This will ensure the connection process is the owner of the socket. It expects the listener's name as argument.

    +
    Perform the socket handshake
    +
    +
    {ok, Socket} = ranch:handshake(Ref).
    +
    +

    If your protocol code requires specific socket options, you should set them while initializing your connection process, after calling ranch:handshake/1,2. You can use Transport:setopts/2 for that purpose.

    +

    Following is the complete protocol code for the example found in examples/tcp_echo/.

    +
    Protocol module that echoes everything it receives
    +
    +
    -module(echo_protocol).
+-behaviour(ranch_protocol).
+
+-export([start_link/4]).
+-export([init/3]).
+
+start_link(Ref, _Socket, Transport, Opts) ->
+	Pid = spawn_link(?MODULE, init, [Ref, Transport, Opts]),
+	{ok, Pid}.
+
+init(Ref, Transport, _Opts = []) ->
+	{ok, Socket} = ranch:handshake(Ref),
+	loop(Socket, Transport).
+
+loop(Socket, Transport) ->
+	case Transport:recv(Socket, 0, 5000) of
+		{ok, Data} ->
+			Transport:send(Socket, Data),
+			loop(Socket, Transport);
+		_ ->
+			ok = Transport:close(Socket)
+	end.
    +
    +

    Using gen_statem

    +

    Special processes like the ones that use the gen_statem or gen_server behaviours have the particularity of having their start_link call not return until the init function returns. This is problematic, because you won't be able to call ranch:handshake/1,2 from the init callback as this would cause a deadlock to happen.

    +

    Use the gen_statem:enter_loop/4 function. It allows you to start your process normally (although it must be started with proc_lib like all special processes), then perform any needed operations before falling back into the normal gen_statem execution loop.

    +
    Use a gen_statem for protocol handling
    +
    +
    -module(my_protocol).
+-behaviour(gen_statem).
+-behaviour(ranch_protocol).
+
+-export([start_link/4]).
+-export([init/1]).
+%% Exports of other gen_statem callbacks here.
+
+start_link(Ref, _Socket, Transport, Opts) ->
+	{ok, proc_lib:spawn_link(?MODULE, init, [{Ref, Transport, Opts}])}.
+
+init({Ref, Transport, _Opts = []}) ->
+	%% Perform any required state initialization here.
+	{ok, Socket} = ranch:handshake(Ref),
+	ok = Transport:setopts(Socket, [{active, once}]),
+	gen_statem:enter_loop(?MODULE, [], state_name, {state_data, Socket, Transport}).
+
+%% Other gen_statem callbacks here.
    +
    +

    Check the tcp_reverse example for a complete example.

    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/ssl_auth.asciidoc b/docs/en/ranch/1.8/guide/ssl_auth.asciidoc new file mode 100644 index 00000000..de16107a --- /dev/null +++ b/docs/en/ranch/1.8/guide/ssl_auth.asciidoc @@ -0,0 +1,120 @@ +== SSL client authentication + +=== Purpose + +SSL client authentication is a mechanism allowing applications to +identify certificates. This allows your application to make sure that +the client is an authorized certificate, but makes no claim about +whether the user can be trusted. This can be combined with a password +based authentication to attain greater security. + +The server only needs to retain the certificate serial number and +the certificate issuer to authenticate the certificate. Together, +they can be used to uniquely identify a certicate. + +As Ranch allows the same protocol code to be used for both SSL and +non-SSL transports, you need to make sure you are in an SSL context +before attempting to perform an SSL client authentication. This +can be done by checking the return value of `Transport:name/0`. + +=== Obtaining client certificates + +You can obtain client certificates from various sources. You can +generate them yourself, or you can use a service like CAcert.org +which allows you to generate client and server certificates for +free. + +Following are the steps you need to take to create a CAcert.org +account, generate a certificate and install it in your favorite +browser. + +* Open http://cacert.org in your favorite browser +* Root Certificate link: install both certificates +* Join (Register an account) +* Verify your account (check your email inbox!) +* Log in +* Client Certificates: New +* Follow instructions to create the certificate +* Install the certificate in your browser + +You can optionally save the certificate for later use, for example +to extract the `IssuerID` information as will be detailed later on. + +=== Transport configuration + +The SSL transport does not request a client certificate by default. +You need to specify the `{verify, verify_peer}` option when starting +the listener to enable this behavior. + +.Configure a listener for SSL authentication + +[source,erlang] +{ok, _} = ranch:start_listener(my_ssl, + ranch_ssl, [ + {port, SSLPort}, + {certfile, PathToCertfile}, + {cacertfile, PathToCACertfile}, + {verify, verify_peer} + ], + my_protocol, [] +). + +In this example we set the required `port` and `certfile`, but also +the `cacertfile` containing the CACert.org root certificate, and +the option to request the client certificate. + +If you enable the `{verify, verify_peer}` option and the client does +not have a client certificate configured for your domain, then no +certificate will be sent. This allows you to use SSL for more than +just authenticated clients. + +=== Authentication + +To authenticate users, you must first save the certificate information +required. If you have your users' certificate files, you can simply +load the certificate and retrieve the information directly. + +.Retrieve the issuer ID from a certificate + +[source,erlang] +---- +certfile_to_issuer_id(Filename) -> + {ok, Data} = file:read_file(Filename), + [{'Certificate', Cert, not_encrypted}] = public_key:pem_decode(Data), + {ok, IssuerID} = public_key:pkix_issuer_id(Cert, self), + IssuerID. +---- + +The `IssuerID` variable contains both the certificate serial number +and the certificate issuer stored in a tuple, so this value alone can +be used to uniquely identify the user certificate. You can save this +value in a database, a configuration file or any other place where an +Erlang term can be stored and retrieved. + +To retrieve the `IssuerID` from a running connection, you need to first +retrieve the client certificate and then extract this information from +it. Ranch does not provide a function to retrieve the client certificate. +Instead you can use the `ssl:peercert/1` function. Once you have the +certificate, you can again use the `public_key:pkix_issuer_id/2` to +extract the `IssuerID` value. + +The following function returns the `IssuerID` or `false` if no client +certificate was found. This snippet is intended to be used from your +protocol code. + +.Retrieve the issuer ID from the certificate for the current connection + +[source,erlang] +---- +socket_to_issuer_id(Socket) -> + case ssl:peercert(Socket) of + {error, no_peercert} -> + false; + {ok, Cert} -> + {ok, IssuerID} = public_key:pkix_issuer_id(Cert, self), + IssuerID + end. +---- + +You then only need to match the `IssuerID` value to authenticate the +user. diff --git a/docs/en/ranch/1.8/guide/ssl_auth/index.html b/docs/en/ranch/1.8/guide/ssl_auth/index.html new file mode 100644 index 00000000..f63a2040 --- /dev/null +++ b/docs/en/ranch/1.8/guide/ssl_auth/index.html @@ -0,0 +1,254 @@ + + + + + + + + + + Nine Nines: SSL client authentication + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    SSL client authentication

    + +

    Purpose

    +

    SSL client authentication is a mechanism allowing applications to identify certificates. This allows your application to make sure that the client is an authorized certificate, but makes no claim about whether the user can be trusted. This can be combined with a password based authentication to attain greater security.

    +

    The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate.

    +

    As Ranch allows the same protocol code to be used for both SSL and non-SSL transports, you need to make sure you are in an SSL context before attempting to perform an SSL client authentication. This can be done by checking the return value of Transport:name/0.

    +

    Obtaining client certificates

    +

    You can obtain client certificates from various sources. You can generate them yourself, or you can use a service like CAcert.org which allows you to generate client and server certificates for free.

    +

    Following are the steps you need to take to create a CAcert.org account, generate a certificate and install it in your favorite browser.

    +
    • Open http://cacert.org in your favorite browser +
      • +
    • Root Certificate link: install both certificates +
      • +
    • Join (Register an account) +
      • +
    • Verify your account (check your email inbox!) +
      • +
    • Log in +
      • +
    • Client Certificates: New +
      • +
    • Follow instructions to create the certificate +
      • +
    • Install the certificate in your browser +
      • +
    +

    You can optionally save the certificate for later use, for example to extract the IssuerID information as will be detailed later on.

    +

    Transport configuration

    +

    The SSL transport does not request a client certificate by default. You need to specify the {verify, verify_peer} option when starting the listener to enable this behavior.

    +
    Configure a listener for SSL authentication
    +
    +
    {ok, _} = ranch:start_listener(my_ssl,
+	ranch_ssl, [
+		{port, SSLPort},
+		{certfile, PathToCertfile},
+		{cacertfile, PathToCACertfile},
+		{verify, verify_peer}
+	],
+	my_protocol, []
+).
    +
    +

    In this example we set the required port and certfile, but also the cacertfile containing the CACert.org root certificate, and the option to request the client certificate.

    +

    If you enable the {verify, verify_peer} option and the client does not have a client certificate configured for your domain, then no certificate will be sent. This allows you to use SSL for more than just authenticated clients.

    +

    Authentication

    +

    To authenticate users, you must first save the certificate information required. If you have your users' certificate files, you can simply load the certificate and retrieve the information directly.

    +
    Retrieve the issuer ID from a certificate
    +
    +
    certfile_to_issuer_id(Filename) ->
+	{ok, Data} = file:read_file(Filename),
+	[{'Certificate', Cert, not_encrypted}] = public_key:pem_decode(Data),
+	{ok, IssuerID} = public_key:pkix_issuer_id(Cert, self),
+	IssuerID.
    +
    +

    The IssuerID variable contains both the certificate serial number and the certificate issuer stored in a tuple, so this value alone can be used to uniquely identify the user certificate. You can save this value in a database, a configuration file or any other place where an Erlang term can be stored and retrieved.

    +

    To retrieve the IssuerID from a running connection, you need to first retrieve the client certificate and then extract this information from it. Ranch does not provide a function to retrieve the client certificate. Instead you can use the ssl:peercert/1 function. Once you have the certificate, you can again use the public_key:pkix_issuer_id/2 to extract the IssuerID value.

    +

    The following function returns the IssuerID or false if no client certificate was found. This snippet is intended to be used from your protocol code.

    +
    Retrieve the issuer ID from the certificate for the current connection
    +
    +
    socket_to_issuer_id(Socket) ->
+	case ssl:peercert(Socket) of
+		{error, no_peercert} ->
+			false;
+		{ok, Cert} ->
+			{ok, IssuerID} = public_key:pkix_issuer_id(Cert, self),
+			IssuerID
+	end.
    +
    +

    You then only need to match the IssuerID value to authenticate the user.

    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/transports.asciidoc b/docs/en/ranch/1.8/guide/transports.asciidoc new file mode 100644 index 00000000..70efa1be --- /dev/null +++ b/docs/en/ranch/1.8/guide/transports.asciidoc @@ -0,0 +1,172 @@ +== Transports + +A transport defines the interface to interact with a socket. + +Transports can be used for connecting, listening and accepting +connections, but also for receiving and sending data. Both +passive and active mode are supported, although all sockets +are initialized as passive. + +=== TCP transport + +The TCP transport is a thin wrapper around `gen_tcp`. + +=== SSL transport + +The SSL transport is a thin wrapper around `ssl`. + +Ranch depends on `ssl` by default so any necessary +dependencies will start when Ranch is started. It is +possible to remove the dependency when the SSL transport +will not be used. Refer to your release build tool's +documentation for more information. + +When embedding Ranch listeners that have an SSL transport, +your application must depend on the `ssl` application for +proper behavior. + +=== Sending and receiving data + +This section assumes that `Transport` is a valid transport handler +(like `ranch_tcp` or `ranch_ssl`) and `Socket` is a connected +socket obtained through the listener. + +You can send data to a socket by calling the `Transport:send/2` +function. The data can be given as `iodata()`, which is defined as +`binary() | iolist()`. All the following calls will work: + +.Sending data to the socket + +[source,erlang] +---- +Transport:send(Socket, <<"Ranch is cool!">>). +Transport:send(Socket, "Ranch is cool!"). +Transport:send(Socket, ["Ranch", ["is", "cool!"]]). +Transport:send(Socket, ["Ranch", [<<"is">>, "cool!"]]). +---- + +You can receive data either in passive or in active mode. Passive mode +means that you will perform a blocking `Transport:recv/3` call, while +active mode means that you will receive the data as a message. + +By default, all data will be received as binary. It is possible to +receive data as strings, although this is not recommended as binaries +are a more efficient construct, especially for binary protocols. + +Receiving data using passive mode requires a single function call. The +first argument is the socket, and the third argument is a timeout duration +before the call returns with `{error, timeout}`. + +The second argument is the amount of data in bytes that we want to receive. +The function will wait for data until it has received exactly this amount. +If you are not expecting a precise size, you can specify 0 which will make +this call return as soon as data was read, regardless of its size. + +.Receiving data from the socket in passive mode + +[source,erlang] +{ok, Data} = Transport:recv(Socket, 0, 5000). + +Active mode requires you to inform the socket that you want to receive +data as a message and to write the code to actually receive it. + +There are two kinds of active modes: `{active, once}` and +`{active, true}`. The first will send a single message before going +back to passive mode; the second will send messages indefinitely. +We recommend not using the `{active, true}` mode as it could quickly +flood your process mailbox. It's better to keep the data in the socket +and read it only when required. + +Three different messages can be received: + +* `{OK, Socket, Data}` +* `{Closed, Socket}` +* `{Error, Socket, Reason}` + +The value of `OK`, `Closed` and `Error` can be different +depending on the transport being used. To be able to properly match +on them you must first call the `Transport:messages/0` function. + +.Retrieving the transport's active message identifiers + +[source,erlang] +{OK, Closed, Error} = Transport:messages(). + +To start receiving messages you will need to call the `Transport:setopts/2` +function, and do so every time you want to receive data. + +.Receiving messages from the socket in active mode + +[source,erlang] +---- +{OK, Closed, Error} = Transport:messages(), +Transport:setopts(Socket, [{active, once}]), +receive + {OK, Socket, Data} -> + io:format("data received: ~p~n", [Data]); + {Closed, Socket} -> + io:format("socket got closed!~n"); + {Error, Socket, Reason} -> + io:format("error happened: ~p~n", [Reason]) +end. +---- + +You can easily integrate active sockets with existing Erlang code as all +you really need is just a few more clauses when receiving messages. + +=== Sending files + +As in the previous section it is assumed `Transport` is a valid transport +handler and `Socket` is a connected socket obtained through the listener. + +To send a whole file, with name `Filename`, over a socket: + +.Sending a file by filename + +[source,erlang] +{ok, SentBytes} = Transport:sendfile(Socket, Filename). + +Or part of a file, with `Offset` greater than or equal to 0, `Bytes` number of +bytes and chunks of size `ChunkSize`: + +.Sending part of a file by filename in chunks + +[source,erlang] +Opts = [{chunk_size, ChunkSize}], +{ok, SentBytes} = Transport:sendfile(Socket, Filename, Offset, Bytes, Opts). + +To improve efficiency when sending multiple parts of the same file it is also +possible to use a file descriptor opened in raw mode: + +.Sending a file opened in raw mode + +[source,erlang] +{ok, RawFile} = file:open(Filename, [raw, read, binary]), +{ok, SentBytes} = Transport:sendfile(Socket, RawFile, Offset, Bytes, Opts). + +=== Upgrading a TCP socket to SSL + +A connected TCP socket can be upgraded to a SSL socket via the function +`ranch_ssl:handshake/3`. The socket *must* be in `{active, false}` mode +before telling the client that the server is ready to upgrade in order +to avoid race conditions. + +.Performing a TLS handshake on a TCP socket +[source,erlang] +{ok, NewSocket} = ranch_ssl:handshake(Socket, SslOpts, 5000). + +=== Writing a transport handler + +A transport handler is a module implementing the `ranch_transport` behavior. +It defines a certain number of callbacks that must be written in order to +allow transparent usage of the transport handler. + +The behavior doesn't define the socket options available when opening a +socket. These do not need to be common to all transports as it's easy enough +to write different initialization functions for the different transports that +will be used. With one exception though. The `setopts/2` function *must* +implement the `{active, once}` and the `{active, true}` options. + +If the transport handler doesn't have a native implementation of `sendfile/5` a +fallback is available, `ranch_transport:sendfile/6`. The extra first argument +is the transport's module. See `ranch_ssl` for an example. diff --git a/docs/en/ranch/1.8/guide/transports/index.html b/docs/en/ranch/1.8/guide/transports/index.html new file mode 100644 index 00000000..aa0274f4 --- /dev/null +++ b/docs/en/ranch/1.8/guide/transports/index.html @@ -0,0 +1,288 @@ + + + + + + + + + + Nine Nines: Transports + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Transports

    + +

    A transport defines the interface to interact with a socket.

    +

    Transports can be used for connecting, listening and accepting connections, but also for receiving and sending data. Both passive and active mode are supported, although all sockets are initialized as passive.

    +

    TCP transport

    +

    The TCP transport is a thin wrapper around gen_tcp.

    +

    SSL transport

    +

    The SSL transport is a thin wrapper around ssl.

    +

    Ranch depends on ssl by default so any necessary dependencies will start when Ranch is started. It is possible to remove the dependency when the SSL transport will not be used. Refer to your release build tool's documentation for more information.

    +

    When embedding Ranch listeners that have an SSL transport, your application must depend on the ssl application for proper behavior.

    +

    Sending and receiving data

    +

    This section assumes that Transport is a valid transport handler (like ranch_tcp or ranch_ssl) and Socket is a connected socket obtained through the listener.

    +

    You can send data to a socket by calling the Transport:send/2 function. The data can be given as iodata(), which is defined as binary() | iolist(). All the following calls will work:

    +
    Sending data to the socket
    +
    +
    Transport:send(Socket, <<"Ranch is cool!">>).
+Transport:send(Socket, "Ranch is cool!").
+Transport:send(Socket, ["Ranch", ["is", "cool!"]]).
+Transport:send(Socket, ["Ranch", [<<"is">>, "cool!"]]).
    +
    +

    You can receive data either in passive or in active mode. Passive mode means that you will perform a blocking Transport:recv/3 call, while active mode means that you will receive the data as a message.

    +

    By default, all data will be received as binary. It is possible to receive data as strings, although this is not recommended as binaries are a more efficient construct, especially for binary protocols.

    +

    Receiving data using passive mode requires a single function call. The first argument is the socket, and the third argument is a timeout duration before the call returns with {error, timeout}.

    +

    The second argument is the amount of data in bytes that we want to receive. The function will wait for data until it has received exactly this amount. If you are not expecting a precise size, you can specify 0 which will make this call return as soon as data was read, regardless of its size.

    +
    Receiving data from the socket in passive mode
    +
    +
    {ok, Data} = Transport:recv(Socket, 0, 5000).
    +
    +

    Active mode requires you to inform the socket that you want to receive data as a message and to write the code to actually receive it.

    +

    There are two kinds of active modes: {active, once} and {active, true}. The first will send a single message before going back to passive mode; the second will send messages indefinitely. We recommend not using the {active, true} mode as it could quickly flood your process mailbox. It's better to keep the data in the socket and read it only when required.

    +

    Three different messages can be received:

    +
    • {OK, Socket, Data} +
      • +
    • {Closed, Socket} +
      • +
    • {Error, Socket, Reason} +
      • +
    +

    The value of OK, Closed and Error can be different depending on the transport being used. To be able to properly match on them you must first call the Transport:messages/0 function.

    +
    Retrieving the transport's active message identifiers
    +
    +
    {OK, Closed, Error} = Transport:messages().
    +
    +

    To start receiving messages you will need to call the Transport:setopts/2 function, and do so every time you want to receive data.

    +
    Receiving messages from the socket in active mode
    +
    +
    {OK, Closed, Error} = Transport:messages(),
+Transport:setopts(Socket, [{active, once}]),
+receive
+	{OK, Socket, Data} ->
+		io:format("data received: ~p~n", [Data]);
+	{Closed, Socket} ->
+		io:format("socket got closed!~n");
+	{Error, Socket, Reason} ->
+		io:format("error happened: ~p~n", [Reason])
+end.
    +
    +

    You can easily integrate active sockets with existing Erlang code as all you really need is just a few more clauses when receiving messages.

    +

    Sending files

    +

    As in the previous section it is assumed Transport is a valid transport handler and Socket is a connected socket obtained through the listener.

    +

    To send a whole file, with name Filename, over a socket:

    +
    Sending a file by filename
    +
    +
    {ok, SentBytes} = Transport:sendfile(Socket, Filename).
    +
    +

    Or part of a file, with Offset greater than or equal to 0, Bytes number of bytes and chunks of size ChunkSize:

    +
    Sending part of a file by filename in chunks
    +
    +
    Opts = [{chunk_size, ChunkSize}],
+{ok, SentBytes} = Transport:sendfile(Socket, Filename, Offset, Bytes, Opts).
    +
    +

    To improve efficiency when sending multiple parts of the same file it is also possible to use a file descriptor opened in raw mode:

    +
    Sending a file opened in raw mode
    +
    +
    {ok, RawFile} = file:open(Filename, [raw, read, binary]),
+{ok, SentBytes} = Transport:sendfile(Socket, RawFile, Offset, Bytes, Opts).
    +
    +

    Upgrading a TCP socket to SSL

    +

    A connected TCP socket can be upgraded to a SSL socket via the function ranch_ssl:handshake/3. The socket must be in {active, false} mode before telling the client that the server is ready to upgrade in order to avoid race conditions.

    +
    Performing a TLS handshake on a TCP socket
    +
    +
    {ok, NewSocket} = ranch_ssl:handshake(Socket, SslOpts, 5000).
    +
    +

    Writing a transport handler

    +

    A transport handler is a module implementing the ranch_transport behavior. It defines a certain number of callbacks that must be written in order to allow transparent usage of the transport handler.

    +

    The behavior doesn't define the socket options available when opening a socket. These do not need to be common to all transports as it's easy enough to write different initialization functions for the different transports that will be used. With one exception though. The setopts/2 function must implement the {active, once} and the {active, true} options.

    +

    If the transport handler doesn't have a native implementation of sendfile/5 a fallback is available, ranch_transport:sendfile/6. The extra first argument is the transport's module. See ranch_ssl for an example.

    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/guide/upcoming_2.0_changes.asciidoc b/docs/en/ranch/1.8/guide/upcoming_2.0_changes.asciidoc new file mode 100644 index 00000000..d7430901 --- /dev/null +++ b/docs/en/ranch/1.8/guide/upcoming_2.0_changes.asciidoc @@ -0,0 +1,34 @@ +[appendix] +== Upcoming changes in Ranch 2.0 + +The following changes will be done in Ranch 2.0. In most +cases an alternative is already available in the most +recent Ranch version. + +* The function `ranch:start_listener/6` has been deprecated + in favor of `ranch:start_listener/5`. The number of acceptors + was removed and will be taken from the transport options. + +* The function `ranch:child_spec/6` has also been deprecated, + in favor of `ranch:child_spec/5`. + +* The function `ranch:accept_ack/1` has been deprecated in + favor of `ranch:handshake/1,2`. + +* The function `ranch:info/1,2` will return a map containing + each listener's information rather than a list of key/values. + The `num_acceptors` key will be removed. + +* The socket will no longer be passed to the protocol when + starting it. It will be available as a return value from + `ranch:handshake/1,2` only. + +* Starting from Ranch 2.0 it will no longer be allowed to + pass Ranch options along with socket options as a proplist. + The only forms allowed will be the `ranch:opts()` map or socket + options as-is. The `ranch:opts()` map must be used in case socket + options also use a map. + +* The `socket` option will be removed. A more viable solution + is to define a custom transport module that returns a fresh + socket when `Transport:listen/1` is called. diff --git a/docs/en/ranch/1.8/guide/upcoming_2.0_changes/index.html b/docs/en/ranch/1.8/guide/upcoming_2.0_changes/index.html new file mode 100644 index 00000000..59c70a06 --- /dev/null +++ b/docs/en/ranch/1.8/guide/upcoming_2.0_changes/index.html @@ -0,0 +1,195 @@ + + + + + + + + + + Nine Nines: Upcoming changes in Ranch 2.0 + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Upcoming changes in Ranch 2.0

    + +

    The following changes will be done in Ranch 2.0. In most cases an alternative is already available in the most recent Ranch version.

    +
    • The function ranch:start_listener/6 has been deprecated in favor of ranch:start_listener/5. The number of acceptors was removed and will be taken from the transport options. +
      • +
    • The function ranch:child_spec/6 has also been deprecated, in favor of ranch:child_spec/5. +
      • +
    • The function ranch:accept_ack/1 has been deprecated in favor of ranch:handshake/1,2. +
      • +
    • The function ranch:info/1,2 will return a map containing each listener's information rather than a list of key/values. The num_acceptors key will be removed. +
      • +
    • The socket will no longer be passed to the protocol when starting it. It will be available as a return value from ranch:handshake/1,2 only. +
      • +
    • Starting from Ranch 2.0 it will no longer be allowed to pass Ranch options along with socket options as a proplist. The only forms allowed will be the ranch:opts() map or socket options as-is. The ranch:opts() map must be used in case socket options also use a map. +
      • +
    • The socket option will be removed. A more viable solution is to define a custom transport module that returns a fresh socket when Transport:listen/1 is called. +
      • +
    + + + + + + + + + + + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/index.html b/docs/en/ranch/1.8/manual/index.html new file mode 100644 index 00000000..feaaaf49 --- /dev/null +++ b/docs/en/ranch/1.8/manual/index.html @@ -0,0 +1,201 @@ + + + + + + + + + + Nine Nines: Ranch Function Reference + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Ranch Function Reference

    + +

    Name

    +

    ranch - Socket acceptor pool for TCP protocols

    +

    Description

    +

    Ranch is a socket acceptor pool for TCP protocols.

    +

    Ranch manages listeners which are a set of processes that accept and manage connections. The connection's transport and protocol modules are configured per listener. Listeners can be inspected and reconfigured without interruptions in service.

    +

    Modules

    +

    Functions:

    + +

    Transports:

    + +

    Behaviors:

    + +

    Dependencies

    +
    • ssl - Secure communication over sockets +
      • +
    +

    All these applications must be started before the ranch application. To start Ranch and all dependencies at once:

    +
    +
    {ok, _} = application:ensure_all_started(ranch).
    +
    +

    Environment

    +

    The ranch application defines one application environment configuration parameter.

    +
    profile (false)
    +

    When enabled, Ranch will start eprof profiling automatically.

    +

    You can use the ranch_app:profile_output/0 function to stop profiling and output the results to the files procs.profile and total.profile. Do not use in production.

    +
    +
    +

    See also

    +

    ssl(7)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.child_spec/index.html b/docs/en/ranch/1.8/manual/ranch.child_spec/index.html new file mode 100644 index 00000000..768ec5ab --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.child_spec/index.html @@ -0,0 +1,219 @@ + + + + + + + + + + Nine Nines: ranch:child_spec(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:child_spec(3)

    + +

    Name

    +

    ranch:child_spec - Build child specifications for a new listener

    +

    Description

    +
    +
    child_spec(Ref       :: ranch_ref(),
+           Transport :: module(),
+           TransOpts :: ranch:opts(),
+           Protocol  :: module(),
+           ProtoOpts :: any())
+    -> supervisor:child_spec()
    +
    +

    Build child specifications for a new listener.

    +

    This function can be used to embed a listener directly in an application's supervision tree.

    +

    Arguments

    +
    Ref
    +

    The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the configuration.

    +

    It can be any Erlang term. An atom is generally good enough, for example api, my_app_clear or my_app_tls.

    +
    +
    Transport
    +

    The transport module that will be used by Ranch to accept connections and that will be passed to the protocol module along with the socket.

    +

    The interface of the transport module is documented in the ranch_transport(3) manual.

    +
    +
    TransportOpts
    +

    Transport options include the Ranch-specific options and the socket options. The listener's port number must be defined in the socket options.

    +

    Socket options may be given directly if there are no Ranch-specific options.

    +

    The available options for the built-in Ranch transports are documented in the ranch_tcp(3) and ranch_ssl(3) manuals.

    +
    +
    Protocol
    +

    The protocol module that will be used by Ranch after the connection has been accepted.

    +

    The interface of the protocol module is documented in the ranch_protocol(3) manual.

    +
    +
    ProtocolOpts
    +

    The protocol options given when calling the protocol module. Please consult the documentation of the protocol module you are using for more details.

    +
    +
    +

    Return value

    +

    Child specifications are returned.

    +

    Changelog

    +
    • 1.4: The NumAcceptors argument was moved to the transport options. +
      • +
    +

    Examples

    +
    Embed a listener
    +
    +
    -behavior(supervisor).
+
+init(_) ->
+    {ok, {#{strategy => one_for_one}, [
+        ranch:child_spec(echo,
+            ranch_tcp, [{port, 5555}],
+            echo_protocol, []
+        )
+    ]}}.
    +
    +

    See also

    +

    ranch:start_listener(3), ranch:stop_listener(3), ranch(3), ranch_tcp(3), ranch_ssl(3), ranch_transport(3), ranch_protocol(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.get_addr/index.html b/docs/en/ranch/1.8/manual/ranch.get_addr/index.html new file mode 100644 index 00000000..75c68874 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.get_addr/index.html @@ -0,0 +1,187 @@ + + + + + + + + + + Nine Nines: ranch:get_addr(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:get_addr(3)

    + +

    Name

    +

    ranch:get_addr - Get the listening port and IP

    +

    Description

    +
    +
    get_addr(Ref :: ranch:ref())
+    -> {IP   :: inet:ip_address(),
+        Port :: inet:port_number()}
    +
    +

    Get the listening port and IP.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    +

    Return value

    +

    The address of the listener is returned as a tuple.

    +

    The IP address is the IP of the network interface the socket is bound to.

    +

    Examples

    +
    Get the listening port and IP
    +
    +
    {IP, Port} = ranch:get_addr(example).
    +
    +

    See also

    +

    ranch:start_listener(3), ranch:get_port(3), ranch:info(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.get_max_connections/index.html b/docs/en/ranch/1.8/manual/ranch.get_max_connections/index.html new file mode 100644 index 00000000..a5725f25 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.get_max_connections/index.html @@ -0,0 +1,185 @@ + + + + + + + + + + Nine Nines: ranch:get_max_connections(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:get_max_connections(3)

    + +

    Name

    +

    ranch:get_max_connections - Get the max number of connections

    +

    Description

    +
    +
    get_max_connections(Ref :: ranch:ref())
+    -> MaxConns :: ranch:max_conns()
    +
    +

    Get the max number of connections.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    +

    Return value

    +

    The maximum number of connections is returned.

    +

    Examples

    +
    Get the max number of connections
    +
    +
    MaxConns = ranch:get_max_connections(example).
    +
    +

    See also

    +

    ranch:get_protocol_options(3), ranch:get_transport_options(3), ranch:set_max_connections(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.get_port/index.html b/docs/en/ranch/1.8/manual/ranch.get_port/index.html new file mode 100644 index 00000000..654e1bf0 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.get_port/index.html @@ -0,0 +1,186 @@ + + + + + + + + + + Nine Nines: ranch:get_port(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:get_port(3)

    + +

    Name

    +

    ranch:get_port - Get the listening port

    +

    Description

    +
    +
    get_port(Ref :: ranch:ref())
+    -> Port :: inet:port_number()
    +
    +

    Get the listening port.

    +

    This function is particularly useful to retrieve the listening port number when it was not provided in the options and was chosen randomly instead.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    +

    Return value

    +

    The listening port is returned.

    +

    Examples

    +
    Get the listening port
    +
    +
    Port = ranch:get_port(example).
    +
    +

    See also

    +

    ranch:start_listener(3), ranch:get_addr(3), ranch:info(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.get_protocol_options/index.html b/docs/en/ranch/1.8/manual/ranch.get_protocol_options/index.html new file mode 100644 index 00000000..fb328f7f --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.get_protocol_options/index.html @@ -0,0 +1,185 @@ + + + + + + + + + + Nine Nines: ranch:get_protocol_options(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:get_protocol_options(3)

    + +

    Name

    +

    ranch:get_protocol_options - Get the current protocol options

    +

    Description

    +
    +
    get_protocol_options(Ref :: ranch:ref())
+    -> ProtoOpts :: any()
    +
    +

    Get the current protocol options.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    +

    Return value

    +

    The current protocol options are returned.

    +

    Examples

    +
    Get the current protocol options
    +
    +
    ProtoOpts = ranch:get_protocol_options(example).
    +
    +

    See also

    +

    ranch:get_max_connections(3), ranch:get_transport_options(3), ranch:set_protocol_options(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.get_status/index.html b/docs/en/ranch/1.8/manual/ranch.get_status/index.html new file mode 100644 index 00000000..c40608d1 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.get_status/index.html @@ -0,0 +1,188 @@ + + + + + + + + + + Nine Nines: ranch:get_status(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:get_status(3)

    + +

    Name

    +

    ranch:get_status - Get a listener's running state

    +

    Description

    +
    +
    get_status(Ref :: ranch_ref()) -> running | suspended
    +
    +

    Get a listener's running state.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    +

    Return value

    +

    An atom is returned indicating the running status of the listener.

    +

    Changelog

    +
    • 1.6: Function introduced. +
      • +
    +

    Examples

    +
    Get a listener's running state
    +
    +
    ranch:get_status(example).
    +
    +

    See also

    +

    ranch:start_listener(3), ranch:stop_listener(3), ranch:suspend_listener(3), ranch:resume_listener(3), ranch:set_transport_options(3), ranch:wait_for_connections(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.get_transport_options/index.html b/docs/en/ranch/1.8/manual/ranch.get_transport_options/index.html new file mode 100644 index 00000000..fea15783 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.get_transport_options/index.html @@ -0,0 +1,185 @@ + + + + + + + + + + Nine Nines: ranch:get_transport_options(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:get_transport_options(3)

    + +

    Name

    +

    ranch:get_transport_options - Get the current transport options

    +

    Description

    +
    +
    get_transport_options(Ref :: ranch:ref())
+    -> TransOpts :: any()
    +
    +

    Get the current transport options.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    +

    Return value

    +

    The current transport options are returned.

    +

    Examples

    +
    Get the current transport options
    +
    +
    TransOpts = ranch:get_transport_options(example).
    +
    +

    See also

    +

    ranch:get_max_connections(3), ranch:get_protocol_options(3), ranch:set_transport_options(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.handshake/index.html b/docs/en/ranch/1.8/manual/ranch.handshake/index.html new file mode 100644 index 00000000..0397df7b --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.handshake/index.html @@ -0,0 +1,208 @@ + + + + + + + + + + Nine Nines: ranch:handshake(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:handshake(3)

    + +

    Name

    +

    ranch:handshake - Perform the transport handshake

    +

    Description

    +
    +
    handshake(Ref)       -> handshake(Ref, [])
+handshake(Ref, Opts) -> {ok, Socket}
+
+Ref    :: ranch:ref()
+Opts   :: any()
+Socket :: any()
    +
    +

    Perform the transport handshake.

    +

    This function must be called by the protocol process in order to retrieve the socket for the connection. Ranch performs the handshake necessary to give control of the socket to this process and also does the transport handshake, for example setting up the TLS connection.

    +

    Currently the socket can be obtained from a Protocol:start_link/4 argument and as a return value from ranch:handshake/1,2. In Ranch 2.0 the socket will only be available from ranch:handshake/1,2.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    Opts
    +

    Transport handshake options.

    +

    Allowed options depend on the transport module.

    +
    +
    +

    Return value

    +

    An ok tuple is returned containing the socket for the connection.

    +

    This function will trigger an exception when an error occurs.

    +

    Changelog

    +
    • 1.6: Function introduced. Replaces ranch:accept_ack/1. +
      • +
    +

    Examples

    +
    Initialize the connection process
    +
    +
    start_link(Ref, _, Transport, Opts) ->
+    Pid = proc_lib:spawn_link(?MODULE, init,
+        [Ref, Transport, Opts]),
+    {ok, Pid}.
+
+init(Ref, Transport, Opts) ->
+    {ok, Socket} = ranch:handshake(Ref),
+    loop(#state{ref=Ref, socket=Socket,
+        transport=Transport, opts=Opts}).
    +
    +

    See also

    +

    ranch:start_listener(3), ranch:recv_proxy_header(3), ranch:remove_connection(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.info/index.html b/docs/en/ranch/1.8/manual/ranch.info/index.html new file mode 100644 index 00000000..36ca7392 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.info/index.html @@ -0,0 +1,233 @@ + + + + + + + + + + Nine Nines: ranch:info(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:info(3)

    + +

    Name

    +

    ranch:info - Overview of Ranch listeners

    +

    Description

    +
    +
    info() -> [{Ref, Info}]
+info(Ref) -> Info
+
+Info :: [{Key :: atom(), Value :: any()}]
    +
    +

    Overview of Ranch listeners.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    +

    Return value

    +

    Returns detailed information about one or all Ranch listeners. The following keys are returned:

    +
    pid
    +

    Pid of the listener's top-level supervisor.

    +
    +
    status
    +

    Listener status, either running or suspended.

    +
    +
    ip
    +

    Interface Ranch listens on.

    +
    +
    port
    +

    Port number Ranch listens on.

    +
    +
    num_acceptors
    +

    Number of acceptor processes.

    +
    +
    max_connections
    +

    Maximum number of connections.

    +
    +
    active_connections
    +

    Number of active connections.

    +
    +
    all_connections
    +

    Number of connections, including those removed from the count.

    +
    +
    transport
    +

    Transport module.

    +
    +
    transport_options
    +

    Transport options.

    +
    +
    protocol
    +

    Protocol module.

    +
    +
    protocol_options
    +

    Protocol options.

    +
    +
    + + +

    Examples

    +
    Get information about all listeners
    +
    +
    AllInfo = ranch:info().
    +
    +
    Get information about a specific listener
    +
    +
    Info = ranch:info(example).
    +
    +

    See also

    +

    ranch:get_addr(3), ranch:get_port(3), ranch:procs(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.procs/index.html b/docs/en/ranch/1.8/manual/ranch.procs/index.html new file mode 100644 index 00000000..e72bfd83 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.procs/index.html @@ -0,0 +1,196 @@ + + + + + + + + + + Nine Nines: ranch:procs(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:procs(3)

    + +

    Name

    +

    ranch:procs - Retrieve pids from a listener

    +

    Description

    +
    +
    procs(Ref  :: ranch:ref(),
+      Type :: acceptors | connections)
+    -> Pids :: [pid()]
    +
    +

    Retrieve pids from a listener.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    Type
    +

    The type of process that will be returned.

    +
    +
    +

    Return value

    +

    A list of pids is returned.

    +

    Examples

    +
    Get the pids of the acceptor processes
    +
    +
    Pids = ranch:procs(acceptors).
    +
    +
    Get the pids of the connection processes
    +
    +
    Pids = ranch:procs(connections).
    +
    +

    See also

    +

    ranch:get_addr(3), ranch:get_port(3), ranch:info(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.recv_proxy_header/index.html b/docs/en/ranch/1.8/manual/ranch.recv_proxy_header/index.html new file mode 100644 index 00000000..91874776 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.recv_proxy_header/index.html @@ -0,0 +1,206 @@ + + + + + + + + + + Nine Nines: ranch:recv_proxy_header(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:recv_proxy_header(3)

    + +

    Name

    +

    ranch:recv_proxy_header - Receive the PROXY protocol header

    +

    Description

    +
    +
    recv_proxy_header(ranch:ref(), timeout())
+    -> {ok, ranch_proxy_header:proxy_info()}
+     | {error, Reason :: atom()}
+     | {error, protocol_error, HumanReadable :: atom()}
    +
    +

    Receive the PROXY protocol header.

    +

    This function must be called before ranch:handshake/1,2 on newly accepted connections to read and parse the PROXY protocol header, if any.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    Timeout
    +

    Receive timeout in milliseconds.

    +
    +
    +

    Return value

    +

    An ok tuple is returned containing PROXY header information on success.

    +

    An error 2-tuple is returned when a socket error occurs.

    +

    An error 3-tuple is returned when a protocol error occurs and Ranch was not able to parse the PROXY header information. The third element contains a human-readable description of the error.

    +

    Changelog

    +
    • 1.7: Function introduced. +
      • +
    +

    Examples

    +
    Receive the PROXY protocol header
    +
    +
    start_link(Ref, _, Transport, Opts) ->
+    Pid = proc_lib:spawn_link(?MODULE, init,
+        [Ref, Transport, Opts]),
+    {ok, Pid}.
+
+init(Ref, Transport, Opts) ->
+    {ok, ProxyInfo} = ranch:recv_proxy_header(Ref, 1000),
+    {ok, Socket} = ranch:handshake(Ref),
+    loop(#state{ref=Ref, socket=Socket, transport=Transport,
+        proxy_info=ProxyInfo, opts=Opts}).
    +
    +

    See also

    +

    ranch:start_listener(3), ranch:handshake(3), ranch:remove_connection(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.remove_connection/index.html b/docs/en/ranch/1.8/manual/ranch.remove_connection/index.html new file mode 100644 index 00000000..fd9e107a --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.remove_connection/index.html @@ -0,0 +1,186 @@ + + + + + + + + + + Nine Nines: ranch:remove_connection(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:remove_connection(3)

    + +

    Name

    +

    ranch:remove_connection - Remove connection from the count

    +

    Description

    +
    +
    remove_connection(Ref :: ranch:ref()) -> ok
    +
    +

    Remove connection from the count.

    +

    This connection will no longer be included in the count when limiting the number of connections. This can be useful in a mixed environment where some connections are active and others are passive. Passive connections spend most of their time idling and are not consuming much resources.

    +

    This function may only be called from a connection process.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    +

    Return value

    +

    The atom ok is always returned. It can be safely ignored.

    +

    Examples

    +
    Remove the connection process from the count
    +
    +
    ranch:remove_connection(example).
    +
    +

    See also

    +

    ranch:start_listener(3), ranch:handshake(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.resume_listener/index.html b/docs/en/ranch/1.8/manual/ranch.resume_listener/index.html new file mode 100644 index 00000000..cc3eda7d --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.resume_listener/index.html @@ -0,0 +1,192 @@ + + + + + + + + + + Nine Nines: ranch:resume_listener(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:resume_listener(3)

    + +

    Name

    +

    ranch:resume_listener - Resume a suspended listener

    +

    Description

    +
    +
    resume_listener(Ref :: ranch_ref())
+    -> ok | {error, any()}
    +
    +

    Resume a suspended listener.

    +

    Ranch will start listening for and accepting connections again. The function ranch:set_transport_options(3) can be used to change the transport options before resuming the listener.

    +

    Nothing is done when the listener is already running.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    +

    Return value

    +

    The atom ok is returned on success.

    +

    An error tuple is returned when the listener could not be restarted.

    +

    Changelog

    +
    • 1.6: Function introduced. +
      • +
    +

    Examples

    +
    Resume a listener
    +
    +
    ok = ranch:resume_listener(example).
    +
    +

    See also

    +

    ranch:start_listener(3), ranch:stop_listener(3), ranch:suspend_listener(3), ranch:get_status(3), ranch:set_transport_options(3), ranch:wait_for_connections(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.set_max_connections/index.html b/docs/en/ranch/1.8/manual/ranch.set_max_connections/index.html new file mode 100644 index 00000000..7a5d226b --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.set_max_connections/index.html @@ -0,0 +1,190 @@ + + + + + + + + + + Nine Nines: ranch:set_max_connections(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:set_max_connections(3)

    + +

    Name

    +

    ranch:set_max_connections - Set the max number of connections

    +

    Description

    +
    +
    set_max_connections(Ref      :: ranch:ref(),
+                    MaxConns :: ranch:max_conns())
+    -> ok
    +
    +

    Set the max number of connections.

    +

    The change will be applied immediately. If the new value is smaller than the previous one, Ranch will wait for the extra connections to terminate and will not accept new connections until the number of connections goes below the limit.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    MaxConns
    +

    The new maximum number of connections.

    +
    +
    +

    Return value

    +

    The atom ok is always returned. It can be safely ignored.

    +

    Examples

    +
    Set the max number of connections
    +
    +
    ranch:set_max_connections(example, 10000).
    +
    +

    See also

    +

    ranch:get_max_connections(3), ranch:set_protocol_options(3), ranch:set_transport_options(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.set_protocol_options/index.html b/docs/en/ranch/1.8/manual/ranch.set_protocol_options/index.html new file mode 100644 index 00000000..3e4e4632 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.set_protocol_options/index.html @@ -0,0 +1,190 @@ + + + + + + + + + + Nine Nines: ranch:set_protocol_options(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:set_protocol_options(3)

    + +

    Name

    +

    ranch:set_protocol_options - Set the protocol options

    +

    Description

    +
    +
    set_protocol_options(Ref       :: ranch:ref(),
+                     ProtoOpts :: any())
+    -> ok
    +
    +

    Set the protocol options.

    +

    The change will be applied immediately for all new connections. Old connections will not receive the new options.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    ProtoOpts
    +

    The new protocol options.

    +
    +
    +

    Return value

    +

    The atom ok is always returned. It can be safely ignored.

    +

    Examples

    +
    Set the protocol options
    +
    +
    ranch:set_protocol_options(example, ProtoOpts).
    +
    +

    See also

    +

    ranch:get_protocol_options(3), ranch:set_max_connections(3), ranch:set_transport_options(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.set_transport_options/index.html b/docs/en/ranch/1.8/manual/ranch.set_transport_options/index.html new file mode 100644 index 00000000..9b174655 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.set_transport_options/index.html @@ -0,0 +1,195 @@ + + + + + + + + + + Nine Nines: ranch:set_transport_options(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:set_transport_options(3)

    + +

    Name

    +

    ranch:set_transport_options - Set the transport options

    +

    Description

    +
    +
    set_transport_options(Ref       :: ranch:ref(),
+                      TransOpts :: any())
+    -> ok | {error, running}
    +
    +

    Set the transport options.

    +

    The listener must be suspended for this call to succeed. If the listener is running, {error, running} will be returned.

    +

    The change will take effect when the listener resumes.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    TransOpts
    +

    The new transport options.

    +
    +
    +

    Return value

    +

    The atom ok is always returned. It can be safely ignored.

    +

    Examples

    +
    Set the transport options
    +
    +
    Ref = example,
+
+ok = ranch:suspend_listener(Ref),
+ok = ranch:set_transport_options(Ref, TransOpts),
+ok = ranch:resume_listener(Ref).
    +
    +

    See also

    +

    ranch:suspend_listener(3), ranch:resume_listener(3), ranch:get_transport_options(3), ranch:set_max_connections(3), ranch:set_protocol_options(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.start_listener/index.html b/docs/en/ranch/1.8/manual/ranch.start_listener/index.html new file mode 100644 index 00000000..9a4d173d --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.start_listener/index.html @@ -0,0 +1,244 @@ + + + + + + + + + + Nine Nines: ranch:start_listener(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:start_listener(3)

    + +

    Name

    +

    ranch:start_listener - Start a listener

    +

    Description

    +
    +
    start_listener(Ref       :: ranch_ref(),
+               Transport :: module(),
+               TransOpts :: ranch:opts(),
+               Protocol  :: module(),
+               ProtoOpts :: any())
+    -> {ok, ListenerPid :: pid()}
+     | {error, any()}
    +
    +

    Start a listener.

    +

    A listener is a set of processes that accepts and manages connections using the given transport and protocol modules.

    +

    Arguments

    +
    Ref
    +

    The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the configuration.

    +

    It can be any Erlang term. An atom is generally good enough, for example api, my_app_clear or my_app_tls.

    +
    +
    Transport
    +

    The transport module that will be used by Ranch to accept connections and that will be passed to the protocol module along with the socket.

    +

    The interface of the transport module is documented in the ranch_transport(3) manual.

    +
    +
    TransportOpts
    +

    Transport options include the Ranch-specific options and the socket options. The listener's port number must be defined in the socket options.

    +

    Socket options may be given directly if there are no Ranch-specific options.

    +

    The available options for the built-in Ranch transports are documented in the ranch_tcp(3) and ranch_ssl(3) manuals.

    +
    +
    Protocol
    +

    The protocol module that will be used by Ranch after the connection has been accepted.

    +

    The interface of the protocol module is documented in the ranch_protocol(3) manual.

    +
    +
    ProtocolOpts
    +

    The protocol options given when calling the protocol module. Please consult the documentation of the protocol module you are using for more details.

    +
    +
    +

    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 Ranch is already in use.

    +

    Changelog

    +
    • 1.4: The NumAcceptors argument was moved to the transport options. +
      • +
    +

    Examples

    +
    Start a listener
    +
    +
    {ok, _} = ranch:start_listener(example,
+    ranch_tcp, [{port, 8080}],
+    cowboy_http2, #{}
+).
    +
    +
    Start a listener with Ranch-specific options
    +
    +
    {ok, _} = ranch:start_listener(example,
+    ranch_tcp, #{
+        num_acceptors => 75,
+        socket_opts => [{port, 8080}]
+    },
+    cowboy_http2, #{}
+).
    +
    +
    Start a listener on a random port
    +
    +
    Ref = example,
+
+{ok, _} = ranch:start_listener(Ref,
+    ranch_tcp, #{},
+    cowboy_http2, #{}
+),
+
+Port = ranch:get_port(Ref).
    +
    +

    See also

    +

    ranch:stop_listener(3), ranch:child_spec(3), ranch(3), ranch_tcp(3), ranch_ssl(3), ranch_transport(3), ranch_protocol(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.stop_listener/index.html b/docs/en/ranch/1.8/manual/ranch.stop_listener/index.html new file mode 100644 index 00000000..f5e820b2 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.stop_listener/index.html @@ -0,0 +1,189 @@ + + + + + + + + + + Nine Nines: ranch:stop_listener(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:stop_listener(3)

    + +

    Name

    +

    ranch:stop_listener - Stop a listener

    +

    Description

    +
    +
    stop_listener(Ref :: ranch_ref())
+    -> ok | {error, not_found}
    +
    +

    Stop a listener.

    +

    The listener is stopped gracefully, first by closing the listening port, then by stopping the connection processes. These processes are stopped according to the shutdown transport option, which may be set to brutally kill all connection processes or give them some time to stop properly.

    +

    In order for the connection processes to exit gracefully, they need to trap exit signals and stop before the configured shutdown timeout. If greater control over the shutdown is required the functions ranch:suspend_listener(3) and ranch:wait_for_connections(3) can be used.

    +

    This function does not return until the listener is completely stopped.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    +

    Return value

    +

    The atom ok is returned on success.

    +

    An error tuple is returned when the listener is not found.

    +

    Examples

    +
    Stop a listener
    +
    +
    ok = ranch:stop_listener(example).
    +
    +

    See also

    +

    ranch:start_listener(3), ranch:child_spec(3), ranch:suspend_listener(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.suspend_listener/index.html b/docs/en/ranch/1.8/manual/ranch.suspend_listener/index.html new file mode 100644 index 00000000..61549a9c --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.suspend_listener/index.html @@ -0,0 +1,193 @@ + + + + + + + + + + Nine Nines: ranch:suspend_listener(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:suspend_listener(3)

    + +

    Name

    +

    ranch:suspend_listener - Suspend a running listener

    +

    Description

    +
    +
    suspend_listener(Ref :: ranch_ref())
+    -> ok | {error, any()}
    +
    +

    Suspend a running listener.

    +

    Ranch will stop listening for and accepting connections and the listening socket will be closed. Existing connections will continue undisturbed. The function ranch:wait_for_connections(3) can be used to wait for connections to be closed if necessary.

    +

    Some transport options can only be changed when the listener is suspended. Please consult the ranch:set_transport_options(3) manual for more information.

    +

    Nothing is done when the listener is already suspended.

    +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    +

    Return value

    +

    The atom ok is returned on success.

    +

    An error tuple is returned when the listener could not be suspended.

    +

    Changelog

    +
    • 1.6: Function introduced. +
      • +
    +

    Examples

    +
    Suspend a listener
    +
    +
    ok = ranch:suspend_listener(example).
    +
    +

    See also

    +

    ranch:start_listener(3), ranch:stop_listener(3), ranch:resume_listener(3), ranch:get_status(3), ranch:set_transport_options(3), ranch:wait_for_connections(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch.wait_for_connections/index.html b/docs/en/ranch/1.8/manual/ranch.wait_for_connections/index.html new file mode 100644 index 00000000..7a661190 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch.wait_for_connections/index.html @@ -0,0 +1,213 @@ + + + + + + + + + + Nine Nines: ranch:wait_for_connections(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch:wait_for_connections(3)

    + +

    Name

    +

    ranch:wait_for_connections - Wait for a specific number of connections

    +

    Description

    +
    +
    wait_for_connections(Ref      :: ranch:ref(),
+                     Operator,
+                     NumConns :: non_neg_integer())
+    -> ok
+
+Operator :: '>' | '>=' | '==' | '=<' | '<'
    +
    +

    Wait for a specific number of connections.

    +

    This function waits until the number of connections on the given listener becomes higher than, equal to or lower than the given number. It never returns otherwise.

    +

    This function can be used to gracefully shutdown a listener by first suspending the listener and then waiting for connections to terminate before finally stopping the listener.

    + +

    Arguments

    +
    Ref
    +

    The listener name.

    +
    +
    Operator
    +

    The operator to use for the comparison.

    +
    +
    NumConns
    +

    The number of connections to reach.

    +
    +
    +

    Return value

    +

    The atom ok is always returned. It can be safely ignored.

    +

    Changelog

    +
    • 1.6: Function introduced. +
      • +
    +

    Examples

    +
    Wait for at least 100 connections
    +
    +
    ranch:wait_for_connections(example, '>=', 100).
    +
    +
    Gracefully shutdown a listener
    +
    +
    Ref = example,
+
+ok = ranch:suspend_listener(Ref),
+ranch:wait_for_connections(Ref, '==', 0),
+ok = ranch:stop_listener(Ref).
    +
    +

    See also

    +

    ranch:stop_listener(3), ranch:suspend_listener(3), ranch:resume_listener(3), ranch(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch/index.html b/docs/en/ranch/1.8/manual/ranch/index.html new file mode 100644 index 00000000..b12eadbc --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch/index.html @@ -0,0 +1,298 @@ + + + + + + + + + + Nine Nines: ranch(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch(3)

    + +

    Name

    +

    ranch - Socket acceptor pool

    +

    Description

    +

    The module ranch provides functions for starting and manipulating Ranch listeners.

    +

    Exports

    +

    Start/stop:

    + +

    Suspend/resume:

    + +

    Connections:

    + +

    Options:

    + +

    Introspection:

    + +

    Types

    +

    max_conns()

    +
    +
    max_conns() = non_neg_integer() | infinity
    +
    +

    Maximum number of connections allowed on this listener.

    +

    This is a soft limit. The actual number of connections might be slightly above the limit due to concurrency when accepting new connections. Some connections may also be removed from this count explicitly by the user code.

    +

    opt()

    +
    +
    opt() = {ack_timeout, timeout()}
+      | {connection_type, worker | supervisor}
+      | {max_connections, max_conns()}
+      | {num_acceptors, pos_integer()}
+      | {shutdown, timeout() | brutal_kill}
+      | {socket, any()}
    +
    +

    Deprecated form for Ranch-specific options.

    +

    Please use the opts() type when you need to provide Ranch-specific transport options. Socket options will remain separate from the Ranch-specific options.

    +

    opts()

    +
    +
    opts() = any() | #{
+    connection_type   => worker | supervisor,
+    handshake_timeout => timeout(),
+    max_connections   => max_conns(),
+    logger            => module(),
+    num_acceptors     => pos_integer(),
+    shutdown          => timeout() | brutal_kill,
+    socket            => any(),
+    socket_opts       => any()
+}
    +
    +

    Transport options.

    +

    The transport options are a combination of Ranch-specific options and socket options. Socket options may be given directly (assuming they are not a map and no Ranch-specific option needs to be given) or as part of socket_opts.

    +

    None of the options are required.

    +
    ack_timeout
    +

    When ack_timeout is found in a transport options proplist, it is converted to the handshake_timeout option from the map. They are equivalent. The ack_timeout option will be removed in Ranch 2.0.

    +
    +
    connection_type (worker)
    +

    Type of process that will handle the connection.

    +
    +
    handshake_timeout (5000)
    +

    Maximum allowed time for the ranch:handshake/1,2 call to finish.

    +
    +
    max_connections (1024)
    +

    Maximum number of active connections. Soft limit. Use infinity to disable the limit entirely.

    +
    +
    num_acceptors (10)
    +

    Number of processes that accept connections.

    +
    +
    shutdown (5000)
    +

    Maximum allowed time for children to stop on listener shutdown.

    +
    +
    socket
    +

    Listening socket opened externally to be used instead of calling Transport:listen/1. This option will be removed in Ranch 2.0. Use a custom transport module acting as a wrapper for ranch_tcp or ranch_ssl instead.

    +
    +
    socket_opts
    +

    Socket options given to Transport:listen/1. Please refer to the documentation of the transport module you are using for more details.

    +
    +
    +

    ref()

    +
    +
    ref() = any()
    +
    +

    Unique name used to refer to a listener.

    +

    Changelog

    +
    • 1.6: The logger option was added. +
      • +
    • 1.6: The opt() type was deprecated in favor of the new opts() type. +
      • +
    +

    See also

    +

    ranch(7)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch_app/index.html b/docs/en/ranch/1.8/manual/ranch_app/index.html new file mode 100644 index 00000000..95a21bc1 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch_app/index.html @@ -0,0 +1,201 @@ + + + + + + + + + + Nine Nines: ranch(7) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch(7)

    + +

    Name

    +

    ranch - Socket acceptor pool for TCP protocols

    +

    Description

    +

    Ranch is a socket acceptor pool for TCP protocols.

    +

    Ranch manages listeners which are a set of processes that accept and manage connections. The connection's transport and protocol modules are configured per listener. Listeners can be inspected and reconfigured without interruptions in service.

    +

    Modules

    +

    Functions:

    + +

    Transports:

    + +

    Behaviors:

    + +

    Dependencies

    +
    • ssl - Secure communication over sockets +
      • +
    +

    All these applications must be started before the ranch application. To start Ranch and all dependencies at once:

    +
    +
    {ok, _} = application:ensure_all_started(ranch).
    +
    +

    Environment

    +

    The ranch application defines one application environment configuration parameter.

    +
    profile (false)
    +

    When enabled, Ranch will start eprof profiling automatically.

    +

    You can use the ranch_app:profile_output/0 function to stop profiling and output the results to the files procs.profile and total.profile. Do not use in production.

    +
    +
    +

    See also

    +

    ssl(7)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch_protocol/index.html b/docs/en/ranch/1.8/manual/ranch_protocol/index.html new file mode 100644 index 00000000..9607bb31 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch_protocol/index.html @@ -0,0 +1,185 @@ + + + + + + + + + + Nine Nines: ranch_protocol(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch_protocol(3)

    + +

    Name

    +

    ranch_protocol - Protocol modules

    +

    Description

    +

    The module ranch_protocol defines the interface used by Ranch protocols.

    +

    Callbacks

    +

    Ranch protocols implement the following interface:

    +
    +
    start_link(Ref       :: ranch:ref(),
+           _,
+           Transport :: module(),
+           ProtoOpts :: any())
+    -> {ok, ConnPid :: pid()}
+     | {ok, SupPid :: pid(), ConnPid :: pid()}
    +
    +

    Start a new connection process.

    +

    The only purpose of this callback is to start a process that will handle the socket. It must spawn the process, link and then return the new pid. This function will always be called from inside a supervisor.

    +

    This callback can also return two pids. The first pid is the pid of the process that will be supervised. The second pid is the pid of the process that will receive ownership of the socket. This second process must be a child of the first. This form is only available when connection_type is set to supervisor.

    +

    If any other value is returned, the supervisor will close the socket and assume no process has been started.

    +

    Do not perform any operations in this callback, as this would block the supervisor responsible for starting connection processes and degrade performance severely.

    +

    Changelog

    +
    • 1.6: The second argument Socket was deprecated and will be removed in Ranch 2.0. The socket should be obtained by calling ranch:handshake(3). +
      • +
    +

    See also

    +

    ranch:handshake(3), ranch(7)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch_proxy_header.header/index.html b/docs/en/ranch/1.8/manual/ranch_proxy_header.header/index.html new file mode 100644 index 00000000..a8d3e9d0 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch_proxy_header.header/index.html @@ -0,0 +1,220 @@ + + + + + + + + + + Nine Nines: ranch_proxy_header:header(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch_proxy_header:header(3)

    + +

    Name

    +

    ranch_proxy_header:header - Build a PROXY protocol header

    +

    Description

    +
    +
    header(ProxyInfo)            -> header(ProxyInfo, #{})
+header(ProxyInfo, BuildOpts) -> iodata()
+
+ProxyInfo :: ranch_proxy_header:proxy_info()
+BuildOpts :: #{
+    checksum => crc32c,
+    padding  => pos_integer() %% >= 3
+}
    +
    +

    Build a PROXY protocol header.

    +

    Arguments

    +
    ProxyInfo
    +

    The proxy information to encode.

    +
    +
    BuildOpts
    +

    Options to control whether to add a checksum or padding should be included in the encoded PROXY protocol header.

    +
    +
    +

    Return value

    +

    The PROXY protocol header is returned.

    +

    Changelog

    +
    • 1.7: Function introduced. +
      • +
    +

    Examples

    +
    Build a PROXY protocol header
    +
    +
    ProxyInfo = #{
+    version => 2,
+    command => proxy,
+
+    transport_family   => ipv4,
+    transport_protocol => stream,
+
+    src_address  => {192, 168, 1, 11},
+    src_port     => 54321,
+    dest_address => {192, 168, 1, 42},
+    dest_port    => 443
+},
+Data = ranch_proxy_header:parse(ProxyInfo).
    +
    +
    Build a PROXY protocol header with checksum and padding
    +
    +
    Data = ranch_proxy_header:parse(ProxyInfo, #{
+    checksum => crc32c,
+    padding  => 7
+}).
    +
    +

    See also

    +

    ranch_proxy_header:header(3), ranch_proxy_header(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch_proxy_header.parse/index.html b/docs/en/ranch/1.8/manual/ranch_proxy_header.parse/index.html new file mode 100644 index 00000000..2489ce91 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch_proxy_header.parse/index.html @@ -0,0 +1,191 @@ + + + + + + + + + + Nine Nines: ranch_proxy_header:parse(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch_proxy_header:parse(3)

    + +

    Name

    +

    ranch_proxy_header:parse - Parse a PROXY protocol header

    +

    Description

    +
    +
    parse(Data :: binary())
+    -> {ok, ranch_proxy_header:proxy_info(), Rest :: binary()}
+     | {error, HumanReadable :: atom()}
    +
    +

    Parse a PROXY protocol header.

    +

    Arguments

    +
    Data
    +

    The PROXY protocol header optionally followed by more data.

    +
    +
    +

    Return value

    +

    An ok tuple is returned on success, containing the proxy information found in the header and the rest of the data if more was provided.

    +

    An error tuple is returned when a protocol error is detected. It contains a human readable message about the error.

    +

    Changelog

    +
    • 1.7: Function introduced. +
      • +
    +

    Examples

    +
    Parse the PROXY protocol header
    +
    +
    {ok ProxyInfo, Rest} = ranch_proxy_header:parse(Data).
    +
    +

    See also

    +

    ranch_proxy_header:header(3), ranch_proxy_header(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch_proxy_header/index.html b/docs/en/ranch/1.8/manual/ranch_proxy_header/index.html new file mode 100644 index 00000000..3aae5bda --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch_proxy_header/index.html @@ -0,0 +1,274 @@ + + + + + + + + + + Nine Nines: ranch_proxy_header(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch_proxy_header(3)

    + +

    Name

    +

    ranch_proxy_header - PROXY protocol

    +

    Description

    +

    The module ranch_proxy_header provides functions for parsing and building the PROXY protocol header.

    +

    Exports

    + +

    Types

    +

    proxy_info()

    +
    +
    proxy_info() = #{
+    %% Mandatory part.
+    version := 1 | 2,
+    command := local | proxy,
+    transport_family   => undefined | ipv4 | ipv6 | unix,
+    transport_protocol => undefined | stream | dgram,
+
+    %% Addresses.
+    src_address  => inet:ip_address() | binary(),
+    src_port     => inet:port_number(),
+    dest_address => inet:ip_address() | binary(),
+    dest_port    => inet:port_number(),
+
+    %% Extra TLV-encoded data.
+    alpn      => binary(), %% US-ASCII.
+    authority => binary(), %% UTF-8.
+    netns     => binary(), %% US-ASCII.
+    ssl       => #{
+        client   := [ssl | cert_conn | cert_sess],
+        verified := boolean(),
+        version  => binary(), %% US-ASCII.
+        cipher   => binary(), %% US-ASCII.
+        sig_alg  => binary(), %% US-ASCII.
+        key_alg  => binary(), %% US-ASCII.
+        cn       => binary()  %% UTF-8.
+    },
+
+    %% Unknown TLVs can't be parsed so the raw data is given.
+    raw_tlvs => [{0..255, binary()}]
+}.
    +
    +

    The PROXY protocol information.

    +

    The following fields may be found, although most of them are optional:

    +
    version
    +

    The PROXY protocol version used.

    +
    +
    command
    +

    proxy is used for proxied connections. local for non-proxied connections. Those do not have any additional information.

    +
    +
    transport_family
    +

    The transport family of the original connection.

    +
    +
    transport_protocol
    +

    The transport protocol of the original connection.

    +
    +
    src_address
    +

    The source address of the original connection. This is the original address of the client.

    +
    +
    src_port
    +

    The source port of the original connection. This is the port the client opened on its end for the connection. It is not defined for UNIX domain sockets.

    +
    +
    dest_address
    +

    The destination address of the original connection.

    +
    +
    dest_port
    +

    The destination port of the original connection. It is not defined for UNIX domain sockets.

    +
    +
    alpn
    +

    The upper layer protocol in use over the connection. This is typically negotiated via the ALPN extension for TLS.

    +
    +
    authority
    +

    The host name serving as authority for the connection. This is typically passed using the SNI extension for TLS.

    +
    +
    netns
    +

    The namespace's name for the original connection.

    +
    +
    ssl
    +

    Various informations pertaining to the original SSL/TLS connection.

    +
    client
    +

    A list containing a number of flags. ssl indicates that the client connected over SSL/TLS. cert_conn indicates that the client provided a certificate over the original connection. cert_sess indicates that the client provided a certificate at least once over the TLS session this connection belongs to.

    +
    +
    verified
    +

    Whether the client presented a certificate and it was successfully verified.

    +
    +
    version
    +

    The US-ASCII string containing the SSL/TLS version used for the original connection.

    +
    +
    cipher
    +

    The US-ASCII string name of the cipher used.

    +
    +
    sig_alg
    +

    The US-ASCII string name of the algorithm used to sign the certificate provided by the client.

    +
    +
    key_alg
    +

    The US-ASCII string name of the algorithm used to generate the key of the certificate provided by the client.

    +
    +
    cn
    +

    The UTF-8 string representation of the Common Name field of the client certificate's Distinguished Name.

    +
    +
    +
    +
    raw_tlvs
    +

    The non-standard TLVs that Ranch was not able to parse.

    +
    +
    +

    Changelog

    +
    • 1.7: Module introduced. +
      • +
    +

    See also

    +

    ranch(7)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch_ssl/index.html b/docs/en/ranch/1.8/manual/ranch_ssl/index.html new file mode 100644 index 00000000..ff227404 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch_ssl/index.html @@ -0,0 +1,337 @@ + + + + + + + + + + Nine Nines: ranch_ssl(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch_ssl(3)

    + +

    Name

    +

    ranch_ssl - SSL transport

    +

    Description

    +

    The module ranch_ssl implements an SSL Ranch transport.

    +

    Exports

    +

    The module ranch_ssl implements the interface defined by ranch_transport(3).

    +

    Types

    +

    opt()

    +
    +
    opt() :: ranch_tcp:opt() | ssl_opt()
    +
    +

    Listen options.

    +

    The TCP options are defined in ranch_tcp(3).

    +

    opts()

    +
    +
    opts() :: [opt()]
    +
    +

    List of listen options.

    +

    ssl_opt()

    +
    +
    ssl_opt() = {alpn_preferred_protocols, [binary()]}
+          | {beast_mitigation, one_n_minus_one | zero_n | disabled}
+          | {cacertfile, string()}
+          | {cacerts, [public_key:der_encoded()]}
+          | {cert, public_key:der_encoded()}
+          | {certfile, string()}
+          | {ciphers, [ssl:erl_cipher_suite()] | string()}
+          | {client_renegotiation, boolean()}
+          | {crl_cache, {module(), {internal | any(), list()}}}
+          | {crl_check, boolean() | peer | best_effort}
+          | {depth, 0..255}
+          | {dh, public_key:der_encoded()}
+          | {dhfile, string()}
+          | {fail_if_no_peer_cert, boolean()}
+          | {hibernate_after, integer() | undefined}
+          | {honor_cipher_order, boolean()}
+          | {key, {'RSAPrivateKey' | 'DSAPrivateKey' | 'PrivateKeyInfo',
+                public_key:der_encoded()}}
+          | {keyfile, string()}
+          | {log_alert, boolean()}
+          | {next_protocols_advertised, [binary()]}
+          | {padding_check, boolean()}
+          | {partial_chain, fun(([public_key:der_encoded()])
+                -> {trusted_ca, public_key:der_encoded()} | unknown_ca)}
+          | {password, string()}
+          | {psk_identity, string()}
+          | {reuse_session, fun()}
+          | {reuse_sessions, boolean()}
+          | {secure_renegotiate, boolean()}
+          | {signature_algs, [{atom(), atom()}]}
+          | {sni_fun, fun()}
+          | {sni_hosts, [{string(), ssl_opt()}]}
+          | {user_lookup_fun, {fun(), any()}}
+          | {v2_hello_compatible, boolean()}
+          | {verify, ssl:verify_type()}
+          | {verify_fun, {fun(), any()}}
+          | {versions, [atom()]}
    +
    +

    SSL-specific listen options.

    +

    Specifying a certificate is mandatory, either through the cert or certfile option, or by configuring SNI. None of the other options are required.

    +

    The default value is given next to the option name:

    +
    alpn_preferred_protocols
    +

    Perform Application-Layer Protocol Negotiation with the given list of preferred protocols.

    +
    +
    beast_mitigation
    +

    Change the BEAST mitigation strategy for SSL-3.0 and TLS-1.0 to interoperate with legacy software.

    +
    +
    cacertfile
    +

    Path to PEM encoded trusted certificates file used to verify peer certificates.

    +
    +
    cacerts
    +

    List of DER encoded trusted certificates.

    +
    +
    cert
    +

    DER encoded user certificate.

    +
    +
    certfile
    +

    Path to the PEM encoded user certificate file. May also contain the private key.

    +
    +
    ciphers
    +

    List of ciphers that clients are allowed to use.

    +
    +
    client_renegotiation (true)
    +

    Whether to allow client-initiated renegotiation.

    +
    +
    crl_cache ({ssl_crl_cache, {internal, []}})
    +

    Customize the module used to cache Certificate Revocation Lists.

    +
    +
    crl_check (false)
    +

    Whether to perform CRL check on all certificates in the chain during validation.

    +
    +
    depth (1)
    +

    Maximum of intermediate certificates allowed in the certification path.

    +
    +
    dh
    +

    DER encoded Diffie-Hellman parameters.

    +
    +
    dhfile
    +

    Path to the PEM encoded Diffie-Hellman parameters file.

    +
    +
    fail_if_no_peer_cert (false)
    +

    Whether to refuse the connection if the client sends an empty certificate.

    +
    +
    hibernate_after (undefined)
    +

    Time in ms after which SSL socket processes go into hibernation to reduce memory usage.

    +
    +
    honor_cipher_order (false)
    +

    If true, use the server's preference for cipher selection. If false, use the client's preference.

    +
    +
    key
    +

    DER encoded user private key.

    +
    +
    keyfile
    +

    Path to the PEM encoded private key file, if different from the certfile.

    +
    +
    log_alert (true)
    +

    If false, error reports will not be displayed.

    +
    +
    next_protocols_advertised
    +

    List of protocols to send to the client if it supports the Next Protocol extension.

    +
    +
    padding_check
    +

    Allow disabling the block cipher padding check for TLS-1.0 to be able to interoperate with legacy software.

    +
    +
    partial_chain
    +

    Claim an intermediate CA in the chain as trusted.

    +
    +
    password
    +

    Password to the private key file, if password protected.

    +
    +
    psk_identity
    +

    Provide the given PSK identity hint to the client during the handshake.

    +
    +
    reuse_session
    +

    Custom policy to decide whether a session should be reused.

    +
    +
    reuse_sessions (false)
    +

    Whether to allow session reuse.

    +
    +
    secure_renegotiate (false)
    +

    Whether to reject renegotiation attempts that do not conform to RFC5746.

    +
    +
    signature_algs
    +

    The TLS signature algorithm extension may be used, from TLS 1.2, to negotiate which signature algorithm to use during the TLS handshake.

    +
    +
    sni_fun
    +

    Function called when the client requests a host using Server Name Indication. Returns options to apply.

    +
    +
    sni_hosts
    +

    Options to apply for the host that matches what the client requested with Server Name Indication.

    +
    +
    user_lookup_fun
    +

    Function called to determine the shared secret when using PSK, or provide parameters when using SRP.

    +
    +
    v2_hello_compatible
    +

    Accept clients that send hello messages in SSL-2.0 format while offering supported SSL/TLS versions.

    +
    +
    verify (verify_none)
    +

    Use verify_peer to request a certificate from the client.

    +
    +
    verify_fun
    +

    Custom policy to decide whether a client certificate is valid.

    +
    +
    versions
    +

    TLS protocol versions that will be supported.

    +
    +
    +

    Note that the client will not send a certificate unless the value for the verify option is set to verify_peer. This means that fail_if_no_peer_cert only applies when combined with the verify option. The verify_fun option allows greater control over the client certificate validation.

    +

    The options sni_fun and sni_hosts are mutually exclusive.

    +

    See also

    +

    ranch(7), ranch_transport(3), ranch_tcp(3), ssl(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch_tcp/index.html b/docs/en/ranch/1.8/manual/ranch_tcp/index.html new file mode 100644 index 00000000..e23ed610 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch_tcp/index.html @@ -0,0 +1,284 @@ + + + + + + + + + + Nine Nines: ranch_tcp(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch_tcp(3)

    + +

    Name

    +

    ranch_tcp - TCP transport

    +

    Description

    +

    The module ranch_tcp implements a TCP Ranch transport.

    +

    The function sendfile may not work correctly when used against files stored in a VirtualBox shared folder.

    +

    Exports

    +

    The module ranch_tcp implements the interface defined by ranch_transport(3).

    +

    Types

    +

    opt()

    +
    +
    opt() = {backlog, non_neg_integer()}
+      | {buffer, non_neg_integer()}
+      | {delay_send, boolean()}
+      | {dontroute, boolean()}
+      | {exit_on_close, boolean()}
+      | {fd, non_neg_integer()}
+      | {high_msgq_watermark, non_neg_integer()}
+      | {high_watermark, non_neg_integer()}
+      | inet
+      | inet6
+      | {ip, inet:ip_address()}
+      | {ipv6_v6only, boolean()}
+      | {keepalive, boolean()}
+      | {linger, {boolean(), non_neg_integer()}}
+      | {low_msgq_watermark, non_neg_integer()}
+      | {low_watermark, non_neg_integer()}
+      | {nodelay, boolean()}
+      | {port, inet:port_number()}
+      | {priority, integer()}
+      | {raw, non_neg_integer(), non_neg_integer(), binary()}
+      | {recbuf, non_neg_integer()}
+      | {send_timeout, timeout()}
+      | {send_timeout_close, boolean()}
+      | {sndbuf, non_neg_integer()}
+      | {tos, integer()}
    +
    +

    Listen options.

    +

    Note that additional options may be set by the protocol module using Transport:setopts/2.

    +

    None of the options are required.

    +

    Please consult the gen_tcp and inet manuals for a more thorough description of these options. This manual only aims to provide a short description along with what the defaults are. Defaults may be different in Ranch compared to gen_tcp. Defaults are given next to the option name:

    +
    backlog (1024)
    +

    Max length of the queue of pending connections.

    +
    +
    buffer
    +

    Size of the buffer used by the Erlang driver. Default is system-dependent.

    +
    +
    delay_send (false)
    +

    Always queue data before sending, to send fewer, larger packets over the network.

    +
    +
    dontroute (false)
    +

    Don't send via a gateway, only send to directly connected hosts.

    +
    +
    exit_on_close (true)
    +

    Disable to allow sending data after a close has been detected.

    +
    +
    fd
    +

    File descriptor of the socket, if it was opened externally.

    +
    +
    high_msgq_watermark (8192)
    +

    Limit in the amount of data in the socket message queue before the queue becomes busy.

    +
    +
    high_watermark (8192)
    +

    Limit in the amount of data in the ERTS socket implementation's queue before the socket becomes busy.

    +
    +
    inet
    +

    Set up the socket for IPv4.

    +
    +
    inet6
    +

    Set up the socket for IPv6.

    +
    +
    ip
    +

    Interface to listen on. Listen on all interfaces by default.

    +
    +
    ipv6_v6only (false)
    +

    Listen on IPv4 and IPv6 (false) or only on IPv6 (true). Use with inet6.

    +
    +
    keepalive (false)
    +

    Enable sending of keep-alive messages.

    +
    +
    linger ({false, 0})
    +

    Whether to wait and how long to flush data sent before closing the socket.

    +
    +
    low_msgq_watermark (4096)
    +

    Amount of data in the socket message queue before the queue leaves busy state.

    +
    +
    low_watermark (4096)
    +

    Amount of data in the ERTS socket implementation's queue before the socket leaves busy state.

    +
    +
    nodelay (true)
    +

    Whether to enable TCP_NODELAY.

    +
    +
    port (0)
    +

    TCP port number to listen on. 0 means a random port will be used.

    +
    +
    priority (0)
    +

    Priority value for all packets to be sent on this socket.

    +
    +
    recbuf
    +

    Minimum size of the socket's receive buffer. Default is system-dependent.

    +
    +
    send_timeout (30000)
    +

    How long the send call may wait for confirmation before returning.

    +
    +
    send_timeout_close (true)
    +

    Whether to close the socket when the confirmation wasn't received.

    +
    +
    sndbuf
    +

    Minimum size of the socket's send buffer. Default is system-dependent.

    +
    +
    tos
    +

    Value for the IP_TOS IP level option. Use with caution.

    +
    +
    +

    In addition, the raw option can be used to set system-specific options by specifying the protocol level, the option number and the actual option value specified as a binary. This option is not portable. Use with caution.

    +

    opts()

    +
    +
    opts() :: [opt()]
    +
    +

    List of listen options.

    +

    See also

    +

    ranch(7), ranch_transport(3), ranch_ssl(3), gen_tcp(3), inet(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch_transport.sendfile/index.html b/docs/en/ranch/1.8/manual/ranch_transport.sendfile/index.html new file mode 100644 index 00000000..86134512 --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch_transport.sendfile/index.html @@ -0,0 +1,220 @@ + + + + + + + + + + Nine Nines: ranch_transport:sendfile(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch_transport:sendfile(3)

    + +

    Name

    +

    ranch_transport:sendfile - Send a file on the socket

    +

    Description

    +
    +
    sendfile(Transport :: module(),
+         Socket    :: ranch_transport:socket(),
+         File      :: file:name_all() | file:fd(),
+         Offset    :: non_neg_integer(),
+         Bytes     :: non_neg_integer(),
+         Opts      :: ranch_transport:sendfile_opts())
+    -> {ok, SentBytes :: non_neg_integer()} | {error, atom()}
    +
    +

    Send a file on the socket.

    +

    The file may be sent full or in parts, and may be specified by its filename or by an already open file descriptor.

    +

    This function emulates the function file:sendfile/2,4,5 and may be used when transports are not manipulating TCP directly.

    +

    Arguments

    +
    Transport
    +

    The transport module.

    +
    +
    Socket
    +

    The socket.

    +
    +
    File
    +

    The filename or file descriptor for the file to be sent.

    +
    +
    Offset
    +

    Start position in the file, in bytes.

    +
    +
    Bytes
    +

    Length in bytes.

    +
    +
    Opts
    +

    Additional options.

    +
    +
    +

    Return value

    +

    The number of bytes actually sent is returned on success inside an ok tuple.

    +

    An error tuple is returned otherwise.

    +

    Changelog

    +
    • 1.6: The type of the File argument was extended. +
      • +
    +

    Examples

    +
    Implement Transport:sendfile using the fallback
    +
    +
    sendfile(Socket, Filename) ->
+    sendfile(Socket, Filename, 0, 0, []).
+
+sendfile(Socket, File, Offset, Bytes) ->
+    sendfile(Socket, File, Offset, Bytes, []).
+
+sendfile(Socket, File, Offset, Bytes, Opts) ->
+    ranch_transport:sendfile(?MODULE, Socket,
+        File, Offset, Bytes, Opts).
    +
    +

    See also

    +

    ranch_transport(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/1.8/manual/ranch_transport/index.html b/docs/en/ranch/1.8/manual/ranch_transport/index.html new file mode 100644 index 00000000..add1765d --- /dev/null +++ b/docs/en/ranch/1.8/manual/ranch_transport/index.html @@ -0,0 +1,385 @@ + + + + + + + + + + Nine Nines: ranch_transport(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    ranch_transport(3)

    + +

    Name

    +

    ranch_transport - Transport modules

    +

    Description

    +

    The module ranch_transport defines the interface used by Ranch transports.

    +

    Callbacks

    +

    Ranch transports implement the following interface:

    +

    accept

    +
    +
    accept(LSocket :: socket(), Timeout :: timeout())
+    -> {ok, Socket :: socket()}
+     | {error, closed | timeout | atom()}
    +
    +

    Use the listening socket returned by listen/1 to accept a new connection. The timeout is specified in milliseconds.

    +

    close

    +
    +
    close(Socket :: socket()) -> ok
    +
    +

    Close the socket.

    +

    controlling_process

    +
    +
    controlling_process(Socket :: socket(), Pid :: pid())
+    -> ok | {error, closed | not_owner | atom()}
    +
    +

    Assign a new controlling process to the socket. The controlling process is the process that is linked to and receives messages from the socket.

    +

    getopts

    +
    +
    getopts(Socket :: socket(), SockOpts :: [atom()])
+    -> {ok, any()} | {error, atom()}
    +
    +

    Get one or more options for the socket.

    +

    getstat

    +
    +
    getstat(Socket :: socket())
+    -> {ok, SockStatValues :: any()} | {error, atom()}
    +
    +

    Get all statistics for the socket.

    +
    +
    getstat(Socket :: socket(), SockStats :: [atom()])
+    -> {ok, SockStatValues :: any()} | {error, atom()}
    +
    +

    Get one or more statistic options for the socket.

    +

    handshake

    +
    +
    handshake(Socket0  :: socket(),
+          SockOpts :: any(),
+          Timeout  :: timeout())
+    -> {ok, Socket}
    +
    +

    Perform the transport-level handshake.

    +

    This function will be called by connection processes before performing any socket operation. It allows transports that require extra initialization to perform their task and return a socket that is ready to use.

    +

    This function may also be used to upgrade a connection from a transport to another depending on the capabilities of the transports. For example a ranch_tcp socket may be upgraded to a ranch_ssl one using this function.

    +

    listen

    +
    +
    listen(SockOpts :: any())
+    -> {ok, LSocket :: socket()} | {error, atom()}
    +
    +

    Create a socket that listens on the given port.

    +

    The port may not be specified or may be set to 0, which means a random available port number will be chosen.

    +

    messages

    +
    +
    messages()
+    -> {OK     :: atom(),
+        Closed :: atom(),
+        Error  :: atom()}
    +
    +

    Return the tuple keys for the messages sent by the socket.

    +

    name

    +
    +
    name() -> Name :: atom()
    +
    +

    Return the name of the transport.

    +

    peername

    +
    +
    peername(Socket :: socket())
+    -> {ok, {inet:ip_address(), inet:port_number()}}
+     | {error, atom()}.
    +
    +

    Return the address and port number for the other end of the connection.

    +

    recv

    +
    +
    recv(Socket :: socket(),
+     Length :: non_neg_integer(),
+     Timeout :: timeout())
+    -> {ok, Packet :: any()}
+     | {error, closed | timeout | atom()}
    +
    +

    Receive a packet from the socket in passive mode.

    +

    Attempting to receive data from a socket that is in active mode will return an error.

    +

    A length of 0 will return the data available on the socket as soon as possible, regardless of length.

    +

    While it is possible to use the timeout value infinity, it is highly discouraged as it could cause your process to get stuck waiting for data that will never come. This may happen when a socket becomes half-open due to a crash of the remote endpoint. Wi-Fi going down is another common culprit.

    +

    secure

    +
    +
    secure() -> boolean()
    +
    +

    Return whether the transport can be used for secure connections.

    +

    send

    +
    +
    send(Socket :: socket(), Packet :: iodata())
+    -> ok | {error, atom()}
    +
    +

    Send a packet on the socket.

    +

    sendfile

    +
    +
    sendfile(Socket, File)
+    -> sendfile(Socket, File, 0, 0, [])
+
+sendfile(Socket, File, Offset, Bytes)
+    -> sendfile(Socket, File, Offset, Bytes, [])
+
+sendfile(Socket :: socket(),
+         File   :: file:name_all() | file:fd(),
+         Offset :: non_neg_integer(),
+         Bytes  :: non_neg_integer(),
+         Opts   :: sendfile_opts())
+    -> {ok, SentBytes :: non_neg_integer()} | {error, atom()}
    +
    +

    Send a file on the socket.

    +

    The file may be sent full or in parts, and may be specified by its filename or by an already open file descriptor.

    +

    Transports that manipulate TCP directly may use the file:sendfile/2,4,5 function, which calls the sendfile syscall where applicable (on Linux, for example). Other transports can use the sendfile/6 function exported from this module.

    +

    setopts

    +
    +
    setopts(Socket :: socket(), SockOpts :: any())
+    -> ok | {error, atom()}
    +
    +

    Set one or more options for the socket.

    +

    shutdown

    +
    +
    shutdown(Socket :: socket(),
+         How    :: read | write | read_write)
+    -> ok | {error, atom()}
    +
    +

    Close the socket for reading and/or writing.

    +

    sockname

    +
    +
    sockname(Socket :: socket())
+    -> {ok, {inet:ip_address(), inet:port_number()}}
+     | {error, atom()}.
    +
    +

    Return the address and port number for the local end of the connection.

    +

    Exports

    +

    The following function can be used when implementing transport modules:

    + +

    Types

    +

    sendfile_opts()

    +
    +
    sendfile_opts() :: [{chunk_size, non_neg_integer()}]
    +
    +

    Options accepted by the sendfile function and callbacks:

    +
    chunk_size (8191)
    +

    The chunk size, in bytes.

    +
    +
    +

    socket()

    +
    +
    socket() :: any()
    +
    +

    The socket.

    +

    The exact type will vary depending on the transport module.

    +

    Changelog

    +
    • 1.6: The socket() type was added for documentation purposes. +
      • +
    • 1.6: The type of the sendfile filename was extended. +
      • +
    +

    See also

    +

    ranch(7), ranch_tcp(3), ranch_ssl(3)

    + + + + + + +
    + +
    + + +

    + Ranch + 1.8 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +

    Like my work? Donate!

    +

    Donate to Loïc Hoguin because his work on Cowboy, Ranch, Gun and Erlang.mk is fantastic:

    +
    + + + + + + + + + +

    Recurring payment options are also available via GitHub Sponsors. These funds are used to cover the recurring expenses like food, dedicated servers or domain names.

    + + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/ranch/2.0/guide/connection_draining/index.html b/docs/en/ranch/2.0/guide/connection_draining/index.html index 278339db..3c3e2a00 100644 --- a/docs/en/ranch/2.0/guide/connection_draining/index.html +++ b/docs/en/ranch/2.0/guide/connection_draining/index.html @@ -200,14 +200,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/embedded/index.html b/docs/en/ranch/2.0/guide/embedded/index.html index 4f9d9cf1..77e08615 100644 --- a/docs/en/ranch/2.0/guide/embedded/index.html +++ b/docs/en/ranch/2.0/guide/embedded/index.html @@ -141,14 +141,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/index.html b/docs/en/ranch/2.0/guide/index.html index 5d740e7c..2959cb6c 100644 --- a/docs/en/ranch/2.0/guide/index.html +++ b/docs/en/ranch/2.0/guide/index.html @@ -133,14 +133,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/internals/index.html b/docs/en/ranch/2.0/guide/internals/index.html index ca802f1f..e0bb9256 100644 --- a/docs/en/ranch/2.0/guide/internals/index.html +++ b/docs/en/ranch/2.0/guide/internals/index.html @@ -149,14 +149,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/introduction/index.html b/docs/en/ranch/2.0/guide/introduction/index.html index 859cb6dd..b9fa77ca 100644 --- a/docs/en/ranch/2.0/guide/introduction/index.html +++ b/docs/en/ranch/2.0/guide/introduction/index.html @@ -127,14 +127,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/listeners/index.html b/docs/en/ranch/2.0/guide/listeners/index.html index 226bc9d4..1a50fe1c 100644 --- a/docs/en/ranch/2.0/guide/listeners/index.html +++ b/docs/en/ranch/2.0/guide/listeners/index.html @@ -390,14 +390,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/migrating_from_1.5/index.html b/docs/en/ranch/2.0/guide/migrating_from_1.5/index.html index 1cd0d5ef..b86e59d2 100644 --- a/docs/en/ranch/2.0/guide/migrating_from_1.5/index.html +++ b/docs/en/ranch/2.0/guide/migrating_from_1.5/index.html @@ -163,14 +163,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/migrating_from_1.6/index.html b/docs/en/ranch/2.0/guide/migrating_from_1.6/index.html index f5f9cbf8..9d717153 100644 --- a/docs/en/ranch/2.0/guide/migrating_from_1.6/index.html +++ b/docs/en/ranch/2.0/guide/migrating_from_1.6/index.html @@ -143,14 +143,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/migrating_from_1.7/index.html b/docs/en/ranch/2.0/guide/migrating_from_1.7/index.html index 186d66a8..e5514929 100644 --- a/docs/en/ranch/2.0/guide/migrating_from_1.7/index.html +++ b/docs/en/ranch/2.0/guide/migrating_from_1.7/index.html @@ -200,14 +200,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/migrating_from_1.x/index.html b/docs/en/ranch/2.0/guide/migrating_from_1.x/index.html index 2f74fb23..5b3585f3 100644 --- a/docs/en/ranch/2.0/guide/migrating_from_1.x/index.html +++ b/docs/en/ranch/2.0/guide/migrating_from_1.x/index.html @@ -216,14 +216,14 @@
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/parsers/index.html b/docs/en/ranch/2.0/guide/parsers/index.html index b1fed3f6..e4106ea9 100644 --- a/docs/en/ranch/2.0/guide/parsers/index.html +++ b/docs/en/ranch/2.0/guide/parsers/index.html @@ -183,14 +183,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/protocols/index.html b/docs/en/ranch/2.0/guide/protocols/index.html index 2388c2e8..f7e98c58 100644 --- a/docs/en/ranch/2.0/guide/protocols/index.html +++ b/docs/en/ranch/2.0/guide/protocols/index.html @@ -190,14 +190,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/ssl_auth/index.html b/docs/en/ranch/2.0/guide/ssl_auth/index.html index 33bf8d00..5f3a2fa3 100644 --- a/docs/en/ranch/2.0/guide/ssl_auth/index.html +++ b/docs/en/ranch/2.0/guide/ssl_auth/index.html @@ -196,14 +196,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/guide/transports/index.html b/docs/en/ranch/2.0/guide/transports/index.html index 9c209377..5b5ee18e 100644 --- a/docs/en/ranch/2.0/guide/transports/index.html +++ b/docs/en/ranch/2.0/guide/transports/index.html @@ -230,14 +230,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/index.html b/docs/en/ranch/2.0/manual/index.html index cf98781d..261556ba 100644 --- a/docs/en/ranch/2.0/manual/index.html +++ b/docs/en/ranch/2.0/manual/index.html @@ -143,14 +143,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.child_spec/index.html b/docs/en/ranch/2.0/manual/ranch.child_spec/index.html index 6e98f76b..3348e51e 100644 --- a/docs/en/ranch/2.0/manual/ranch.child_spec/index.html +++ b/docs/en/ranch/2.0/manual/ranch.child_spec/index.html @@ -165,14 +165,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.get_addr/index.html b/docs/en/ranch/2.0/manual/ranch.get_addr/index.html index ad1de90d..69771ad5 100644 --- a/docs/en/ranch/2.0/manual/ranch.get_addr/index.html +++ b/docs/en/ranch/2.0/manual/ranch.get_addr/index.html @@ -139,14 +139,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.get_max_connections/index.html b/docs/en/ranch/2.0/manual/ranch.get_max_connections/index.html index 1a0d8d2b..13fc2150 100644 --- a/docs/en/ranch/2.0/manual/ranch.get_max_connections/index.html +++ b/docs/en/ranch/2.0/manual/ranch.get_max_connections/index.html @@ -131,14 +131,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.get_port/index.html b/docs/en/ranch/2.0/manual/ranch.get_port/index.html index 2c60b6cf..eed1a6d4 100644 --- a/docs/en/ranch/2.0/manual/ranch.get_port/index.html +++ b/docs/en/ranch/2.0/manual/ranch.get_port/index.html @@ -129,14 +129,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.get_protocol_options/index.html b/docs/en/ranch/2.0/manual/ranch.get_protocol_options/index.html index 9bce1073..85eece21 100644 --- a/docs/en/ranch/2.0/manual/ranch.get_protocol_options/index.html +++ b/docs/en/ranch/2.0/manual/ranch.get_protocol_options/index.html @@ -127,14 +127,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.get_status/index.html b/docs/en/ranch/2.0/manual/ranch.get_status/index.html index 9f0b40f9..196e9497 100644 --- a/docs/en/ranch/2.0/manual/ranch.get_status/index.html +++ b/docs/en/ranch/2.0/manual/ranch.get_status/index.html @@ -130,14 +130,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.get_transport_options/index.html b/docs/en/ranch/2.0/manual/ranch.get_transport_options/index.html index c0c1f2f2..a308bacd 100644 --- a/docs/en/ranch/2.0/manual/ranch.get_transport_options/index.html +++ b/docs/en/ranch/2.0/manual/ranch.get_transport_options/index.html @@ -127,14 +127,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.handshake/index.html b/docs/en/ranch/2.0/manual/ranch.handshake/index.html index 9331ac89..28b331c3 100644 --- a/docs/en/ranch/2.0/manual/ranch.handshake/index.html +++ b/docs/en/ranch/2.0/manual/ranch.handshake/index.html @@ -153,14 +153,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.handshake_cancel/index.html b/docs/en/ranch/2.0/manual/ranch.handshake_cancel/index.html index b44475d4..12311b26 100644 --- a/docs/en/ranch/2.0/manual/ranch.handshake_cancel/index.html +++ b/docs/en/ranch/2.0/manual/ranch.handshake_cancel/index.html @@ -140,14 +140,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.handshake_continue/index.html b/docs/en/ranch/2.0/manual/ranch.handshake_continue/index.html index 76268ec1..1121940d 100644 --- a/docs/en/ranch/2.0/manual/ranch.handshake_continue/index.html +++ b/docs/en/ranch/2.0/manual/ranch.handshake_continue/index.html @@ -150,14 +150,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.info/index.html b/docs/en/ranch/2.0/manual/ranch.info/index.html index d3bf03dc..266c8d56 100644 --- a/docs/en/ranch/2.0/manual/ranch.info/index.html +++ b/docs/en/ranch/2.0/manual/ranch.info/index.html @@ -176,14 +176,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.procs/index.html b/docs/en/ranch/2.0/manual/ranch.procs/index.html index 48846737..e32bed48 100644 --- a/docs/en/ranch/2.0/manual/ranch.procs/index.html +++ b/docs/en/ranch/2.0/manual/ranch.procs/index.html @@ -138,14 +138,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.recv_proxy_header/index.html b/docs/en/ranch/2.0/manual/ranch.recv_proxy_header/index.html index 93d4157b..8f6119a7 100644 --- a/docs/en/ranch/2.0/manual/ranch.recv_proxy_header/index.html +++ b/docs/en/ranch/2.0/manual/ranch.recv_proxy_header/index.html @@ -148,14 +148,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.remove_connection/index.html b/docs/en/ranch/2.0/manual/ranch.remove_connection/index.html index 63fa99c6..332c443b 100644 --- a/docs/en/ranch/2.0/manual/ranch.remove_connection/index.html +++ b/docs/en/ranch/2.0/manual/ranch.remove_connection/index.html @@ -128,14 +128,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.resume_listener/index.html b/docs/en/ranch/2.0/manual/ranch.resume_listener/index.html index 2e7df507..4df6a268 100644 --- a/docs/en/ranch/2.0/manual/ranch.resume_listener/index.html +++ b/docs/en/ranch/2.0/manual/ranch.resume_listener/index.html @@ -134,14 +134,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.set_max_connections/index.html b/docs/en/ranch/2.0/manual/ranch.set_max_connections/index.html index 93d47ce1..9c72ff6c 100644 --- a/docs/en/ranch/2.0/manual/ranch.set_max_connections/index.html +++ b/docs/en/ranch/2.0/manual/ranch.set_max_connections/index.html @@ -136,14 +136,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.set_protocol_options/index.html b/docs/en/ranch/2.0/manual/ranch.set_protocol_options/index.html index 4833d2bd..a917c3ae 100644 --- a/docs/en/ranch/2.0/manual/ranch.set_protocol_options/index.html +++ b/docs/en/ranch/2.0/manual/ranch.set_protocol_options/index.html @@ -132,14 +132,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.set_transport_options/index.html b/docs/en/ranch/2.0/manual/ranch.set_transport_options/index.html index 3c63f6dd..1166b6f9 100644 --- a/docs/en/ranch/2.0/manual/ranch.set_transport_options/index.html +++ b/docs/en/ranch/2.0/manual/ranch.set_transport_options/index.html @@ -171,14 +171,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.start_listener/index.html b/docs/en/ranch/2.0/manual/ranch.start_listener/index.html index b281d4b1..a090c37c 100644 --- a/docs/en/ranch/2.0/manual/ranch.start_listener/index.html +++ b/docs/en/ranch/2.0/manual/ranch.start_listener/index.html @@ -188,14 +188,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.stop_listener/index.html b/docs/en/ranch/2.0/manual/ranch.stop_listener/index.html index d3bc6e90..00473f25 100644 --- a/docs/en/ranch/2.0/manual/ranch.stop_listener/index.html +++ b/docs/en/ranch/2.0/manual/ranch.stop_listener/index.html @@ -131,14 +131,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.suspend_listener/index.html b/docs/en/ranch/2.0/manual/ranch.suspend_listener/index.html index d40b1422..99c935ce 100644 --- a/docs/en/ranch/2.0/manual/ranch.suspend_listener/index.html +++ b/docs/en/ranch/2.0/manual/ranch.suspend_listener/index.html @@ -135,14 +135,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch.wait_for_connections/index.html b/docs/en/ranch/2.0/manual/ranch.wait_for_connections/index.html index aad64e33..066c069e 100644 --- a/docs/en/ranch/2.0/manual/ranch.wait_for_connections/index.html +++ b/docs/en/ranch/2.0/manual/ranch.wait_for_connections/index.html @@ -155,14 +155,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch/index.html b/docs/en/ranch/2.0/manual/ranch/index.html index b9f6eb9e..a1a968bb 100644 --- a/docs/en/ranch/2.0/manual/ranch/index.html +++ b/docs/en/ranch/2.0/manual/ranch/index.html @@ -251,14 +251,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch_app/index.html b/docs/en/ranch/2.0/manual/ranch_app/index.html index cb790282..5c3f9685 100644 --- a/docs/en/ranch/2.0/manual/ranch_app/index.html +++ b/docs/en/ranch/2.0/manual/ranch_app/index.html @@ -143,14 +143,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch_protocol/index.html b/docs/en/ranch/2.0/manual/ranch_protocol/index.html index f9049b65..b166cad2 100644 --- a/docs/en/ranch/2.0/manual/ranch_protocol/index.html +++ b/docs/en/ranch/2.0/manual/ranch_protocol/index.html @@ -128,14 +128,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch_proxy_header.header/index.html b/docs/en/ranch/2.0/manual/ranch_proxy_header.header/index.html index ee58dcbc..e9d7ead3 100644 --- a/docs/en/ranch/2.0/manual/ranch_proxy_header.header/index.html +++ b/docs/en/ranch/2.0/manual/ranch_proxy_header.header/index.html @@ -162,14 +162,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch_proxy_header.parse/index.html b/docs/en/ranch/2.0/manual/ranch_proxy_header.parse/index.html index 64561ede..431c6bf1 100644 --- a/docs/en/ranch/2.0/manual/ranch_proxy_header.parse/index.html +++ b/docs/en/ranch/2.0/manual/ranch_proxy_header.parse/index.html @@ -133,14 +133,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch_proxy_header/index.html b/docs/en/ranch/2.0/manual/ranch_proxy_header/index.html index 1a2eeec3..cbb3303e 100644 --- a/docs/en/ranch/2.0/manual/ranch_proxy_header/index.html +++ b/docs/en/ranch/2.0/manual/ranch_proxy_header/index.html @@ -216,14 +216,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch_ssl/index.html b/docs/en/ranch/2.0/manual/ranch_ssl/index.html index d81ccf6d..34757b18 100644 --- a/docs/en/ranch/2.0/manual/ranch_ssl/index.html +++ b/docs/en/ranch/2.0/manual/ranch_ssl/index.html @@ -326,14 +326,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch_tcp/index.html b/docs/en/ranch/2.0/manual/ranch_tcp/index.html index 91f27b50..5d685585 100644 --- a/docs/en/ranch/2.0/manual/ranch_tcp/index.html +++ b/docs/en/ranch/2.0/manual/ranch_tcp/index.html @@ -228,14 +228,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch_transport.sendfile/index.html b/docs/en/ranch/2.0/manual/ranch_transport.sendfile/index.html index e9880038..f27c3d2c 100644 --- a/docs/en/ranch/2.0/manual/ranch_transport.sendfile/index.html +++ b/docs/en/ranch/2.0/manual/ranch_transport.sendfile/index.html @@ -162,14 +162,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/en/ranch/2.0/manual/ranch_transport/index.html b/docs/en/ranch/2.0/manual/ranch_transport/index.html index 04743904..0edb4039 100644 --- a/docs/en/ranch/2.0/manual/ranch_transport/index.html +++ b/docs/en/ranch/2.0/manual/ranch_transport/index.html @@ -369,14 +369,14 @@ http://www.gnu.org/software/src-highlite -->
  • 2.0
    • +
  • 1.8
    • +
  • 1.7
  • 1.6
  • 1.5
    • -
  • 1.4
    • -

    Like my work? Donate!

    diff --git a/docs/index.html b/docs/index.html index 2c94fd1d..dbaf9dce 100644 --- a/docs/index.html +++ b/docs/index.html @@ -69,6 +69,13 @@ @@ -120,6 +120,11 @@ +
  • Cowlib 2.11 Function Reference
    • + + + +
  • Cowlib 2.10 Function Reference
    • @@ -198,6 +203,13 @@ +
  • Ranch 1.8 User Guide
    • + + +
  • Ranch 1.8 Function Reference
    • + + +
  • Ranch 1.7 User Guide
    • @@ -218,13 +230,6 @@
  • Ranch 1.5 Function Reference
    • - -
  • Ranch 1.4 User Guide
    • - - -
  • Ranch 1.4 Function Reference
    • - - diff --git a/docs/index.xml b/docs/index.xml index 60dc3cb7..a728cc0f 100644 --- a/docs/index.xml +++ b/docs/index.xml @@ -87,10 +87,10 @@ Copyright (c) 2013-2020, Loïc Hoguin &lt;essen@ninenines.eu&gt; Permiss Introduction - https://ninenines.eu/docs/en/ranch/1.4/guide/introduction/ + https://ninenines.eu/docs/en/ranch/1.5/guide/introduction/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/guide/introduction/ + https://ninenines.eu/docs/en/ranch/1.5/guide/introduction/ Ranch is a socket acceptor pool for TCP protocols. Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own. Prerequisites It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols. @@ -99,10 +99,10 @@ Supported platforms Ranch is tested and supported on Linux, FreeBSD, OSX and Win Introduction - https://ninenines.eu/docs/en/ranch/1.5/guide/introduction/ + https://ninenines.eu/docs/en/ranch/1.6/guide/introduction/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.5/guide/introduction/ + https://ninenines.eu/docs/en/ranch/1.6/guide/introduction/ Ranch is a socket acceptor pool for TCP protocols. Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own. Prerequisites It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols. @@ -111,10 +111,10 @@ Supported platforms Ranch is tested and supported on Linux, FreeBSD, OSX and Win Introduction - https://ninenines.eu/docs/en/ranch/1.6/guide/introduction/ + https://ninenines.eu/docs/en/ranch/1.7/guide/introduction/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.6/guide/introduction/ + https://ninenines.eu/docs/en/ranch/1.7/guide/introduction/ Ranch is a socket acceptor pool for TCP protocols. Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own. Prerequisites It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols. @@ -123,10 +123,10 @@ Supported platforms Ranch is tested and supported on Linux, FreeBSD, OSX and Win Introduction - https://ninenines.eu/docs/en/ranch/1.7/guide/introduction/ + https://ninenines.eu/docs/en/ranch/1.8/guide/introduction/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.7/guide/introduction/ + https://ninenines.eu/docs/en/ranch/1.8/guide/introduction/ Ranch is a socket acceptor pool for TCP protocols. Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own. Prerequisites It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols. @@ -145,17 +145,6 @@ Prerequisites It is assumed the developer already knows Erlang and has some expe Supported platforms Ranch is tested and supported on Linux, FreeBSD, macOS and Windows. - - The modern Web - https://ninenines.eu/docs/en/cowboy/2.3/guide/modern_web/ - Mon, 01 Jan 0001 00:00:00 +0000 - - https://ninenines.eu/docs/en/cowboy/2.3/guide/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. - - The modern Web https://ninenines.eu/docs/en/cowboy/2.4/guide/modern_web/ @@ -212,13 +201,14 @@ HTTP/2 HTTP/2 is the most efficient protocol for consuming Web services. It enab - Erlang and the Web - https://ninenines.eu/docs/en/cowboy/2.3/guide/erlang_web/ + The modern Web + https://ninenines.eu/docs/en/cowboy/2.9/guide/modern_web/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/erlang_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. + https://ninenines.eu/docs/en/cowboy/2.9/guide/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. @@ -272,13 +262,13 @@ The Web is concurrent When you access a website there is little concurrency invo - Listeners - https://ninenines.eu/docs/en/ranch/1.4/guide/listeners/ + Erlang and the Web + https://ninenines.eu/docs/en/cowboy/2.9/guide/erlang_web/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/guide/listeners/ - A listener is a set of processes whose role is to listen on a port for new connections. It manages a pool of acceptor processes, each of them indefinitely accepting connections. When it does, it starts a new process executing the protocol handler code. All the socket programming is abstracted through the use of transport handlers. -The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application. + https://ninenines.eu/docs/en/cowboy/2.9/guide/erlang_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. @@ -311,6 +301,16 @@ The listener takes care of supervising all the acceptor and connection processes The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application. + + Listeners + https://ninenines.eu/docs/en/ranch/1.8/guide/listeners/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/guide/listeners/ + A listener is a set of processes whose role is to listen on a port for new connections. It manages a pool of acceptor processes, each of them indefinitely accepting connections. When it does, it starts a new process executing the protocol handler code. All the socket programming is abstracted through the use of transport handlers. +The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application. + + Listeners https://ninenines.eu/docs/en/ranch/2.0/guide/listeners/ @@ -441,18 +441,6 @@ Gun provides convenience functions for performing GET, HEAD, OPTIONS, POST, PATC Gun will send a gun_inform message for every intermediate informational responses received. - - Introduction - https://ninenines.eu/docs/en/cowboy/2.3/guide/introduction/ - Mon, 01 Jan 0001 00:00:00 +0000 - - https://ninenines.eu/docs/en/cowboy/2.3/guide/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. - - Introduction https://ninenines.eu/docs/en/cowboy/2.4/guide/introduction/ @@ -514,16 +502,15 @@ Cowboy is a high quality project. It has a small code base, is very efficient (b - Transports - https://ninenines.eu/docs/en/ranch/1.4/guide/transports/ + Introduction + https://ninenines.eu/docs/en/cowboy/2.9/guide/introduction/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/guide/transports/ - A transport defines the interface to interact with a socket. -Transports can be used for connecting, listening and accepting connections, but also for receiving and sending data. Both passive and active mode are supported, although all sockets are initialized as passive. -TCP transport The TCP transport is a thin wrapper around gen_tcp. -SSL transport The SSL transport is a thin wrapper around ssl. -Ranch depends on ssl by default so any necessary dependencies will start when Ranch is started. + https://ninenines.eu/docs/en/cowboy/2.9/guide/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. @@ -565,6 +552,19 @@ SSL transport The SSL transport is a thin wrapper around ssl. Ranch depends on ssl by default so any necessary dependencies will start when Ranch is started. + + Transports + https://ninenines.eu/docs/en/ranch/1.8/guide/transports/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/guide/transports/ + A transport defines the interface to interact with a socket. +Transports can be used for connecting, listening and accepting connections, but also for receiving and sending data. Both passive and active mode are supported, although all sockets are initialized as passive. +TCP transport The TCP transport is a thin wrapper around gen_tcp. +SSL transport The SSL transport is a thin wrapper around ssl. +Ranch depends on ssl by default so any necessary dependencies will start when Ranch is started. + + Transports https://ninenines.eu/docs/en/ranch/2.0/guide/transports/ @@ -633,16 +633,6 @@ Gun connections Gun is designed with the HTTP/2 and Websocket protocols in mind. A Gun connection is an Erlang process that manages a socket to a remote endpoint. - - Protocols - https://ninenines.eu/docs/en/ranch/1.4/guide/protocols/ - Mon, 01 Jan 0001 00:00:00 +0000 - - https://ninenines.eu/docs/en/ranch/1.4/guide/protocols/ - A protocol handler starts a connection process and defines the protocol logic executed in this process. -Writing a protocol handler All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/4. This callback is responsible for spawning a new process for handling the connection. It receives four arguments: the name of the listener, the socket, the transport handler being used and the protocol options defined in the call to ranch:start_listener/5. - - Protocols https://ninenines.eu/docs/en/ranch/1.5/guide/protocols/ @@ -675,22 +665,22 @@ Writing a protocol handler All protocol handlers must implement the ranch_protoc Protocols - https://ninenines.eu/docs/en/ranch/2.0/guide/protocols/ + https://ninenines.eu/docs/en/ranch/1.8/guide/protocols/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/2.0/guide/protocols/ + https://ninenines.eu/docs/en/ranch/1.8/guide/protocols/ A protocol handler starts a connection process and defines the protocol logic executed in this process. -Writing a protocol handler All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/3. This callback is responsible for spawning a new process for handling the connection. It receives three arguments: the name of the listener, the transport handler being used and the protocol options defined in the call to ranch:start_listener/5. +Writing a protocol handler All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/4. This callback is responsible for spawning a new process for handling the connection. It receives four arguments: the name of the listener, the socket, the transport handler being used and the protocol options defined in the call to ranch:start_listener/5. - Getting started - https://ninenines.eu/docs/en/cowboy/2.3/guide/getting_started/ + Protocols + https://ninenines.eu/docs/en/ranch/2.0/guide/protocols/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/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. + https://ninenines.eu/docs/en/ranch/2.0/guide/protocols/ + A protocol handler starts a connection process and defines the protocol logic executed in this process. +Writing a protocol handler All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/3. This callback is responsible for spawning a new process for handling the connection. It receives three arguments: the name of the listener, the transport handler being used and the protocol options defined in the call to ranch:start_listener/5. @@ -743,6 +733,16 @@ This chapter walks you through all the steps of setting up Cowboy, writing your This chapter walks you through all the steps of setting up Cowboy, writing your first application and generating your first release. + + Getting started + https://ninenines.eu/docs/en/cowboy/2.9/guide/getting_started/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/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. + + HTTP https://ninenines.eu/docs/en/gun/1.0/guide/http/ @@ -803,16 +803,6 @@ Stream references use the Erlang reference data type and are therefore unique. Streams can be canceled at any time. - - Embedded mode - https://ninenines.eu/docs/en/ranch/1.4/guide/embedded/ - Mon, 01 Jan 0001 00:00:00 +0000 - - https://ninenines.eu/docs/en/ranch/1.4/guide/embedded/ - Embedded mode allows you to insert Ranch listeners directly in your supervision tree. This allows for greater fault tolerance control by permitting the shutdown of a listener due to the failure of another part of the application and vice versa. -Embedding To embed Ranch in your application you can simply add the child specs to your supervision tree. This can all be done in the init/1 function of one of your application supervisors. - - Embedded mode https://ninenines.eu/docs/en/ranch/1.5/guide/embedded/ @@ -845,24 +835,22 @@ Embedding To embed Ranch in your application you can simply add the child specs Embedded mode - https://ninenines.eu/docs/en/ranch/2.0/guide/embedded/ + https://ninenines.eu/docs/en/ranch/1.8/guide/embedded/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/2.0/guide/embedded/ + https://ninenines.eu/docs/en/ranch/1.8/guide/embedded/ Embedded mode allows you to insert Ranch listeners directly in your supervision tree. This allows for greater fault tolerance control by permitting the shutdown of a listener due to the failure of another part of the application and vice versa. -However, just as for non-embedded listeners that were started via ranch:start_listener/5, it is required that the ranch application is running before you can start embedded listeners. Furthermore, this also means that embedded listeners will restart when ranch_sup fails. +Embedding To embed Ranch in your application you can simply add the child specs to your supervision tree. This can all be done in the init/1 function of one of your application supervisors. - Flow diagram - https://ninenines.eu/docs/en/cowboy/2.3/guide/flow_diagram/ + Embedded mode + https://ninenines.eu/docs/en/ranch/2.0/guide/embedded/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/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 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. + https://ninenines.eu/docs/en/ranch/2.0/guide/embedded/ + Embedded mode allows you to insert Ranch listeners directly in your supervision tree. This allows for greater fault tolerance control by permitting the shutdown of a listener due to the failure of another part of the application and vice versa. +However, just as for non-embedded listeners that were started via ranch:start_listener/5, it is required that the ranch application is running before you can start embedded listeners. Furthermore, this also means that embedded listeners will restart when ranch_sup fails. @@ -925,6 +913,18 @@ Overview As you can see on the diagram, the client begins by connecting to the s After Ranch accepts a new connection, whether it is an HTTP/1. + + Flow diagram + https://ninenines.eu/docs/en/cowboy/2.9/guide/flow_diagram/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/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 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. + + Websocket https://ninenines.eu/docs/en/gun/1.0/guide/websocket/ @@ -982,10 +982,10 @@ You must use the gun:ws_upgrade/2,3,4 function to upgrade to Websocket. Writing parsers - https://ninenines.eu/docs/en/ranch/1.4/guide/parsers/ + https://ninenines.eu/docs/en/ranch/1.5/guide/parsers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/guide/parsers/ + https://ninenines.eu/docs/en/ranch/1.5/guide/parsers/ There are three kinds of protocols: Text protocols Schema-less binary protocols Schema-based binary protocols This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators. This chapter isn&apos;t specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn&apos;t been parsed is saved in a buffer. @@ -993,10 +993,10 @@ This chapter isn&apos;t specifically about Ranch, we assume here that you kn Writing parsers - https://ninenines.eu/docs/en/ranch/1.5/guide/parsers/ + https://ninenines.eu/docs/en/ranch/1.6/guide/parsers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.5/guide/parsers/ + https://ninenines.eu/docs/en/ranch/1.6/guide/parsers/ There are three kinds of protocols: Text protocols Schema-less binary protocols Schema-based binary protocols This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators. This chapter isn&apos;t specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn&apos;t been parsed is saved in a buffer. @@ -1004,10 +1004,10 @@ This chapter isn&apos;t specifically about Ranch, we assume here that you kn Writing parsers - https://ninenines.eu/docs/en/ranch/1.6/guide/parsers/ + https://ninenines.eu/docs/en/ranch/1.7/guide/parsers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.6/guide/parsers/ + https://ninenines.eu/docs/en/ranch/1.7/guide/parsers/ There are three kinds of protocols: Text protocols Schema-less binary protocols Schema-based binary protocols This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators. This chapter isn&apos;t specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn&apos;t been parsed is saved in a buffer. @@ -1015,10 +1015,10 @@ This chapter isn&apos;t specifically about Ranch, we assume here that you kn Writing parsers - https://ninenines.eu/docs/en/ranch/1.7/guide/parsers/ + https://ninenines.eu/docs/en/ranch/1.8/guide/parsers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.7/guide/parsers/ + https://ninenines.eu/docs/en/ranch/1.8/guide/parsers/ There are three kinds of protocols: Text protocols Schema-less binary protocols Schema-based binary protocols This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators. This chapter isn&apos;t specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn&apos;t been parsed is saved in a buffer. @@ -1076,17 +1076,6 @@ Features added Update Cowlib to 2.5.1 Bugs fixed A bug in the experimental gun Features added CONNECT requests can now be issued on HTTP/1.1 connections. The tunneled connection can use any of the protocols Gun supports: HTTP/1.1, HTTP/2 and Websocket over both TCP and TLS transports. Note that Gun currently does not support tunneling a TLS connection over a TLS connection due to limitations in Erlang/OTP. Gun supports sending multiple CONNECT requests, allowing the tunnel to the origin server to go through multiple proxies. - - Listeners - https://ninenines.eu/docs/en/cowboy/2.3/guide/listeners/ - Mon, 01 Jan 0001 00:00:00 +0000 - - https://ninenines.eu/docs/en/cowboy/2.3/guide/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. - - Listeners https://ninenines.eu/docs/en/cowboy/2.4/guide/listeners/ @@ -1143,13 +1132,14 @@ Cowboy provides two types of listeners: one listening for clear TCP connections, - SSL client authentication - https://ninenines.eu/docs/en/ranch/1.4/guide/ssl_auth/ + Listeners + https://ninenines.eu/docs/en/cowboy/2.9/guide/listeners/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/guide/ssl_auth/ - Purpose SSL client authentication is a mechanism allowing applications to identify certificates. This allows your application to make sure that the client is an authorized certificate, but makes no claim about whether the user can be trusted. This can be combined with a password based authentication to attain greater security. -The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate. + https://ninenines.eu/docs/en/cowboy/2.9/guide/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. @@ -1184,24 +1174,22 @@ The server only needs to retain the certificate serial number and the certificat SSL client authentication - https://ninenines.eu/docs/en/ranch/2.0/guide/ssl_auth/ + https://ninenines.eu/docs/en/ranch/1.8/guide/ssl_auth/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/2.0/guide/ssl_auth/ + https://ninenines.eu/docs/en/ranch/1.8/guide/ssl_auth/ Purpose SSL client authentication is a mechanism allowing applications to identify certificates. This allows your application to make sure that the client is an authorized certificate, but makes no claim about whether the user can be trusted. This can be combined with a password based authentication to attain greater security. The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate. - Routing - https://ninenines.eu/docs/en/cowboy/2.3/guide/routing/ + SSL client authentication + https://ninenines.eu/docs/en/ranch/2.0/guide/ssl_auth/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/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&apos;s a match, the route&apos;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. + https://ninenines.eu/docs/en/ranch/2.0/guide/ssl_auth/ + Purpose SSL client authentication is a mechanism allowing applications to identify certificates. This allows your application to make sure that the client is an authorized certificate, but makes no claim about whether the user can be trusted. This can be combined with a password based authentication to attain greater security. +The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate. @@ -1264,6 +1252,18 @@ Cowboy routes requests using the following algorithm: If no configured host matches the request URI, a 400 response is returned. Otherwise, the first configured host that matches the request URI will be used. Only the paths configured for this host will be considered. If none of the configured paths found in the previous step match the request URI, a 404 response is returned. + + Routing + https://ninenines.eu/docs/en/cowboy/2.9/guide/routing/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/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. +Cowboy routes requests using the following algorithm: +If no configured host matches the request URI, a 400 response is returned. Otherwise, the first configured host that matches the request URI will be used. Only the paths configured for this host will be considered. If none of the configured paths found in the previous step match the request URI, a 404 response is returned. + + Connection draining https://ninenines.eu/docs/en/ranch/2.0/guide/connection_draining/ @@ -1276,40 +1276,40 @@ For this purpose, you should first suspend the listener you wish to stop gracefu Internals - https://ninenines.eu/docs/en/ranch/1.4/guide/internals/ + https://ninenines.eu/docs/en/ranch/1.5/guide/internals/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/guide/internals/ + https://ninenines.eu/docs/en/ranch/1.5/guide/internals/ This chapter may not apply to embedded Ranch as embedding allows you to use an architecture specific to your application, which may or may not be compatible with the description of the Ranch application. Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system. Internals - https://ninenines.eu/docs/en/ranch/1.5/guide/internals/ + https://ninenines.eu/docs/en/ranch/1.6/guide/internals/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.5/guide/internals/ + https://ninenines.eu/docs/en/ranch/1.6/guide/internals/ This chapter may not apply to embedded Ranch as embedding allows you to use an architecture specific to your application, which may or may not be compatible with the description of the Ranch application. Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system. Internals - https://ninenines.eu/docs/en/ranch/1.6/guide/internals/ + https://ninenines.eu/docs/en/ranch/1.7/guide/internals/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.6/guide/internals/ + https://ninenines.eu/docs/en/ranch/1.7/guide/internals/ This chapter may not apply to embedded Ranch as embedding allows you to use an architecture specific to your application, which may or may not be compatible with the description of the Ranch application. Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system. Internals - https://ninenines.eu/docs/en/ranch/1.7/guide/internals/ + https://ninenines.eu/docs/en/ranch/1.8/guide/internals/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.7/guide/internals/ + https://ninenines.eu/docs/en/ranch/1.8/guide/internals/ This chapter may not apply to embedded Ranch as embedding allows you to use an architecture specific to your application, which may or may not be compatible with the description of the Ranch application. Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system. @@ -1344,18 +1344,6 @@ Features added The protocols CONNECT destination option has been added as a repl Gun 2.0 adds many more features such as Websocket over HTTP/2, a built-in cookie store, graceful shutdown, flow control for data messages, event handlers and more. - - Constraints - https://ninenines.eu/docs/en/cowboy/2.3/guide/constraints/ - Mon, 01 Jan 0001 00:00:00 +0000 - - https://ninenines.eu/docs/en/cowboy/2.3/guide/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}. - - Constraints https://ninenines.eu/docs/en/cowboy/2.4/guide/constraints/ @@ -1416,6 +1404,18 @@ Syntax Constraints are provided as a list of fields. For each field in the list, 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}. + + Constraints + https://ninenines.eu/docs/en/cowboy/2.9/guide/constraints/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/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}. + + Upcoming changes in Ranch 2.0 https://ninenines.eu/docs/en/ranch/1.6/guide/upcoming_2.0_changes/ @@ -1436,6 +1436,16 @@ The function ranch:start_listener/6 has been deprecated in favor of ranch:start_ The function ranch:start_listener/6 has been deprecated in favor of ranch:start_listener/5. The number of acceptors was removed and will be taken from the transport options. The function ranch:child_spec/6 has also been deprecated, in favor of ranch:child_spec/5. The function ranch:accept_ack/1 has been deprecated in favor of ranch:handshake/1,2. The function ranch:info/1,2 will return a map containing each listener&apos;s information rather than a list of key/values. + + Upcoming changes in Ranch 2.0 + https://ninenines.eu/docs/en/ranch/1.8/guide/upcoming_2.0_changes/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/guide/upcoming_2.0_changes/ + The following changes will be done in Ranch 2.0. In most cases an alternative is already available in the most recent Ranch version. +The function ranch:start_listener/6 has been deprecated in favor of ranch:start_listener/5. The number of acceptors was removed and will be taken from the transport options. The function ranch:child_spec/6 has also been deprecated, in favor of ranch:child_spec/5. The function ranch:accept_ack/1 has been deprecated in favor of ranch:handshake/1,2. The function ranch:info/1,2 will return a map containing each listener&apos;s information rather than a list of key/values. + + Internals https://ninenines.eu/docs/en/ranch/2.0/guide/internals/ @@ -1458,10 +1468,10 @@ Features added CONNECT requests can now be issued on HTTP/1.1 connections. The t Handlers - https://ninenines.eu/docs/en/cowboy/2.3/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.4/guide/handlers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.4/guide/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. @@ -1471,10 +1481,10 @@ init(Req, State) -&gt; {ok, Req, State}. Despite sending no reply, a 204 No Handlers - https://ninenines.eu/docs/en/cowboy/2.4/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.5/guide/handlers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.4/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.5/guide/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. @@ -1484,10 +1494,10 @@ init(Req, State) -&gt; {ok, Req, State}. Despite sending no reply, a 204 No Handlers - https://ninenines.eu/docs/en/cowboy/2.5/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.6/guide/handlers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.5/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.6/guide/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. @@ -1497,10 +1507,10 @@ init(Req, State) -&gt; {ok, Req, State}. Despite sending no reply, a 204 No Handlers - https://ninenines.eu/docs/en/cowboy/2.6/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.7/guide/handlers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.6/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.7/guide/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. @@ -1510,10 +1520,10 @@ init(Req, State) -&gt; {ok, Req, State}. Despite sending no reply, a 204 No Handlers - https://ninenines.eu/docs/en/cowboy/2.7/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.8/guide/handlers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.7/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.8/guide/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. @@ -1523,10 +1533,10 @@ init(Req, State) -&gt; {ok, Req, State}. Despite sending no reply, a 204 No Handlers - https://ninenines.eu/docs/en/cowboy/2.8/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.9/guide/handlers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.8/guide/handlers/ + https://ninenines.eu/docs/en/cowboy/2.9/guide/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. @@ -1577,13 +1587,14 @@ Because the plain crc32 checksum is not supported by the PROXY protocol, the con - Loop handlers - https://ninenines.eu/docs/en/cowboy/2.3/guide/loop_handlers/ + Migrating from Ranch 1.7 to 1.8 + https://ninenines.eu/docs/en/ranch/1.8/guide/migrating_from_1.7/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/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. + https://ninenines.eu/docs/en/ranch/1.8/guide/migrating_from_1.7/ + Ranch 1.8 is a compatibility update for Erlang/OTP 24. +Ranch 1.8 is compatible with Erlang/OTP 21.0 onward. Support for Erlang/OTP 19 and 20 has been removed. +Bugs fixed An issue with the PROXY protocol was fixed in Ranch 1.7.1. The wrong CRC32 algorithm was used and would cause checksum verification to fail when used. The configuration value when building PROXY headers has been changed to crc32c to reflect the correct algorithm. @@ -1636,6 +1647,16 @@ Loop handlers are used for requests where a response might not be immediately av 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 + https://ninenines.eu/docs/en/cowboy/2.9/guide/loop_handlers/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/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. + + Migrating from Gun 1.0 to 1.1 https://ninenines.eu/docs/en/gun/1.3/guide/migrating_from_1.0/ @@ -1658,18 +1679,7 @@ Features added CONNECT requests can now be issued on HTTP/1.1 connections. The t Static files - https://ninenines.eu/docs/en/cowboy/2.3/guide/static_files/ - Mon, 01 Jan 0001 00:00:00 +0000 - - https://ninenines.eu/docs/en/cowboy/2.3/guide/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. - - - - Static files - https://ninenines.eu/docs/en/cowboy/2.4/guide/static_files/ + https://ninenines.eu/docs/en/cowboy/2.4/guide/static_files/ Mon, 01 Jan 0001 00:00:00 +0000 https://ninenines.eu/docs/en/cowboy/2.4/guide/static_files/ @@ -1722,6 +1732,17 @@ For systems in production, consider using one of the many Content Distribution N The static handler can serve either one file or all files from a given directory. The etag generation and mime types can be configured. + + Static files + https://ninenines.eu/docs/en/cowboy/2.9/guide/static_files/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/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. + + Migrating from Ranch 1.6 to 1.7 https://ninenines.eu/docs/en/ranch/2.0/guide/migrating_from_1.6/ @@ -1756,24 +1777,24 @@ While a third-party library already existed, it was not entirely compatible with - Migrating from Gun 1.0 to 1.1 - https://ninenines.eu/docs/en/gun/2.0/guide/migrating_from_1.0/ + Migrating from Ranch 1.6 to 1.7 + https://ninenines.eu/docs/en/ranch/1.8/guide/migrating_from_1.6/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/gun/2.0/guide/migrating_from_1.0/ - Gun 1.1 updates the Cowlib dependency to 2.5.1 and fixes a few problems with experimental features. -Features added Update Cowlib to 2.5.1 Bugs fixed A bug in the experimental gun_sse_h where lone id lines were not propagated has been fixed by updating the Cowlib dependency. The status code was incorrectly given to the experimental content handlers as a binary. It has been fixed an an integer is now given as was intended. + https://ninenines.eu/docs/en/ranch/1.8/guide/migrating_from_1.6/ + Ranch 1.7 adds built-in support for the PROXY protocol. +The PROXY protocol is a simple and efficient way for proxies to transmit information about the client. +While a third-party library already existed, it was not entirely compatible with the Ranch interface, in particular when socket active mode was involved. This new implementation fixes that and supports the full protocol with as little overhead as possible compared to normal operations: just one extra function call. - The Req object - https://ninenines.eu/docs/en/cowboy/2.3/guide/req/ + Migrating from Gun 1.0 to 1.1 + https://ninenines.eu/docs/en/gun/2.0/guide/migrating_from_1.0/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/req/ - 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. + https://ninenines.eu/docs/en/gun/2.0/guide/migrating_from_1.0/ + Gun 1.1 updates the Cowlib dependency to 2.5.1 and fixes a few problems with experimental features. +Features added Update Cowlib to 2.5.1 Bugs fixed A bug in the experimental gun_sse_h where lone id lines were not propagated has been fixed by updating the Cowlib dependency. The status code was incorrectly given to the experimental content handlers as a binary. It has been fixed an an integer is now given as was intended. @@ -1831,6 +1852,17 @@ It is not really an object in the object-oriented sense. It is a simple map that 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. + + The Req object + https://ninenines.eu/docs/en/cowboy/2.9/guide/req/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/req/ + 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. + + Migrating from Ranch 1.5 to 1.6 https://ninenines.eu/docs/en/ranch/2.0/guide/migrating_from_1.5/ @@ -1854,25 +1886,24 @@ Features added Listeners can now be suspended/resumed without stopping existing - Migrating from Ranch 1.x - https://ninenines.eu/docs/en/ranch/1.6/guide/migrating_from_1.x/ + Migrating from Ranch 1.5 to 1.6 + https://ninenines.eu/docs/en/ranch/1.8/guide/migrating_from_1.5/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.6/guide/migrating_from_1.x/ - The changelog for Ranch releases before 1.6 can be found in this section. -1.5.0 Add transport functions getopts/2, getstat/1 and getstat/2 Fix ranch:info/0 and ranch:procs/2 in embedded mode Prevent ranch_conns_sup from stopping on unexpected messages 1.4.0 Add new transport option num_acceptor Deprecate ranch:start_listener/6 in favor of start_listener/5 Deprecate ranch:child_spec/6 in favor of child_spec/5 1.3.0 The version numbers 1.3.1 and 1.3.2 were later made to fix small mistakes made during the 1. + https://ninenines.eu/docs/en/ranch/1.8/guide/migrating_from_1.5/ + Ranch 1.6 added the ability to suspend and resume listeners. It also deprecates a number of features and add interfaces that will be used in Ranch 2.0. +Ranch 1.6 is compatible with Erlang/OTP 18.0 onward. Support for older releases has been removed. +Features added Listeners can now be suspended/resumed without stopping existing connection processes. This effectively closes the listening socket and stops the acceptor processes. Transport options can now be updated for suspended listeners. - Reading the request body - https://ninenines.eu/docs/en/cowboy/2.3/guide/req_body/ + Migrating from Ranch 1.x + https://ninenines.eu/docs/en/ranch/1.6/guide/migrating_from_1.x/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/req_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. + https://ninenines.eu/docs/en/ranch/1.6/guide/migrating_from_1.x/ + The changelog for Ranch releases before 1.6 can be found in this section. +1.5.0 Add transport functions getopts/2, getstat/1 and getstat/2 Fix ranch:info/0 and ranch:procs/2 in embedded mode Prevent ranch_conns_sup from stopping on unexpected messages 1.4.0 Add new transport option num_acceptor Deprecate ranch:start_listener/6 in favor of start_listener/5 Deprecate ranch:child_spec/6 in favor of child_spec/5 1.3.0 The version numbers 1.3.1 and 1.3.2 were later made to fix small mistakes made during the 1. @@ -1936,15 +1967,15 @@ You are not required to read it, however. If a body is present and was not read, - Sending a response - https://ninenines.eu/docs/en/cowboy/2.3/guide/resp/ + Reading the request body + https://ninenines.eu/docs/en/cowboy/2.9/guide/req_body/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/resp/ - 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. + https://ninenines.eu/docs/en/cowboy/2.9/guide/req_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. @@ -2007,6 +2038,18 @@ Cowboy also provides a simplified interface for sending files. It can also send 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. + + Sending a response + https://ninenines.eu/docs/en/cowboy/2.9/guide/resp/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/resp/ + 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. + + Migrating from Ranch 1.x https://ninenines.eu/docs/en/ranch/2.0/guide/migrating_from_1.x/ @@ -2028,13 +2071,13 @@ While only one response is allowed for every request, HTTP/2 introduced a mechan - Using cookies - https://ninenines.eu/docs/en/cowboy/2.3/guide/cookies/ + Migrating from Ranch 1.x + https://ninenines.eu/docs/en/ranch/1.8/guide/migrating_from_1.x/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/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). + https://ninenines.eu/docs/en/ranch/1.8/guide/migrating_from_1.x/ + The changelog for Ranch releases before 1.6 can be found in this section. +1.5.0 Add transport functions getopts/2, getstat/1 and getstat/2 Fix ranch:info/0 and ranch:procs/2 in embedded mode Prevent ranch_conns_sup from stopping on unexpected messages 1.4.0 Add new transport option num_acceptor Deprecate ranch:start_listener/6 in favor of start_listener/5 Deprecate ranch:child_spec/6 in favor of child_spec/5 1.3.0 The version numbers 1.3.1 and 1.3.2 were later made to fix small mistakes made during the 1. @@ -2088,14 +2131,13 @@ Cookies are a name/value store where the names and values are stored in plain te - Multipart requests - https://ninenines.eu/docs/en/cowboy/2.3/guide/multipart/ + Using cookies + https://ninenines.eu/docs/en/cowboy/2.9/guide/cookies/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/multipart/ - 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. + https://ninenines.eu/docs/en/cowboy/2.9/guide/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). @@ -2154,14 +2196,14 @@ In the context of HTTP, multipart is most often used with the multipart/form-dat - REST principles - https://ninenines.eu/docs/en/cowboy/2.3/guide/rest_principles/ + Multipart requests + https://ninenines.eu/docs/en/cowboy/2.9/guide/multipart/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/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&apos;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. + https://ninenines.eu/docs/en/cowboy/2.9/guide/multipart/ + 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. @@ -2220,15 +2262,14 @@ We will first attempt to define REST and will look at what it means in the conte - REST handlers - https://ninenines.eu/docs/en/cowboy/2.3/guide/rest_handlers/ + REST principles + https://ninenines.eu/docs/en/cowboy/2.9/guide/rest_principles/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/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&apos;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) -&gt; {cowboy_rest, Req, State}. + https://ninenines.eu/docs/en/cowboy/2.9/guide/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&apos;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. @@ -2292,14 +2333,15 @@ init(Req, State) -&gt; {cowboy_rest, Req, State}. - REST flowcharts - https://ninenines.eu/docs/en/cowboy/2.3/guide/rest_flowcharts/ + REST handlers + https://ninenines.eu/docs/en/cowboy/2.9/guide/rest_handlers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/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 &quot;Start&quot; diagram, and all paths excluding the OPTIONS path go through the &quot;Content negotiation&quot; diagram and optionally the &quot;Conditional requests&quot; diagram if the resource exists. + https://ninenines.eu/docs/en/cowboy/2.9/guide/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&apos;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) -&gt; {cowboy_rest, Req, State}. @@ -2358,13 +2400,14 @@ All paths start with the &quot;Start&quot; diagram, and all paths exclud - Designing a resource handler - https://ninenines.eu/docs/en/cowboy/2.3/guide/resource_design/ + REST flowcharts + https://ninenines.eu/docs/en/cowboy/2.9/guide/rest_flowcharts/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/resource_design/ - 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. + https://ninenines.eu/docs/en/cowboy/2.9/guide/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 &quot;Start&quot; diagram, and all paths excluding the OPTIONS path go through the &quot;Content negotiation&quot; diagram and optionally the &quot;Conditional requests&quot; diagram if the resource exists. @@ -2418,14 +2461,13 @@ The service Can the service become unavailable, and when it does, can we detect - The Websocket protocol - https://ninenines.eu/docs/en/cowboy/2.3/guide/ws_protocol/ + Designing a resource handler + https://ninenines.eu/docs/en/cowboy/2.9/guide/resource_design/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/ws_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). + https://ninenines.eu/docs/en/cowboy/2.9/guide/resource_design/ + 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. @@ -2484,13 +2526,14 @@ Websocket connections are fully asynchronous, unlike HTTP/1.1 (synchronous) and - Websocket handlers - https://ninenines.eu/docs/en/cowboy/2.3/guide/ws_handlers/ + The Websocket protocol + https://ninenines.eu/docs/en/cowboy/2.9/guide/ws_protocol/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/ws_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. + https://ninenines.eu/docs/en/cowboy/2.9/guide/ws_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). @@ -2544,14 +2587,13 @@ As Websocket connections are established through the HTTP/1.1 upgrade mechanism, - Streams - https://ninenines.eu/docs/en/cowboy/2.3/guide/streams/ + Websocket handlers + https://ninenines.eu/docs/en/cowboy/2.9/guide/ws_handlers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/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. + https://ninenines.eu/docs/en/cowboy/2.9/guide/ws_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. @@ -2610,14 +2652,14 @@ All versions of HTTP allow clients to initiate streams. HTTP/2 is the only one a - Middlewares - https://ninenines.eu/docs/en/cowboy/2.3/guide/middlewares/ + Streams + https://ninenines.eu/docs/en/cowboy/2.9/guide/streams/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/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. + https://ninenines.eu/docs/en/cowboy/2.9/guide/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. @@ -2675,6 +2717,17 @@ Middlewares give you complete control over how requests are to be processed. You Cowboy will execute all middlewares in the given order, unless one of them decides to stop processing. + + Middlewares + https://ninenines.eu/docs/en/cowboy/2.9/guide/middlewares/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/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. + + Changes since Cowboy 2.6 https://ninenines.eu/docs/en/cowboy/2.6/guide/migrating_from_2.6/ @@ -2688,16 +2741,6 @@ A bug in the HTTP/2 code that resulted in the failure to fully send iolist respo Cowboy will now use the host header when the HTTP/2 :authority pseudo header is missing. - - Migrating from Cowboy 2.2 to 2.3 - https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_2.2/ - Mon, 01 Jan 0001 00:00:00 +0000 - - https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_2.2/ - Cowboy 2.3 focused on making the Cowboy processes behave properly according to OTP principles. This version is a very good milestone toward that goal and most of everything should now work. Release upgrades and a few details will be improved in future versions. -Features added Add support for all functions from the module sys. Note that Cowboy currently does not implement the sys debugging mechanisms as tracing is recommended instead. Add a max_frame_size option for Websocket handlers to close the connection when the client attempts to send a frame that&apos;s too large. - - Migrating from Cowboy 2.3 to 2.4 https://ninenines.eu/docs/en/cowboy/2.4/guide/migrating_from_2.3/ @@ -2737,6 +2780,16 @@ Features added Add option linger_timeout to control how long Cowboy will wait be One process per connection The first version of Cowboy featured a single process per connection, whereas the current version of Cowboy features one process per connection plus one process per request. This has a negative impact on performance, but is necessary in order to provide a common interface for both HTTP/1. + + Performance + https://ninenines.eu/docs/en/cowboy/2.9/guide/performance/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/performance/ + This chapter describes the performance characteristics of Cowboy and offers suggestions to get the most performance out of your application. +One process per connection The first version of Cowboy featured a single process per connection, whereas the current version of Cowboy features one process per connection plus one process per request. This has a negative impact on performance, but is necessary in order to provide a common interface for both HTTP/1. + + Migrating from Cowboy 2.7 to 2.8 https://ninenines.eu/docs/en/cowboy/2.8/guide/migrating_from_2.7/ @@ -2748,13 +2801,14 @@ Cowboy 2.8 also contains a small number of tweaks and bug fixes. Cowboy 2.8 is t - Migrating from Cowboy 2.1 to 2.2 - https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_2.1/ + Migrating from Cowboy 2.8 to 2.9 + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.8/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_2.1/ - Cowboy 2.2 focused on adding features required for writing gRPC servers and on completing test suites for the core HTTP RFCs, fixing many bugs along the way. -Features added Add support for sending trailers at the end of response bodies. Trailers are additional header fields that may be sent after the body to add more information to the response. Their usage is required in gRPC servers. They are optional and may be discarded in other scenarios (for example if the request goes through an HTTP/1. + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.8/ + Cowboy 2.9 implements graceful shutdown of connection processes for both HTTP/1.1 and HTTP/2 connections. +Cowboy 2.9 is the first release to support the much awaited Erlang/OTP 24 out of the box. While users that were using Ranch 2.0 already were ready for OTP 24, the Ranch version used by Cowboy out of the box was not compatible and had to be updated. +Cowboy 2.9 also contains a small number of tweaks and bug fixes. @@ -2809,13 +2863,13 @@ Features added Add support for the PROXY protocol header. It can be enabled via - Migrating from Cowboy 2.0 to 2.1 - https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_2.0/ + Migrating from Cowboy 2.7 to 2.8 + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.7/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_2.0/ - 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. + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.7/ + Cowboy 2.8 contains many optimizations for all protocols. HTTP/1.1 has received the largest improvements and Cowboy will now be able to handle noticeably more requests. Thanks to the folks at Stressgrid for helping identify that the performance was lower than it should have been and for benchmarking my many changes and experiments. +Cowboy 2.8 also contains a small number of tweaks and bug fixes. Cowboy 2.8 is the first Cowboy release, ever, to be consistently green on all tested platforms. @@ -2870,14 +2924,12 @@ Features added Add support for the PROXY protocol header. It can be enabled via - Migrating from Cowboy 1.0 to 2.0 - https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_1.0/ + Migrating from Cowboy 2.6 to 2.7 + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.6/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_1.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. + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.6/ + Cowboy 2.7 improves the HTTP/2 code with optimizations around the sending of DATA and WINDOW_UPDATE frames; graceful shutdown of the connection when the client is going away; and rate limiting mechanisms. New options and mechanisms have also been added to control the amount of memory Cowboy ends up using with both HTTP/1.1 and HTTP/2. Much, but not all, of this work was done to address HTTP/2 CVEs about potential denial of service. @@ -2931,13 +2983,14 @@ Features added Add option linger_timeout to control how long Cowboy will wait be - HTTP and other specifications - https://ninenines.eu/docs/en/cowboy/2.3/guide/specs/ + Migrating from Cowboy 2.5 to 2.6 + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.5/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/specs/ - This chapter intends to list all the specification documents for or related to HTTP. -HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol 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 PROXY: The PROXY protocol REST: Fielding&apos;s Dissertation RFC 1945: HTTP/1. + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.5/ + Cowboy 2.6 greatly refactored the HTTP/2 code, a large part of which was moved to Cowlib and is now used by both the Cowboy server and the Gun client. +A large number of tickets were also closed which resulted in many bugs fixed and many features and options added, although some of them are still experimental. +Features added Add support for the PROXY protocol header. It can be enabled via the proxy_header option. @@ -2991,6 +3044,16 @@ Features added Add support for all functions from the module sys. Note that Cowb Features added Add experimental support for Websocket over HTTP/2. You can use the enable_connect_protocol option to enable. It implements the following draft: https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-01 Add options max_decode_table_size and max_encode_table_size to restrict the size of the HPACK compression dictionary. + + Migrating from Cowboy 2.4 to 2.5 + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.4/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.4/ + Cowboy 2.5 focused on making the test suites pass. A variety of new features, fixes and improvements have also been worked on. +Features added Add option linger_timeout to control how long Cowboy will wait before closing the socket when shutting down the connection. This helps avoid the TCP reset problem HTTP/1.1 suffers from. The default is now 1000 ms. It is now possible to stream a response body without using chunked transfer-encoding when the protocol is HTTP/1. + + HTTP and other specifications https://ninenines.eu/docs/en/cowboy/2.4/guide/specs/ @@ -3042,6 +3105,16 @@ Features added Add support for sending trailers at the end of response bodies. T Features added Add support for all functions from the module sys. Note that Cowboy currently does not implement the sys debugging mechanisms as tracing is recommended instead. Add a max_frame_size option for Websocket handlers to close the connection when the client attempts to send a frame that&apos;s too large. + + Migrating from Cowboy 2.3 to 2.4 + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.3/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.3/ + Cowboy 2.4 focused on improving the HTTP/2 implementation. All existing tests from RFC7540 and the h2spec test suite now all pass. Numerous options have been added to control SETTINGS and related behavior. In addition experimental support for Websocket over HTTP/2 was added. +Features added Add experimental support for Websocket over HTTP/2. You can use the enable_connect_protocol option to enable. It implements the following draft: https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-01 Add options max_decode_table_size and max_encode_table_size to restrict the size of the HPACK compression dictionary. + + HTTP and other specifications https://ninenines.eu/docs/en/cowboy/2.5/guide/specs/ @@ -3082,6 +3155,16 @@ Features added It is now possible to obtain the client TLS certificate and the l Features added Add support for sending trailers at the end of response bodies. Trailers are additional header fields that may be sent after the body to add more information to the response. Their usage is required in gRPC servers. They are optional and may be discarded in other scenarios (for example if the request goes through an HTTP/1. + + Migrating from Cowboy 2.2 to 2.3 + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.2/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.2/ + Cowboy 2.3 focused on making the Cowboy processes behave properly according to OTP principles. This version is a very good milestone toward that goal and most of everything should now work. Release upgrades and a few details will be improved in future versions. +Features added Add support for all functions from the module sys. Note that Cowboy currently does not implement the sys debugging mechanisms as tracing is recommended instead. Add a max_frame_size option for Websocket handlers to close the connection when the client attempts to send a frame that&apos;s too large. + + Migrating from Cowboy 1.0 to 2.0 https://ninenines.eu/docs/en/cowboy/2.6/guide/migrating_from_1.0/ @@ -3114,6 +3197,16 @@ Compatibility Compatibility with Erlang/OTP R16, 17 and 18 has been dropped. Erl 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. + + Migrating from Cowboy 2.1 to 2.2 + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.1/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.1/ + Cowboy 2.2 focused on adding features required for writing gRPC servers and on completing test suites for the core HTTP RFCs, fixing many bugs along the way. +Features added Add support for sending trailers at the end of response bodies. Trailers are additional header fields that may be sent after the body to add more information to the response. Their usage is required in gRPC servers. They are optional and may be discarded in other scenarios (for example if the request goes through an HTTP/1. + + HTTP and other specifications https://ninenines.eu/docs/en/cowboy/2.6/guide/specs/ @@ -3145,6 +3238,16 @@ The documentation has seen great work, in particular the manual. Each module and Compatibility Compatibility with Erlang/OTP R16, 17 and 18 has been dropped. Erlang/OTP 19. + + Migrating from Cowboy 2.0 to 2.1 + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.0/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_2.0/ + 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. + + HTTP and other specifications https://ninenines.eu/docs/en/cowboy/2.8/guide/specs/ @@ -3156,16 +3259,48 @@ HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message He - cow_cookie(3) - https://ninenines.eu/docs/en/cowlib/2.10/manual/cow_cookie/ + Migrating from Cowboy 1.0 to 2.0 + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_1.0/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowlib/2.10/manual/cow_cookie/ - Name cow_cookie - Cookies -Description The module cow_cookie provides functions for parsing and manipulating cookie headers. -Exports cow_cookie:parse_cookie(3) - Parse a cookie header cow_cookie:parse_set_cookie(3) - Parse a set-cookie header cow_cookie:cookie(3) - Generate a cookie header cow_cookie:setcookie(3) - Generate a set-cookie header Types cookie_attrs() cookie_attrs() :: #{ expires =&gt; calendar:datetime(), max_age =&gt; calendar:datetime(), domain =&gt; binary(), path =&gt; binary(), secure =&gt; true, http_only =&gt; true, same_site =&gt; strict | lax | none } Cookie attributes parsed from the set-cookie header. - - + https://ninenines.eu/docs/en/cowboy/2.9/guide/migrating_from_1.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. + + + + HTTP and other specifications + https://ninenines.eu/docs/en/cowboy/2.9/guide/specs/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/guide/specs/ + This chapter intends to list all the specification documents for or related to HTTP. +HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol 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 PROXY: The PROXY protocol REST: Fielding&apos;s Dissertation RFC 1945: HTTP/1. + + + + cow_cookie(3) + https://ninenines.eu/docs/en/cowlib/2.10/manual/cow_cookie/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowlib/2.10/manual/cow_cookie/ + Name cow_cookie - Cookies +Description The module cow_cookie provides functions for parsing and manipulating cookie headers. +Exports cow_cookie:parse_cookie(3) - Parse a cookie header cow_cookie:parse_set_cookie(3) - Parse a set-cookie header cow_cookie:cookie(3) - Generate a cookie header cow_cookie:setcookie(3) - Generate a set-cookie header Types cookie_attrs() cookie_attrs() :: #{ expires =&gt; calendar:datetime(), max_age =&gt; calendar:datetime(), domain =&gt; binary(), path =&gt; binary(), secure =&gt; true, http_only =&gt; true, same_site =&gt; strict | lax | none } Cookie attributes parsed from the set-cookie header. + + + + cow_cookie(3) + https://ninenines.eu/docs/en/cowlib/2.11/manual/cow_cookie/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowlib/2.11/manual/cow_cookie/ + Name cow_cookie - Cookies +Description The module cow_cookie provides functions for parsing and manipulating cookie headers. +Exports cow_cookie:parse_cookie(3) - Parse a cookie header cow_cookie:parse_set_cookie(3) - Parse a set-cookie header cow_cookie:cookie(3) - Generate a cookie header cow_cookie:setcookie(3) - Generate a set-cookie header Types cookie_attrs() cookie_attrs() :: #{ expires =&gt; calendar:datetime(), max_age =&gt; calendar:datetime(), domain =&gt; binary(), path =&gt; binary(), secure =&gt; true, http_only =&gt; true, same_site =&gt; strict | lax | none } Cookie attributes parsed from the set-cookie header. + + cow_cookie(3) https://ninenines.eu/docs/en/cowlib/2.8/manual/cow_cookie/ @@ -3201,6 +3336,19 @@ Arguments Cookies A list of pairs of cookie name and value. Changelog 2.9: Function introduced. Examples Generate a cookie header Cookie = cow_cookie:cookie([{&lt;&lt;"sessionid"&gt;&gt;, ID}]). See also cow_cookie(3), cow_cookie:parse_cookie(3), cow_cookie:parse_set_cookie(3), cow_cookie:setcookie(3) + + cow_cookie:cookie(3) + https://ninenines.eu/docs/en/cowlib/2.11/manual/cow_cookie.cookie/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowlib/2.11/manual/cow_cookie.cookie/ + Name cow_cookie:cookie - Generate a cookie header +Description cookie(Cookies) -&gt; iolist() Cookies :: [{Name :: iodata(), Value :: iodata()}] Generate a cookie header. +Arguments Cookies A list of pairs of cookie name and value. + Return value An iolist with the generated cookie header value. +Changelog 2.9: Function introduced. Examples Generate a cookie header Cookie = cow_cookie:cookie([{&lt;&lt;"sessionid"&gt;&gt;, ID}]). See also cow_cookie(3), cow_cookie:parse_cookie(3), cow_cookie:parse_set_cookie(3), cow_cookie:setcookie(3) + + cow_cookie:cookie(3) https://ninenines.eu/docs/en/cowlib/2.9/manual/cow_cookie.cookie/ @@ -3228,6 +3376,20 @@ An exception is thrown in the event of a parse error. Changelog 2.9: Fixes to the parser may lead to potential incompatibilities. A cookie name starting with $ is no longer ignored. + + cow_cookie:parse_cookie(3) + https://ninenines.eu/docs/en/cowlib/2.11/manual/cow_cookie.parse_cookie/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowlib/2.11/manual/cow_cookie.parse_cookie/ + Name cow_cookie:parse_cookie - Parse a cookie header +Description parse_cookie(Cookie :: binary()) -&gt; [{binary(), binary()}] Parse a cookie header. +Arguments Cookie The cookie header value. + Return value A list of cookie name/value pairs is returned on success. +An exception is thrown in the event of a parse error. +Changelog 2.9: Fixes to the parser may lead to potential incompatibilities. A cookie name starting with $ is no longer ignored. + + cow_cookie:parse_cookie(3) https://ninenines.eu/docs/en/cowlib/2.8/manual/cow_cookie.parse_cookie/ @@ -3269,6 +3431,19 @@ Arguments SetCookie The set-cookie header value. An atom ignore is returned when the cookie has both an empty name and an empty value, and must be ignored. + + cow_cookie:parse_set_cookie(3) + https://ninenines.eu/docs/en/cowlib/2.11/manual/cow_cookie.parse_set_cookie/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowlib/2.11/manual/cow_cookie.parse_set_cookie/ + Name cow_cookie:parse_set_cookie - Parse a set-cookie header +Description parse_set_cookie(SetCookie :: binary()) -&gt; {ok, Name, Value, Attrs} | ignore Name :: binary() Value :: binary() Attrs :: cow_cookie:cookie_attrs() Parse a set-cookie header. +Arguments SetCookie The set-cookie header value. + Return value An ok tuple with the cookie name, value and attributes is returned on success. +An atom ignore is returned when the cookie has both an empty name and an empty value, and must be ignored. + + cow_cookie:parse_set_cookie(3) https://ninenines.eu/docs/en/cowlib/2.9/manual/cow_cookie.parse_set_cookie/ @@ -3299,10 +3474,10 @@ Changelog 1.0: Function introduced. Examples Generate a set-cookie header SetC cow_cookie:setcookie(3) - https://ninenines.eu/docs/en/cowlib/2.8/manual/cow_cookie.setcookie/ + https://ninenines.eu/docs/en/cowlib/2.11/manual/cow_cookie.setcookie/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowlib/2.8/manual/cow_cookie.setcookie/ + https://ninenines.eu/docs/en/cowlib/2.11/manual/cow_cookie.setcookie/ Name cow_cookie:setcookie - Generate a set-cookie header Description setcookie(Name :: iodata(), Value :: iodata(), Opts :: cow_cookie:cookie_opts()) -&gt; iolist() Generate a set-cookie header. Arguments Name Cookie name. @@ -3314,10 +3489,10 @@ Changelog 1.0: Function introduced. Examples Generate a set-cookie header SetC cow_cookie:setcookie(3) - https://ninenines.eu/docs/en/cowlib/2.9/manual/cow_cookie.setcookie/ + https://ninenines.eu/docs/en/cowlib/2.8/manual/cow_cookie.setcookie/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowlib/2.9/manual/cow_cookie.setcookie/ + https://ninenines.eu/docs/en/cowlib/2.8/manual/cow_cookie.setcookie/ Name cow_cookie:setcookie - Generate a set-cookie header Description setcookie(Name :: iodata(), Value :: iodata(), Opts :: cow_cookie:cookie_opts()) -&gt; iolist() Generate a set-cookie header. Arguments Name Cookie name. @@ -3328,16 +3503,18 @@ Changelog 1.0: Function introduced. Examples Generate a set-cookie header SetC - Cowboy Function Reference - https://ninenines.eu/docs/en/cowboy/2.3/manual/ + cow_cookie:setcookie(3) + https://ninenines.eu/docs/en/cowlib/2.9/manual/cow_cookie.setcookie/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/ - 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: -cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols: + https://ninenines.eu/docs/en/cowlib/2.9/manual/cow_cookie.setcookie/ + Name cow_cookie:setcookie - Generate a set-cookie header +Description setcookie(Name :: iodata(), Value :: iodata(), Opts :: cow_cookie:cookie_opts()) -&gt; iolist() Generate a set-cookie header. +Arguments Name Cookie name. + Value Cookie value. + Opts Options added to the set-cookie header as attributes. + Return value An iolist with the generated set-cookie header value. +Changelog 1.0: Function introduced. Examples Generate a set-cookie header SetCookie = cow_cookie:setcookie(&lt;&lt;"sessionid"&gt;&gt;, ID, #{ http_only =&gt; true, secure =&gt; true }). @@ -3406,12 +3583,16 @@ cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_ro - Cowboy User Guide - https://ninenines.eu/docs/en/cowboy/2.3/guide/ + Cowboy Function Reference + https://ninenines.eu/docs/en/cowboy/2.9/manual/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/guide/ - Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Additional information Migrating from Cowboy 2. + https://ninenines.eu/docs/en/cowboy/2.9/manual/ + 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: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols: @@ -3460,14 +3641,12 @@ cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_ro - cowboy(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy/ + Cowboy User Guide + https://ninenines.eu/docs/en/cowboy/2.9/guide/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy/ - Name cowboy - HTTP server -Description The module cowboy provides convenience functions for manipulating Ranch listeners. -Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&apos;s environment value 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. + https://ninenines.eu/docs/en/cowboy/2.9/guide/ + Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Performance Additional information Migrating from Cowboy 2. @@ -3526,16 +3705,14 @@ Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:s - cowboy(7) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_app/ + cowboy(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_app/ - 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: -cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols: + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy/ + Name cowboy - HTTP server +Description The module cowboy provides convenience functions for manipulating Ranch listeners. +Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&apos;s environment value 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. @@ -3604,16 +3781,16 @@ cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_ro - cowboy:set_env(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.set_env/ + cowboy(7) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_app/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.set_env/ - Name cowboy:set_env - Update a listener&apos;s environment value -Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_app/ + 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: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols: @@ -3682,15 +3859,16 @@ Arguments Name The name of the listener to update. - cowboy:start_clear(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.start_clear/ + cowboy:set_env(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy.set_env/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.start_clear/ - Name cowboy:start_clear - Listen for connections using plain TCP -Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy.set_env/ + Name cowboy:set_env - Update a listener&apos;s environment value +Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; 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. @@ -3754,14 +3932,14 @@ Arguments Name The listener name is used to refer to this listener in future cal - cowboy:start_tls(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.start_tls/ + cowboy:start_clear(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy.start_clear/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.start_tls/ - Name cowboy:start_tls - Listen for connections using TLS -Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy.start_clear/ + Name cowboy:start_clear - Listen for connections using plain TCP +Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {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. @@ -3826,18 +4004,15 @@ Arguments Name The listener name is used to refer to this listener in future cal - cowboy:stop_listener(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.stop_listener/ + cowboy:start_tls(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy.start_tls/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.stop_listener/ - Name cowboy:stop_listener - Stop the given listener -Description stop_listener(Name :: ranch:ref()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy.start_tls/ + Name cowboy:start_tls - Listen for connections using TLS +Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {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. @@ -3915,6 +4090,21 @@ The name of the listener is the first argument given to the cowboy:start_clear(3 The {error, not_found} tuple is returned when the listener does not exist. + + cowboy:stop_listener(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy.stop_listener/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy.stop_listener/ + Name cowboy:stop_listener - Stop the given listener +Description stop_listener(Name :: ranch:ref()) -&gt; 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. + + cowboy_compress_h(3) https://ninenines.eu/docs/en/cowboy/2.6/manual/cowboy_compress_h/ @@ -3949,16 +4139,14 @@ Normal responses will only be compressed when their size is lower than the confi - cowboy_constraints(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_constraints/ + cowboy_compress_h(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_compress_h/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_constraints/ - 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: -cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_compress_h/ + Name cowboy_compress_h - Compress stream handler +Description The module cowboy_compress_h compresses response bodies automatically when the client supports it. It will not try to compress responses that already have a content encoding. +Normal responses will only be compressed when their size is lower than the configured threshold. Streamed responses are always compressed, including when the sendfile command is used. Because the file must be read in memory to be compressed, this module is not suitable for automatically compressing large files. @@ -4027,16 +4215,16 @@ cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - - cowboy_constraints:int(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_constraints.int/ + cowboy_constraints(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_constraints/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_constraints.int/ - Name cowboy_constraints:int - Integer constraint -Description Constraint functions implement a number of different operations. -int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. -int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. -int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_constraints/ + 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: +cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function. @@ -4105,17 +4293,16 @@ int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | - cowboy_constraints:nonempty(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_constraints.nonempty/ + cowboy_constraints:int(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_constraints.int/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_constraints.nonempty/ - Name cowboy_constraints:nonempty - Non-empty constraint + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_constraints.int/ + Name cowboy_constraints:int - Integer constraint Description Constraint functions implement a number of different operations. -nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. -nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. -nonempty(format_error, Error) -&gt; 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. +int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. +int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. +int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message. @@ -4189,15 +4376,17 @@ Arguments Arguments vary depending on the operation. Constraint functions always - cowboy_handler(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_handler/ + cowboy_constraints:nonempty(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_constraints.nonempty/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_handler/ - 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_constraints.nonempty/ + Name cowboy_constraints:nonempty - Non-empty constraint +Description Constraint functions implement a number of different operations. +nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. +nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. +nonempty(format_error, Error) -&gt; 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. @@ -4261,17 +4450,15 @@ This module also defines a callback interface for handling HTTP requests. - cowboy_handler:terminate(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_handler.terminate/ + cowboy_handler(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_handler/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_handler.terminate/ - Name cowboy_handler:terminate - Terminate the handler -Description terminate(Reason, PartialReq, State, Handler) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_handler/ + 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. @@ -4345,14 +4532,17 @@ It is possible to remove fields from the Req object to save memory when the hand - cowboy_http(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_http/ + cowboy_handler:terminate(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_handler.terminate/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_http/ - 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 =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), max_skip_body_length =&gt; non_neg_integer(), middlewares =&gt; [module()], request_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_handler.terminate/ + Name cowboy_handler:terminate - Terminate the handler +Description terminate(Reason, PartialReq, State, Handler) -&gt; 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. @@ -4411,16 +4601,14 @@ Options opts() :: #{ active_n =&gt; pos_integer(), chunked =&gt; boolean - cowboy_http2(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_http2/ + cowboy_http(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_http/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_http2/ - Name cowboy_http2 - HTTP/2 -Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. -Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), inactivity_timeout =&gt; timeout(), middlewares =&gt; [module()], preface_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_http/ + 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() :: #{ active_n =&gt; pos_integer(), chunked =&gt; boolean(), connection_type =&gt; worker | supervisor, http10_keepalive =&gt; boolean(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), initial_stream_flow_size =&gt; non_neg_integer(), linger_timeout =&gt; timeout(), logger =&gt; module(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), max_skip_body_length =&gt; non_neg_integer(), proxy_header =&gt; boolean(), request_timeout =&gt; timeout(), sendfile =&gt; boolean(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1. @@ -4479,16 +4667,14 @@ Options opts() :: #{ active_n =&gt; pos_integer(), connection_type =&gt; - cowboy_loop(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_loop/ + cowboy_http2(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_http2/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_loop/ - 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). + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_http2/ + Name cowboy_http2 - HTTP/2 +Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. +Options opts() :: #{ active_n =&gt; pos_integer(), connection_type =&gt; worker | supervisor, connection_window_margin_size =&gt; 0..16#7fffffff, connection_window_update_threshold =&gt; 0..16#7fffffff, enable_connect_protocol =&gt; boolean(), goaway_initial_timeout =&gt; timeout(), goaway_complete_timeout =&gt; timeout(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), initial_connection_window_size =&gt; 65535..16#7fffffff, initial_stream_window_size =&gt; 0..16#7fffffff, linger_timeout =&gt; timeout(), logger =&gt; module(), max_concurrent_streams =&gt; non_neg_integer() | infinity, max_connection_buffer_size =&gt; non_neg_integer(), max_connection_window_size =&gt; 0..16#7fffffff, max_decode_table_size =&gt; non_neg_integer(), max_encode_table_size =&gt; non_neg_integer(), max_frame_size_received =&gt; 16384. @@ -4557,8 +4743,21 @@ Loop until receiving a specific message, then send a response and stop execution - cowboy_metrics_h(3) - https://ninenines.eu/docs/en/cowboy/2.7/manual/cowboy_metrics_h/ + cowboy_loop(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_loop/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_loop/ + 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). + + + + cowboy_metrics_h(3) + https://ninenines.eu/docs/en/cowboy/2.7/manual/cowboy_metrics_h/ Mon, 01 Jan 0001 00:00:00 +0000 https://ninenines.eu/docs/en/cowboy/2.7/manual/cowboy_metrics_h/ @@ -4579,16 +4778,14 @@ Types metrics() metrics() :: #{ %% The identifier for this listener. ref := ranc - cowboy_middleware(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_middleware/ + cowboy_metrics_h(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_metrics_h/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_middleware/ - 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) -&gt; {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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_metrics_h/ + Name cowboy_metrics_h - Metrics stream handler +Description The module cowboy_metrics_h gathers metrics and other information about a stream. It then calls the configured callback with this data. +Types metrics() metrics() :: #{ %% The identifier for this listener. ref := ranch:ref(), %% The pid for this connection. pid := pid(), %% The streamid also indicates the total number of requests on %% this connection (StreamID div 2 + 1). streamid := cowboy_stream:streamid(), %% The terminate reason is always useful. @@ -4657,15 +4854,16 @@ execute(Req, Env) -&gt; {ok, Req, Env} | {suspend, module(), atom(), [any()] - cowboy_req(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req/ + cowboy_middleware(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_middleware/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req/ - 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_middleware/ + 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) -&gt; {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. @@ -4729,17 +4927,15 @@ Type Name pattern Return type access no verb, parse_*, match_* Value question h - cowboy_req:binding(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.binding/ + cowboy_req(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.binding/ - Name cowboy_req:binding - Access a value bound from the route -Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; 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). + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req/ + 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. @@ -4813,16 +5009,17 @@ Arguments Name Desired binding name as an atom. - cowboy_req:bindings(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.bindings/ + cowboy_req:binding(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.binding/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.bindings/ - Name cowboy_req:bindings - Access all values bound from the route -Description bindings(Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.binding/ + Name cowboy_req:binding - Access a value bound from the route +Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; 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). @@ -4891,16 +5088,16 @@ Changelog 2.0: Only the values are returned, they are no longer wrapped in a tup - cowboy_req:body_length(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.body_length/ + cowboy_req:bindings(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.bindings/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.body_length/ - Name cowboy_req:body_length - Body length -Description body_length(Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.bindings/ + Name cowboy_req:bindings - Access all values bound from the route +Description bindings(Req :: cowboy_req:req()) -&gt; cowboy_router:bindings() Return a map containing all bindings. Arguments Req The Req object. - Return value The length of the request body, or undefined if it is not known. + 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. @@ -4968,6 +5165,19 @@ Arguments Req The Req object. Return value The length of the request body, or undefined if it is not known. + + cowboy_req:body_length(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.body_length/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.body_length/ + Name cowboy_req:body_length - Body length +Description body_length(Req :: cowboy_req:req()) -&gt; 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. + + cowboy_req:cast(3) https://ninenines.eu/docs/en/cowboy/2.7/manual/cowboy_req.cast/ @@ -4999,15 +5209,18 @@ Changelog 2.7: Function introduced. Examples Increase the HTTP/1. - cowboy_req:cert(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.cert/ + cowboy_req:cast(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.cast/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.cert/ - Name cowboy_req:cert - Client TLS certificate -Description cert(Req :: cowboy_req:req()) -&gt; binary() | undefined Return the peer&apos;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 =&gt; #{dispatch =&gt; Dispatch} }). + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.cast/ + Name cowboy_req:cast - Cast a stream handler event +Description cast(Event :: any(), Req :: cowboy_req:req()) -&gt; ok Cast a stream handler event. +The event will be passed to stream handlers through the info/3 callback. +Arguments Event The event to be sent to stream handlers. + Req The Req object. + Return value The atom ok is always returned. It can be safely ignored. +Changelog 2.7: Function introduced. Examples Increase the HTTP/1. @@ -5071,17 +5284,15 @@ Using the default configuration this function will always return undefined. You - cowboy_req:delete_resp_header(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.delete_resp_header/ + cowboy_req:cert(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.cert/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.delete_resp_header/ - Name cowboy_req:delete_resp_header - Delete a response header -Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.cert/ + Name cowboy_req:cert - Client TLS certificate +Description cert(Req :: cowboy_req:req()) -&gt; binary() | undefined Return the peer&apos;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}, {certfile, "path/to/cert.pem"}, {verify, verify_peer} ], #{ env =&gt; #{dispatch =&gt; Dispatch} }). @@ -5154,6 +5365,20 @@ Arguments Name Header name as a lowercase binary string. Return value A new Req object is returned. + + cowboy_req:delete_resp_header(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.delete_resp_header/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.delete_resp_header/ + Name cowboy_req:delete_resp_header - Delete a response header +Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; 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. + + cowboy_req:filter_cookies(3) https://ninenines.eu/docs/en/cowboy/2.7/manual/cowboy_req.filter_cookies/ @@ -5179,16 +5404,15 @@ Malformed cookies are unfortunately fairly common due to the string-based interf - cowboy_req:has_body(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.has_body/ + cowboy_req:filter_cookies(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.filter_cookies/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.has_body/ - Name cowboy_req:has_body - Is there a request body? -Description has_body(Req :: cowboy_req:req()) -&gt; 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) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.filter_cookies/ + Name cowboy_req:filter_cookies - Filter cookie headers +Description filter_cookies(Names, Req) -&gt; Req Names :: [atom() | binary()] Filter cookie headers. +This function is meant to be used before attempting to parse or match cookies in order to remove cookies that are not relevant and are potentially malformed. Because Cowboy by default crashes on malformed cookies, this function allows processing requests that would otherwise result in a 400 error. +Malformed cookies are unfortunately fairly common due to the string-based interface provided by browsers and this function provides a middle ground between Cowboy&apos;s strict behavior and chaotic real world use cases. @@ -5257,17 +5481,16 @@ Changelog 1.0: Function introduced. Examples Ensure the request has a body tru - cowboy_req:has_resp_body(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_body/ + cowboy_req:has_body(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.has_body/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_body/ - Name cowboy_req:has_resp_body - Is there a response body? -Description has_resp_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether a response body has been set. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.has_body/ + Name cowboy_req:has_body - Is there a request body? +Description has_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether the request has a body. 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(&lt;&lt;" + 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) @@ -5341,15 +5564,17 @@ Changelog 1.0: Function introduced. Examples Check whether a body has been set - cowboy_req:has_resp_header(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_header/ + cowboy_req:has_resp_body(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.has_resp_body/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_header/ - Name cowboy_req:has_resp_header - Is the given response header set? -Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.has_resp_body/ + Name cowboy_req:has_resp_body - Is there a response body? +Description has_resp_body(Req :: cowboy_req:req()) -&gt; 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(&lt;&lt;" @@ -5413,15 +5638,15 @@ Arguments Name Header name as a lowercase binary string. - cowboy_req:header(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.header/ + cowboy_req:has_resp_header(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.has_resp_header/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.header/ - Name cowboy_req:header - HTTP header -Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given HTTP header. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.has_resp_header/ + Name cowboy_req:has_resp_header - Is the given response header set? +Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; 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. -Headers can also be obtained using pattern matching: +Arguments Name Header name as a lowercase binary string. @@ -5485,17 +5710,15 @@ Headers can also be obtained using pattern matching: - cowboy_req:headers(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.headers/ + cowboy_req:header(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.header/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.headers/ - Name cowboy_req:headers - HTTP headers -Description headers(Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.header/ + Name cowboy_req:header - HTTP header +Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; 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: @@ -5569,17 +5792,17 @@ Changelog 2.0: Only the headers are returned, they are no longer wrapped in a tu - cowboy_req:host(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.host/ + cowboy_req:headers(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.headers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.host/ - Name cowboy_req:host - URI host name -Description host(Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.headers/ + Name cowboy_req:headers - HTTP headers +Description headers(Req :: cowboy_req:req()) -&gt; 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. @@ -5653,17 +5876,17 @@ Changelog 2.0: Only the host name is returned, it is no longer wrapped in a tupl - cowboy_req:host_info(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.host_info/ + cowboy_req:host(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.host/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.host_info/ - Name cowboy_req:host_info - Access the route&apos;s heading host segments -Description host_info(Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.host/ + Name cowboy_req:host - URI host name +Description host(Req :: cowboy_req:req()) -&gt; 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. @@ -5737,15 +5960,17 @@ Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tup - cowboy_req:inform(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.inform/ + cowboy_req:host_info(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.host_info/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.inform/ - Name cowboy_req:inform - Send an informational response -Description inform(Status, Req :: cowboy_req:req()) -&gt; inform(StatusCode, #{}, Req) inform(Status, Headers, Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.host_info/ + Name cowboy_req:host_info - Access the route&apos;s heading host segments +Description host_info(Req :: cowboy_req:req()) -&gt; 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. @@ -5809,14 +6034,15 @@ Any number of informational responses can be sent as long as they are sent befor - cowboy_req:match_cookies(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.match_cookies/ + cowboy_req:inform(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.inform/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.match_cookies/ - Name cowboy_req:match_cookies - Match cookies against constraints -Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.inform/ + Name cowboy_req:inform - Send an informational response +Description inform(Status, Req :: cowboy_req:req()) -&gt; inform(StatusCode, #{}, Req) inform(Status, Headers, Req :: cowboy_req:req()) -&gt; 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. @@ -5875,14 +6101,14 @@ Cowboy will only return the cookie values specified in the fields list, and igno - cowboy_req:match_qs(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.match_qs/ + cowboy_req:match_cookies(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.match_cookies/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.match_qs/ - Name cowboy_req:match_qs - Match the query string against constraints -Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.match_cookies/ + Name cowboy_req:match_cookies - Match cookies against constraints +Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; 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. @@ -5941,17 +6167,14 @@ Cowboy will only return the query string values specified in the fields list, an - cowboy_req:method(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.method/ + cowboy_req:match_qs(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.match_qs/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.method/ - Name cowboy_req:method - HTTP method -Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&apos;s HTTP method. -The method can also be obtained using pattern matching: -#{method := Method} = Req. Arguments Req The Req object. - Return value The request&apos;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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.match_qs/ + Name cowboy_req:match_qs - Match the query string against constraints +Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; 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. @@ -6025,18 +6248,17 @@ Changelog 2.0: Only the method is returned, it is no longer wrapped in a tuple.< - cowboy_req:parse_cookies(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.parse_cookies/ + cowboy_req:method(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.method/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.parse_cookies/ - Name cowboy_req:parse_cookies - Parse cookie headers -Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. -Alias for cowboy_req:parse_header(&lt;&lt;&quot;cookie&quot;&gt;&gt;, 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.method/ + Name cowboy_req:method - HTTP method +Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&apos;s HTTP method. +The method can also be obtained using pattern matching: +#{method := Method} = Req. Arguments Req The Req object. + Return value The request&apos;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. @@ -6111,15 +6333,16 @@ This function will crash on invalid cookie data. Because invalid cookies are fai - cowboy_req:parse_header(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.parse_header/ + cowboy_req:parse_cookies(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.parse_cookies/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.parse_header/ - Name cowboy_req:parse_header - Parse the given HTTP header -Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.parse_cookies/ + Name cowboy_req:parse_cookies - Parse cookie headers +Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. +Alias for cowboy_req:parse_header(&lt;&lt;&quot;cookie&quot;&gt;&gt;, Req). +When the cookie header is missing or empty, [] is returned. +This function will crash on invalid cookie data. Because invalid cookies are fairly common when dealing with browsers (because of the string interface that the Javascript API provides), it is recommended to filter the cookie header value before attempting to parse it. @@ -6183,15 +6406,15 @@ The type of the parsed value varies depending on the header. - cowboy_req:parse_qs(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.parse_qs/ + cowboy_req:parse_header(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.parse_header/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.parse_qs/ - Name cowboy_req:parse_qs - Parse the query string -Description parse_qs(Req :: cowboy_req:req()) -&gt; [{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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.parse_header/ + Name cowboy_req:parse_header - Parse the given HTTP header +Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; 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. @@ -6255,17 +6478,15 @@ Arguments Req The Req object. - cowboy_req:path(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.path/ + cowboy_req:parse_qs(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.parse_qs/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.path/ - Name cowboy_req:path - URI path -Description path(Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.parse_qs/ + Name cowboy_req:parse_qs - Parse the query string +Description parse_qs(Req :: cowboy_req:req()) -&gt; [{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. @@ -6339,17 +6560,17 @@ Changelog 2.0: Only the path is returned, it is no longer wrapped in a tuple. - cowboy_req:path_info(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.path_info/ + cowboy_req:path(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.path/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.path_info/ - Name cowboy_req:path_info - Access the route&apos;s trailing path segments -Description path_info(Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.path/ + Name cowboy_req:path - URI path +Description path(Req :: cowboy_req:req()) -&gt; 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. @@ -6423,17 +6644,17 @@ Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tup - cowboy_req:peer(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.peer/ + cowboy_req:path_info(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.path_info/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.peer/ - Name cowboy_req:peer - Peer address and port -Description peer(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the peer&apos;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&apos;s IP address and port number. -The peer is not necessarily the client&apos;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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.path_info/ + Name cowboy_req:path_info - Access the route&apos;s trailing path segments +Description path_info(Req :: cowboy_req:req()) -&gt; 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. @@ -6507,16 +6728,17 @@ The peer is not necessarily the client&apos;s IP address and port. It is the - cowboy_req:port(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.port/ + cowboy_req:peer(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.peer/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.port/ - Name cowboy_req:port - URI port number -Description port(Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.peer/ + Name cowboy_req:peer - Peer address and port +Description peer(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the peer&apos;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&apos;s IP address and port number. +The peer is not necessarily the client&apos;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. @@ -6585,14 +6807,16 @@ The port number can also be obtained using pattern matching: - cowboy_req:push(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.push/ + cowboy_req:port(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.port/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.push/ - Name cowboy_req:push - Push a resource to the client -Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.port/ + Name cowboy_req:port - URI port number +Description port(Req :: cowboy_req:req()) -&gt; 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. @@ -6651,17 +6875,14 @@ Cowboy handles push requests the same way as if they came from the client, inclu - cowboy_req:qs(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.qs/ + cowboy_req:push(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.push/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.qs/ - Name cowboy_req:qs - URI query string -Description qs(Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.push/ + Name cowboy_req:push - Push a resource to the client +Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; 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. @@ -6734,6 +6955,20 @@ The query string can also be obtained using pattern matching: Changelog 2.0: Only the query string is returned, it is no longer wrapped in a tuple. + + cowboy_req:qs(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.qs/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.qs/ + Name cowboy_req:qs - URI query string +Description qs(Req :: cowboy_req:req()) -&gt; 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. + + cowboy_req:read_and_match_urlencoded_body(3) https://ninenines.eu/docs/en/cowboy/2.5/manual/cowboy_req.read_and_match_urlencoded_body/ @@ -6779,14 +7014,14 @@ This function reads the request body and parses it as application/x-www-form-url - cowboy_req:read_body(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_body/ + cowboy_req:read_and_match_urlencoded_body(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.read_and_match_urlencoded_body/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_body/ - Name cowboy_req:read_body - Read the request body -Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.read_and_match_urlencoded_body/ + Name cowboy_req:read_and_match_urlencoded_body - Read, parse and match a urlencoded request body against constraints +Description read_and_match_urlencoded_body(Fields, Req) -&gt; read_and_match_urlencoded_body(Fields, Req, #{}) read_and_match_urlencoded_body(Fields, Req, Opts) -&gt; {ok, Body, Req} Fields :: cowboy:fields() Req :: cowboy_req:req() Opts :: cowboy_req:read_body_opts() Body :: #{atom() =&gt; any()} Read, parse and match a urlencoded request body against constraints. +This function reads the request body and parses it as application/x-www-form-urlencoded. It then applies the given field constraints to the urlencoded data and returns the result as a map. @@ -6845,14 +7080,14 @@ This function reads a chunk of the request body. A more tuple is returned when m - cowboy_req:read_part(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_part/ + cowboy_req:read_body(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.read_body/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_part/ - Name cowboy_req:read_part - Read the next multipart headers -Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.read_body/ + Name cowboy_req:read_body - Read the request body +Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {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. @@ -6911,14 +7146,14 @@ This function reads the request body and parses it as multipart. Each parts of a - cowboy_req:read_part_body(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_part_body/ + cowboy_req:read_part(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.read_part/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_part_body/ - Name cowboy_req:read_part_body - Read the current part&apos;s body -Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.read_part/ + Name cowboy_req:read_part - Read the next multipart headers +Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; 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. @@ -6977,15 +7212,14 @@ This function reads the request body and parses it as multipart. Each parts of a - cowboy_req:read_urlencoded_body(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_urlencoded_body/ + cowboy_req:read_part_body(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.read_part_body/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_urlencoded_body/ - Name cowboy_req:read_urlencoded_body - Read and parse a urlencoded request body -Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.read_part_body/ + Name cowboy_req:read_part_body - Read the current part&apos;s body +Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {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. @@ -7049,14 +7283,15 @@ The urlencoded media type is used by Web browsers when submitting HTML forms usi - cowboy_req:reply(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.reply/ + cowboy_req:read_urlencoded_body(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.read_urlencoded_body/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.reply/ - Name cowboy_req:reply - Send the response -Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.read_urlencoded_body/ + Name cowboy_req:read_urlencoded_body - Read and parse a urlencoded request body +Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {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. @@ -7115,15 +7350,14 @@ The header names must be given as lowercase binary strings. While header names a - cowboy_req:resp_header(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.resp_header/ + cowboy_req:reply(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.reply/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.resp_header/ - Name cowboy_req:resp_header - Response header -Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.reply/ + Name cowboy_req:reply - Send the response +Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; 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. @@ -7187,16 +7421,15 @@ The header name must be given as a lowercase binary string. While header names a - cowboy_req:resp_headers(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.resp_headers/ + cowboy_req:resp_header(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.resp_header/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.resp_headers/ - Name cowboy_req:resp_headers - Response headers -Description resp_headers(Req :: cowboy_req:req()) -&gt; 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) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.resp_header/ + Name cowboy_req:resp_header - Response header +Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; 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. @@ -7265,18 +7498,16 @@ Changelog 2.0: Function introduced. Examples Get all response headers Headers - cowboy_req:scheme(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.scheme/ + cowboy_req:resp_headers(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.resp_headers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.scheme/ - Name cowboy_req:scheme - URI scheme -Description scheme(Req :: cowboy_req:req()) -&gt; 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 &lt;&lt;&quot;http&quot;&gt;&gt; or &lt;&lt;&quot;https&quot;&gt;&gt;. -Changelog 2.0: Function introduced. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.resp_headers/ + Name cowboy_req:resp_headers - Response headers +Description resp_headers(Req :: cowboy_req:req()) -&gt; 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) @@ -7355,15 +7586,18 @@ Changelog 2.0: Function introduced. - cowboy_req:set_resp_body(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_body/ + cowboy_req:scheme(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.scheme/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_body/ - Name cowboy_req:set_resp_body - Set the response body -Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.scheme/ + Name cowboy_req:scheme - URI scheme +Description scheme(Req :: cowboy_req:req()) -&gt; 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 &lt;&lt;&quot;http&quot;&gt;&gt; or &lt;&lt;&quot;https&quot;&gt;&gt;. +Changelog 2.0: Function introduced. @@ -7427,17 +7661,15 @@ This function can also be used to remove a response body that was set previously - cowboy_req:set_resp_cookie(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_cookie/ + cowboy_req:set_resp_body(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_body/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_cookie/ - Name cowboy_req:set_resp_cookie - Set a cookie -Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, [], Req) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_body/ + Name cowboy_req:set_resp_body - Set the response body +Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; 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. @@ -7511,15 +7743,17 @@ Arguments Name Cookie name. - cowboy_req:set_resp_header(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_header/ + cowboy_req:set_resp_cookie(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_cookie/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_header/ - Name cowboy_req:set_resp_header - Set a response header -Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_cookie/ + Name cowboy_req:set_resp_cookie - Set a cookie +Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, Req, #{}) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; 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. @@ -7583,15 +7817,15 @@ Cowboy does not allow duplicate header names. - cowboy_req:set_resp_headers(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_headers/ + cowboy_req:set_resp_header(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_header/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_headers/ - Name cowboy_req:set_resp_headers - Set several response headers -Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; Req Headers :: cowboy:http_headers() Set several headers to be sent with the response. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_header/ + Name cowboy_req:set_resp_header - Set a response header +Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; 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. +Cowboy does not allow duplicate header names. @@ -7655,17 +7889,15 @@ Cowboy does not allow duplicate header names. Headers set by this function may b - cowboy_req:sock(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.sock/ + cowboy_req:set_resp_headers(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_headers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.sock/ - Name cowboy_req:sock - Socket address and port -Description sock(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the socket&apos;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&apos;s local IP address and port number. -Changelog 2.1: Function introduced. Examples Get the socket&apos;s IP address and port number. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.set_resp_headers/ + Name cowboy_req:set_resp_headers - Set several response headers +Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; 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. @@ -7739,15 +7971,17 @@ Changelog 2.1: Function introduced. Examples Get the socket&apos;s IP addr - cowboy_req:stream_body(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.stream_body/ + cowboy_req:sock(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.sock/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.stream_body/ - Name cowboy_req:stream_body - Stream the response body -Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; 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) or be a call to the cowboy_req:stream_trailers(3) function. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.sock/ + Name cowboy_req:sock - Socket address and port +Description sock(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the socket&apos;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&apos;s local IP address and port number. +Changelog 2.1: Function introduced. Examples Get the socket&apos;s IP address and port number. @@ -7811,13 +8045,25 @@ The second argument indicates if this call is the final call. Use the nofin valu - cowboy_req:stream_events(3) - https://ninenines.eu/docs/en/cowboy/2.5/manual/cowboy_req.stream_events/ + cowboy_req:stream_body(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.stream_body/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.5/manual/cowboy_req.stream_events/ - Name cowboy_req:stream_events - Stream events -Description stream_events(Events, IsFin, Req :: cowboy_req:req()) -&gt; ok Events :: Event | [Event] IsFin :: fin | nofin Event :: #{ comment =&gt; iodata(), data =&gt; iodata(), event =&gt; iodata() | atom(), id =&gt; iodata(), retry =&gt; non_neg_integer() } Stream events. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.stream_body/ + Name cowboy_req:stream_body - Stream the response body +Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; ok Data :: cowboy_req:resp_body() 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) or be a call to the cowboy_req:stream_trailers(3) function. + + + + cowboy_req:stream_events(3) + https://ninenines.eu/docs/en/cowboy/2.5/manual/cowboy_req.stream_events/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.5/manual/cowboy_req.stream_events/ + Name cowboy_req:stream_events - Stream events +Description stream_events(Events, IsFin, Req :: cowboy_req:req()) -&gt; ok Events :: Event | [Event] IsFin :: fin | nofin Event :: #{ comment =&gt; iodata(), data =&gt; iodata(), event =&gt; iodata() | atom(), id =&gt; iodata(), retry =&gt; non_neg_integer() } Stream events. This function should only be used for text/event-stream responses when using server-sent events. Cowboy will automatically encode the given events to their text representation. @@ -7855,15 +8101,14 @@ This function should only be used for text/event-stream responses when using ser - cowboy_req:stream_reply(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.stream_reply/ + cowboy_req:stream_events(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.stream_events/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.stream_reply/ - Name cowboy_req:stream_reply - Send the response headers -Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.stream_events/ + Name cowboy_req:stream_events - Stream events +Description stream_events(Events, IsFin, Req :: cowboy_req:req()) -&gt; ok Events :: Event | [Event] IsFin :: fin | nofin Event :: #{ comment =&gt; iodata(), data =&gt; iodata(), event =&gt; iodata() | atom(), id =&gt; iodata(), retry =&gt; non_neg_integer() } Stream events. +This function should only be used for text/event-stream responses when using server-sent events. Cowboy will automatically encode the given events to their text representation. @@ -7927,15 +8172,15 @@ Cowboy does not allow duplicate header names. Headers set by this function may o - cowboy_req:stream_trailers(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.stream_trailers/ + cowboy_req:stream_reply(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.stream_reply/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.stream_trailers/ - Name cowboy_req:stream_trailers - Send the response trailers -Description stream_trailers(Trailers, Req :: cowboy_req:req()) -&gt; ok Trailers :: cowboy:http_headers() Send the response trailers and terminate the stream. -This function can only be called once, after initiating a response using cowboy_req:stream_reply(3) and sending zero or more body chunks using cowboy_req:stream_body(3) with the nofin argument set. The function stream_trailers/2 implies fin and automatically terminate the response. -You must list all field names sent in trailers in the trailer header, otherwise they might be dropped by intermediaries or clients. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.stream_reply/ + Name cowboy_req:stream_reply - Send the response headers +Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; 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. @@ -7999,14 +8244,15 @@ You must list all field names sent in trailers in the trailer header, otherwise - cowboy_req:uri(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.uri/ + cowboy_req:stream_trailers(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.stream_trailers/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.uri/ - Name cowboy_req:uri - Reconstructed URI -Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. -By default Cowboy will build a URI using the components found in the request. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.stream_trailers/ + Name cowboy_req:stream_trailers - Send the response trailers +Description stream_trailers(Trailers, Req :: cowboy_req:req()) -&gt; ok Trailers :: cowboy:http_headers() Send the response trailers and terminate the stream. +This function can only be called once, after initiating a response using cowboy_req:stream_reply(3) and sending zero or more body chunks using cowboy_req:stream_body(3) with the nofin argument set. The function stream_trailers/2 implies fin and automatically terminate the response. +You must list all field names sent in trailers in the trailer header, otherwise they might be dropped by intermediaries or clients. @@ -8065,17 +8311,14 @@ By default Cowboy will build a URI using the components found in the request. - cowboy_req:version(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.version/ + cowboy_req:uri(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.uri/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.version/ - Name cowboy_req:version - HTTP version -Description version(Req :: cowboy_req:req()) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.uri/ + Name cowboy_req:uri - Reconstructed URI +Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. +By default Cowboy will build a URI using the components found in the request. @@ -8149,16 +8392,17 @@ Changelog 2.0: Only the version is returned, it is no longer wrapped in a tuple. - cowboy_rest(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_rest/ + cowboy_req:version(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.version/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_rest/ - 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) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} | {{switch_handler, Module}, Req, State} | {{switch_handler, Module, Opts}, Req, State} terminate(Reason, Req, State) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_req.version/ + Name cowboy_req:version - HTTP version +Description version(Req :: cowboy_req:req()) -&gt; 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. @@ -8227,16 +8471,16 @@ init(Req, State) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -& - cowboy_router(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_router/ + cowboy_rest(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_rest/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_router/ - 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_rest/ + 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) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} | {{switch_handler, Module}, Req, State} | {{switch_handler, Module, Opts}, Req, State} terminate(Reason, Req, State) -&gt; 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. @@ -8301,17 +8545,14 @@ The router takes the dispatch rules as input from the middleware environment. Di - cowboy_router:compile(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_router.compile/ + cowboy_router(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_router/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_router.compile/ - Name cowboy_router:compile - Compile routes to the resources -Description compile(cowboy_router:routes()) -&gt; 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([ {'_', [ {" + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_router/ + 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. The environment can contain the rules directly or a tuple {persistent_term, Key}, in which case Cowboy will call persistent_term:get(Key) to retrieve the dispatch rules. @@ -8385,15 +8626,17 @@ Changelog 1.0: Function introduced. Examples Compile routes and start a listen - cowboy_static(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_static/ + cowboy_router:compile(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_router.compile/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_static/ - 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_router.compile/ + Name cowboy_router:compile - Compile routes to the resources +Description compile(cowboy_router:routes()) -&gt; 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([ {'_', [ {" @@ -8457,16 +8700,15 @@ Options opts() :: {priv_file, App, Path} | {priv_file, App, Path, Extra} | {file - cowboy_stream(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_stream/ + cowboy_static(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_static/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_stream/ - 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_static/ + 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 :: [Charset | Etag | Mimetypes] Charset :: {charset, module(), function()} | {charset, binary()} 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. @@ -8534,6 +8776,19 @@ Cowboy calls the stream handler for nearly all events related to a stream. Excep Extra care must be taken when implementing stream handlers to ensure compatibility. + + cowboy_stream(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_stream/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_stream/ + Name cowboy_stream - 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. + + cowboy_stream_h(3) https://ninenines.eu/docs/en/cowboy/2.6/manual/cowboy_stream_h/ @@ -8570,6 +8825,18 @@ Options opts() :: #{ env =&gt; cowboy_middleware:env(), middlewares =&gt The default value is given next to the option name: + + cowboy_stream_h(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_stream_h/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_stream_h/ + Name cowboy_stream_h - Default stream handler +Description The module cowboy_stream_h is Cowboy&apos;s default stream handler and defines much of its behavior. It is responsible for managing the request process, sending it the request body and translating its messages into commands that Cowboy understands. +Options opts() :: #{ env =&gt; cowboy_middleware:env(), middlewares =&gt; [module()], shutdown_timeout =&gt; timeout() } Configuration for the default stream handler. +The default value is given next to the option name: + + cowboy_tracer_h(3) https://ninenines.eu/docs/en/cowboy/2.7/manual/cowboy_tracer_h/ @@ -8593,15 +8860,14 @@ Options opts() :: #{ tracer_callback =&gt; Callback, tracer_flags =&gt; - cowboy_websocket(3) - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_websocket/ + cowboy_tracer_h(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_tracer_h/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_websocket/ - 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) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; 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. + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_tracer_h/ + Name cowboy_tracer_h - Tracer stream handler +Description The module cowboy_tracer_h can be used to conditionally trace streams based on information found in the request. Trace messages are given to the configured callback. +Options opts() :: #{ tracer_callback =&gt; Callback, tracer_flags =&gt; [atom()], tracer_match_specs =&gt; [MatchSpec] } Callback :: fun((init | terminate | tuple(), State) -&gt; State) MatchSpec :: MatchPredicate | {method, binary()} | {host, binary()} | {path, binary()} | {path_start, binary()} | {header, binary()} | {header, binary(), binary()} | {peer_ip, inet:ip_address()} MatchPredicate :: fun((cowboy_stream:streamid(), cowboy_req:req(), cowboy:opts()) -&gt; boolean()) } Configuration for the tracer stream handler. @@ -8664,6 +8930,18 @@ Callbacks Websocket handlers must implement the following callback interface: init(Req, State) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: ping | pong | {text | binary | ping | pong, binary()} Info :: any() CallResult :: {commands(), State} | {commands(), State, hibernate} | Deprecated Deprecated :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} OutFrame :: cow_ws:frame() %% see types below 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. + + cowboy_websocket(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_websocket/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowboy/2.9/manual/cowboy_websocket/ + 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) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: ping | pong | {text | binary | ping | pong, binary()} Info :: any() CallResult :: {commands(), State} | {commands(), State, hibernate} | Deprecated Deprecated :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} OutFrame :: cow_ws:frame() %% see types below 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. + + Cowlib Function Reference https://ninenines.eu/docs/en/cowlib/2.10/manual/ @@ -8676,6 +8954,18 @@ It is optimized for completeness rather than speed. No value is ignored, they ar Modules cow_cookie(3) - Cookies Dependencies crypto - Crypto functions All these applications must be started before the cowlib application. To start Cowlib and all dependencies at once: + + Cowlib Function Reference + https://ninenines.eu/docs/en/cowlib/2.11/manual/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowlib/2.11/manual/ + Name cowlib - Support library for manipulating Web protocols +Description Cowlib provides libraries for parsing and building messages for various Web protocols, including HTTP/1.1, HTTP/2 and Websocket. +It is optimized for completeness rather than speed. No value is ignored, they are all returned. +Modules cow_cookie(3) - Cookies Dependencies crypto - Crypto functions All these applications must be started before the cowlib application. To start Cowlib and all dependencies at once: + + Cowlib Function Reference https://ninenines.eu/docs/en/cowlib/2.8/manual/ @@ -8712,6 +9002,18 @@ It is optimized for completeness rather than speed. No value is ignored, they ar Modules cow_cookie(3) - Cookies Dependencies crypto - Crypto functions All these applications must be started before the cowlib application. To start Cowlib and all dependencies at once: + + cowlib(7) + https://ninenines.eu/docs/en/cowlib/2.11/manual/cowlib_app/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/cowlib/2.11/manual/cowlib_app/ + Name cowlib - Support library for manipulating Web protocols +Description Cowlib provides libraries for parsing and building messages for various Web protocols, including HTTP/1.1, HTTP/2 and Websocket. +It is optimized for completeness rather than speed. No value is ignored, they are all returned. +Modules cow_cookie(3) - Cookies Dependencies crypto - Crypto functions All these applications must be started before the cowlib application. To start Cowlib and all dependencies at once: + + cowlib(7) https://ninenines.eu/docs/en/cowlib/2.8/manual/cowlib_app/ @@ -10829,7 +11131,7 @@ Gun will now start processing the messages it received while waiting for the con https://ninenines.eu/docs/en/gun/2.0/manual/gun_up/ Name gun_up - The connection is up -Description {gun_up, ConnPid, Protocol} ConnPid :: pid() Protocol :: http | http2 | socks The connection is up. +Description {gun_up, ConnPid, Protocol} ConnPid :: pid() Protocol :: http | http2 | raw | socks The connection is up. This message informs the owner process that the connection or reconnection completed. If Gun is configured to connect to a Socks server, then the connection is not usable yet. One or more gun_tunnel_up(3) messages will follow. Otherwise, Gun will start processing the messages it received while waiting for the connection to be up. @@ -10959,17 +11261,6 @@ This message informs the relevant process that the server sent the enclosed fram This message can only be sent on streams that were upgraded to the Websocket protocol. - - HTTP status codes(7) - https://ninenines.eu/docs/en/cowboy/2.3/manual/http_status_codes/ - Mon, 01 Jan 0001 00:00:00 +0000 - - https://ninenines.eu/docs/en/cowboy/2.3/manual/http_status_codes/ - 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. - - HTTP status codes(7) https://ninenines.eu/docs/en/cowboy/2.4/manual/http_status_codes/ @@ -11026,12 +11317,14 @@ Description This chapter aims to list all HTTP status codes that Cowboy may retu - Ranch Function Reference - https://ninenines.eu/docs/en/ranch/1.4/manual/ + HTTP status codes(7) + https://ninenines.eu/docs/en/cowboy/2.9/manual/http_status_codes/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/manual/ - ranch(7) ranch(3) ranch_protocol(3) ranch_ssl(3) ranch_tcp(3) ranch_transport(3) + https://ninenines.eu/docs/en/cowboy/2.9/manual/http_status_codes/ + 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. @@ -11073,10 +11366,10 @@ ranch_ssl(3) - SSL transport ranch_tcp(3) - TCP transport Behaviors: Ranch Function Reference - https://ninenines.eu/docs/en/ranch/2.0/manual/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/2.0/manual/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ Name ranch - Socket acceptor pool for TCP protocols Description Ranch is a socket acceptor pool for TCP protocols. Ranch manages listeners which are a set of processes that accept and manage connections. The connection&apos;s transport and protocol modules are configured per listener. Listeners can be inspected and reconfigured without interruptions in service. @@ -11086,12 +11379,17 @@ ranch_ssl(3) - SSL transport ranch_tcp(3) - TCP transport Behaviors: - Ranch User Guide - https://ninenines.eu/docs/en/ranch/1.4/guide/ + Ranch Function Reference + https://ninenines.eu/docs/en/ranch/2.0/manual/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/guide/ - Introduction Listeners Transports Protocols Embedded mode Writing parsers SSL client authentication Internals + https://ninenines.eu/docs/en/ranch/2.0/manual/ + Name ranch - Socket acceptor pool for TCP protocols +Description Ranch is a socket acceptor pool for TCP protocols. +Ranch manages listeners which are a set of processes that accept and manage connections. The connection&apos;s transport and protocol modules are configured per listener. Listeners can be inspected and reconfigured without interruptions in service. +Modules Functions: +ranch(3) - Socket acceptor pool ranch_proxy_header(3) - PROXY protocol Transports: +ranch_ssl(3) - SSL transport ranch_tcp(3) - TCP transport Behaviors: @@ -11123,24 +11421,20 @@ ranch_ssl(3) - SSL transport ranch_tcp(3) - TCP transport Behaviors: Ranch User Guide - https://ninenines.eu/docs/en/ranch/2.0/guide/ + https://ninenines.eu/docs/en/ranch/1.8/guide/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/2.0/guide/ - Interface Introduction Listeners Transports Protocols Embedded mode How to Writing parsers SSL client authentication Connection draining Advanced Internals Additional information Migrating from Ranch 1.7 to 2.0 Migrating from Ranch 1.6 to 1.7 Migrating from Ranch 1.5 to 1.6 Migrating from Ranch 1.x + https://ninenines.eu/docs/en/ranch/1.8/guide/ + Interface Introduction Listeners Transports Protocols Embedded mode How to Writing parsers SSL client authentication Advanced Internals Additional information Upcoming changes in Ranch 2.0 Migrating from Ranch 1.7 to 1.8 Migrating from Ranch 1.6 to 1.7 Migrating from Ranch 1.5 to 1.6 Migrating from Ranch 1.x - ranch(3) - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch/ + Ranch User Guide + https://ninenines.eu/docs/en/ranch/2.0/guide/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch/ - Name ranch - socket acceptor pool -Description The ranch module provides functions for starting and manipulating Ranch listeners. -Types max_conns() = non_neg_integer() | infinity Maximum number of connections allowed on this listener. -This is a soft limit. The actual number of connections might be slightly above the limit due to concurrency when accepting new connections. Some connections may also be removed from this count explicitly by the user code. -opt() opt() = {ack_timeout, timeout()} | {connection_type, worker | supervisor} | {max_connections, max_conns()} | {num_acceptors, pos_integer()} | {shutdown, timeout() | brutal_kill} | {socket, any()} Ranch-specific transport options. + https://ninenines.eu/docs/en/ranch/2.0/guide/ + Interface Introduction Listeners Transports Protocols Embedded mode How to Writing parsers SSL client authentication Connection draining Advanced Internals Additional information Migrating from Ranch 1.7 to 2.0 Migrating from Ranch 1.6 to 1.7 Migrating from Ranch 1.5 to 1.6 Migrating from Ranch 1.x @@ -11186,29 +11480,30 @@ ranch:accept_ack(3) - Deprecated in favor of ranch:handshake(3) ranch:handshake ranch(3) - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch/ Name ranch - Socket acceptor pool Description The module ranch provides functions for starting and manipulating Ranch listeners. Exports Start/stop: ranch:start_listener(3) - Start a listener ranch:stop_listener(3) - Stop a listener ranch:child_spec(3) - Build child specifications for a new listener Suspend/resume: ranch:suspend_listener(3) - Suspend a running listener ranch:resume_listener(3) - Resume a suspended listener ranch:get_status(3) - Get a listener&apos;s running state Connections: -ranch:handshake(3) - Perform the transport handshake ranch:handshake_continue(3) - Resume the paused transport handshake ranch:handshake_cancel(3) - Cancel the paused transport handshake ranch:recv_proxy_header(3) - Receive the PROXY protocol header ranch:remove_connection(3) - Remove connection from the count Options: +ranch:accept_ack(3) - Deprecated in favor of ranch:handshake(3) ranch:handshake(3) - Perform the transport handshake ranch:recv_proxy_header(3) - Receive the PROXY protocol header ranch:remove_connection(3) - Remove connection from the count Options: - ranch(7) - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_app/ + ranch(3) + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_app/ - Name ranch - Socket acceptor pool for TCP protocols. -Dependencies The ranch application depends on the ssl application to start. It is used for handling secure connections, when the transport is ranch_ssl. It can be disabled if SSL is not used. -Environment The ranch application defines one application environment configuration parameter. -profile (false) When enabled, Ranch will start eprof profiling automatically. - You can use the ranch_app:profile_output/0 function to stop profiling and output the results to the files procs. + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch/ + Name ranch - Socket acceptor pool +Description The module ranch provides functions for starting and manipulating Ranch listeners. +Exports Start/stop: +ranch:start_listener(3) - Start a listener ranch:stop_listener(3) - Stop a listener ranch:child_spec(3) - Build child specifications for a new listener Suspend/resume: +ranch:suspend_listener(3) - Suspend a running listener ranch:resume_listener(3) - Resume a suspended listener ranch:get_status(3) - Get a listener&apos;s running state Connections: +ranch:handshake(3) - Perform the transport handshake ranch:handshake_continue(3) - Resume the paused transport handshake ranch:handshake_cancel(3) - Cancel the paused transport handshake ranch:recv_proxy_header(3) - Receive the PROXY protocol header ranch:remove_connection(3) - Remove connection from the count Options: @@ -11252,6 +11547,20 @@ ranch(3) - Socket acceptor pool ranch_proxy_header(3) - PROXY protocol Transp ranch_ssl(3) - SSL transport ranch_tcp(3) - TCP transport Behaviors: + + ranch(7) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_app/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_app/ + Name ranch - Socket acceptor pool for TCP protocols +Description Ranch is a socket acceptor pool for TCP protocols. +Ranch manages listeners which are a set of processes that accept and manage connections. The connection&apos;s transport and protocol modules are configured per listener. Listeners can be inspected and reconfigured without interruptions in service. +Modules Functions: +ranch(3) - Socket acceptor pool ranch_proxy_header(3) - PROXY protocol Transports: +ranch_ssl(3) - SSL transport ranch_tcp(3) - TCP transport Behaviors: + + ranch(7) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_app/ @@ -11290,6 +11599,18 @@ This function can be used to embed a listener directly in an application&apo Arguments Ref The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the configuration. + + ranch:child_spec(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.child_spec/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.child_spec/ + Name ranch:child_spec - Build child specifications for a new listener +Description child_spec(Ref :: ranch_ref(), Transport :: module(), TransOpts :: ranch:opts(), Protocol :: module(), ProtoOpts :: any()) -&gt; supervisor:child_spec() Build child specifications for a new listener. +This function can be used to embed a listener directly in an application&apos;s supervision tree. +Arguments Ref The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the configuration. + + ranch:child_spec(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.child_spec/ @@ -11332,10 +11653,24 @@ Examples Get the listening port and IP {IP, Port} = ranch:get_addr(example). ranch:get_addr(3) - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.get_addr/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_addr/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.get_addr/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_addr/ + Name ranch:get_addr - Get the listening port and IP +Description get_addr(Ref :: ranch:ref()) -&gt; {IP :: inet:ip_address(), Port :: inet:port_number()} Get the listening port and IP. +Arguments Ref The listener name. + Return value The address of the listener is returned as a tuple. +The IP address is the IP of the network interface the socket is bound to. +Examples Get the listening port and IP {IP, Port} = ranch:get_addr(example). + + + + ranch:get_addr(3) + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.get_addr/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.get_addr/ Name ranch:get_addr - Get the listening address Description get_addr(Ref :: ranch:ref()) -&gt; {IP :: inet:ip_address(), Port :: inet:port_number()} | {local, SocketFile :: binary()} | {undefined, undefined} Get the listening address. Arguments Ref The listener name. @@ -11368,6 +11703,19 @@ Arguments Ref The listener name. Examples Get the max number of connections MaxConns = ranch:get_max_connections(example). See also ranch:get_protocol_options(3), ranch:get_transport_options(3), ranch:set_max_connections(3), ranch(3) + + ranch:get_max_connections(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_max_connections/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_max_connections/ + Name ranch:get_max_connections - Get the max number of connections +Description get_max_connections(Ref :: ranch:ref()) -&gt; MaxConns :: ranch:max_conns() Get the max number of connections. +Arguments Ref The listener name. + Return value The maximum number of connections is returned. +Examples Get the max number of connections MaxConns = ranch:get_max_connections(example). See also ranch:get_protocol_options(3), ranch:get_transport_options(3), ranch:set_max_connections(3), ranch(3) + + ranch:get_max_connections(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.get_max_connections/ @@ -11409,6 +11757,20 @@ Arguments Ref The listener name. Examples Get the listening port Port = ranch:get_port(example). See also ranch:start_listener(3), ranch:get_addr(3), ranch:info(3), ranch(3) + + ranch:get_port(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_port/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_port/ + Name ranch:get_port - Get the listening port +Description get_port(Ref :: ranch:ref()) -&gt; Port :: inet:port_number() Get the listening port. +This function is particularly useful to retrieve the listening port number when it was not provided in the options and was chosen randomly instead. +Arguments Ref The listener name. + Return value The listening port is returned. +Examples Get the listening port Port = ranch:get_port(example). See also ranch:start_listener(3), ranch:get_addr(3), ranch:info(3), ranch(3) + + ranch:get_port(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.get_port/ @@ -11449,6 +11811,19 @@ Arguments Ref The listener name. Examples Get the current protocol options ProtoOpts = ranch:get_protocol_options(example). See also ranch:get_max_connections(3), ranch:get_transport_options(3), ranch:set_protocol_options(3), ranch(3) + + ranch:get_protocol_options(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_protocol_options/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_protocol_options/ + Name ranch:get_protocol_options - Get the current protocol options +Description get_protocol_options(Ref :: ranch:ref()) -&gt; ProtoOpts :: any() Get the current protocol options. +Arguments Ref The listener name. + Return value The current protocol options are returned. +Examples Get the current protocol options ProtoOpts = ranch:get_protocol_options(example). See also ranch:get_max_connections(3), ranch:get_transport_options(3), ranch:set_protocol_options(3), ranch(3) + + ranch:get_protocol_options(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.get_protocol_options/ @@ -11488,6 +11863,19 @@ Arguments Ref The listener name. Changelog 1.6: Function introduced. Examples Get a listener&apos;s running state ranch:get_status(example). See also ranch:start_listener(3), ranch:stop_listener(3), ranch:suspend_listener(3), ranch:resume_listener(3), ranch:set_transport_options(3), ranch:wait_for_connections(3), ranch(3) + + ranch:get_status(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_status/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_status/ + Name ranch:get_status - Get a listener&apos;s running state +Description get_status(Ref :: ranch_ref()) -&gt; running | suspended Get a listener&apos;s running state. +Arguments Ref The listener name. + Return value An atom is returned indicating the running status of the listener. +Changelog 1.6: Function introduced. Examples Get a listener&apos;s running state ranch:get_status(example). See also ranch:start_listener(3), ranch:stop_listener(3), ranch:suspend_listener(3), ranch:resume_listener(3), ranch:set_transport_options(3), ranch:wait_for_connections(3), ranch(3) + + ranch:get_status(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.get_status/ @@ -11527,6 +11915,19 @@ Arguments Ref The listener name. Examples Get the current transport options TransOpts = ranch:get_transport_options(example). See also ranch:get_max_connections(3), ranch:get_protocol_options(3), ranch:set_transport_options(3), ranch(3) + + ranch:get_transport_options(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_transport_options/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.get_transport_options/ + Name ranch:get_transport_options - Get the current transport options +Description get_transport_options(Ref :: ranch:ref()) -&gt; TransOpts :: any() Get the current transport options. +Arguments Ref The listener name. + Return value The current transport options are returned. +Examples Get the current transport options TransOpts = ranch:get_transport_options(example). See also ranch:get_max_connections(3), ranch:get_protocol_options(3), ranch:set_transport_options(3), ranch(3) + + ranch:get_transport_options(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.get_transport_options/ @@ -11562,6 +11963,17 @@ Description handshake(Ref) -&gt; handshake(Ref, []) handshake(Ref, Opts) -&a This function must be called by the protocol process in order to retrieve the socket for the connection. Ranch performs the handshake necessary to give control of the socket to this process and also does the transport handshake, for example setting up the TLS connection. + + ranch:handshake(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.handshake/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.handshake/ + Name ranch:handshake - Perform the transport handshake +Description handshake(Ref) -&gt; handshake(Ref, []) handshake(Ref, Opts) -&gt; {ok, Socket} Ref :: ranch:ref() Opts :: any() Socket :: any() Perform the transport handshake. +This function must be called by the protocol process in order to retrieve the socket for the connection. Ranch performs the handshake necessary to give control of the socket to this process and also does the transport handshake, for example setting up the TLS connection. + + ranch:handshake(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.handshake/ @@ -11633,6 +12045,21 @@ pid Pid of the listener&apos;s top-level supervisor. ip Interface Ranch listens on. + + ranch:info(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.info/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.info/ + Name ranch:info - Overview of Ranch listeners +Description info() -&gt; [{Ref, Info}] info(Ref) -&gt; Info Info :: [{Key :: atom(), Value :: any()}] Overview of Ranch listeners. +Arguments Ref The listener name. + Return value Returns detailed information about one or all Ranch listeners. The following keys are returned: +pid Pid of the listener&apos;s top-level supervisor. + status Listener status, either running or suspended. + ip Interface Ranch listens on. + + ranch:info(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.info/ @@ -11676,6 +12103,20 @@ Arguments Ref The listener name. Examples Get the pids of the acceptor processes Pids = ranch:procs(acceptors). Get the pids of the connection processes Pids = ranch:procs(connections). + + ranch:procs(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.procs/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.procs/ + Name ranch:procs - Retrieve pids from a listener +Description procs(Ref :: ranch:ref(), Type :: acceptors | connections) -&gt; Pids :: [pid()] Retrieve pids from a listener. +Arguments Ref The listener name. + Type The type of process that will be returned. + Return value A list of pids is returned. +Examples Get the pids of the acceptor processes Pids = ranch:procs(acceptors). Get the pids of the connection processes Pids = ranch:procs(connections). + + ranch:procs(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.procs/ @@ -11704,6 +12145,20 @@ Arguments Ref The listener name. Return value An ok tuple is returned containing PROXY header information on success. + + ranch:recv_proxy_header(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.recv_proxy_header/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.recv_proxy_header/ + Name ranch:recv_proxy_header - Receive the PROXY protocol header +Description recv_proxy_header(ranch:ref(), timeout()) -&gt; {ok, ranch_proxy_header:proxy_info()} | {error, Reason :: atom()} | {error, protocol_error, HumanReadable :: atom()} Receive the PROXY protocol header. +This function must be called before ranch:handshake/1,2 on newly accepted connections to read and parse the PROXY protocol header, if any. +Arguments Ref The listener name. + Timeout Receive timeout in milliseconds. + Return value An ok tuple is returned containing PROXY header information on success. + + ranch:recv_proxy_header(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.recv_proxy_header/ @@ -11742,6 +12197,18 @@ This connection will no longer be included in the count when limiting the number This function may only be called from a connection process. + + ranch:remove_connection(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.remove_connection/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.remove_connection/ + Name ranch:remove_connection - Remove connection from the count +Description remove_connection(Ref :: ranch:ref()) -&gt; ok Remove connection from the count. +This connection will no longer be included in the count when limiting the number of connections. This can be useful in a mixed environment where some connections are active and others are passive. Passive connections spend most of their time idling and are not consuming much resources. +This function may only be called from a connection process. + + ranch:remove_connection(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.remove_connection/ @@ -11782,6 +12249,20 @@ Arguments Ref The listener name. Return value The atom ok is returned on success. + + ranch:resume_listener(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.resume_listener/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.resume_listener/ + Name ranch:resume_listener - Resume a suspended listener +Description resume_listener(Ref :: ranch_ref()) -&gt; ok | {error, any()} Resume a suspended listener. +Ranch will start listening for and accepting connections again. The function ranch:set_transport_options(3) can be used to change the transport options before resuming the listener. +Nothing is done when the listener is already running. +Arguments Ref The listener name. + Return value The atom ok is returned on success. + + ranch:resume_listener(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.resume_listener/ @@ -11820,6 +12301,18 @@ The change will be applied immediately. If the new value is smaller than the pre Arguments Ref The listener name. + + ranch:set_max_connections(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.set_max_connections/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.set_max_connections/ + Name ranch:set_max_connections - Set the max number of connections +Description set_max_connections(Ref :: ranch:ref(), MaxConns :: ranch:max_conns()) -&gt; ok Set the max number of connections. +The change will be applied immediately. If the new value is smaller than the previous one, Ranch will wait for the extra connections to terminate and will not accept new connections until the number of connections goes below the limit. +Arguments Ref The listener name. + + ranch:set_max_connections(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.set_max_connections/ @@ -11861,6 +12354,21 @@ Arguments Ref The listener name. Examples Set the protocol options ranch:set_protocol_options(example, ProtoOpts). + + ranch:set_protocol_options(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.set_protocol_options/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.set_protocol_options/ + Name ranch:set_protocol_options - Set the protocol options +Description set_protocol_options(Ref :: ranch:ref(), ProtoOpts :: any()) -&gt; ok Set the protocol options. +The change will be applied immediately for all new connections. Old connections will not receive the new options. +Arguments Ref The listener name. + ProtoOpts The new protocol options. + Return value The atom ok is always returned. It can be safely ignored. +Examples Set the protocol options ranch:set_protocol_options(example, ProtoOpts). + + ranch:set_protocol_options(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.set_protocol_options/ @@ -11906,6 +12414,21 @@ Arguments Ref The listener name. Return value The atom ok is always returned. + + ranch:set_transport_options(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.set_transport_options/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.set_transport_options/ + Name ranch:set_transport_options - Set the transport options +Description set_transport_options(Ref :: ranch:ref(), TransOpts :: any()) -&gt; ok | {error, running} Set the transport options. +The listener must be suspended for this call to succeed. If the listener is running, {error, running} will be returned. +The change will take effect when the listener resumes. +Arguments Ref The listener name. + TransOpts The new transport options. + Return value The atom ok is always returned. + + ranch:set_transport_options(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.set_transport_options/ @@ -11942,6 +12465,18 @@ A listener is a set of processes that accepts and manages connections using the Arguments Ref The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the configuration. + + ranch:start_listener(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.start_listener/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.start_listener/ + Name ranch:start_listener - Start a listener +Description start_listener(Ref :: ranch_ref(), Transport :: module(), TransOpts :: ranch:opts(), Protocol :: module(), ProtoOpts :: any()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start a listener. +A listener is a set of processes that accepts and manages connections using the given transport and protocol modules. +Arguments Ref The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the configuration. + + ranch:start_listener(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.start_listener/ @@ -11978,6 +12513,18 @@ The listener is stopped gracefully, first by closing the listening port, then by In order for the connection processes to exit gracefully, they need to trap exit signals and stop before the configured shutdown timeout. + + ranch:stop_listener(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.stop_listener/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.stop_listener/ + Name ranch:stop_listener - Stop a listener +Description stop_listener(Ref :: ranch_ref()) -&gt; ok | {error, not_found} Stop a listener. +The listener is stopped gracefully, first by closing the listening port, then by stopping the connection processes. These processes are stopped according to the shutdown transport option, which may be set to brutally kill all connection processes or give them some time to stop properly. +In order for the connection processes to exit gracefully, they need to trap exit signals and stop before the configured shutdown timeout. + + ranch:stop_listener(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.stop_listener/ @@ -12014,6 +12561,18 @@ Ranch will stop listening for and accepting connections and the listening socket Some transport options can only be changed when the listener is suspended. Please consult the ranch:set_transport_options(3) manual for more information. + + ranch:suspend_listener(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.suspend_listener/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.suspend_listener/ + Name ranch:suspend_listener - Suspend a running listener +Description suspend_listener(Ref :: ranch_ref()) -&gt; ok | {error, any()} Suspend a running listener. +Ranch will stop listening for and accepting connections and the listening socket will be closed. Existing connections will continue undisturbed. The function ranch:wait_for_connections(3) can be used to wait for connections to be closed if necessary. +Some transport options can only be changed when the listener is suspended. Please consult the ranch:set_transport_options(3) manual for more information. + + ranch:suspend_listener(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.suspend_listener/ @@ -12052,10 +12611,10 @@ This function can be used to gracefully shutdown a listener by first suspending ranch:wait_for_connections(3) - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.wait_for_connections/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.wait_for_connections/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.wait_for_connections/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch.wait_for_connections/ Name ranch:wait_for_connections - Wait for a specific number of connections Description wait_for_connections(Ref :: ranch:ref(), Operator, NumConns :: non_neg_integer()) -&gt; ok Operator :: '&gt;' | '&gt;=' | '==' | '=&lt;' | '&lt;' Wait for a specific number of connections. This function waits until the number of connections on the given listener becomes higher than, equal to or lower than the given number. It never returns otherwise. @@ -12063,19 +12622,15 @@ This function can be used to gracefully shutdown a listener by first suspending - ranch_protocol(3) - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_protocol/ + ranch:wait_for_connections(3) + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.wait_for_connections/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_protocol/ - Name ranch_protocol - behaviour for protocol modules -Description The ranch_protocol behaviour defines the interface used by Ranch protocols. -Types None. -Callbacks start_link(Ref, Socket, Transport, ProtoOpts) -&gt; {ok, pid()} | {ok, pid(), pid()} Ref = ranch:ref() Listener name. - Socket = any() Socket for this connection. - Transport = module() Transport module for this socket. - ProtoOpts = any() Protocol options. - Start a new connection process for the given socket. + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch.wait_for_connections/ + Name ranch:wait_for_connections - Wait for a specific number of connections +Description wait_for_connections(Ref :: ranch:ref(), Operator, NumConns :: non_neg_integer()) -&gt; ok Operator :: '&gt;' | '&gt;=' | '==' | '=&lt;' | '&lt;' Wait for a specific number of connections. +This function waits until the number of connections on the given listener becomes higher than, equal to or lower than the given number. It never returns otherwise. +This function can be used to gracefully shutdown a listener by first suspending the listener and then waiting for connections to terminate before finally stopping the listener. @@ -12120,6 +12675,19 @@ start_link(Ref :: ranch:ref(), _, Transport :: module(), ProtoOpts :: any()) -&a The only purpose of this callback is to start a process that will handle the socket. It must spawn the process, link and then return the new pid. + + ranch_protocol(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_protocol/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_protocol/ + Name ranch_protocol - Protocol modules +Description The module ranch_protocol defines the interface used by Ranch protocols. +Callbacks Ranch protocols implement the following interface: +start_link(Ref :: ranch:ref(), _, Transport :: module(), ProtoOpts :: any()) -&gt; {ok, ConnPid :: pid()} | {ok, SupPid :: pid(), ConnPid :: pid()} Start a new connection process. +The only purpose of this callback is to start a process that will handle the socket. It must spawn the process, link and then return the new pid. + + ranch_protocol(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_protocol/ @@ -12144,6 +12712,17 @@ Description The module ranch_proxy_header provides functions for parsing and bui Exports ranch_proxy_header:parse(3) - Parse a PROXY protocol header ranch_proxy_header:header(3) - Build a PROXY protocol header Types proxy_info() proxy_info() = #{ %% Mandatory part. version := 1 | 2, command := local | proxy, transport_family =&gt; undefined | ipv4 | ipv6 | unix, transport_protocol =&gt; undefined | stream | dgram, %% Addresses. + + ranch_proxy_header(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_proxy_header/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_proxy_header/ + Name ranch_proxy_header - PROXY protocol +Description The module ranch_proxy_header provides functions for parsing and building the PROXY protocol header. +Exports ranch_proxy_header:parse(3) - Parse a PROXY protocol header ranch_proxy_header:header(3) - Build a PROXY protocol header Types proxy_info() proxy_info() = #{ %% Mandatory part. version := 1 | 2, command := local | proxy, transport_family =&gt; undefined | ipv4 | ipv6 | unix, transport_protocol =&gt; undefined | stream | dgram, %% Addresses. + + ranch_proxy_header(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_proxy_header/ @@ -12168,6 +12747,19 @@ Arguments ProxyInfo The proxy information to encode. Return value The PROXY protocol header is returned. + + ranch_proxy_header:header(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_proxy_header.header/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_proxy_header.header/ + Name ranch_proxy_header:header - Build a PROXY protocol header +Description header(ProxyInfo) -&gt; header(ProxyInfo, #{}) header(ProxyInfo, BuildOpts) -&gt; iodata() ProxyInfo :: ranch_proxy_header:proxy_info() BuildOpts :: #{ checksum =&gt; crc32c, padding =&gt; pos_integer() %% &gt;= 3 } Build a PROXY protocol header. +Arguments ProxyInfo The proxy information to encode. + BuildOpts Options to control whether to add a checksum or padding should be included in the encoded PROXY protocol header. + Return value The PROXY protocol header is returned. + + ranch_proxy_header:header(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_proxy_header.header/ @@ -12196,10 +12788,10 @@ An error tuple is returned when a protocol error is detected. ranch_proxy_header:parse(3) - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_proxy_header.parse/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_proxy_header.parse/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_proxy_header.parse/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_proxy_header.parse/ Name ranch_proxy_header:parse - Parse a PROXY protocol header Description parse(Data :: binary()) -&gt; {ok, ranch_proxy_header:proxy_info(), Rest :: binary()} | {error, HumanReadable :: atom()} Parse a PROXY protocol header. Arguments Data The PROXY protocol header optionally followed by more data. @@ -12208,14 +12800,16 @@ An error tuple is returned when a protocol error is detected. - ranch_ssl(3) - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_ssl/ + ranch_proxy_header:parse(3) + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_proxy_header.parse/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_ssl/ - Name ranch_ssl - SSL transport module -Description The ranch_ssl module implements an SSL Ranch transport. -Types ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {beast_mitigation, one_n_minus_one | zero_n | disabled} | {cacertfile, string()} | {cacerts, [public_key:der_encoded()]} | {cert, public_key:der_encoded()} | {certfile, string()} | {ciphers, [ssl:erl_cipher_suite()] | string()} | {client_renegotiation, boolean()} | {crl_cache, {module(), {internal | any(), list()}}} | {crl_check, boolean() | peer | best_effort} | {depth, 0..255} | {dh, public_key:der_encoded()} | {dhfile, string()} | {fail_if_no_peer_cert, boolean()} | {hibernate_after, integer() | undefined} | {honor_cipher_order, boolean()} | {key, {'RSAPrivateKey' | 'DSAPrivateKey' | 'PrivateKeyInfo', public_key:der_encoded()}} | {keyfile, string()} | {log_alert, boolean()} | {next_protocols_advertised, [binary()]} | {padding_check, boolean()} | {partial_chain, fun(([public_key:der_encoded()]) -&gt; {trusted_ca, public_key:der_encoded()} | unknown_ca)} | {password, string()} | {psk_identity, string()} | {reuse_session, fun()} | {reuse_sessions, boolean()} | {secure_renegotiate, boolean()} | {signature_algs, [{atom(), atom()}]} | {sni_fun, fun()} | {sni_hosts, [{string(), ssl_opt()}]} | {user_lookup_fun, {fun(), any()}} | {v2_hello_compatible, boolean()} | {verify, ssl:verify_type()} | {verify_fun, {fun(), any()}} | {versions, [atom()]}. + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_proxy_header.parse/ + Name ranch_proxy_header:parse - Parse a PROXY protocol header +Description parse(Data :: binary()) -&gt; {ok, ranch_proxy_header:proxy_info(), Rest :: binary()} | {error, HumanReadable :: atom()} Parse a PROXY protocol header. +Arguments Data The PROXY protocol header optionally followed by more data. + Return value An ok tuple is returned on success, containing the proxy information found in the header and the rest of the data if more was provided. +An error tuple is returned when a protocol error is detected. @@ -12261,29 +12855,32 @@ ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {beast_mitigation ranch_ssl(3) - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_ssl/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_ssl/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_ssl/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_ssl/ Name ranch_ssl - SSL transport Description The module ranch_ssl implements an SSL Ranch transport. Exports The module ranch_ssl implements the interface defined by ranch_transport(3). Types opt() opt() :: ranch_tcp:opt() | ssl_opt() Listen options. The TCP options are defined in ranch_tcp(3). opts() opts() :: [opt()] List of listen options. -ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {anti_replay, '10k' | '100k' | {integer(), integer(), integer()}} | {beast_mitigation, one_n_minus_one | zero_n | disabled} | {cacertfile, file:filename()} | {cacerts, [public_key:der_encoded()]} | {cert, public_key:der_encoded()} | {certfile, file:filename()} | {ciphers, ssl:ciphers()} | {client_renegotiation, boolean()} | {crl_cache, [any()]} | {crl_check, boolean() | peer | best_effort} | {depth, integer()} | {dh, binary()} | {dhfile, file:filename()} | {eccs, [ssl:named_curve()]} | {fail_if_no_peer_cert, boolean()} | {handshake, hello | full} | {hibernate_after, timeout()} | {honor_cipher_order, boolean()} | {honor_ecc_order, boolean()} | {key, ssl:key()} | {key_update_at, pos_integer()} | {keyfile, file:filename()} | {log_alert, boolean()} | {log_level, logger:level()} | {max_handshake_size, integer()} | {middlebox_comp_mode, boolean()} | {next_protocols_advertised, [binary()]} | {padding_check, boolean()} | {partial_chain, fun()} | {password, string()} | {protocol, tls | dtls} | {psk_identity, string()} | {reuse_session, fun()} | {reuse_sessions, boolean()} | {secure_renegotiate, boolean()} | {session_tickets, disabled | stateful | stateless} | {signature_algs, [{ssl:hash(), ssl:sign_algo()}]} | {signature_algs_cert, [ssl:sign_scheme()]} | {sni_fun, fun()} | {sni_hosts, [{string(), ssl_opt()}]} | {supported_groups, [ssl:group()]} | {user_lookup_fun, {fun(), any()}} | {verify, verify_none | verify_peer} | {verify_fun, {fun(), any()}} | {versions, [ssl:protocol_version()]} SSL-specific listen options. +ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {beast_mitigation, one_n_minus_one | zero_n | disabled} | {cacertfile, string()} | {cacerts, [public_key:der_encoded()]} | {cert, public_key:der_encoded()} | {certfile, string()} | {ciphers, [ssl:erl_cipher_suite()] | string()} | {client_renegotiation, boolean()} | {crl_cache, {module(), {internal | any(), list()}}} | {crl_check, boolean() | peer | best_effort} | {depth, 0. - ranch_tcp(3) - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_tcp/ + ranch_ssl(3) + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_ssl/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_tcp/ - Name ranch_tcp - TCP transport module -Description The ranch_tcp module implements a TCP Ranch transport. -Note that due to bugs in OTP up to at least R16B02, it is recommended to disable async threads when using the sendfile function of this transport, as it can make the threads stuck indefinitely. -Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | {delay_send, boolean()} | {dontroute, boolean()} | {exit_on_close, boolean()} | {fd, non_neg_integer()} | {high_msgq_watermark, non_neg_integer()} | {high_watermark, non_neg_integer()} | inet | inet6 | {ip, inet:ip_address()} | {ipv6_v6only, boolean()} | {keepalive, boolean()} | {linger, {boolean(), non_neg_integer()}} | {low_msgq_watermark, non_neg_integer()} | {low_watermark, non_neg_integer()} | {nodelay, boolean()} | {port, inet:port_number()} | {priority, integer()} | {raw, non_neg_integer(), non_neg_integer(), binary()} | {recbuf, non_neg_integer()} | {send_timeout, timeout()} | {send_timeout_close, boolean()} | {sndbuf, non_neg_integer()} | {tos, integer()} Listen options. + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_ssl/ + Name ranch_ssl - SSL transport +Description The module ranch_ssl implements an SSL Ranch transport. +Exports The module ranch_ssl implements the interface defined by ranch_transport(3). +Types opt() opt() :: ranch_tcp:opt() | ssl_opt() Listen options. +The TCP options are defined in ranch_tcp(3). +opts() opts() :: [opt()] List of listen options. +ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {anti_replay, '10k' | '100k' | {integer(), integer(), integer()}} | {beast_mitigation, one_n_minus_one | zero_n | disabled} | {cacertfile, file:filename()} | {cacerts, [public_key:der_encoded()]} | {cert, public_key:der_encoded()} | {certfile, file:filename()} | {ciphers, ssl:ciphers()} | {client_renegotiation, boolean()} | {crl_cache, [any()]} | {crl_check, boolean() | peer | best_effort} | {depth, integer()} | {dh, binary()} | {dhfile, file:filename()} | {eccs, [ssl:named_curve()]} | {fail_if_no_peer_cert, boolean()} | {handshake, hello | full} | {hibernate_after, timeout()} | {honor_cipher_order, boolean()} | {honor_ecc_order, boolean()} | {key, ssl:key()} | {key_update_at, pos_integer()} | {keyfile, file:filename()} | {log_alert, boolean()} | {log_level, logger:level()} | {max_handshake_size, integer()} | {middlebox_comp_mode, boolean()} | {next_protocols_advertised, [binary()]} | {padding_check, boolean()} | {partial_chain, fun()} | {password, string()} | {protocol, tls | dtls} | {psk_identity, string()} | {reuse_session, fun()} | {reuse_sessions, boolean()} | {secure_renegotiate, boolean()} | {session_tickets, disabled | stateful | stateless} | {signature_algs, [{ssl:hash(), ssl:sign_algo()}]} | {signature_algs_cert, [ssl:sign_scheme()]} | {sni_fun, fun()} | {sni_hosts, [{string(), ssl_opt()}]} | {supported_groups, [ssl:group()]} | {user_lookup_fun, {fun(), any()}} | {verify, verify_none | verify_peer} | {verify_fun, {fun(), any()}} | {versions, [ssl:protocol_version()]} SSL-specific listen options. @@ -12326,30 +12923,28 @@ Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | ranch_tcp(3) - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_tcp/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_tcp/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_tcp/ + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_tcp/ Name ranch_tcp - TCP transport Description The module ranch_tcp implements a TCP Ranch transport. The function sendfile may not work correctly when used against files stored in a VirtualBox shared folder. Exports The module ranch_tcp implements the interface defined by ranch_transport(3). -Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | {delay_send, boolean()} | {dontroute, boolean()} | {exit_on_close, boolean()} | {fd, non_neg_integer()} | {high_msgq_watermark, non_neg_integer()} | {high_watermark, non_neg_integer()} | inet | inet6 | {ip, inet:ip_address() | inet:local_address()} | {ipv6_v6only, boolean()} | {keepalive, boolean()} | {linger, {boolean(), non_neg_integer()}} | {low_msgq_watermark, non_neg_integer()} | {low_watermark, non_neg_integer()} | {nodelay, boolean()} | {port, inet:port_number()} | {priority, integer()} | {raw, non_neg_integer(), non_neg_integer(), binary()} | {recbuf, non_neg_integer()} | {send_timeout, timeout()} | {send_timeout_close, boolean()} | {sndbuf, non_neg_integer()} | {tos, integer()} Listen options. +Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | {delay_send, boolean()} | {dontroute, boolean()} | {exit_on_close, boolean()} | {fd, non_neg_integer()} | {high_msgq_watermark, non_neg_integer()} | {high_watermark, non_neg_integer()} | inet | inet6 | {ip, inet:ip_address()} | {ipv6_v6only, boolean()} | {keepalive, boolean()} | {linger, {boolean(), non_neg_integer()}} | {low_msgq_watermark, non_neg_integer()} | {low_watermark, non_neg_integer()} | {nodelay, boolean()} | {port, inet:port_number()} | {priority, integer()} | {raw, non_neg_integer(), non_neg_integer(), binary()} | {recbuf, non_neg_integer()} | {send_timeout, timeout()} | {send_timeout_close, boolean()} | {sndbuf, non_neg_integer()} | {tos, integer()} Listen options. - ranch_transport(3) - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_transport/ + ranch_tcp(3) + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_tcp/ Mon, 01 Jan 0001 00:00:00 +0000 - https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_transport/ - Name ranch_transport - behaviour for transport modules -Description The ranch_transport behaviour defines the interface used by Ranch transports. -Types sendfile_opts() = [{chunk_size, non_neg_integer()}] Options used by the sendfile function and callbacks. -Allows configuring the chunk size, in bytes. Defaults to 8191 bytes. -Callbacks accept(LSocket, Timeout) -&gt; {ok, CSocket} | {error, closed | timeout | atom()} LSocket = CSocket = any() Listening socket. - Timeout = timeout() Accept timeout. - Accept a connection on the given listening socket. + https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_tcp/ + Name ranch_tcp - TCP transport +Description The module ranch_tcp implements a TCP Ranch transport. +The function sendfile may not work correctly when used against files stored in a VirtualBox shared folder. +Exports The module ranch_tcp implements the interface defined by ranch_transport(3). +Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | {delay_send, boolean()} | {dontroute, boolean()} | {exit_on_close, boolean()} | {fd, non_neg_integer()} | {high_msgq_watermark, non_neg_integer()} | {high_watermark, non_neg_integer()} | inet | inet6 | {ip, inet:ip_address() | inet:local_address()} | {ipv6_v6only, boolean()} | {keepalive, boolean()} | {linger, {boolean(), non_neg_integer()}} | {low_msgq_watermark, non_neg_integer()} | {low_watermark, non_neg_integer()} | {nodelay, boolean()} | {port, inet:port_number()} | {priority, integer()} | {raw, non_neg_integer(), non_neg_integer(), binary()} | {recbuf, non_neg_integer()} | {send_timeout, timeout()} | {send_timeout_close, boolean()} | {sndbuf, non_neg_integer()} | {tos, integer()} Listen options. @@ -12393,6 +12988,19 @@ accept accept(LSocket :: socket(), Timeout :: timeout()) -&gt; {ok, Socket : close close(Socket :: socket()) -&gt; ok Close the socket. + + ranch_transport(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_transport/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_transport/ + Name ranch_transport - Transport modules +Description The module ranch_transport defines the interface used by Ranch transports. +Callbacks Ranch transports implement the following interface: +accept accept(LSocket :: socket(), Timeout :: timeout()) -&gt; {ok, Socket :: socket()} | {error, closed | timeout | atom()} Use the listening socket returned by listen/1 to accept a new connection. The timeout is specified in milliseconds. +close close(Socket :: socket()) -&gt; ok Close the socket. + + ranch_transport(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_transport/ @@ -12430,6 +13038,18 @@ The file may be sent full or in parts, and may be specified by its filename or b This function emulates the function file:sendfile/2,4,5 and may be used when transports are not manipulating TCP directly. + + ranch_transport:sendfile(3) + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_transport.sendfile/ + Mon, 01 Jan 0001 00:00:00 +0000 + + https://ninenines.eu/docs/en/ranch/1.8/manual/ranch_transport.sendfile/ + Name ranch_transport:sendfile - Send a file on the socket +Description sendfile(Transport :: module(), Socket :: ranch_transport:socket(), File :: file:name_all() | file:fd(), Offset :: non_neg_integer(), Bytes :: non_neg_integer(), Opts :: ranch_transport:sendfile_opts()) -&gt; {ok, SentBytes :: non_neg_integer()} | {error, atom()} Send a file on the socket. +The file may be sent full or in parts, and may be specified by its filename or by an already open file descriptor. +This function emulates the function file:sendfile/2,4,5 and may be used when transports are not manipulating TCP directly. + + ranch_transport:sendfile(3) https://ninenines.eu/docs/en/ranch/2.0/manual/ranch_transport.sendfile/ -- cgit v1.2.3