From fec98300ec9af6c8b5f3120a60f217983c451076 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Wed, 2 May 2018 11:35:26 +0200 Subject: Cowboy 2.4.0 --- docs/en/cowboy/2.0/guide/constraints/index.html | 5 +- docs/en/cowboy/2.0/guide/cookies/index.html | 5 +- docs/en/cowboy/2.0/guide/erlang_web/index.html | 5 +- docs/en/cowboy/2.0/guide/flow_diagram/index.html | 5 +- .../en/cowboy/2.0/guide/getting_started/index.html | 5 +- docs/en/cowboy/2.0/guide/handlers/index.html | 5 +- docs/en/cowboy/2.0/guide/index.html | 5 +- docs/en/cowboy/2.0/guide/introduction/index.html | 5 +- docs/en/cowboy/2.0/guide/listeners/index.html | 5 +- docs/en/cowboy/2.0/guide/loop_handlers/index.html | 5 +- docs/en/cowboy/2.0/guide/middlewares/index.html | 5 +- .../cowboy/2.0/guide/migrating_from_1.0/index.html | 5 +- docs/en/cowboy/2.0/guide/modern_web/index.html | 5 +- docs/en/cowboy/2.0/guide/multipart/index.html | 5 +- docs/en/cowboy/2.0/guide/req/index.html | 5 +- docs/en/cowboy/2.0/guide/req_body/index.html | 5 +- .../en/cowboy/2.0/guide/resource_design/index.html | 5 +- docs/en/cowboy/2.0/guide/resp/index.html | 5 +- .../en/cowboy/2.0/guide/rest_flowcharts/index.html | 5 +- docs/en/cowboy/2.0/guide/rest_handlers/index.html | 5 +- .../en/cowboy/2.0/guide/rest_principles/index.html | 5 +- docs/en/cowboy/2.0/guide/routing/index.html | 5 +- docs/en/cowboy/2.0/guide/specs/index.html | 5 +- docs/en/cowboy/2.0/guide/static_files/index.html | 5 +- docs/en/cowboy/2.0/guide/streams/index.html | 5 +- docs/en/cowboy/2.0/guide/ws_handlers/index.html | 5 +- docs/en/cowboy/2.0/guide/ws_protocol/index.html | 5 +- .../en/cowboy/2.0/manual/cowboy.set_env/index.html | 5 +- .../2.0/manual/cowboy.start_clear/index.html | 5 +- .../cowboy/2.0/manual/cowboy.start_tls/index.html | 5 +- .../2.0/manual/cowboy.stop_listener/index.html | 5 +- docs/en/cowboy/2.0/manual/cowboy/index.html | 5 +- docs/en/cowboy/2.0/manual/cowboy_app/index.html | 5 +- .../2.0/manual/cowboy_constraints.int/index.html | 5 +- .../manual/cowboy_constraints.nonempty/index.html | 5 +- .../2.0/manual/cowboy_constraints/index.html | 5 +- .../2.0/manual/cowboy_handler.terminate/index.html | 5 +- .../en/cowboy/2.0/manual/cowboy_handler/index.html | 5 +- docs/en/cowboy/2.0/manual/cowboy_http/index.html | 5 +- docs/en/cowboy/2.0/manual/cowboy_http2/index.html | 5 +- docs/en/cowboy/2.0/manual/cowboy_loop/index.html | 5 +- .../cowboy/2.0/manual/cowboy_middleware/index.html | 5 +- .../2.0/manual/cowboy_req.binding/index.html | 5 +- .../2.0/manual/cowboy_req.bindings/index.html | 5 +- .../2.0/manual/cowboy_req.body_length/index.html | 5 +- .../cowboy_req.delete_resp_header/index.html | 5 +- .../2.0/manual/cowboy_req.has_body/index.html | 5 +- .../2.0/manual/cowboy_req.has_resp_body/index.html | 5 +- .../manual/cowboy_req.has_resp_header/index.html | 5 +- .../cowboy/2.0/manual/cowboy_req.header/index.html | 5 +- .../2.0/manual/cowboy_req.headers/index.html | 5 +- .../cowboy/2.0/manual/cowboy_req.host/index.html | 5 +- .../2.0/manual/cowboy_req.host_info/index.html | 5 +- .../2.0/manual/cowboy_req.match_cookies/index.html | 5 +- .../2.0/manual/cowboy_req.match_qs/index.html | 5 +- .../cowboy/2.0/manual/cowboy_req.method/index.html | 5 +- .../2.0/manual/cowboy_req.parse_cookies/index.html | 5 +- .../2.0/manual/cowboy_req.parse_header/index.html | 5 +- .../2.0/manual/cowboy_req.parse_qs/index.html | 5 +- .../cowboy/2.0/manual/cowboy_req.path/index.html | 5 +- .../2.0/manual/cowboy_req.path_info/index.html | 5 +- .../cowboy/2.0/manual/cowboy_req.peer/index.html | 5 +- .../cowboy/2.0/manual/cowboy_req.port/index.html | 5 +- .../cowboy/2.0/manual/cowboy_req.push/index.html | 5 +- docs/en/cowboy/2.0/manual/cowboy_req.qs/index.html | 5 +- .../2.0/manual/cowboy_req.read_body/index.html | 5 +- .../2.0/manual/cowboy_req.read_part/index.html | 5 +- .../manual/cowboy_req.read_part_body/index.html | 5 +- .../cowboy_req.read_urlencoded_body/index.html | 5 +- .../cowboy/2.0/manual/cowboy_req.reply/index.html | 5 +- .../2.0/manual/cowboy_req.resp_header/index.html | 5 +- .../2.0/manual/cowboy_req.resp_headers/index.html | 5 +- .../cowboy/2.0/manual/cowboy_req.scheme/index.html | 5 +- .../2.0/manual/cowboy_req.set_resp_body/index.html | 5 +- .../manual/cowboy_req.set_resp_cookie/index.html | 5 +- .../manual/cowboy_req.set_resp_header/index.html | 5 +- .../manual/cowboy_req.set_resp_headers/index.html | 5 +- .../2.0/manual/cowboy_req.stream_body/index.html | 5 +- .../2.0/manual/cowboy_req.stream_reply/index.html | 5 +- .../en/cowboy/2.0/manual/cowboy_req.uri/index.html | 5 +- .../2.0/manual/cowboy_req.version/index.html | 5 +- docs/en/cowboy/2.0/manual/cowboy_req/index.html | 5 +- docs/en/cowboy/2.0/manual/cowboy_rest/index.html | 5 +- .../2.0/manual/cowboy_router.compile/index.html | 5 +- docs/en/cowboy/2.0/manual/cowboy_router/index.html | 5 +- docs/en/cowboy/2.0/manual/cowboy_static/index.html | 5 +- docs/en/cowboy/2.0/manual/cowboy_stream/index.html | 5 +- .../cowboy/2.0/manual/cowboy_websocket/index.html | 5 +- .../cowboy/2.0/manual/http_status_codes/index.html | 5 +- docs/en/cowboy/2.0/manual/index.html | 5 +- docs/en/cowboy/2.1/guide/constraints/index.html | 5 +- docs/en/cowboy/2.1/guide/cookies/index.html | 5 +- docs/en/cowboy/2.1/guide/erlang_web/index.html | 5 +- docs/en/cowboy/2.1/guide/flow_diagram/index.html | 5 +- .../en/cowboy/2.1/guide/getting_started/index.html | 5 +- docs/en/cowboy/2.1/guide/handlers/index.html | 5 +- docs/en/cowboy/2.1/guide/index.html | 5 +- docs/en/cowboy/2.1/guide/introduction/index.html | 5 +- docs/en/cowboy/2.1/guide/listeners/index.html | 5 +- docs/en/cowboy/2.1/guide/loop_handlers/index.html | 5 +- docs/en/cowboy/2.1/guide/middlewares/index.html | 5 +- .../cowboy/2.1/guide/migrating_from_1.0/index.html | 5 +- .../cowboy/2.1/guide/migrating_from_2.0/index.html | 5 +- docs/en/cowboy/2.1/guide/modern_web/index.html | 5 +- docs/en/cowboy/2.1/guide/multipart/index.html | 5 +- docs/en/cowboy/2.1/guide/req/index.html | 5 +- docs/en/cowboy/2.1/guide/req_body/index.html | 5 +- .../en/cowboy/2.1/guide/resource_design/index.html | 5 +- docs/en/cowboy/2.1/guide/resp/index.html | 5 +- .../en/cowboy/2.1/guide/rest_flowcharts/index.html | 5 +- docs/en/cowboy/2.1/guide/rest_handlers/index.html | 5 +- .../en/cowboy/2.1/guide/rest_principles/index.html | 5 +- docs/en/cowboy/2.1/guide/routing/index.html | 5 +- docs/en/cowboy/2.1/guide/specs/index.html | 5 +- docs/en/cowboy/2.1/guide/static_files/index.html | 5 +- docs/en/cowboy/2.1/guide/streams/index.html | 5 +- docs/en/cowboy/2.1/guide/ws_handlers/index.html | 5 +- docs/en/cowboy/2.1/guide/ws_protocol/index.html | 5 +- .../en/cowboy/2.1/manual/cowboy.set_env/index.html | 5 +- .../2.1/manual/cowboy.start_clear/index.html | 5 +- .../cowboy/2.1/manual/cowboy.start_tls/index.html | 5 +- .../2.1/manual/cowboy.stop_listener/index.html | 5 +- docs/en/cowboy/2.1/manual/cowboy/index.html | 5 +- docs/en/cowboy/2.1/manual/cowboy_app/index.html | 5 +- .../2.1/manual/cowboy_constraints.int/index.html | 5 +- .../manual/cowboy_constraints.nonempty/index.html | 5 +- .../2.1/manual/cowboy_constraints/index.html | 5 +- .../2.1/manual/cowboy_handler.terminate/index.html | 5 +- .../en/cowboy/2.1/manual/cowboy_handler/index.html | 5 +- docs/en/cowboy/2.1/manual/cowboy_http/index.html | 5 +- docs/en/cowboy/2.1/manual/cowboy_http2/index.html | 5 +- docs/en/cowboy/2.1/manual/cowboy_loop/index.html | 5 +- .../cowboy/2.1/manual/cowboy_middleware/index.html | 5 +- .../2.1/manual/cowboy_req.binding/index.html | 5 +- .../2.1/manual/cowboy_req.bindings/index.html | 5 +- .../2.1/manual/cowboy_req.body_length/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.cert/index.html | 5 +- .../cowboy_req.delete_resp_header/index.html | 5 +- .../2.1/manual/cowboy_req.has_body/index.html | 5 +- .../2.1/manual/cowboy_req.has_resp_body/index.html | 5 +- .../manual/cowboy_req.has_resp_header/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.header/index.html | 5 +- .../2.1/manual/cowboy_req.headers/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.host/index.html | 5 +- .../2.1/manual/cowboy_req.host_info/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.inform/index.html | 5 +- .../2.1/manual/cowboy_req.match_cookies/index.html | 5 +- .../2.1/manual/cowboy_req.match_qs/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.method/index.html | 5 +- .../2.1/manual/cowboy_req.parse_cookies/index.html | 5 +- .../2.1/manual/cowboy_req.parse_header/index.html | 5 +- .../2.1/manual/cowboy_req.parse_qs/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.path/index.html | 5 +- .../2.1/manual/cowboy_req.path_info/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.peer/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.port/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.push/index.html | 5 +- docs/en/cowboy/2.1/manual/cowboy_req.qs/index.html | 5 +- .../2.1/manual/cowboy_req.read_body/index.html | 5 +- .../2.1/manual/cowboy_req.read_part/index.html | 5 +- .../manual/cowboy_req.read_part_body/index.html | 5 +- .../cowboy_req.read_urlencoded_body/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.reply/index.html | 5 +- .../2.1/manual/cowboy_req.resp_header/index.html | 5 +- .../2.1/manual/cowboy_req.resp_headers/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.scheme/index.html | 5 +- .../2.1/manual/cowboy_req.set_resp_body/index.html | 5 +- .../manual/cowboy_req.set_resp_cookie/index.html | 5 +- .../manual/cowboy_req.set_resp_header/index.html | 5 +- .../manual/cowboy_req.set_resp_headers/index.html | 5 +- .../cowboy/2.1/manual/cowboy_req.sock/index.html | 5 +- .../2.1/manual/cowboy_req.stream_body/index.html | 5 +- .../2.1/manual/cowboy_req.stream_reply/index.html | 5 +- .../en/cowboy/2.1/manual/cowboy_req.uri/index.html | 5 +- .../2.1/manual/cowboy_req.version/index.html | 5 +- docs/en/cowboy/2.1/manual/cowboy_req/index.html | 5 +- docs/en/cowboy/2.1/manual/cowboy_rest/index.html | 5 +- .../2.1/manual/cowboy_router.compile/index.html | 5 +- docs/en/cowboy/2.1/manual/cowboy_router/index.html | 5 +- docs/en/cowboy/2.1/manual/cowboy_static/index.html | 5 +- docs/en/cowboy/2.1/manual/cowboy_stream/index.html | 5 +- .../cowboy/2.1/manual/cowboy_websocket/index.html | 5 +- .../cowboy/2.1/manual/http_status_codes/index.html | 5 +- docs/en/cowboy/2.1/manual/index.html | 5 +- docs/en/cowboy/2.2/guide/constraints/index.html | 5 +- docs/en/cowboy/2.2/guide/cookies/index.html | 5 +- docs/en/cowboy/2.2/guide/erlang_web/index.html | 5 +- docs/en/cowboy/2.2/guide/flow_diagram/index.html | 5 +- .../en/cowboy/2.2/guide/getting_started/index.html | 5 +- docs/en/cowboy/2.2/guide/handlers/index.html | 5 +- docs/en/cowboy/2.2/guide/index.html | 5 +- docs/en/cowboy/2.2/guide/introduction/index.html | 5 +- docs/en/cowboy/2.2/guide/listeners/index.html | 5 +- docs/en/cowboy/2.2/guide/loop_handlers/index.html | 5 +- docs/en/cowboy/2.2/guide/middlewares/index.html | 5 +- .../cowboy/2.2/guide/migrating_from_1.0/index.html | 5 +- .../cowboy/2.2/guide/migrating_from_2.0/index.html | 5 +- .../cowboy/2.2/guide/migrating_from_2.1/index.html | 5 +- .../cowboy/2.2/guide/migrating_from_2.2/index.html | 5 +- docs/en/cowboy/2.2/guide/modern_web/index.html | 5 +- docs/en/cowboy/2.2/guide/multipart/index.html | 5 +- docs/en/cowboy/2.2/guide/req/index.html | 5 +- docs/en/cowboy/2.2/guide/req_body/index.html | 5 +- .../en/cowboy/2.2/guide/resource_design/index.html | 5 +- docs/en/cowboy/2.2/guide/resp/index.html | 5 +- .../en/cowboy/2.2/guide/rest_flowcharts/index.html | 5 +- docs/en/cowboy/2.2/guide/rest_handlers/index.html | 5 +- .../en/cowboy/2.2/guide/rest_principles/index.html | 5 +- docs/en/cowboy/2.2/guide/routing/index.html | 5 +- docs/en/cowboy/2.2/guide/specs/index.html | 5 +- docs/en/cowboy/2.2/guide/static_files/index.html | 5 +- docs/en/cowboy/2.2/guide/streams/index.html | 5 +- docs/en/cowboy/2.2/guide/ws_handlers/index.html | 5 +- docs/en/cowboy/2.2/guide/ws_protocol/index.html | 5 +- .../en/cowboy/2.2/manual/cowboy.set_env/index.html | 5 +- .../2.2/manual/cowboy.start_clear/index.html | 5 +- .../cowboy/2.2/manual/cowboy.start_tls/index.html | 5 +- .../2.2/manual/cowboy.stop_listener/index.html | 5 +- docs/en/cowboy/2.2/manual/cowboy/index.html | 5 +- docs/en/cowboy/2.2/manual/cowboy_app/index.html | 5 +- .../2.2/manual/cowboy_constraints.int/index.html | 5 +- .../manual/cowboy_constraints.nonempty/index.html | 5 +- .../2.2/manual/cowboy_constraints/index.html | 5 +- .../2.2/manual/cowboy_handler.terminate/index.html | 5 +- .../en/cowboy/2.2/manual/cowboy_handler/index.html | 5 +- docs/en/cowboy/2.2/manual/cowboy_http/index.html | 5 +- docs/en/cowboy/2.2/manual/cowboy_http2/index.html | 5 +- docs/en/cowboy/2.2/manual/cowboy_loop/index.html | 5 +- .../cowboy/2.2/manual/cowboy_middleware/index.html | 5 +- .../2.2/manual/cowboy_req.binding/index.html | 5 +- .../2.2/manual/cowboy_req.bindings/index.html | 5 +- .../2.2/manual/cowboy_req.body_length/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.cert/index.html | 5 +- .../cowboy_req.delete_resp_header/index.html | 5 +- .../2.2/manual/cowboy_req.has_body/index.html | 5 +- .../2.2/manual/cowboy_req.has_resp_body/index.html | 5 +- .../manual/cowboy_req.has_resp_header/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.header/index.html | 5 +- .../2.2/manual/cowboy_req.headers/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.host/index.html | 5 +- .../2.2/manual/cowboy_req.host_info/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.inform/index.html | 5 +- .../2.2/manual/cowboy_req.match_cookies/index.html | 5 +- .../2.2/manual/cowboy_req.match_qs/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.method/index.html | 5 +- .../2.2/manual/cowboy_req.parse_cookies/index.html | 5 +- .../2.2/manual/cowboy_req.parse_header/index.html | 5 +- .../2.2/manual/cowboy_req.parse_qs/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.path/index.html | 5 +- .../2.2/manual/cowboy_req.path_info/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.peer/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.port/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.push/index.html | 5 +- docs/en/cowboy/2.2/manual/cowboy_req.qs/index.html | 5 +- .../2.2/manual/cowboy_req.read_body/index.html | 5 +- .../2.2/manual/cowboy_req.read_part/index.html | 5 +- .../manual/cowboy_req.read_part_body/index.html | 5 +- .../cowboy_req.read_urlencoded_body/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.reply/index.html | 5 +- .../2.2/manual/cowboy_req.resp_header/index.html | 5 +- .../2.2/manual/cowboy_req.resp_headers/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.scheme/index.html | 5 +- .../2.2/manual/cowboy_req.set_resp_body/index.html | 5 +- .../manual/cowboy_req.set_resp_cookie/index.html | 5 +- .../manual/cowboy_req.set_resp_header/index.html | 5 +- .../manual/cowboy_req.set_resp_headers/index.html | 5 +- .../cowboy/2.2/manual/cowboy_req.sock/index.html | 5 +- .../2.2/manual/cowboy_req.stream_body/index.html | 5 +- .../2.2/manual/cowboy_req.stream_reply/index.html | 5 +- .../manual/cowboy_req.stream_trailers/index.html | 5 +- .../en/cowboy/2.2/manual/cowboy_req.uri/index.html | 5 +- .../2.2/manual/cowboy_req.version/index.html | 5 +- docs/en/cowboy/2.2/manual/cowboy_req/index.html | 5 +- docs/en/cowboy/2.2/manual/cowboy_rest/index.html | 5 +- .../2.2/manual/cowboy_router.compile/index.html | 5 +- docs/en/cowboy/2.2/manual/cowboy_router/index.html | 5 +- docs/en/cowboy/2.2/manual/cowboy_static/index.html | 5 +- docs/en/cowboy/2.2/manual/cowboy_stream/index.html | 5 +- .../cowboy/2.2/manual/cowboy_websocket/index.html | 5 +- .../cowboy/2.2/manual/http_status_codes/index.html | 5 +- docs/en/cowboy/2.2/manual/index.html | 5 +- docs/en/cowboy/2.3/guide/constraints/index.html | 5 +- docs/en/cowboy/2.3/guide/cookies/index.html | 5 +- docs/en/cowboy/2.3/guide/erlang_web/index.html | 5 +- docs/en/cowboy/2.3/guide/flow_diagram/index.html | 5 +- .../en/cowboy/2.3/guide/getting_started/index.html | 5 +- docs/en/cowboy/2.3/guide/handlers/index.html | 5 +- docs/en/cowboy/2.3/guide/index.html | 5 +- docs/en/cowboy/2.3/guide/introduction/index.html | 5 +- docs/en/cowboy/2.3/guide/listeners/index.html | 5 +- docs/en/cowboy/2.3/guide/loop_handlers/index.html | 5 +- docs/en/cowboy/2.3/guide/middlewares/index.html | 5 +- .../cowboy/2.3/guide/migrating_from_1.0/index.html | 5 +- .../cowboy/2.3/guide/migrating_from_2.0/index.html | 5 +- .../cowboy/2.3/guide/migrating_from_2.1/index.html | 5 +- .../cowboy/2.3/guide/migrating_from_2.2/index.html | 5 +- docs/en/cowboy/2.3/guide/modern_web/index.html | 5 +- docs/en/cowboy/2.3/guide/multipart/index.html | 5 +- docs/en/cowboy/2.3/guide/req/index.html | 5 +- docs/en/cowboy/2.3/guide/req_body/index.html | 5 +- .../en/cowboy/2.3/guide/resource_design/index.html | 5 +- docs/en/cowboy/2.3/guide/resp/index.html | 5 +- .../en/cowboy/2.3/guide/rest_flowcharts/index.html | 5 +- docs/en/cowboy/2.3/guide/rest_handlers/index.html | 5 +- .../en/cowboy/2.3/guide/rest_principles/index.html | 5 +- docs/en/cowboy/2.3/guide/routing/index.html | 5 +- docs/en/cowboy/2.3/guide/specs/index.html | 5 +- docs/en/cowboy/2.3/guide/static_files/index.html | 5 +- docs/en/cowboy/2.3/guide/streams/index.html | 5 +- docs/en/cowboy/2.3/guide/ws_handlers/index.html | 5 +- docs/en/cowboy/2.3/guide/ws_protocol/index.html | 5 +- .../en/cowboy/2.3/manual/cowboy.set_env/index.html | 5 +- .../2.3/manual/cowboy.start_clear/index.html | 5 +- .../cowboy/2.3/manual/cowboy.start_tls/index.html | 5 +- .../2.3/manual/cowboy.stop_listener/index.html | 5 +- docs/en/cowboy/2.3/manual/cowboy/index.html | 5 +- docs/en/cowboy/2.3/manual/cowboy_app/index.html | 5 +- .../2.3/manual/cowboy_constraints.int/index.html | 5 +- .../manual/cowboy_constraints.nonempty/index.html | 5 +- .../2.3/manual/cowboy_constraints/index.html | 5 +- .../2.3/manual/cowboy_handler.terminate/index.html | 5 +- .../en/cowboy/2.3/manual/cowboy_handler/index.html | 5 +- docs/en/cowboy/2.3/manual/cowboy_http/index.html | 5 +- docs/en/cowboy/2.3/manual/cowboy_http2/index.html | 29 +- docs/en/cowboy/2.3/manual/cowboy_loop/index.html | 5 +- .../cowboy/2.3/manual/cowboy_middleware/index.html | 5 +- .../2.3/manual/cowboy_req.binding/index.html | 5 +- .../2.3/manual/cowboy_req.bindings/index.html | 5 +- .../2.3/manual/cowboy_req.body_length/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.cert/index.html | 5 +- .../cowboy_req.delete_resp_header/index.html | 5 +- .../2.3/manual/cowboy_req.has_body/index.html | 5 +- .../2.3/manual/cowboy_req.has_resp_body/index.html | 5 +- .../manual/cowboy_req.has_resp_header/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.header/index.html | 5 +- .../2.3/manual/cowboy_req.headers/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.host/index.html | 5 +- .../2.3/manual/cowboy_req.host_info/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.inform/index.html | 5 +- .../2.3/manual/cowboy_req.match_cookies/index.html | 5 +- .../2.3/manual/cowboy_req.match_qs/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.method/index.html | 5 +- .../2.3/manual/cowboy_req.parse_cookies/index.html | 5 +- .../2.3/manual/cowboy_req.parse_header/index.html | 5 +- .../2.3/manual/cowboy_req.parse_qs/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.path/index.html | 5 +- .../2.3/manual/cowboy_req.path_info/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.peer/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.port/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.push/index.html | 5 +- docs/en/cowboy/2.3/manual/cowboy_req.qs/index.html | 5 +- .../2.3/manual/cowboy_req.read_body/index.html | 5 +- .../2.3/manual/cowboy_req.read_part/index.html | 5 +- .../manual/cowboy_req.read_part_body/index.html | 5 +- .../cowboy_req.read_urlencoded_body/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.reply/index.html | 5 +- .../2.3/manual/cowboy_req.resp_header/index.html | 5 +- .../2.3/manual/cowboy_req.resp_headers/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.scheme/index.html | 5 +- .../2.3/manual/cowboy_req.set_resp_body/index.html | 5 +- .../manual/cowboy_req.set_resp_cookie/index.html | 5 +- .../manual/cowboy_req.set_resp_header/index.html | 5 +- .../manual/cowboy_req.set_resp_headers/index.html | 5 +- .../cowboy/2.3/manual/cowboy_req.sock/index.html | 5 +- .../2.3/manual/cowboy_req.stream_body/index.html | 5 +- .../2.3/manual/cowboy_req.stream_reply/index.html | 5 +- .../manual/cowboy_req.stream_trailers/index.html | 5 +- .../en/cowboy/2.3/manual/cowboy_req.uri/index.html | 5 +- .../2.3/manual/cowboy_req.version/index.html | 5 +- docs/en/cowboy/2.3/manual/cowboy_req/index.html | 5 +- docs/en/cowboy/2.3/manual/cowboy_rest/index.html | 5 +- .../2.3/manual/cowboy_router.compile/index.html | 5 +- docs/en/cowboy/2.3/manual/cowboy_router/index.html | 5 +- docs/en/cowboy/2.3/manual/cowboy_static/index.html | 5 +- docs/en/cowboy/2.3/manual/cowboy_stream/index.html | 5 +- .../cowboy/2.3/manual/cowboy_websocket/index.html | 5 +- .../cowboy/2.3/manual/http_status_codes/index.html | 5 +- docs/en/cowboy/2.3/manual/index.html | 5 +- docs/en/cowboy/2.4/guide/constraints.asciidoc | 123 + docs/en/cowboy/2.4/guide/constraints/index.html | 301 +++ docs/en/cowboy/2.4/guide/cookies.asciidoc | 139 + docs/en/cowboy/2.4/guide/cookies/index.html | 304 +++ docs/en/cowboy/2.4/guide/cowboy.sty | 8 + docs/en/cowboy/2.4/guide/erlang_web.asciidoc | 209 ++ docs/en/cowboy/2.4/guide/erlang_web/index.html | 354 +++ docs/en/cowboy/2.4/guide/flow_diagram.asciidoc | 109 + docs/en/cowboy/2.4/guide/flow_diagram/index.html | 273 ++ docs/en/cowboy/2.4/guide/getting_started.asciidoc | 147 + .../en/cowboy/2.4/guide/getting_started/index.html | 321 +++ docs/en/cowboy/2.4/guide/handlers.asciidoc | 90 + docs/en/cowboy/2.4/guide/handlers/index.html | 251 ++ docs/en/cowboy/2.4/guide/http_req_resp.png | Bin 0 -> 20713 bytes docs/en/cowboy/2.4/guide/http_req_resp.svg | 543 ++++ docs/en/cowboy/2.4/guide/index.html | 357 +++ docs/en/cowboy/2.4/guide/introduction.asciidoc | 75 + docs/en/cowboy/2.4/guide/introduction/index.html | 239 ++ docs/en/cowboy/2.4/guide/listeners.asciidoc | 115 + docs/en/cowboy/2.4/guide/listeners/index.html | 269 ++ docs/en/cowboy/2.4/guide/loop_handlers.asciidoc | 128 + docs/en/cowboy/2.4/guide/loop_handlers/index.html | 291 ++ docs/en/cowboy/2.4/guide/middlewares.asciidoc | 69 + docs/en/cowboy/2.4/guide/middlewares/index.html | 252 ++ .../cowboy/2.4/guide/migrating_from_1.0.asciidoc | 214 ++ .../cowboy/2.4/guide/migrating_from_1.0/index.html | 548 ++++ .../cowboy/2.4/guide/migrating_from_2.0.asciidoc | 107 + .../cowboy/2.4/guide/migrating_from_2.0/index.html | 348 +++ .../cowboy/2.4/guide/migrating_from_2.1.asciidoc | 107 + .../cowboy/2.4/guide/migrating_from_2.1/index.html | 363 +++ .../cowboy/2.4/guide/migrating_from_2.2.asciidoc | 56 + .../cowboy/2.4/guide/migrating_from_2.2/index.html | 268 ++ .../cowboy/2.4/guide/migrating_from_2.3.asciidoc | 66 + .../cowboy/2.4/guide/migrating_from_2.3/index.html | 281 ++ docs/en/cowboy/2.4/guide/modern_web.asciidoc | 122 + docs/en/cowboy/2.4/guide/modern_web/index.html | 271 ++ docs/en/cowboy/2.4/guide/multipart.asciidoc | 169 ++ docs/en/cowboy/2.4/guide/multipart/index.html | 329 +++ docs/en/cowboy/2.4/guide/req.asciidoc | 364 +++ docs/en/cowboy/2.4/guide/req/index.html | 567 ++++ docs/en/cowboy/2.4/guide/req_body.asciidoc | 130 + docs/en/cowboy/2.4/guide/req_body/index.html | 304 +++ docs/en/cowboy/2.4/guide/resource_design.asciidoc | 220 ++ .../en/cowboy/2.4/guide/resource_design/index.html | 373 +++ docs/en/cowboy/2.4/guide/resp.asciidoc | 368 +++ docs/en/cowboy/2.4/guide/resp/index.html | 533 ++++ docs/en/cowboy/2.4/guide/rest_cond.png | Bin 0 -> 111628 bytes docs/en/cowboy/2.4/guide/rest_cond.svg | 1656 ++++++++++++ docs/en/cowboy/2.4/guide/rest_conneg.png | Bin 0 -> 78133 bytes docs/en/cowboy/2.4/guide/rest_conneg.svg | 1135 ++++++++ docs/en/cowboy/2.4/guide/rest_delete.png | Bin 0 -> 122185 bytes docs/en/cowboy/2.4/guide/rest_delete.svg | 1718 ++++++++++++ docs/en/cowboy/2.4/guide/rest_flowcharts.asciidoc | 248 ++ .../en/cowboy/2.4/guide/rest_flowcharts/index.html | 404 +++ docs/en/cowboy/2.4/guide/rest_get_head.png | Bin 0 -> 94321 bytes docs/en/cowboy/2.4/guide/rest_get_head.svg | 1523 +++++++++++ docs/en/cowboy/2.4/guide/rest_handlers.asciidoc | 138 + docs/en/cowboy/2.4/guide/rest_handlers/index.html | 447 +++ docs/en/cowboy/2.4/guide/rest_options.png | Bin 0 -> 8539 bytes docs/en/cowboy/2.4/guide/rest_options.svg | 387 +++ docs/en/cowboy/2.4/guide/rest_principles.asciidoc | 160 ++ .../en/cowboy/2.4/guide/rest_principles/index.html | 313 +++ docs/en/cowboy/2.4/guide/rest_put_post_patch.png | Bin 0 -> 206747 bytes docs/en/cowboy/2.4/guide/rest_put_post_patch.svg | 2856 ++++++++++++++++++++ docs/en/cowboy/2.4/guide/rest_start.png | Bin 0 -> 105640 bytes docs/en/cowboy/2.4/guide/rest_start.svg | 1356 ++++++++++ docs/en/cowboy/2.4/guide/routing.asciidoc | 222 ++ docs/en/cowboy/2.4/guide/routing/index.html | 421 +++ docs/en/cowboy/2.4/guide/specs.asciidoc | 193 ++ docs/en/cowboy/2.4/guide/specs/index.html | 1015 +++++++ docs/en/cowboy/2.4/guide/static_files.asciidoc | 163 ++ docs/en/cowboy/2.4/guide/static_files/index.html | 333 +++ docs/en/cowboy/2.4/guide/streams.asciidoc | 65 + docs/en/cowboy/2.4/guide/streams/index.html | 221 ++ docs/en/cowboy/2.4/guide/ws_handlers.asciidoc | 293 ++ docs/en/cowboy/2.4/guide/ws_handlers/index.html | 457 ++++ docs/en/cowboy/2.4/guide/ws_protocol.asciidoc | 69 + docs/en/cowboy/2.4/guide/ws_protocol/index.html | 230 ++ .../en/cowboy/2.4/manual/cowboy.set_env/index.html | 255 ++ .../2.4/manual/cowboy.start_clear/index.html | 286 ++ .../cowboy/2.4/manual/cowboy.start_tls/index.html | 291 ++ .../2.4/manual/cowboy.stop_listener/index.html | 225 ++ docs/en/cowboy/2.4/manual/cowboy/index.html | 267 ++ docs/en/cowboy/2.4/manual/cowboy_app/index.html | 309 +++ .../2.4/manual/cowboy_constraints.int/index.html | 230 ++ .../manual/cowboy_constraints.nonempty/index.html | 229 ++ .../2.4/manual/cowboy_constraints/index.html | 222 ++ .../2.4/manual/cowboy_handler.terminate/index.html | 247 ++ .../en/cowboy/2.4/manual/cowboy_handler/index.html | 234 ++ docs/en/cowboy/2.4/manual/cowboy_http/index.html | 393 +++ docs/en/cowboy/2.4/manual/cowboy_http2/index.html | 375 +++ docs/en/cowboy/2.4/manual/cowboy_loop/index.html | 258 ++ .../cowboy/2.4/manual/cowboy_middleware/index.html | 253 ++ .../2.4/manual/cowboy_req.binding/index.html | 254 ++ .../2.4/manual/cowboy_req.bindings/index.html | 224 ++ .../2.4/manual/cowboy_req.body_length/index.html | 227 ++ .../cowboy/2.4/manual/cowboy_req.cert/index.html | 242 ++ .../cowboy_req.delete_resp_header/index.html | 233 ++ .../2.4/manual/cowboy_req.has_body/index.html | 218 ++ .../2.4/manual/cowboy_req.has_resp_body/index.html | 220 ++ .../manual/cowboy_req.has_resp_header/index.html | 233 ++ .../cowboy/2.4/manual/cowboy_req.header/index.html | 260 ++ .../2.4/manual/cowboy_req.headers/index.html | 228 ++ .../cowboy/2.4/manual/cowboy_req.host/index.html | 229 ++ .../2.4/manual/cowboy_req.host_info/index.html | 225 ++ .../cowboy/2.4/manual/cowboy_req.inform/index.html | 263 ++ .../2.4/manual/cowboy_req.match_cookies/index.html | 261 ++ .../2.4/manual/cowboy_req.match_qs/index.html | 261 ++ .../cowboy/2.4/manual/cowboy_req.method/index.html | 238 ++ .../2.4/manual/cowboy_req.parse_cookies/index.html | 229 ++ .../2.4/manual/cowboy_req.parse_header/index.html | 421 +++ .../2.4/manual/cowboy_req.parse_qs/index.html | 255 ++ .../cowboy/2.4/manual/cowboy_req.path/index.html | 228 ++ .../2.4/manual/cowboy_req.path_info/index.html | 225 ++ .../cowboy/2.4/manual/cowboy_req.peer/index.html | 236 ++ .../cowboy/2.4/manual/cowboy_req.port/index.html | 228 ++ .../cowboy/2.4/manual/cowboy_req.push/index.html | 280 ++ docs/en/cowboy/2.4/manual/cowboy_req.qs/index.html | 227 ++ .../2.4/manual/cowboy_req.read_body/index.html | 281 ++ .../2.4/manual/cowboy_req.read_part/index.html | 300 ++ .../manual/cowboy_req.read_part_body/index.html | 268 ++ .../cowboy_req.read_urlencoded_body/index.html | 264 ++ .../cowboy/2.4/manual/cowboy_req.reply/index.html | 303 +++ .../2.4/manual/cowboy_req.resp_header/index.html | 251 ++ .../2.4/manual/cowboy_req.resp_headers/index.html | 217 ++ .../cowboy/2.4/manual/cowboy_req.scheme/index.html | 227 ++ .../2.4/manual/cowboy_req.set_resp_body/index.html | 276 ++ .../manual/cowboy_req.set_resp_cookie/index.html | 305 +++ .../manual/cowboy_req.set_resp_header/index.html | 259 ++ .../manual/cowboy_req.set_resp_headers/index.html | 247 ++ .../cowboy/2.4/manual/cowboy_req.sock/index.html | 224 ++ .../2.4/manual/cowboy_req.stream_body/index.html | 257 ++ .../2.4/manual/cowboy_req.stream_reply/index.html | 290 ++ .../manual/cowboy_req.stream_trailers/index.html | 245 ++ .../en/cowboy/2.4/manual/cowboy_req.uri/index.html | 315 +++ .../2.4/manual/cowboy_req.version/index.html | 226 ++ docs/en/cowboy/2.4/manual/cowboy_req/index.html | 552 ++++ docs/en/cowboy/2.4/manual/cowboy_rest/index.html | 808 ++++++ .../2.4/manual/cowboy_router.compile/index.html | 225 ++ docs/en/cowboy/2.4/manual/cowboy_router/index.html | 248 ++ docs/en/cowboy/2.4/manual/cowboy_static/index.html | 313 +++ docs/en/cowboy/2.4/manual/cowboy_stream/index.html | 590 ++++ .../cowboy/2.4/manual/cowboy_websocket/index.html | 446 +++ .../cowboy/2.4/manual/http_status_codes/index.html | 409 +++ docs/en/cowboy/2.4/manual/index.html | 309 +++ docs/en/erlang.mk/1/guide/app/index.html | 3 - docs/en/erlang.mk/1/guide/asciidoc/index.html | 3 - docs/en/erlang.mk/1/guide/ci/index.html | 3 - docs/en/erlang.mk/1/guide/common_test/index.html | 3 - docs/en/erlang.mk/1/guide/compat/index.html | 3 - docs/en/erlang.mk/1/guide/contributing/index.html | 3 - docs/en/erlang.mk/1/guide/coverage/index.html | 3 - docs/en/erlang.mk/1/guide/deps/index.html | 3 - docs/en/erlang.mk/1/guide/dialyzer/index.html | 3 - docs/en/erlang.mk/1/guide/edoc/index.html | 3 - docs/en/erlang.mk/1/guide/escripts/index.html | 3 - docs/en/erlang.mk/1/guide/eunit/index.html | 3 - .../erlang.mk/1/guide/external_plugins/index.html | 3 - .../1/guide/external_plugins_list/index.html | 3 - docs/en/erlang.mk/1/guide/getting_started.asciidoc | 2 +- .../erlang.mk/1/guide/getting_started/index.html | 5 +- docs/en/erlang.mk/1/guide/history/index.html | 3 - docs/en/erlang.mk/1/guide/index.html | 3 - docs/en/erlang.mk/1/guide/installation/index.html | 3 - docs/en/erlang.mk/1/guide/kerl/index.html | 3 - docs/en/erlang.mk/1/guide/limitations/index.html | 3 - docs/en/erlang.mk/1/guide/overview/index.html | 3 - docs/en/erlang.mk/1/guide/ports/index.html | 3 - docs/en/erlang.mk/1/guide/releases/index.html | 3 - docs/en/erlang.mk/1/guide/sfx/index.html | 3 - docs/en/erlang.mk/1/guide/shell/index.html | 3 - docs/en/erlang.mk/1/guide/sphinx/index.html | 3 - docs/en/erlang.mk/1/guide/updating/index.html | 3 - docs/en/erlang.mk/1/guide/why/index.html | 3 - docs/en/erlang.mk/1/guide/xref/index.html | 3 - docs/en/gun/1.0/guide/connect/index.html | 3 - docs/en/gun/1.0/guide/http/index.html | 3 - docs/en/gun/1.0/guide/index.html | 3 - docs/en/gun/1.0/guide/introduction/index.html | 3 - docs/en/gun/1.0/guide/protocols/index.html | 3 - docs/en/gun/1.0/guide/start/index.html | 3 - docs/en/gun/1.0/guide/websocket/index.html | 3 - docs/en/gun/1.0/manual/gun/index.html | 3 - docs/en/gun/1.0/manual/gun_app/index.html | 3 - docs/en/gun/1.0/manual/index.html | 3 - docs/en/ranch/1.2/guide/embedded/index.html | 3 - docs/en/ranch/1.2/guide/index.html | 3 - docs/en/ranch/1.2/guide/internals/index.html | 3 - docs/en/ranch/1.2/guide/introduction/index.html | 3 - docs/en/ranch/1.2/guide/listeners/index.html | 3 - docs/en/ranch/1.2/guide/parsers/index.html | 3 - docs/en/ranch/1.2/guide/protocols/index.html | 3 - docs/en/ranch/1.2/guide/ssl_auth/index.html | 3 - docs/en/ranch/1.2/guide/transports/index.html | 3 - docs/en/ranch/1.2/manual/index.html | 3 - docs/en/ranch/1.2/manual/ranch/index.html | 3 - docs/en/ranch/1.2/manual/ranch_app/index.html | 3 - docs/en/ranch/1.2/manual/ranch_protocol/index.html | 3 - docs/en/ranch/1.2/manual/ranch_ssl/index.html | 3 - docs/en/ranch/1.2/manual/ranch_tcp/index.html | 3 - .../en/ranch/1.2/manual/ranch_transport/index.html | 3 - docs/en/ranch/1.3/guide/embedded/index.html | 3 - docs/en/ranch/1.3/guide/index.html | 3 - docs/en/ranch/1.3/guide/internals/index.html | 3 - docs/en/ranch/1.3/guide/introduction/index.html | 3 - docs/en/ranch/1.3/guide/listeners/index.html | 3 - docs/en/ranch/1.3/guide/parsers/index.html | 3 - docs/en/ranch/1.3/guide/protocols/index.html | 3 - docs/en/ranch/1.3/guide/ssl_auth/index.html | 3 - docs/en/ranch/1.3/guide/transports/index.html | 3 - docs/en/ranch/1.3/manual/index.html | 3 - docs/en/ranch/1.3/manual/ranch/index.html | 3 - docs/en/ranch/1.3/manual/ranch_app/index.html | 3 - docs/en/ranch/1.3/manual/ranch_protocol/index.html | 3 - docs/en/ranch/1.3/manual/ranch_ssl/index.html | 3 - docs/en/ranch/1.3/manual/ranch_tcp/index.html | 3 - .../en/ranch/1.3/manual/ranch_transport/index.html | 3 - docs/en/ranch/1.4/guide/embedded/index.html | 3 - docs/en/ranch/1.4/guide/index.html | 3 - docs/en/ranch/1.4/guide/internals/index.html | 3 - docs/en/ranch/1.4/guide/introduction/index.html | 3 - docs/en/ranch/1.4/guide/listeners/index.html | 3 - docs/en/ranch/1.4/guide/parsers/index.html | 3 - docs/en/ranch/1.4/guide/protocols/index.html | 3 - docs/en/ranch/1.4/guide/ssl_auth/index.html | 3 - docs/en/ranch/1.4/guide/transports/index.html | 3 - docs/en/ranch/1.4/manual/index.html | 3 - docs/en/ranch/1.4/manual/ranch/index.html | 3 - docs/en/ranch/1.4/manual/ranch_app/index.html | 3 - docs/en/ranch/1.4/manual/ranch_protocol/index.html | 3 - docs/en/ranch/1.4/manual/ranch_ssl/index.html | 3 - docs/en/ranch/1.4/manual/ranch_tcp/index.html | 3 - .../en/ranch/1.4/manual/ranch_transport/index.html | 3 - 611 files changed, 46737 insertions(+), 1414 deletions(-) create mode 100644 docs/en/cowboy/2.4/guide/constraints.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/constraints/index.html create mode 100644 docs/en/cowboy/2.4/guide/cookies.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/cookies/index.html create mode 100644 docs/en/cowboy/2.4/guide/cowboy.sty create mode 100644 docs/en/cowboy/2.4/guide/erlang_web.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/erlang_web/index.html create mode 100644 docs/en/cowboy/2.4/guide/flow_diagram.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/flow_diagram/index.html create mode 100644 docs/en/cowboy/2.4/guide/getting_started.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/getting_started/index.html create mode 100644 docs/en/cowboy/2.4/guide/handlers.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/handlers/index.html create mode 100644 docs/en/cowboy/2.4/guide/http_req_resp.png create mode 100644 docs/en/cowboy/2.4/guide/http_req_resp.svg create mode 100644 docs/en/cowboy/2.4/guide/index.html create mode 100644 docs/en/cowboy/2.4/guide/introduction.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/introduction/index.html create mode 100644 docs/en/cowboy/2.4/guide/listeners.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/listeners/index.html create mode 100644 docs/en/cowboy/2.4/guide/loop_handlers.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/loop_handlers/index.html create mode 100644 docs/en/cowboy/2.4/guide/middlewares.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/middlewares/index.html create mode 100644 docs/en/cowboy/2.4/guide/migrating_from_1.0.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/migrating_from_1.0/index.html create mode 100644 docs/en/cowboy/2.4/guide/migrating_from_2.0.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/migrating_from_2.0/index.html create mode 100644 docs/en/cowboy/2.4/guide/migrating_from_2.1.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/migrating_from_2.1/index.html create mode 100644 docs/en/cowboy/2.4/guide/migrating_from_2.2.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/migrating_from_2.2/index.html create mode 100644 docs/en/cowboy/2.4/guide/migrating_from_2.3.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/migrating_from_2.3/index.html create mode 100644 docs/en/cowboy/2.4/guide/modern_web.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/modern_web/index.html create mode 100644 docs/en/cowboy/2.4/guide/multipart.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/multipart/index.html create mode 100644 docs/en/cowboy/2.4/guide/req.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/req/index.html create mode 100644 docs/en/cowboy/2.4/guide/req_body.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/req_body/index.html create mode 100644 docs/en/cowboy/2.4/guide/resource_design.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/resource_design/index.html create mode 100644 docs/en/cowboy/2.4/guide/resp.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/resp/index.html create mode 100644 docs/en/cowboy/2.4/guide/rest_cond.png create mode 100644 docs/en/cowboy/2.4/guide/rest_cond.svg create mode 100644 docs/en/cowboy/2.4/guide/rest_conneg.png create mode 100644 docs/en/cowboy/2.4/guide/rest_conneg.svg create mode 100644 docs/en/cowboy/2.4/guide/rest_delete.png create mode 100644 docs/en/cowboy/2.4/guide/rest_delete.svg create mode 100644 docs/en/cowboy/2.4/guide/rest_flowcharts.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/rest_flowcharts/index.html create mode 100644 docs/en/cowboy/2.4/guide/rest_get_head.png create mode 100644 docs/en/cowboy/2.4/guide/rest_get_head.svg create mode 100644 docs/en/cowboy/2.4/guide/rest_handlers.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/rest_handlers/index.html create mode 100644 docs/en/cowboy/2.4/guide/rest_options.png create mode 100644 docs/en/cowboy/2.4/guide/rest_options.svg create mode 100644 docs/en/cowboy/2.4/guide/rest_principles.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/rest_principles/index.html create mode 100644 docs/en/cowboy/2.4/guide/rest_put_post_patch.png create mode 100644 docs/en/cowboy/2.4/guide/rest_put_post_patch.svg create mode 100644 docs/en/cowboy/2.4/guide/rest_start.png create mode 100644 docs/en/cowboy/2.4/guide/rest_start.svg create mode 100644 docs/en/cowboy/2.4/guide/routing.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/routing/index.html create mode 100644 docs/en/cowboy/2.4/guide/specs.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/specs/index.html create mode 100644 docs/en/cowboy/2.4/guide/static_files.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/static_files/index.html create mode 100644 docs/en/cowboy/2.4/guide/streams.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/streams/index.html create mode 100644 docs/en/cowboy/2.4/guide/ws_handlers.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/ws_handlers/index.html create mode 100644 docs/en/cowboy/2.4/guide/ws_protocol.asciidoc create mode 100644 docs/en/cowboy/2.4/guide/ws_protocol/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy.set_env/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy.start_clear/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy.start_tls/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy.stop_listener/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_app/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_constraints.int/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_constraints.nonempty/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_constraints/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_handler.terminate/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_handler/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_http/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_http2/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_loop/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_middleware/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.binding/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.bindings/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.body_length/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.cert/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.delete_resp_header/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.has_body/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.has_resp_body/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.has_resp_header/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.header/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.headers/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.host/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.host_info/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.inform/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.match_cookies/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.match_qs/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.method/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.parse_cookies/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.parse_header/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.parse_qs/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.path/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.path_info/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.peer/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.port/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.push/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.qs/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.read_body/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.read_part/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.read_part_body/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.read_urlencoded_body/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.reply/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.resp_header/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.resp_headers/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.scheme/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.set_resp_body/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.set_resp_cookie/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.set_resp_header/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.set_resp_headers/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.sock/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.stream_body/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.stream_reply/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.stream_trailers/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.uri/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req.version/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_req/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_rest/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_router.compile/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_router/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_static/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_stream/index.html create mode 100644 docs/en/cowboy/2.4/manual/cowboy_websocket/index.html create mode 100644 docs/en/cowboy/2.4/manual/http_status_codes/index.html create mode 100644 docs/en/cowboy/2.4/manual/index.html (limited to 'docs/en') diff --git a/docs/en/cowboy/2.0/guide/constraints/index.html b/docs/en/cowboy/2.0/guide/constraints/index.html index 67c7b401..41a99e51 100644 --- a/docs/en/cowboy/2.0/guide/constraints/index.html +++ b/docs/en/cowboy/2.0/guide/constraints/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -258,6 +255,8 @@ functions. They should be written to not emit any exceptions.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/cookies/index.html b/docs/en/cowboy/2.0/guide/cookies/index.html index c1ddbf5b..d7e9b89e 100644 --- a/docs/en/cowboy/2.0/guide/cookies/index.html +++ b/docs/en/cowboy/2.0/guide/cookies/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -261,6 +258,8 @@ exception is thrown.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/erlang_web/index.html b/docs/en/cowboy/2.0/guide/erlang_web/index.html index b9666dc4..fe8bd194 100644 --- a/docs/en/cowboy/2.0/guide/erlang_web/index.html +++ b/docs/en/cowboy/2.0/guide/erlang_web/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -311,6 +308,8 @@ ebook version.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/flow_diagram/index.html b/docs/en/cowboy/2.0/guide/flow_diagram/index.html index 1fb963f8..3fa8798a 100644 --- a/docs/en/cowboy/2.0/guide/flow_diagram/index.html +++ b/docs/en/cowboy/2.0/guide/flow_diagram/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -230,6 +227,8 @@ be the cause.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/getting_started/index.html b/docs/en/cowboy/2.0/guide/getting_started/index.html index c0c22309..9e5787dd 100644 --- a/docs/en/cowboy/2.0/guide/getting_started/index.html +++ b/docs/en/cowboy/2.0/guide/getting_started/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -278,6 +275,8 @@ in your browser, you should get a nice Hello Erlang! displayed!

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/handlers/index.html b/docs/en/cowboy/2.0/guide/handlers/index.html index 8c60b150..dd02ef2f 100644 --- a/docs/en/cowboy/2.0/guide/handlers/index.html +++ b/docs/en/cowboy/2.0/guide/handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -208,6 +205,8 @@ process will terminate soon after this call returns.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/index.html b/docs/en/cowboy/2.0/guide/index.html index 81482c89..ad734e47 100644 --- a/docs/en/cowboy/2.0/guide/index.html +++ b/docs/en/cowboy/2.0/guide/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -294,6 +291,8 @@ +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/introduction/index.html b/docs/en/cowboy/2.0/guide/introduction/index.html index 42687bf1..4fea0be7 100644 --- a/docs/en/cowboy/2.0/guide/introduction/index.html +++ b/docs/en/cowboy/2.0/guide/introduction/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -196,6 +193,8 @@ when sending responses.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/listeners/index.html b/docs/en/cowboy/2.0/guide/listeners/index.html index 6fb334e6..caa1ca92 100644 --- a/docs/en/cowboy/2.0/guide/listeners/index.html +++ b/docs/en/cowboy/2.0/guide/listeners/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -226,6 +223,8 @@ shared.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/loop_handlers/index.html b/docs/en/cowboy/2.0/guide/loop_handlers/index.html index 691a8656..916b9c13 100644 --- a/docs/en/cowboy/2.0/guide/loop_handlers/index.html +++ b/docs/en/cowboy/2.0/guide/loop_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -248,6 +245,8 @@ accordingly.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/middlewares/index.html b/docs/en/cowboy/2.0/guide/middlewares/index.html index 5498e73a..f530358f 100644 --- a/docs/en/cowboy/2.0/guide/middlewares/index.html +++ b/docs/en/cowboy/2.0/guide/middlewares/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -209,6 +206,8 @@ values. It puts the result of the request handling into result.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.0/guide/migrating_from_1.0/index.html index f9f25c37..a9c2d433 100644 --- a/docs/en/cowboy/2.0/guide/migrating_from_1.0/index.html +++ b/docs/en/cowboy/2.0/guide/migrating_from_1.0/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -495,6 +492,8 @@ The static file handler has been improved to handle more special +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/modern_web/index.html b/docs/en/cowboy/2.0/guide/modern_web/index.html index 10e81210..7cf52fc9 100644 --- a/docs/en/cowboy/2.0/guide/modern_web/index.html +++ b/docs/en/cowboy/2.0/guide/modern_web/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -228,6 +225,8 @@ the HTTP protocol.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/multipart/index.html b/docs/en/cowboy/2.0/guide/multipart/index.html index 85d74a40..3ca4c312 100644 --- a/docs/en/cowboy/2.0/guide/multipart/index.html +++ b/docs/en/cowboy/2.0/guide/multipart/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -286,6 +283,8 @@ reading as soon as you find the data you need.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/req/index.html b/docs/en/cowboy/2.0/guide/req/index.html index 187e16b6..9d2c03af 100644 --- a/docs/en/cowboy/2.0/guide/req/index.html +++ b/docs/en/cowboy/2.0/guide/req/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -524,6 +521,8 @@ client itself. It may also be a proxy or a gateway.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/req_body/index.html b/docs/en/cowboy/2.0/guide/req_body/index.html index 693a275f..7067bd24 100644 --- a/docs/en/cowboy/2.0/guide/req_body/index.html +++ b/docs/en/cowboy/2.0/guide/req_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -261,6 +258,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/resource_design/index.html b/docs/en/cowboy/2.0/guide/resource_design/index.html index c8393930..a0bb7232 100644 --- a/docs/en/cowboy/2.0/guide/resource_design/index.html +++ b/docs/en/cowboy/2.0/guide/resource_design/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -330,6 +327,8 @@ no way of knowing it has been completed yet, implement the +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/resp/index.html b/docs/en/cowboy/2.0/guide/resp/index.html index 20ca68f5..e989b325 100644 --- a/docs/en/cowboy/2.0/guide/resp/index.html +++ b/docs/en/cowboy/2.0/guide/resp/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -439,6 +436,8 @@ ultimately send a response to the client.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.0/guide/rest_flowcharts/index.html index 746bf165..ddd5a01c 100644 --- a/docs/en/cowboy/2.0/guide/rest_flowcharts/index.html +++ b/docs/en/cowboy/2.0/guide/rest_flowcharts/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -361,6 +358,8 @@ the results for subsequent use.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/rest_handlers/index.html b/docs/en/cowboy/2.0/guide/rest_handlers/index.html index 7080a532..bd7b5e8a 100644 --- a/docs/en/cowboy/2.0/guide/rest_handlers/index.html +++ b/docs/en/cowboy/2.0/guide/rest_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -400,6 +397,8 @@ cellspacing="0" cellpadding="4"> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/rest_principles/index.html b/docs/en/cowboy/2.0/guide/rest_principles/index.html index 63ff04cb..fba4a6f4 100644 --- a/docs/en/cowboy/2.0/guide/rest_principles/index.html +++ b/docs/en/cowboy/2.0/guide/rest_principles/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -270,6 +267,8 @@ anything specific to the service to operate on it.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/routing/index.html b/docs/en/cowboy/2.0/guide/routing/index.html index af027843..878b5ba5 100644 --- a/docs/en/cowboy/2.0/guide/routing/index.html +++ b/docs/en/cowboy/2.0/guide/routing/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -378,6 +375,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/specs/index.html b/docs/en/cowboy/2.0/guide/specs/index.html index 5e6454e0..9d8d5f8f 100644 --- a/docs/en/cowboy/2.0/guide/specs/index.html +++ b/docs/en/cowboy/2.0/guide/specs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -952,6 +949,8 @@ for or related to HTTP.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/static_files/index.html b/docs/en/cowboy/2.0/guide/static_files/index.html index 4a853d2a..38a6b7f0 100644 --- a/docs/en/cowboy/2.0/guide/static_files/index.html +++ b/docs/en/cowboy/2.0/guide/static_files/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -290,6 +287,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/streams/index.html b/docs/en/cowboy/2.0/guide/streams/index.html index f5940dcd..25ce2517 100644 --- a/docs/en/cowboy/2.0/guide/streams/index.html +++ b/docs/en/cowboy/2.0/guide/streams/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -178,6 +175,8 @@ that will modify responses.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/ws_handlers/index.html b/docs/en/cowboy/2.0/guide/ws_handlers/index.html index d1bf51f7..7ae3ab40 100644 --- a/docs/en/cowboy/2.0/guide/ws_handlers/index.html +++ b/docs/en/cowboy/2.0/guide/ws_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -387,6 +384,8 @@ close frame will not be sent.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/guide/ws_protocol/index.html b/docs/en/cowboy/2.0/guide/ws_protocol/index.html index 05cb6369..6ca64be5 100644 --- a/docs/en/cowboy/2.0/guide/ws_protocol/index.html +++ b/docs/en/cowboy/2.0/guide/ws_protocol/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -187,6 +184,8 @@ extensions.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.0/manual/cowboy.set_env/index.html index cc51e6ad..37caa6c0 100644 --- a/docs/en/cowboy/2.0/manual/cowboy.set_env/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy.set_env/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -212,6 +209,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.0/manual/cowboy.start_clear/index.html index 6085e59e..e8c9cb98 100644 --- a/docs/en/cowboy/2.0/manual/cowboy.start_clear/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy.start_clear/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -243,6 +240,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.0/manual/cowboy.start_tls/index.html index d1231d56..47a6e512 100644 --- a/docs/en/cowboy/2.0/manual/cowboy.start_tls/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy.start_tls/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -248,6 +245,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.0/manual/cowboy.stop_listener/index.html index 1248bba8..4c897d52 100644 --- a/docs/en/cowboy/2.0/manual/cowboy.stop_listener/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy.stop_listener/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy/index.html b/docs/en/cowboy/2.0/manual/cowboy/index.html index 4f1c238f..4819d1c0 100644 --- a/docs/en/cowboy/2.0/manual/cowboy/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -224,6 +221,8 @@ and the HTTP/2 options in +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_app/index.html b/docs/en/cowboy/2.0/manual/cowboy_app/index.html index db8b1eb5..a90f099e 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_app/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_app/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -266,6 +263,8 @@ environment configuration parameters.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.0/manual/cowboy_constraints.int/index.html index 3c95bfe4..630c6f59 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_constraints.int/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_constraints.int/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -187,6 +184,8 @@ and the value as second argument.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.0/manual/cowboy_constraints.nonempty/index.html index 8db3bf9d..7236041f 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_constraints.nonempty/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_constraints.nonempty/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ and the value as second argument.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.0/manual/cowboy_constraints/index.html index 1a91b84c..6102131e 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_constraints/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_constraints/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -179,6 +176,8 @@ made the constraint fail.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.0/manual/cowboy_handler.terminate/index.html index d8837baf..28b0ca91 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_handler.terminate/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_handler.terminate/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -204,6 +201,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_handler/index.html b/docs/en/cowboy/2.0/manual/cowboy_handler/index.html index ba9ead63..155205d3 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_handler/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_handler/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -191,6 +188,8 @@ custom handlers to execute the optional terminate callback:

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_http/index.html b/docs/en/cowboy/2.0/manual/cowboy_http/index.html index 04b23f6b..b70e9032 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_http/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_http/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -335,6 +332,8 @@ stream_handlers ([cowboy_stream_h]) +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_http2/index.html b/docs/en/cowboy/2.0/manual/cowboy_http2/index.html index a1232c1d..041f5eb6 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_http2/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_http2/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -218,6 +215,8 @@ stream_handlers ([cowboy_stream_h]) +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_loop/index.html b/docs/en/cowboy/2.0/manual/cowboy_loop/index.html index 6b52be5f..aee94b44 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_loop/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_loop/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -215,6 +212,8 @@ stop +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.0/manual/cowboy_middleware/index.html index 12c1a50e..c4465fd7 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_middleware/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_middleware/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -210,6 +207,8 @@ contains the name of the listener for this connection.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.binding/index.html index 8e27e426..3a103fb3 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.binding/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.binding/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -211,6 +208,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.bindings/index.html index c4f281f4..8ac9b68a 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.bindings/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.bindings/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -181,6 +178,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.body_length/index.html index 980ad858..423a6389 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.body_length/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.body_length/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.delete_resp_header/index.html index c1fe30cf..d39474dc 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.delete_resp_header/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.delete_resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -190,6 +187,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.has_body/index.html index b35e7547..a14f0bfb 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.has_body/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.has_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -175,6 +172,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_body/index.html index 879f61f4..7f83a57b 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_body/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -177,6 +174,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_header/index.html index c9c811b6..9d5ab140 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_header/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -190,6 +187,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.header/index.html index 73dd5bc1..fba7b1fa 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.header/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -217,6 +214,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.headers/index.html index 9c50b9e0..c27f3ed1 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.headers/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.headers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.host/index.html index 4d744cdb..f9f67d2d 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.host/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.host/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.host_info/index.html index e249c5df..c1ee2cc0 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.host_info/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.host_info/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.match_cookies/index.html index 29e8486d..8afa8b86 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.match_cookies/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.match_cookies/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -218,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.match_qs/index.html index 7c8e43b4..31b7e665 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.match_qs/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.match_qs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -218,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.method/index.html index 3b0ad492..0639ceed 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.method/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.method/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -195,6 +192,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.parse_cookies/index.html index d24b42f4..951c7eb1 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.parse_cookies/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.parse_cookies/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.parse_header/index.html index bf9ef103..9550b300 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.parse_header/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.parse_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -378,6 +375,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.parse_qs/index.html index da432442..9ba85f40 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.parse_qs/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.parse_qs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -212,6 +209,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.path/index.html index 078f70f4..bdc79847 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.path/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.path/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.path_info/index.html index 7a76828f..e6c7188f 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.path_info/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.path_info/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.peer/index.html index fef10eb3..64cd9bfb 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.peer/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.peer/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -191,6 +188,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.port/index.html index e064eb73..109626ee 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.port/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.port/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.push/index.html index 248a87d1..03e6fc7c 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.push/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.push/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -236,6 +233,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.qs/index.html index a5f96d69..690ce7ac 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.qs/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.qs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.read_body/index.html index 7d0f1b75..6ef83d9c 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.read_body/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.read_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -238,6 +235,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.read_part/index.html index 6b06150f..84469257 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.read_part/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.read_part/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -257,6 +254,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.read_part_body/index.html index 7f657603..d34368d2 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.read_part_body/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.read_part_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -225,6 +222,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.read_urlencoded_body/index.html index 60890459..9d98a26e 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.read_urlencoded_body/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.read_urlencoded_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -221,6 +218,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.reply/index.html index 2f0af69e..a84f9d70 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.reply/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.reply/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -259,6 +256,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.resp_header/index.html index 88709bf1..89f6c238 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.resp_header/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -208,6 +205,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.resp_headers/index.html index 42652f64..d694f76d 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.resp_headers/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.resp_headers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -174,6 +171,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.scheme/index.html index cbd0b322..5d6d1333 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.scheme/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.scheme/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_body/index.html index 8d74bc58..7e52d831 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_body/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -233,6 +230,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_cookie/index.html index ba3e16cb..51a4e351 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_cookie/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_cookie/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -262,6 +259,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_header/index.html index 42039152..3e58f743 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_header/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -216,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_headers/index.html index 7f76e0a5..54c09e5e 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_headers/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_headers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -204,6 +201,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.stream_body/index.html index 65d3eeed..b03f496f 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.stream_body/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.stream_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -211,6 +208,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.stream_reply/index.html index 9d530fd1..4dbf588e 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.stream_reply/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.stream_reply/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -243,6 +240,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.uri/index.html index f2408f89..052cd5a9 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.uri/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.uri/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -272,6 +269,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.0/manual/cowboy_req.version/index.html index 3b2aa703..467e4ce5 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req.version/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req.version/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -183,6 +180,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_req/index.html b/docs/en/cowboy/2.0/manual/cowboy_req/index.html index 0840e47f..ea6fa0a0 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_req/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_req/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -484,6 +481,8 @@ is zero.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_rest/index.html b/docs/en/cowboy/2.0/manual/cowboy_rest/index.html index 8db14823..d75704c4 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_rest/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_rest/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -736,6 +733,8 @@ accept-language headers when necessary.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.0/manual/cowboy_router.compile/index.html index cc9ec01a..9bd2dedb 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_router.compile/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_router.compile/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_router/index.html b/docs/en/cowboy/2.0/manual/cowboy_router/index.html index 343f1e84..be3545fa 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_router/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_router/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -205,6 +202,8 @@ using the ... syntax.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_static/index.html b/docs/en/cowboy/2.0/manual/cowboy_static/index.html index b0577e0a..45207f9f 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_static/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_static/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -270,6 +267,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_stream/index.html b/docs/en/cowboy/2.0/manual/cowboy_stream/index.html index 0944d0c1..39b3b7bd 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_stream/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_stream/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -506,6 +503,8 @@ tuple.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.0/manual/cowboy_websocket/index.html index bab9a093..26f1e866 100644 --- a/docs/en/cowboy/2.0/manual/cowboy_websocket/index.html +++ b/docs/en/cowboy/2.0/manual/cowboy_websocket/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -390,6 +387,8 @@ req_filter +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/http_status_codes/index.html b/docs/en/cowboy/2.0/manual/http_status_codes/index.html index 13b3bcb5..de93d01c 100644 --- a/docs/en/cowboy/2.0/manual/http_status_codes/index.html +++ b/docs/en/cowboy/2.0/manual/http_status_codes/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -366,6 +363,8 @@ client and the connection is closed.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.0/manual/index.html b/docs/en/cowboy/2.0/manual/index.html index e53b1537..361d5ae8 100644 --- a/docs/en/cowboy/2.0/manual/index.html +++ b/docs/en/cowboy/2.0/manual/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -266,6 +263,8 @@ environment configuration parameters.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/constraints/index.html b/docs/en/cowboy/2.1/guide/constraints/index.html index eaf7dbf7..7eee23d9 100644 --- a/docs/en/cowboy/2.1/guide/constraints/index.html +++ b/docs/en/cowboy/2.1/guide/constraints/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -258,6 +255,8 @@ functions. They should be written to not emit any exceptions.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/cookies/index.html b/docs/en/cowboy/2.1/guide/cookies/index.html index 5c5606f7..9f771038 100644 --- a/docs/en/cowboy/2.1/guide/cookies/index.html +++ b/docs/en/cowboy/2.1/guide/cookies/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -261,6 +258,8 @@ exception is thrown.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/erlang_web/index.html b/docs/en/cowboy/2.1/guide/erlang_web/index.html index 718ed2d0..63069257 100644 --- a/docs/en/cowboy/2.1/guide/erlang_web/index.html +++ b/docs/en/cowboy/2.1/guide/erlang_web/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -311,6 +308,8 @@ ebook version.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/flow_diagram/index.html b/docs/en/cowboy/2.1/guide/flow_diagram/index.html index 5e6d6303..10a05216 100644 --- a/docs/en/cowboy/2.1/guide/flow_diagram/index.html +++ b/docs/en/cowboy/2.1/guide/flow_diagram/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -230,6 +227,8 @@ be the cause.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/getting_started/index.html b/docs/en/cowboy/2.1/guide/getting_started/index.html index bd0c417e..2e500330 100644 --- a/docs/en/cowboy/2.1/guide/getting_started/index.html +++ b/docs/en/cowboy/2.1/guide/getting_started/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -278,6 +275,8 @@ in your browser, you should get a nice Hello Erlang! displayed!

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/handlers/index.html b/docs/en/cowboy/2.1/guide/handlers/index.html index 6319cb2d..f258206e 100644 --- a/docs/en/cowboy/2.1/guide/handlers/index.html +++ b/docs/en/cowboy/2.1/guide/handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -208,6 +205,8 @@ process will terminate soon after this call returns.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/index.html b/docs/en/cowboy/2.1/guide/index.html index 632afdb0..34e13d60 100644 --- a/docs/en/cowboy/2.1/guide/index.html +++ b/docs/en/cowboy/2.1/guide/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -299,6 +296,8 @@ +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/introduction/index.html b/docs/en/cowboy/2.1/guide/introduction/index.html index 0d6c9ab2..b019abc7 100644 --- a/docs/en/cowboy/2.1/guide/introduction/index.html +++ b/docs/en/cowboy/2.1/guide/introduction/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -196,6 +193,8 @@ when sending responses.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/listeners/index.html b/docs/en/cowboy/2.1/guide/listeners/index.html index a1b34b6a..a3eaff09 100644 --- a/docs/en/cowboy/2.1/guide/listeners/index.html +++ b/docs/en/cowboy/2.1/guide/listeners/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -226,6 +223,8 @@ shared.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/loop_handlers/index.html b/docs/en/cowboy/2.1/guide/loop_handlers/index.html index 969d9f17..c67b97df 100644 --- a/docs/en/cowboy/2.1/guide/loop_handlers/index.html +++ b/docs/en/cowboy/2.1/guide/loop_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -248,6 +245,8 @@ accordingly.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/middlewares/index.html b/docs/en/cowboy/2.1/guide/middlewares/index.html index 0f857cda..5b85a962 100644 --- a/docs/en/cowboy/2.1/guide/middlewares/index.html +++ b/docs/en/cowboy/2.1/guide/middlewares/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -209,6 +206,8 @@ values. It puts the result of the request handling into result.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.1/guide/migrating_from_1.0/index.html index f27da8c5..8056bbf5 100644 --- a/docs/en/cowboy/2.1/guide/migrating_from_1.0/index.html +++ b/docs/en/cowboy/2.1/guide/migrating_from_1.0/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -505,6 +502,8 @@ The static file handler has been improved to handle more special +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.1/guide/migrating_from_2.0/index.html index 2d990853..483caffe 100644 --- a/docs/en/cowboy/2.1/guide/migrating_from_2.0/index.html +++ b/docs/en/cowboy/2.1/guide/migrating_from_2.0/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -305,6 +302,8 @@ Cowboy will no longer crash when the cowboy_clock +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/modern_web/index.html b/docs/en/cowboy/2.1/guide/modern_web/index.html index 72e120d6..9305df74 100644 --- a/docs/en/cowboy/2.1/guide/modern_web/index.html +++ b/docs/en/cowboy/2.1/guide/modern_web/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -228,6 +225,8 @@ the HTTP protocol.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/multipart/index.html b/docs/en/cowboy/2.1/guide/multipart/index.html index c9851ead..280dc99b 100644 --- a/docs/en/cowboy/2.1/guide/multipart/index.html +++ b/docs/en/cowboy/2.1/guide/multipart/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -286,6 +283,8 @@ reading as soon as you find the data you need.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/req/index.html b/docs/en/cowboy/2.1/guide/req/index.html index 6bed133d..5f5fffa8 100644 --- a/docs/en/cowboy/2.1/guide/req/index.html +++ b/docs/en/cowboy/2.1/guide/req/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -524,6 +521,8 @@ client itself. It may also be a proxy or a gateway.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/req_body/index.html b/docs/en/cowboy/2.1/guide/req_body/index.html index 2ba56388..72211af3 100644 --- a/docs/en/cowboy/2.1/guide/req_body/index.html +++ b/docs/en/cowboy/2.1/guide/req_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -261,6 +258,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/resource_design/index.html b/docs/en/cowboy/2.1/guide/resource_design/index.html index baaecd32..f3213781 100644 --- a/docs/en/cowboy/2.1/guide/resource_design/index.html +++ b/docs/en/cowboy/2.1/guide/resource_design/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -330,6 +327,8 @@ no way of knowing it has been completed yet, implement the +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/resp/index.html b/docs/en/cowboy/2.1/guide/resp/index.html index f3841375..be83f461 100644 --- a/docs/en/cowboy/2.1/guide/resp/index.html +++ b/docs/en/cowboy/2.1/guide/resp/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -463,6 +460,8 @@ ultimately send a response to the client.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.1/guide/rest_flowcharts/index.html index 979577bd..88150c03 100644 --- a/docs/en/cowboy/2.1/guide/rest_flowcharts/index.html +++ b/docs/en/cowboy/2.1/guide/rest_flowcharts/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -361,6 +358,8 @@ the results for subsequent use.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/rest_handlers/index.html b/docs/en/cowboy/2.1/guide/rest_handlers/index.html index 9eb65918..1104599c 100644 --- a/docs/en/cowboy/2.1/guide/rest_handlers/index.html +++ b/docs/en/cowboy/2.1/guide/rest_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -404,6 +401,8 @@ cellspacing="0" cellpadding="4"> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/rest_principles/index.html b/docs/en/cowboy/2.1/guide/rest_principles/index.html index 79f9ba60..145695d4 100644 --- a/docs/en/cowboy/2.1/guide/rest_principles/index.html +++ b/docs/en/cowboy/2.1/guide/rest_principles/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -270,6 +267,8 @@ anything specific to the service to operate on it.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/routing/index.html b/docs/en/cowboy/2.1/guide/routing/index.html index dce8702e..e6477dd8 100644 --- a/docs/en/cowboy/2.1/guide/routing/index.html +++ b/docs/en/cowboy/2.1/guide/routing/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -378,6 +375,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/specs/index.html b/docs/en/cowboy/2.1/guide/specs/index.html index 8ce1fa3d..684e9c96 100644 --- a/docs/en/cowboy/2.1/guide/specs/index.html +++ b/docs/en/cowboy/2.1/guide/specs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -952,6 +949,8 @@ for or related to HTTP.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/static_files/index.html b/docs/en/cowboy/2.1/guide/static_files/index.html index 90607b85..424037a4 100644 --- a/docs/en/cowboy/2.1/guide/static_files/index.html +++ b/docs/en/cowboy/2.1/guide/static_files/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -290,6 +287,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/streams/index.html b/docs/en/cowboy/2.1/guide/streams/index.html index cc34a8dc..27b5442a 100644 --- a/docs/en/cowboy/2.1/guide/streams/index.html +++ b/docs/en/cowboy/2.1/guide/streams/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -178,6 +175,8 @@ that will modify responses.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/ws_handlers/index.html b/docs/en/cowboy/2.1/guide/ws_handlers/index.html index 7621887e..7f88ad56 100644 --- a/docs/en/cowboy/2.1/guide/ws_handlers/index.html +++ b/docs/en/cowboy/2.1/guide/ws_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -388,6 +385,8 @@ close frame will not be sent.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/guide/ws_protocol/index.html b/docs/en/cowboy/2.1/guide/ws_protocol/index.html index 47694569..5abff552 100644 --- a/docs/en/cowboy/2.1/guide/ws_protocol/index.html +++ b/docs/en/cowboy/2.1/guide/ws_protocol/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -187,6 +184,8 @@ extensions.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.1/manual/cowboy.set_env/index.html index c390f32c..515c2b6a 100644 --- a/docs/en/cowboy/2.1/manual/cowboy.set_env/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy.set_env/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -212,6 +209,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.1/manual/cowboy.start_clear/index.html index aec74c23..4fab22c0 100644 --- a/docs/en/cowboy/2.1/manual/cowboy.start_clear/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy.start_clear/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -243,6 +240,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.1/manual/cowboy.start_tls/index.html index e430f886..53283b4a 100644 --- a/docs/en/cowboy/2.1/manual/cowboy.start_tls/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy.start_tls/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -248,6 +245,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.1/manual/cowboy.stop_listener/index.html index 1e1c99b2..9d63d438 100644 --- a/docs/en/cowboy/2.1/manual/cowboy.stop_listener/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy.stop_listener/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy/index.html b/docs/en/cowboy/2.1/manual/cowboy/index.html index 399a4d4c..60f51834 100644 --- a/docs/en/cowboy/2.1/manual/cowboy/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -224,6 +221,8 @@ and the HTTP/2 options in +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_app/index.html b/docs/en/cowboy/2.1/manual/cowboy_app/index.html index f733b835..eea329dc 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_app/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_app/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -266,6 +263,8 @@ environment configuration parameters.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.1/manual/cowboy_constraints.int/index.html index fcf8ec6e..8403d122 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_constraints.int/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_constraints.int/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -187,6 +184,8 @@ and the value as second argument.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.1/manual/cowboy_constraints.nonempty/index.html index f32b326f..babea3a8 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_constraints.nonempty/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_constraints.nonempty/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ and the value as second argument.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.1/manual/cowboy_constraints/index.html index a64a9c25..022a5ee5 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_constraints/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_constraints/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -179,6 +176,8 @@ made the constraint fail.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.1/manual/cowboy_handler.terminate/index.html index 6bf4c7d9..17c18082 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_handler.terminate/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_handler.terminate/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -204,6 +201,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_handler/index.html b/docs/en/cowboy/2.1/manual/cowboy_handler/index.html index c591fb4c..dd6a9f36 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_handler/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_handler/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -191,6 +188,8 @@ custom handlers to execute the optional terminate callback:

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_http/index.html b/docs/en/cowboy/2.1/manual/cowboy_http/index.html index 06099a9f..7b78dda2 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_http/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_http/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -335,6 +332,8 @@ stream_handlers ([cowboy_stream_h]) +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_http2/index.html b/docs/en/cowboy/2.1/manual/cowboy_http2/index.html index 79a8e542..561f477a 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_http2/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_http2/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -218,6 +215,8 @@ stream_handlers ([cowboy_stream_h]) +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_loop/index.html b/docs/en/cowboy/2.1/manual/cowboy_loop/index.html index 6ce27a72..565b1b6f 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_loop/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_loop/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -215,6 +212,8 @@ stop +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.1/manual/cowboy_middleware/index.html index 08ad9c19..dfa7dfb4 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_middleware/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_middleware/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -210,6 +207,8 @@ contains the name of the listener for this connection.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.binding/index.html index eeb3ddac..27486d32 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.binding/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.binding/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -211,6 +208,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.bindings/index.html index bea8698e..1675b852 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.bindings/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.bindings/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -181,6 +178,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.body_length/index.html index 40271c48..42e557fa 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.body_length/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.body_length/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.cert/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.cert/index.html index 1f488583..eb349301 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.cert/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.cert/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -199,6 +196,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.delete_resp_header/index.html index 29e7aad3..5bf4e0aa 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.delete_resp_header/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.delete_resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -190,6 +187,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.has_body/index.html index 33b28dcf..ebd04648 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.has_body/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.has_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -175,6 +172,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_body/index.html index 2a39e2f3..8edb00b2 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_body/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -177,6 +174,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_header/index.html index fc1159ea..45180520 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_header/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -190,6 +187,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.header/index.html index 9e14d6bc..274e360c 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.header/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -217,6 +214,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.headers/index.html index b03af539..bc3aa462 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.headers/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.headers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.host/index.html index f40ae964..cd090ceb 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.host/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.host/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.host_info/index.html index 5f1ac840..72ad85e4 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.host_info/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.host_info/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.inform/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.inform/index.html index 3979b859..9833ad9c 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.inform/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.inform/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -220,6 +217,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.match_cookies/index.html index 430e3a07..3e60b33e 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.match_cookies/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.match_cookies/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -218,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.match_qs/index.html index 3020030c..becdb80d 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.match_qs/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.match_qs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -218,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.method/index.html index b62b8e9c..02f29ea4 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.method/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.method/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -195,6 +192,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.parse_cookies/index.html index 79f48ace..66c114d1 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.parse_cookies/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.parse_cookies/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.parse_header/index.html index e96a3e8c..4b414188 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.parse_header/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.parse_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -378,6 +375,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.parse_qs/index.html index a84ed92a..3f4bd70d 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.parse_qs/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.parse_qs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -212,6 +209,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.path/index.html index a480faea..8df37d37 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.path/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.path/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.path_info/index.html index f940a70e..1bddc613 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.path_info/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.path_info/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.peer/index.html index 119bcbc2..1d132c25 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.peer/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.peer/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -193,6 +190,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.port/index.html index 6c091eb7..fdedf48b 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.port/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.port/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.push/index.html index dc0d49d8..353f863d 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.push/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.push/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -237,6 +234,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.qs/index.html index bb4d5bc9..77d718c6 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.qs/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.qs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.read_body/index.html index 85f5f826..b2060728 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.read_body/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.read_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -238,6 +235,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.read_part/index.html index 381eb72e..c64a2756 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.read_part/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.read_part/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -257,6 +254,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.read_part_body/index.html index 0c4655e2..66e4c0d0 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.read_part_body/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.read_part_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -225,6 +222,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.read_urlencoded_body/index.html index b66dafba..84bad156 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.read_urlencoded_body/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.read_urlencoded_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -221,6 +218,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.reply/index.html index 89246894..b6e7d8ec 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.reply/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.reply/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -260,6 +257,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.resp_header/index.html index 79704838..1965736a 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.resp_header/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -208,6 +205,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.resp_headers/index.html index a3e2d7fc..e06c3979 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.resp_headers/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.resp_headers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -174,6 +171,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.scheme/index.html index a69c6974..d31254cd 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.scheme/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.scheme/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_body/index.html index 0c5a7a8c..db6c9c1d 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_body/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -233,6 +230,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_cookie/index.html index 2810c45b..4cb01c55 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_cookie/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_cookie/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -262,6 +259,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_header/index.html index b8709e6d..371f9493 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_header/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -216,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_headers/index.html index 061ab43b..8814c9eb 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_headers/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_headers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -204,6 +201,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.sock/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.sock/index.html index 744ebc4c..bff64506 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.sock/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.sock/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -181,6 +178,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.stream_body/index.html index 70ed4b1d..2939d517 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.stream_body/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.stream_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -211,6 +208,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.stream_reply/index.html index 0a3b721b..c0641be7 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.stream_reply/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.stream_reply/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -244,6 +241,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.uri/index.html index 1733ac4f..4248951e 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.uri/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.uri/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -272,6 +269,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.1/manual/cowboy_req.version/index.html index c598ee92..357d0d41 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req.version/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req.version/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -183,6 +180,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_req/index.html b/docs/en/cowboy/2.1/manual/cowboy_req/index.html index d7c3cc19..14239bab 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_req/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_req/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -504,6 +501,8 @@ is zero.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_rest/index.html b/docs/en/cowboy/2.1/manual/cowboy_rest/index.html index b02989ce..2ffb3e23 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_rest/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_rest/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -763,6 +760,8 @@ accept-language headers when necessary.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.1/manual/cowboy_router.compile/index.html index 2ad603e6..40960f07 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_router.compile/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_router.compile/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_router/index.html b/docs/en/cowboy/2.1/manual/cowboy_router/index.html index a131c8cf..e56314f6 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_router/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_router/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -205,6 +202,8 @@ using the ... syntax.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_static/index.html b/docs/en/cowboy/2.1/manual/cowboy_static/index.html index 877fdbc5..e4bee346 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_static/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_static/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -270,6 +267,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_stream/index.html b/docs/en/cowboy/2.1/manual/cowboy_stream/index.html index 752737df..54fa616c 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_stream/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_stream/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -506,6 +503,8 @@ tuple.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.1/manual/cowboy_websocket/index.html index 396ee5c6..750cf5ed 100644 --- a/docs/en/cowboy/2.1/manual/cowboy_websocket/index.html +++ b/docs/en/cowboy/2.1/manual/cowboy_websocket/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -390,6 +387,8 @@ req_filter +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/http_status_codes/index.html b/docs/en/cowboy/2.1/manual/http_status_codes/index.html index 75ca2cdf..70b15e46 100644 --- a/docs/en/cowboy/2.1/manual/http_status_codes/index.html +++ b/docs/en/cowboy/2.1/manual/http_status_codes/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -366,6 +363,8 @@ client and the connection is closed.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.1/manual/index.html b/docs/en/cowboy/2.1/manual/index.html index 7878accd..1d81c7b2 100644 --- a/docs/en/cowboy/2.1/manual/index.html +++ b/docs/en/cowboy/2.1/manual/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -266,6 +263,8 @@ environment configuration parameters.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/constraints/index.html b/docs/en/cowboy/2.2/guide/constraints/index.html index aeec3006..4562b2cb 100644 --- a/docs/en/cowboy/2.2/guide/constraints/index.html +++ b/docs/en/cowboy/2.2/guide/constraints/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -258,6 +255,8 @@ functions. They should be written to not emit any exceptions.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/cookies/index.html b/docs/en/cowboy/2.2/guide/cookies/index.html index 063f3f5d..396803e6 100644 --- a/docs/en/cowboy/2.2/guide/cookies/index.html +++ b/docs/en/cowboy/2.2/guide/cookies/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -261,6 +258,8 @@ exception is thrown.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/erlang_web/index.html b/docs/en/cowboy/2.2/guide/erlang_web/index.html index 03e93cab..a7eaefe5 100644 --- a/docs/en/cowboy/2.2/guide/erlang_web/index.html +++ b/docs/en/cowboy/2.2/guide/erlang_web/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -311,6 +308,8 @@ ebook version.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/flow_diagram/index.html b/docs/en/cowboy/2.2/guide/flow_diagram/index.html index 55d3e1ce..e67dadc6 100644 --- a/docs/en/cowboy/2.2/guide/flow_diagram/index.html +++ b/docs/en/cowboy/2.2/guide/flow_diagram/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -230,6 +227,8 @@ be the cause.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/getting_started/index.html b/docs/en/cowboy/2.2/guide/getting_started/index.html index 95d27165..f42e25c6 100644 --- a/docs/en/cowboy/2.2/guide/getting_started/index.html +++ b/docs/en/cowboy/2.2/guide/getting_started/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -278,6 +275,8 @@ in your browser, you should get a nice Hello Erlang! displayed!

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/handlers/index.html b/docs/en/cowboy/2.2/guide/handlers/index.html index 6cb69323..94d684d9 100644 --- a/docs/en/cowboy/2.2/guide/handlers/index.html +++ b/docs/en/cowboy/2.2/guide/handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -208,6 +205,8 @@ process will terminate soon after this call returns.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/index.html b/docs/en/cowboy/2.2/guide/index.html index d73125df..48145285 100644 --- a/docs/en/cowboy/2.2/guide/index.html +++ b/docs/en/cowboy/2.2/guide/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -309,6 +306,8 @@ +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/introduction/index.html b/docs/en/cowboy/2.2/guide/introduction/index.html index 9405b031..7d7f6c69 100644 --- a/docs/en/cowboy/2.2/guide/introduction/index.html +++ b/docs/en/cowboy/2.2/guide/introduction/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -196,6 +193,8 @@ when sending responses.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/listeners/index.html b/docs/en/cowboy/2.2/guide/listeners/index.html index 5ef7a697..b9b22f95 100644 --- a/docs/en/cowboy/2.2/guide/listeners/index.html +++ b/docs/en/cowboy/2.2/guide/listeners/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -226,6 +223,8 @@ shared.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/loop_handlers/index.html b/docs/en/cowboy/2.2/guide/loop_handlers/index.html index 6d03daa5..1837fd57 100644 --- a/docs/en/cowboy/2.2/guide/loop_handlers/index.html +++ b/docs/en/cowboy/2.2/guide/loop_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -248,6 +245,8 @@ accordingly.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/middlewares/index.html b/docs/en/cowboy/2.2/guide/middlewares/index.html index 6381fde5..55984d10 100644 --- a/docs/en/cowboy/2.2/guide/middlewares/index.html +++ b/docs/en/cowboy/2.2/guide/middlewares/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -209,6 +206,8 @@ values. It puts the result of the request handling into result.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.2/guide/migrating_from_1.0/index.html index 563d85f7..69a39bc6 100644 --- a/docs/en/cowboy/2.2/guide/migrating_from_1.0/index.html +++ b/docs/en/cowboy/2.2/guide/migrating_from_1.0/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -505,6 +502,8 @@ The static file handler has been improved to handle more special +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.2/guide/migrating_from_2.0/index.html index 62b40f7f..438bdad2 100644 --- a/docs/en/cowboy/2.2/guide/migrating_from_2.0/index.html +++ b/docs/en/cowboy/2.2/guide/migrating_from_2.0/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -305,6 +302,8 @@ Cowboy will no longer crash when the cowboy_clock +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/migrating_from_2.1/index.html b/docs/en/cowboy/2.2/guide/migrating_from_2.1/index.html index a3b1102d..bf123dd2 100644 --- a/docs/en/cowboy/2.2/guide/migrating_from_2.1/index.html +++ b/docs/en/cowboy/2.2/guide/migrating_from_2.1/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -320,6 +317,8 @@ Both experimental stream handlers cowboy_metrics_h and +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/migrating_from_2.2/index.html b/docs/en/cowboy/2.2/guide/migrating_from_2.2/index.html index acc1b8fc..3057eb78 100644 --- a/docs/en/cowboy/2.2/guide/migrating_from_2.2/index.html +++ b/docs/en/cowboy/2.2/guide/migrating_from_2.2/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -165,6 +162,8 @@ A miscount of the output HTTP/2 flow control window has been +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/modern_web/index.html b/docs/en/cowboy/2.2/guide/modern_web/index.html index 0c90e333..e5b66f50 100644 --- a/docs/en/cowboy/2.2/guide/modern_web/index.html +++ b/docs/en/cowboy/2.2/guide/modern_web/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -228,6 +225,8 @@ the HTTP protocol.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/multipart/index.html b/docs/en/cowboy/2.2/guide/multipart/index.html index 2e07c550..cfe7501f 100644 --- a/docs/en/cowboy/2.2/guide/multipart/index.html +++ b/docs/en/cowboy/2.2/guide/multipart/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -286,6 +283,8 @@ reading as soon as you find the data you need.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/req/index.html b/docs/en/cowboy/2.2/guide/req/index.html index cde1f4ae..8b6ca4aa 100644 --- a/docs/en/cowboy/2.2/guide/req/index.html +++ b/docs/en/cowboy/2.2/guide/req/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -524,6 +521,8 @@ client itself. It may also be a proxy or a gateway.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/req_body/index.html b/docs/en/cowboy/2.2/guide/req_body/index.html index a0afb383..bb44fb4f 100644 --- a/docs/en/cowboy/2.2/guide/req_body/index.html +++ b/docs/en/cowboy/2.2/guide/req_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -261,6 +258,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/resource_design/index.html b/docs/en/cowboy/2.2/guide/resource_design/index.html index b1e11ac1..c1fb461a 100644 --- a/docs/en/cowboy/2.2/guide/resource_design/index.html +++ b/docs/en/cowboy/2.2/guide/resource_design/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -330,6 +327,8 @@ no way of knowing it has been completed yet, implement the +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/resp/index.html b/docs/en/cowboy/2.2/guide/resp/index.html index 615abdb7..74c860fb 100644 --- a/docs/en/cowboy/2.2/guide/resp/index.html +++ b/docs/en/cowboy/2.2/guide/resp/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -491,6 +488,8 @@ ultimately send a response to the client.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.2/guide/rest_flowcharts/index.html index 4c94b9e4..b0052776 100644 --- a/docs/en/cowboy/2.2/guide/rest_flowcharts/index.html +++ b/docs/en/cowboy/2.2/guide/rest_flowcharts/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -361,6 +358,8 @@ the results for subsequent use.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/rest_handlers/index.html b/docs/en/cowboy/2.2/guide/rest_handlers/index.html index 142d751c..b011e4ca 100644 --- a/docs/en/cowboy/2.2/guide/rest_handlers/index.html +++ b/docs/en/cowboy/2.2/guide/rest_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -404,6 +401,8 @@ cellspacing="0" cellpadding="4"> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/rest_principles/index.html b/docs/en/cowboy/2.2/guide/rest_principles/index.html index e7e9a4df..9ed26b75 100644 --- a/docs/en/cowboy/2.2/guide/rest_principles/index.html +++ b/docs/en/cowboy/2.2/guide/rest_principles/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -270,6 +267,8 @@ anything specific to the service to operate on it.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/routing/index.html b/docs/en/cowboy/2.2/guide/routing/index.html index b527fadd..cfc64a59 100644 --- a/docs/en/cowboy/2.2/guide/routing/index.html +++ b/docs/en/cowboy/2.2/guide/routing/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -378,6 +375,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/specs/index.html b/docs/en/cowboy/2.2/guide/specs/index.html index 5fe68242..e684a680 100644 --- a/docs/en/cowboy/2.2/guide/specs/index.html +++ b/docs/en/cowboy/2.2/guide/specs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -957,6 +954,8 @@ for or related to HTTP.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/static_files/index.html b/docs/en/cowboy/2.2/guide/static_files/index.html index ed972a08..63ed1f00 100644 --- a/docs/en/cowboy/2.2/guide/static_files/index.html +++ b/docs/en/cowboy/2.2/guide/static_files/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -290,6 +287,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/streams/index.html b/docs/en/cowboy/2.2/guide/streams/index.html index 9c5f495e..2833c81c 100644 --- a/docs/en/cowboy/2.2/guide/streams/index.html +++ b/docs/en/cowboy/2.2/guide/streams/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -178,6 +175,8 @@ that will modify responses.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/ws_handlers/index.html b/docs/en/cowboy/2.2/guide/ws_handlers/index.html index 4f64e1ce..e055db17 100644 --- a/docs/en/cowboy/2.2/guide/ws_handlers/index.html +++ b/docs/en/cowboy/2.2/guide/ws_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -388,6 +385,8 @@ close frame will not be sent.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/guide/ws_protocol/index.html b/docs/en/cowboy/2.2/guide/ws_protocol/index.html index fe336246..768d08b3 100644 --- a/docs/en/cowboy/2.2/guide/ws_protocol/index.html +++ b/docs/en/cowboy/2.2/guide/ws_protocol/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -187,6 +184,8 @@ extensions.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy.set_env/index.html b/docs/en/cowboy/2.2/manual/cowboy.set_env/index.html index 87e0edb7..4f89a273 100644 --- a/docs/en/cowboy/2.2/manual/cowboy.set_env/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy.set_env/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -212,6 +209,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy.start_clear/index.html b/docs/en/cowboy/2.2/manual/cowboy.start_clear/index.html index 3f26505e..5540ab6a 100644 --- a/docs/en/cowboy/2.2/manual/cowboy.start_clear/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy.start_clear/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -243,6 +240,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy.start_tls/index.html b/docs/en/cowboy/2.2/manual/cowboy.start_tls/index.html index 20ef884e..fa5b6e8d 100644 --- a/docs/en/cowboy/2.2/manual/cowboy.start_tls/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy.start_tls/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -248,6 +245,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy.stop_listener/index.html b/docs/en/cowboy/2.2/manual/cowboy.stop_listener/index.html index 53843b2d..f9723d88 100644 --- a/docs/en/cowboy/2.2/manual/cowboy.stop_listener/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy.stop_listener/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy/index.html b/docs/en/cowboy/2.2/manual/cowboy/index.html index 97e56b6c..fc3455a9 100644 --- a/docs/en/cowboy/2.2/manual/cowboy/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -224,6 +221,8 @@ and the HTTP/2 options in +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_app/index.html b/docs/en/cowboy/2.2/manual/cowboy_app/index.html index cfe5ef5c..71a4de56 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_app/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_app/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -266,6 +263,8 @@ environment configuration parameters.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_constraints.int/index.html b/docs/en/cowboy/2.2/manual/cowboy_constraints.int/index.html index 5144d5a8..9324a1d7 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_constraints.int/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_constraints.int/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -187,6 +184,8 @@ and the value as second argument.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_constraints.nonempty/index.html b/docs/en/cowboy/2.2/manual/cowboy_constraints.nonempty/index.html index fd2d8624..52d4a0d9 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_constraints.nonempty/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_constraints.nonempty/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ and the value as second argument.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.2/manual/cowboy_constraints/index.html index e88790d0..6f268276 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_constraints/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_constraints/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -179,6 +176,8 @@ made the constraint fail.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_handler.terminate/index.html b/docs/en/cowboy/2.2/manual/cowboy_handler.terminate/index.html index ad59ef6f..0124e0ad 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_handler.terminate/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_handler.terminate/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -204,6 +201,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_handler/index.html b/docs/en/cowboy/2.2/manual/cowboy_handler/index.html index 3a2638be..74a88538 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_handler/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_handler/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -191,6 +188,8 @@ custom handlers to execute the optional terminate callback:

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_http/index.html b/docs/en/cowboy/2.2/manual/cowboy_http/index.html index 1ee845f0..d13f0ab8 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_http/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_http/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -350,6 +347,8 @@ stream_handlers ([cowboy_stream_h]) +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_http2/index.html b/docs/en/cowboy/2.2/manual/cowboy_http2/index.html index 37aae4a8..95778638 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_http2/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_http2/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -218,6 +215,8 @@ stream_handlers ([cowboy_stream_h]) +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_loop/index.html b/docs/en/cowboy/2.2/manual/cowboy_loop/index.html index 87463ac8..4ff9bdfa 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_loop/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_loop/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -215,6 +212,8 @@ stop +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.2/manual/cowboy_middleware/index.html index bae47e73..f2e877ff 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_middleware/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_middleware/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -210,6 +207,8 @@ contains the name of the listener for this connection.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.binding/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.binding/index.html index fe863d15..0e706720 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.binding/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.binding/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -211,6 +208,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.bindings/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.bindings/index.html index 31c419d8..c36c64f9 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.bindings/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.bindings/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -181,6 +178,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.body_length/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.body_length/index.html index ff841ac7..cc03532e 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.body_length/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.body_length/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.cert/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.cert/index.html index 1ebcc1b6..1e039de5 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.cert/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.cert/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -199,6 +196,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.delete_resp_header/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.delete_resp_header/index.html index a4099e80..df7980e2 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.delete_resp_header/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.delete_resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -190,6 +187,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.has_body/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.has_body/index.html index 6598a411..b9fb41bf 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.has_body/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.has_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -175,6 +172,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.has_resp_body/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.has_resp_body/index.html index efa32a55..dc51ebb1 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.has_resp_body/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.has_resp_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -177,6 +174,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.has_resp_header/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.has_resp_header/index.html index 09490f16..ca6ed5bc 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.has_resp_header/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.has_resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -190,6 +187,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.header/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.header/index.html index de95aa00..30db0b0c 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.header/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -217,6 +214,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.headers/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.headers/index.html index a5dbe006..9eddb128 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.headers/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.headers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.host/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.host/index.html index f47bd1df..b6290a15 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.host/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.host/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.host_info/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.host_info/index.html index d00cd086..a209cd1d 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.host_info/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.host_info/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.inform/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.inform/index.html index 9818b3f4..a64fd36f 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.inform/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.inform/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -220,6 +217,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.match_cookies/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.match_cookies/index.html index 8b527274..0e5d09a3 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.match_cookies/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.match_cookies/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -218,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.match_qs/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.match_qs/index.html index 827a9346..93c70bcd 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.match_qs/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.match_qs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -218,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.method/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.method/index.html index 2538291f..b28db246 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.method/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.method/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -195,6 +192,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.parse_cookies/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.parse_cookies/index.html index 7563311d..8d39674e 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.parse_cookies/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.parse_cookies/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.parse_header/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.parse_header/index.html index ab9bdd85..b47462e0 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.parse_header/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.parse_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -378,6 +375,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.parse_qs/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.parse_qs/index.html index 3d5bfc75..95ce3677 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.parse_qs/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.parse_qs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -212,6 +209,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.path/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.path/index.html index 862a4126..614bdd28 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.path/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.path/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.path_info/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.path_info/index.html index 33809fbe..b516c5a0 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.path_info/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.path_info/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.peer/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.peer/index.html index 51d86e7a..eaccb1cf 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.peer/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.peer/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -193,6 +190,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.port/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.port/index.html index 53933637..e9bf7e15 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.port/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.port/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.push/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.push/index.html index ef8f217e..1e382430 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.push/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.push/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -237,6 +234,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.qs/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.qs/index.html index d478756d..c0fefc8e 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.qs/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.qs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.read_body/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.read_body/index.html index 56b9aa9d..03a8b877 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.read_body/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.read_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -238,6 +235,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.read_part/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.read_part/index.html index 689b339c..d6ea2a28 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.read_part/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.read_part/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -257,6 +254,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.read_part_body/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.read_part_body/index.html index 7de86bd6..011da3ac 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.read_part_body/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.read_part_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -225,6 +222,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.read_urlencoded_body/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.read_urlencoded_body/index.html index 4670d8a4..02adbb06 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.read_urlencoded_body/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.read_urlencoded_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -221,6 +218,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.reply/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.reply/index.html index 40fbd0fe..bb7de171 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.reply/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.reply/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -260,6 +257,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.resp_header/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.resp_header/index.html index 7655bb83..36d3178c 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.resp_header/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -208,6 +205,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.resp_headers/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.resp_headers/index.html index ab346562..65403f90 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.resp_headers/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.resp_headers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -174,6 +171,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.scheme/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.scheme/index.html index 66e4b547..87dd0eaf 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.scheme/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.scheme/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_body/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_body/index.html index 88931a32..5b7f03df 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_body/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -233,6 +230,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_cookie/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_cookie/index.html index a8a4cd47..0949b34c 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_cookie/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_cookie/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -262,6 +259,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_header/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_header/index.html index 607c860d..c2c19408 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_header/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -216,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_headers/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_headers/index.html index 2ea7b866..93d150d1 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_headers/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_headers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -204,6 +201,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.sock/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.sock/index.html index e5943151..b88d03b8 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.sock/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.sock/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -181,6 +178,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.stream_body/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.stream_body/index.html index b5da1145..816f97c1 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.stream_body/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.stream_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -214,6 +211,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.stream_reply/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.stream_reply/index.html index 46a37a5b..2d1db595 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.stream_reply/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.stream_reply/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -247,6 +244,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.stream_trailers/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.stream_trailers/index.html index 3e423bf1..397f319c 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.stream_trailers/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.stream_trailers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -202,6 +199,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.uri/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.uri/index.html index b34f21c8..e35ab57c 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.uri/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.uri/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -272,6 +269,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req.version/index.html b/docs/en/cowboy/2.2/manual/cowboy_req.version/index.html index 3840a545..688e01a4 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req.version/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req.version/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -183,6 +180,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_req/index.html b/docs/en/cowboy/2.2/manual/cowboy_req/index.html index e8610881..64ab5f75 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_req/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_req/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -509,6 +506,8 @@ is zero.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_rest/index.html b/docs/en/cowboy/2.2/manual/cowboy_rest/index.html index e48462ca..dfab37b5 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_rest/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_rest/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -765,6 +762,8 @@ listed here, like the authorization header.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_router.compile/index.html b/docs/en/cowboy/2.2/manual/cowboy_router.compile/index.html index a013340a..a73996dc 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_router.compile/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_router.compile/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_router/index.html b/docs/en/cowboy/2.2/manual/cowboy_router/index.html index ce9c0eeb..81f239b4 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_router/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_router/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -205,6 +202,8 @@ using the ... syntax.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_static/index.html b/docs/en/cowboy/2.2/manual/cowboy_static/index.html index 6689a53c..1e18e4a2 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_static/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_static/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -270,6 +267,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_stream/index.html b/docs/en/cowboy/2.2/manual/cowboy_stream/index.html index 49d1a08c..7095a171 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_stream/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_stream/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -547,6 +544,8 @@ tuple.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.2/manual/cowboy_websocket/index.html index 1ed68949..f2c975b3 100644 --- a/docs/en/cowboy/2.2/manual/cowboy_websocket/index.html +++ b/docs/en/cowboy/2.2/manual/cowboy_websocket/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -390,6 +387,8 @@ req_filter +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/http_status_codes/index.html b/docs/en/cowboy/2.2/manual/http_status_codes/index.html index 36422762..95f62853 100644 --- a/docs/en/cowboy/2.2/manual/http_status_codes/index.html +++ b/docs/en/cowboy/2.2/manual/http_status_codes/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -366,6 +363,8 @@ client and the connection is closed.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.2/manual/index.html b/docs/en/cowboy/2.2/manual/index.html index 4fcf13c9..35dd5d68 100644 --- a/docs/en/cowboy/2.2/manual/index.html +++ b/docs/en/cowboy/2.2/manual/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -266,6 +263,8 @@ environment configuration parameters.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/constraints/index.html b/docs/en/cowboy/2.3/guide/constraints/index.html index bf5a0708..c767a5b5 100644 --- a/docs/en/cowboy/2.3/guide/constraints/index.html +++ b/docs/en/cowboy/2.3/guide/constraints/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -258,6 +255,8 @@ functions. They should be written to not emit any exceptions.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/cookies/index.html b/docs/en/cowboy/2.3/guide/cookies/index.html index 99f61964..a5bd8376 100644 --- a/docs/en/cowboy/2.3/guide/cookies/index.html +++ b/docs/en/cowboy/2.3/guide/cookies/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -261,6 +258,8 @@ exception is thrown.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/erlang_web/index.html b/docs/en/cowboy/2.3/guide/erlang_web/index.html index 9e2c2766..62c98047 100644 --- a/docs/en/cowboy/2.3/guide/erlang_web/index.html +++ b/docs/en/cowboy/2.3/guide/erlang_web/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -311,6 +308,8 @@ ebook version.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/flow_diagram/index.html b/docs/en/cowboy/2.3/guide/flow_diagram/index.html index 1e79a2f4..fd9955ba 100644 --- a/docs/en/cowboy/2.3/guide/flow_diagram/index.html +++ b/docs/en/cowboy/2.3/guide/flow_diagram/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -230,6 +227,8 @@ be the cause.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/getting_started/index.html b/docs/en/cowboy/2.3/guide/getting_started/index.html index 2f1b96ba..04e006c5 100644 --- a/docs/en/cowboy/2.3/guide/getting_started/index.html +++ b/docs/en/cowboy/2.3/guide/getting_started/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -278,6 +275,8 @@ in your browser, you should get a nice Hello Erlang! displayed!

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/handlers/index.html b/docs/en/cowboy/2.3/guide/handlers/index.html index 23077390..0761e10a 100644 --- a/docs/en/cowboy/2.3/guide/handlers/index.html +++ b/docs/en/cowboy/2.3/guide/handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -208,6 +205,8 @@ process will terminate soon after this call returns.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/index.html b/docs/en/cowboy/2.3/guide/index.html index d2832e06..3f7e402c 100644 --- a/docs/en/cowboy/2.3/guide/index.html +++ b/docs/en/cowboy/2.3/guide/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -309,6 +306,8 @@ +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/introduction/index.html b/docs/en/cowboy/2.3/guide/introduction/index.html index 9341da01..9e32f1f7 100644 --- a/docs/en/cowboy/2.3/guide/introduction/index.html +++ b/docs/en/cowboy/2.3/guide/introduction/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -196,6 +193,8 @@ when sending responses.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/listeners/index.html b/docs/en/cowboy/2.3/guide/listeners/index.html index 37c0b9a6..c1af1df9 100644 --- a/docs/en/cowboy/2.3/guide/listeners/index.html +++ b/docs/en/cowboy/2.3/guide/listeners/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -226,6 +223,8 @@ shared.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/loop_handlers/index.html b/docs/en/cowboy/2.3/guide/loop_handlers/index.html index f3eb27b2..3b8ad5e1 100644 --- a/docs/en/cowboy/2.3/guide/loop_handlers/index.html +++ b/docs/en/cowboy/2.3/guide/loop_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -248,6 +245,8 @@ accordingly.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/middlewares/index.html b/docs/en/cowboy/2.3/guide/middlewares/index.html index 4343e035..4dd62ec7 100644 --- a/docs/en/cowboy/2.3/guide/middlewares/index.html +++ b/docs/en/cowboy/2.3/guide/middlewares/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -209,6 +206,8 @@ values. It puts the result of the request handling into result.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index f4c0fecf..f8f86008 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -505,6 +502,8 @@ The static file handler has been improved to handle more special +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 119faf1c..952e45d8 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -305,6 +302,8 @@ Cowboy will no longer crash when the cowboy_clock +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 4902ea99..1335e7c1 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -320,6 +317,8 @@ Both experimental stream handlers cowboy_metrics_h and +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index aaedaa30..a9a24dc0 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -225,6 +222,8 @@ A miscount of the output HTTP/2 flow control window has been +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/modern_web/index.html b/docs/en/cowboy/2.3/guide/modern_web/index.html index 3921f478..53fbbc35 100644 --- a/docs/en/cowboy/2.3/guide/modern_web/index.html +++ b/docs/en/cowboy/2.3/guide/modern_web/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -228,6 +225,8 @@ the HTTP protocol.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/multipart/index.html b/docs/en/cowboy/2.3/guide/multipart/index.html index 047c3878..ed410890 100644 --- a/docs/en/cowboy/2.3/guide/multipart/index.html +++ b/docs/en/cowboy/2.3/guide/multipart/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -286,6 +283,8 @@ reading as soon as you find the data you need.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/req/index.html b/docs/en/cowboy/2.3/guide/req/index.html index b4198d42..832f69d1 100644 --- a/docs/en/cowboy/2.3/guide/req/index.html +++ b/docs/en/cowboy/2.3/guide/req/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -524,6 +521,8 @@ client itself. It may also be a proxy or a gateway.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/req_body/index.html b/docs/en/cowboy/2.3/guide/req_body/index.html index d7a28a6c..3f6d4adf 100644 --- a/docs/en/cowboy/2.3/guide/req_body/index.html +++ b/docs/en/cowboy/2.3/guide/req_body/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -261,6 +258,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/resource_design/index.html b/docs/en/cowboy/2.3/guide/resource_design/index.html index 867f91ec..91624692 100644 --- a/docs/en/cowboy/2.3/guide/resource_design/index.html +++ b/docs/en/cowboy/2.3/guide/resource_design/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -330,6 +327,8 @@ no way of knowing it has been completed yet, implement the +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/resp/index.html b/docs/en/cowboy/2.3/guide/resp/index.html index dbfeffbc..5265880e 100644 --- a/docs/en/cowboy/2.3/guide/resp/index.html +++ b/docs/en/cowboy/2.3/guide/resp/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -490,6 +487,8 @@ ultimately send a response to the client.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.3/guide/rest_flowcharts/index.html index 41486014..8a5bb7d6 100644 --- a/docs/en/cowboy/2.3/guide/rest_flowcharts/index.html +++ b/docs/en/cowboy/2.3/guide/rest_flowcharts/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -361,6 +358,8 @@ the results for subsequent use.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/rest_handlers/index.html b/docs/en/cowboy/2.3/guide/rest_handlers/index.html index 58f2b3d3..c40becc1 100644 --- a/docs/en/cowboy/2.3/guide/rest_handlers/index.html +++ b/docs/en/cowboy/2.3/guide/rest_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -404,6 +401,8 @@ cellspacing="0" cellpadding="4"> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/rest_principles/index.html b/docs/en/cowboy/2.3/guide/rest_principles/index.html index 66923155..3909bc20 100644 --- a/docs/en/cowboy/2.3/guide/rest_principles/index.html +++ b/docs/en/cowboy/2.3/guide/rest_principles/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -270,6 +267,8 @@ anything specific to the service to operate on it.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/routing/index.html b/docs/en/cowboy/2.3/guide/routing/index.html index c03dc9a0..94a9a727 100644 --- a/docs/en/cowboy/2.3/guide/routing/index.html +++ b/docs/en/cowboy/2.3/guide/routing/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -378,6 +375,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/specs/index.html b/docs/en/cowboy/2.3/guide/specs/index.html index 08032124..e3ac2115 100644 --- a/docs/en/cowboy/2.3/guide/specs/index.html +++ b/docs/en/cowboy/2.3/guide/specs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -972,6 +969,8 @@ for or related to HTTP.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/static_files/index.html b/docs/en/cowboy/2.3/guide/static_files/index.html index a79f8978..5af9a717 100644 --- a/docs/en/cowboy/2.3/guide/static_files/index.html +++ b/docs/en/cowboy/2.3/guide/static_files/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -290,6 +287,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/streams/index.html b/docs/en/cowboy/2.3/guide/streams/index.html index 3bbed65a..ba977d26 100644 --- a/docs/en/cowboy/2.3/guide/streams/index.html +++ b/docs/en/cowboy/2.3/guide/streams/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -178,6 +175,8 @@ that will modify responses.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/ws_handlers/index.html b/docs/en/cowboy/2.3/guide/ws_handlers/index.html index 83ae4b82..8eeb06d5 100644 --- a/docs/en/cowboy/2.3/guide/ws_handlers/index.html +++ b/docs/en/cowboy/2.3/guide/ws_handlers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -414,6 +411,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/guide/ws_protocol/index.html b/docs/en/cowboy/2.3/guide/ws_protocol/index.html index 26071dfb..f8d4730c 100644 --- a/docs/en/cowboy/2.3/guide/ws_protocol/index.html +++ b/docs/en/cowboy/2.3/guide/ws_protocol/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -187,6 +184,8 @@ extensions.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 6508509e..7ac35e4f 100644 --- a/docs/en/cowboy/2.3/manual/cowboy.set_env/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy.set_env/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -212,6 +209,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index f41bf11c..4eed7b25 100644 --- a/docs/en/cowboy/2.3/manual/cowboy.start_clear/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy.start_clear/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -243,6 +240,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 0c564ae5..43329c93 100644 --- a/docs/en/cowboy/2.3/manual/cowboy.start_tls/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy.start_tls/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -248,6 +245,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 598440d8..297396c0 100644 --- a/docs/en/cowboy/2.3/manual/cowboy.stop_listener/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy.stop_listener/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy/index.html b/docs/en/cowboy/2.3/manual/cowboy/index.html index 105df649..e1114e3c 100644 --- a/docs/en/cowboy/2.3/manual/cowboy/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -224,6 +221,8 @@ and the HTTP/2 options in +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_app/index.html b/docs/en/cowboy/2.3/manual/cowboy_app/index.html index 61d33a83..e716bd07 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_app/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_app/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -266,6 +263,8 @@ environment configuration parameters.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 5d03c19e..ef9a0fff 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_constraints.int/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_constraints.int/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -187,6 +184,8 @@ and the value as second argument.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index e6d2b058..ef770435 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_constraints.nonempty/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_constraints.nonempty/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ and the value as second argument.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.3/manual/cowboy_constraints/index.html index f922d46f..2a1dcaea 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_constraints/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_constraints/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -179,6 +176,8 @@ made the constraint fail.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index e146df7a..33c5e117 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_handler.terminate/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_handler.terminate/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -204,6 +201,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_handler/index.html b/docs/en/cowboy/2.3/manual/cowboy_handler/index.html index 89456d26..c4005e65 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_handler/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_handler/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -191,6 +188,8 @@ custom handlers to execute the optional terminate callback:

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_http/index.html b/docs/en/cowboy/2.3/manual/cowboy_http/index.html index ec3e69f3..1208adb7 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_http/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_http/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -350,6 +347,8 @@ stream_handlers ([cowboy_stream_h]) +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_http2/index.html b/docs/en/cowboy/2.3/manual/cowboy_http2/index.html index a63d0d96..17f977bd 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_http2/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_http2/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -89,14 +86,13 @@ by Lorenzo Bettini http://www.lorenzobettini.it http://www.gnu.org/software/src-highlite --> 
    opts() :: #{
-    connection_type         => worker | supervisor,
-    enable_connect_protocol => boolean(),
-    env                     => cowboy_middleware:env(),
-    inactivity_timeout      => timeout(),
-    middlewares             => [module()],
-    preface_timeout         => timeout(),
-    shutdown_timeout        => timeout(),
-    stream_handlers         => [module()]
+    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 @@ -115,15 +111,6 @@ connection_type (supervisor)

    -enable_connect_protocol (false) -
    -
    -

    - Whether to enable the extended CONNECT method to allow - protocols like Websocket to be used over an HTTP/2 stream. -

    -
    -
    env (#{})
    @@ -228,6 +215,8 @@ stream_handlers ([cowboy_stream_h]) +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_loop/index.html b/docs/en/cowboy/2.3/manual/cowboy_loop/index.html index a16f0298..5e1509e8 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_loop/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_loop/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -215,6 +212,8 @@ stop +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.3/manual/cowboy_middleware/index.html index 656f7f20..fc36df6f 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_middleware/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_middleware/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -210,6 +207,8 @@ contains the name of the listener for this connection.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 765ec661..59913ca4 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.binding/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.binding/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -211,6 +208,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index c2ccd106..32b05cbc 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.bindings/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.bindings/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -181,6 +178,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 988bcf6c..366e4f5a 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 4bb0fd26..69003e07 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.cert/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.cert/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -199,6 +196,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 5a786cc6..37c25b06 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -190,6 +187,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 95b9cb87..33c3e487 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -175,6 +172,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index c227cf96..e09a6b0c 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -177,6 +174,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 8ef78e90..0ca32c35 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -190,6 +187,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 4fa0eed3..d8d47af5 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.header/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.header/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -217,6 +214,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 20fb9aed..dd7bd7c4 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.headers/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.headers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 55415a1b..ff3e9f75 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.host/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.host/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 04f0423f..b2f9e84a 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index d25172d4..b3c42ea1 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.inform/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.inform/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -220,6 +217,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index e881d0eb..0cbf19e3 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -218,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 7bad35bd..6919bc67 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -218,6 +215,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 5b0a3eff..da22f865 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.method/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.method/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -195,6 +192,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index b9e8ad17..5e84d34f 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -186,6 +183,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 886f7235..9ca0c082 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -378,6 +375,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index a59b5459..7d4ac526 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -212,6 +209,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 8bcc6a94..36b9034c 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.path/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.path/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 3e58ce62..c1177e0b 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index a587efb3..ba95b949 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.peer/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.peer/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -193,6 +190,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index bdfedf32..4693579a 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.port/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.port/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -185,6 +182,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index ce05df13..62069867 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.push/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.push/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -237,6 +234,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index ae54351e..faf42606 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.qs/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.qs/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 6d19e562..6b72d096 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -238,6 +235,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 9d9bd8bc..58fe213a 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -257,6 +254,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index c2dba92d..7a5455b1 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -225,6 +222,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 71368ec7..0629a0cf 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -221,6 +218,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 58f42ed8..8abfe8c7 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.reply/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.reply/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -260,6 +257,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 5f17f94b..207afc1c 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -208,6 +205,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 400c5e1b..e071df9a 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -174,6 +171,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 431bfd18..b74e8660 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.scheme/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.scheme/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -184,6 +181,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index c1b99e5f..f1d16a60 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -233,6 +230,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 114ba535..34eafc67 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -262,6 +259,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index b74342ef..a2666709 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -216,6 +213,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 4f4a23d4..8b288823 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -204,6 +201,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 8d1cf806..a3d51e1f 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.sock/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.sock/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -181,6 +178,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 3b2323f5..5b53c4fb 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -214,6 +211,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index f813304f..638e5b89 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -247,6 +244,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index d4397dd8..b36d662e 100644 --- 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 @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -202,6 +199,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 81057420..64b06c85 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.uri/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.uri/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -272,6 +269,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index a1fd45b0..7bc4cf96 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req.version/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req.version/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -183,6 +180,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_req/index.html b/docs/en/cowboy/2.3/manual/cowboy_req/index.html index ce53ead1..6df8f78b 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_req/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_req/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -509,6 +506,8 @@ is zero.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_rest/index.html b/docs/en/cowboy/2.3/manual/cowboy_rest/index.html index 2abd42a4..494edcdf 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_rest/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_rest/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -765,6 +762,8 @@ listed here, like the authorization header.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index 0bf17017..bcb97fb7 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_router.compile/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_router.compile/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -182,6 +179,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_router/index.html b/docs/en/cowboy/2.3/manual/cowboy_router/index.html index 4fc28840..19f5bfef 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_router/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_router/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -205,6 +202,8 @@ using the ... syntax.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_static/index.html b/docs/en/cowboy/2.3/manual/cowboy_static/index.html index e0b5b8f3..e2e03261 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_static/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_static/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -270,6 +267,8 @@ http://www.gnu.org/software/src-highlite --> +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_stream/index.html b/docs/en/cowboy/2.3/manual/cowboy_stream/index.html index 2b85cbe5..f9c2c2fc 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_stream/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_stream/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -547,6 +544,8 @@ tuple.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.3/manual/cowboy_websocket/index.html index 94eaa5f3..16f020f9 100644 --- a/docs/en/cowboy/2.3/manual/cowboy_websocket/index.html +++ b/docs/en/cowboy/2.3/manual/cowboy_websocket/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -403,6 +400,8 @@ req_filter +
  • 2.4
    • +
  • 2.3
  • 2.2
    • 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 index b26c9563..b981a1eb 100644 --- a/docs/en/cowboy/2.3/manual/http_status_codes/index.html +++ b/docs/en/cowboy/2.3/manual/http_status_codes/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -366,6 +363,8 @@ client and the connection is closed.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.3/manual/index.html b/docs/en/cowboy/2.3/manual/index.html index 59b2eefb..12e4ebb3 100644 --- a/docs/en/cowboy/2.3/manual/index.html +++ b/docs/en/cowboy/2.3/manual/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -266,6 +263,8 @@ environment configuration parameters.

    +
  • 2.4
    • +
  • 2.3
  • 2.2
    • diff --git a/docs/en/cowboy/2.4/guide/constraints.asciidoc b/docs/en/cowboy/2.4/guide/constraints.asciidoc new file mode 100644 index 00000000..6cc10752 --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/constraints/index.html b/docs/en/cowboy/2.4/guide/constraints/index.html new file mode 100644 index 00000000..06ea156f --- /dev/null +++ b/docs/en/cowboy/2.4/guide/constraints/index.html @@ -0,0 +1,301 @@ + + + + + + + + + + + + Nine Nines: Constraints + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Constraints

    + +

    Constraints are validation and conversion functions applied +to user input.

    +

    They are used in various places in Cowboy, including the +router and the cowboy_req match functions.

    +
    +

    Syntax

    +
    +

    Constraints are provided as a list of fields. For each field +in the list, specific constraints can be applied, as well as +a default value if the field is missing.

    +

    A field can take the form of an atom field, a tuple with +constraints {field, Constraints} or a tuple with constraints +and a default value {field, Constraints, Default}. +The field form indicates the field is mandatory.

    +

    Note that when used with the router, only the second form +makes sense, as it does not use the default and the field +is always defined.

    +

    Constraints for each field are provided as an ordered list +of atoms or funs to apply. Built-in constraints are provided +as atoms, while custom constraints are provided as funs.

    +

    When multiple constraints are provided, they are applied in +the order given. If the value has been modified by a constraint +then the next one receives the new value.

    +

    For example, the following constraints will first validate +and convert the field my_value to an integer, and then +check that the integer is positive:

    +
    +
    +
    PositiveFun = fun
+    (_, V) when V > 0 ->
+        {ok, V};
+    (_, _) ->
+        {error, not_positive}
+end,
+{my_value, [int, PositiveFun]}.
    +

    We ignore the first fun argument in this snippet. We shouldn’t. +We will simply learn what it is later in this chapter.

    +

    When there’s only one constraint, it can be provided directly +without wrapping it into a list:

    +
    +
    +
    {my_value, int}
    +
    +
    +
    +

    Built-in constraints

    +
    +

    Built-in constraints are specified as an atom:

    +
    + +++ + + + + + + + + + + + + + + + +
    Constraint Description

    int

    Converts binary value to integer.

    nonempty

    Ensures the binary value is non-empty.

    +
    +
    +
    +
    +

    Custom constraints

    +
    +

    Custom constraints are specified as a fun. This fun takes +two arguments. The first argument indicates the operation +to be performed, and the second is the value. What the +value is and what must be returned depends on the operation.

    +

    Cowboy currently defines three operations. The operation +used for validating and converting user input is the forward +operation.

    +
    +
    +
    int(forward, Value) ->
+    try
+        {ok, binary_to_integer(Value)}
+    catch _:_ ->
+        {error, not_an_integer}
+    end;
    +

    The value must be returned even if it is not converted +by the constraint.

    +

    The reverse operation does the opposite: it +takes a converted value and changes it back to what the +user input would have been.

    +
    +
    +
    int(reverse, Value) ->
+        try
+                {ok, integer_to_binary(Value)}
+        catch _:_ ->
+                {error, not_an_integer}
+        end;
    +

    Finally, the format_error operation takes an error +returned by any other operation and returns a formatted +human-readable error message.

    +
    +
    +
    int(format_error, {not_an_integer, Value}) ->
+        io_lib:format("The value ~p is not an integer.", [Value]).
    +

    Notice that for this case you get both the error and +the value that was given to the constraint that produced +this error.

    +

    Cowboy will not catch exceptions coming from constraint +functions. They should be written to not emit any exceptions.

    +
    +
    + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/cookies.asciidoc b/docs/en/cowboy/2.4/guide/cookies.asciidoc new file mode 100644 index 00000000..4825031b --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/cookies/index.html b/docs/en/cowboy/2.4/guide/cookies/index.html new file mode 100644 index 00000000..6891026a --- /dev/null +++ b/docs/en/cowboy/2.4/guide/cookies/index.html @@ -0,0 +1,304 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/cowboy.sty b/docs/en/cowboy/2.4/guide/cowboy.sty new file mode 100644 index 00000000..d5e0d3be --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/erlang_web.asciidoc b/docs/en/cowboy/2.4/guide/erlang_web.asciidoc new file mode 100644 index 00000000..f528adc3 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/erlang_web.asciidoc @@ -0,0 +1,209 @@ +[[erlang_web]] +== Erlang and the Web + +Erlang is the ideal platform for writing Web applications. +Its features are a perfect match for the requirements of +modern Web applications. + +=== The Web is concurrent + +When you access a website there is little concurrency +involved. A few connections are opened and requests +are sent through these connections. Then the web page +is displayed on your screen. Your browser will only +open up to 4 or 8 connections to the server, depending +on your settings. This isn't much. + +But think about it. You are not the only one accessing +the server at the same time. There can be hundreds, if +not thousands, if not millions of connections to the +same server at the same time. + +Even today a lot of systems used in production haven't +solved the C10K problem (ten thousand concurrent connections). +And the ones who did are trying hard to get to the next +step, C100K, and are pretty far from it. + +Erlang meanwhile has no problem handling millions of +connections. At the time of writing there are application +servers written in Erlang that can handle more than two +million connections on a single server in a real production +application, with spare memory and CPU! + +The Web is concurrent, and Erlang is a language designed +for concurrency, so it is a perfect match. + +Of course, various platforms need to scale beyond a few +million connections. This is where Erlang's built-in +distribution mechanisms come in. If one server isn't +enough, add more! Erlang allows you to use the same code +for talking to local processes or to processes in other +parts of your cluster, which means you can scale very +quickly if the need arises. + +The Web has large userbases, and the Erlang platform was +designed to work in a distributed setting, so it is a +perfect match. + +Or is it? Surely you can find solutions to handle that many +concurrent connections with your favorite language... But all +these solutions will break down in the next few years. Why? +Firstly because servers don't get any more powerful, they +instead get a lot more cores and memory. This is only useful +if your application can use them properly, and Erlang is +light-years away from anything else in that area. Secondly, +today your computer and your phone are online, tomorrow your +watch, goggles, bike, car, fridge and tons of other devices +will also connect to various applications on the Internet. + +Only Erlang is prepared to deal with what's coming. + +=== The Web is soft real time + +What does soft real time mean, you ask? It means we want the +operations done as quickly as possible, and in the case of +web applications, it means we want the data propagated fast. + +In comparison, hard real time has a similar meaning, but also +has a hard time constraint, for example an operation needs to +be done in under N milliseconds otherwise the system fails +entirely. + +Users aren't that needy yet, they just want to get access +to their content in a reasonable delay, and they want the +actions they make to register at most a few seconds after +they submitted them, otherwise they'll start worrying about +whether it successfully went through. + +The Web is soft real time because taking longer to perform an +operation would be seen as bad quality of service. + +Erlang is a soft real time system. It will always run +processes fairly, a little at a time, switching to another +process after a while and preventing a single process to +steal resources from all others. This means that Erlang +can guarantee stable low latency of operations. + +Erlang provides the guarantees that the soft real time Web +requires. + +=== The Web is asynchronous + +Long ago, the Web was synchronous because HTTP was synchronous. +You fired a request, and then waited for a response. Not anymore. +It all began when XmlHttpRequest started being used. It allowed +the client to perform asynchronous calls to the server. + +Then Websocket appeared and allowed both the server and the client +to send data to the other endpoint completely asynchronously. The +data is contained within frames and no response is necessary. + +Erlang processes work the same. They send each other data contained +within messages and then continue running without needing a response. +They tend to spend most of their time inactive, waiting for a new +message, and the Erlang VM happily activate them when one is received. + +It is therefore quite easy to imagine Erlang being good at receiving +Websocket frames, which may come in at unpredictable times, pass the +data to the responsible processes which are always ready waiting for +new messages, and perform the operations required by only activating +the required parts of the system. + +The more recent Web technologies, like Websocket of course, but also +HTTP/2.0, are all fully asynchronous protocols. The concept +of requests and responses is retained of course, but anything could +be sent in between, by both the client or the browser, and the +responses could also be received in a completely different order. + +Erlang is by nature asynchronous and really good at it thanks to the +great engineering that has been done in the VM over the years. It's +only natural that it's so good at dealing with the asynchronous Web. + +=== The Web is omnipresent + +The Web has taken a very important part of our lives. We're +connected at all times, when we're on our phone, using our computer, +passing time using a tablet while in the bathroom... And this +isn't going to slow down, every single device at home or on us +will be connected. + +All these devices are always connected. And with the number of +alternatives to give you access to the content you seek, users +tend to not stick around when problems arise. Users today want +their applications to be always available and if it's having +too many issues they just move on. + +Despite this, when developers choose a product to use for building +web applications, their only concern seems to be "Is it fast?", +and they look around for synthetic benchmarks showing which one +is the fastest at sending "Hello world" with only a handful +concurrent connections. Web benchmarks haven't been representative +of reality in a long time, and are drifting further away as +time goes on. + +What developers should really ask themselves is "Can I service +all my users with no interruption?" and they'd find that they have +two choices. They can either hope for the best, or they can use +Erlang. + +Erlang is built for fault tolerance. When writing code in any other +language, you have to check all the return values and act accordingly +to avoid any unforeseen issues. If you're lucky, you won't miss +anything important. When writing Erlang code, you can just check +the success condition and ignore all errors. If an error happens, +the Erlang process crashes and is then restarted by a special +process called a supervisor. + +Erlang developers thus have no need to fear unhandled +errors, and can focus on handling only the errors that should +give some feedback to the user and let the system take care of +the rest. This also has the advantage of allowing them to write +a lot less code, and let them sleep at night. + +Erlang's fault tolerance oriented design is the first piece of +what makes it the best choice for the omnipresent, always available +Web. + +The second piece is Erlang's built-in distribution. Distribution +is a key part of building a fault tolerant system, because it +allows you to handle bigger failures, like a whole server going +down, or even a data center entirely. + +Fault tolerance and distribution are important today, and will be +vital in the future of the Web. Erlang is ready. + +=== Learn Erlang + +If you are new to Erlang, you may want to grab a book or +two to get started. Those are my recommendations as the +author of Cowboy. + +==== The Erlanger Playbook + +The Erlanger Playbook is an ebook I am currently writing, +which covers a number of different topics from code to +documentation to testing Erlang applications. It also has +an Erlang section where it covers directly the building +blocks and patterns, rather than details like the syntax. + +You can most likely read it as a complete beginner, but +you will need a companion book to make the most of it. +Buy it from the https://ninenines.eu[Nine Nines website]. + +==== Programming Erlang + +This book is from one of the creator of Erlang, Joe +Armstrong. It provides a very good explanation of what +Erlang is and why it is so. It serves as a very good +introduction to the language and platform. + +The book is http://pragprog.com/book/jaerlang2/programming-erlang[Programming Erlang], +and it also features a chapter on Cowboy. + +==== Learn You Some Erlang for Great Good! + +http://learnyousomeerlang.com[LYSE] is a much more complete +book covering many aspects of Erlang, while also providing +stories and humor. Be warned: it's pretty verbose. It comes +with a free online version and a more refined paper and +ebook version. diff --git a/docs/en/cowboy/2.4/guide/erlang_web/index.html b/docs/en/cowboy/2.4/guide/erlang_web/index.html new file mode 100644 index 00000000..845f3bf4 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/erlang_web/index.html @@ -0,0 +1,354 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/flow_diagram.asciidoc b/docs/en/cowboy/2.4/guide/flow_diagram.asciidoc new file mode 100644 index 00000000..2d35d4d6 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/flow_diagram.asciidoc @@ -0,0 +1,109 @@ +[[flow_diagram]] +== Flow diagram + +Cowboy is a lightweight HTTP server with support for HTTP/1.1, +HTTP/2 and Websocket. + +It is built on top of Ranch. Please see the Ranch guide for more +information about how the network connections are handled. + +=== Overview + +image::http_req_resp.png[HTTP request/response flowchart] + +As you can see on the diagram, the client +begins by connecting to the server. This step is handled +by a Ranch acceptor, which is a process dedicated to +accepting new connections. + +After Ranch accepts a new connection, whether it is an +HTTP/1.1 or HTTP/2 connection, Cowboy starts receiving +requests and handling them. + +In HTTP/1.1 all requests come sequentially. In HTTP/2 +the requests may arrive and be processed concurrently. + +When a request comes in, Cowboy creates a stream, which +is a set of request/response and all the events associated +with them. The protocol code in Cowboy defers the handling +of these streams to stream handler modules. When you +configure Cowboy you may define one or more module that +will receive all events associated with a stream, including +the request, response, bodies, Erlang messages and more. + +By default Cowboy comes configured with a stream handler +called `cowboy_stream_h`. This stream handler will create +a new process for every request coming in, and then +communicate with this process to read the body or send +a response back. The request process executes middlewares +which, by default, including the router and then the +execution of handlers. Like stream handlers, middlewares +may also be customized. + +A response may be sent at almost any point in this +diagram. If the response must be sent before the stream +is initialized (because an error occurred early, for +example) then stream handlers receive a special event +indicating this error. + +=== Protocol-specific headers + +Cowboy takes care of protocol-specific headers and prevents +you from sending them manually. For HTTP/1.1 this includes +the `transfer-encoding` and `connection` headers. For HTTP/2 +this includes the colon headers like `:status`. + +Cowboy will also remove protocol-specific headers from +requests before passing them to stream handlers. Cowboy +tries to hide the implementation details of all protocols +as well as possible. + +=== Number of processes per connection + +By default, Cowboy will use one process per connection, +plus one process per set of request/response (called a +stream, internally). + +The reason it creates a new process for every request is due +to the requirements of HTTP/2 where requests are executed +concurrently and independently from the connection. The +frames from the different requests end up interleaved on +the single TCP connection. + +The request processes are never reused. There is therefore +no need to perform any cleanup after the response has been +sent. The process will terminate and Erlang/OTP will reclaim +all memory at once. + +Cowboy ultimately does not require more than one process +per connection. It is possible to interact with the connection +directly from a stream handler, a low level interface to Cowboy. +They are executed from within the connection process, and can +handle the incoming requests and send responses. This is however +not recommended in normal circumstances, as a stream handler +taking too long to execute could have a negative impact on +concurrent requests or the state of the connection itself. + +=== Date header + +Because querying for the current date and time can be expensive, +Cowboy generates one 'Date' header value every second, shares it +to all other processes, which then simply copy it in the response. +This allows compliance with HTTP/1.1 with no actual performance loss. + +=== Binaries + +Cowboy makes extensive use of binaries. + +Binaries are more efficient than lists for representing +strings because they take less memory space. Processing +performance can vary depending on the operation. Binaries +are known for generally getting a great boost if the code +is compiled natively. Please see the HiPE documentation +for more details. + +Binaries may end up being shared between processes. This +can lead to some large memory usage when one process keeps +the binary data around forever without freeing it. If you +see some weird memory usage in your application, this might +be the cause. diff --git a/docs/en/cowboy/2.4/guide/flow_diagram/index.html b/docs/en/cowboy/2.4/guide/flow_diagram/index.html new file mode 100644 index 00000000..7e461f74 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/flow_diagram/index.html @@ -0,0 +1,273 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/getting_started.asciidoc b/docs/en/cowboy/2.4/guide/getting_started.asciidoc new file mode 100644 index 00000000..5ef3f139 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/getting_started.asciidoc @@ -0,0 +1,147 @@ +[[getting_started]] +== Getting started + +Erlang is more than a language, it is also an operating system +for your applications. Erlang developers rarely write standalone +modules, they write libraries or applications, and then bundle +those into what is called a release. A release contains the +Erlang VM plus all applications required to run the node, so +it can be pushed to production directly. + +This chapter walks you through all the steps of setting up +Cowboy, writing your first application and generating your first +release. At the end of this chapter you should know everything +you need to push your first Cowboy application to production. + +=== Prerequisites + +We are going to use the https://github.com/ninenines/erlang.mk[Erlang.mk] +build system. If you are using Windows, please check the +http://erlang.mk/guide/installation.html[Installation instructions] +to get your environment setup before you continue. + +=== Bootstrap + +First, let's create the directory for our application. + +[source,bash] +$ mkdir hello_erlang +$ cd hello_erlang + +Then we need to download Erlang.mk. Either use the following +command or download it manually. + +[source,bash] +$ wget https://erlang.mk/erlang.mk + +We can now bootstrap our application. Since we are going to generate +a release, we will also bootstrap it at the same time. + +[source,bash] +$ make -f erlang.mk bootstrap bootstrap-rel + +This creates a Makefile, a base application, and the release files +necessary for creating the release. We can already build and start +this release. + +[source,bash] +---- +$ make run +... +(hello_erlang@127.0.0.1)1> +---- + +Entering the command `i().` will show the running processes, including +one called `hello_erlang_sup`. This is the supervisor for our +application. + +The release currently does nothing. In the rest of this chapter we +will add Cowboy as a dependency and write a simple "Hello world!" +handler. + +=== Cowboy setup + +We will modify the 'Makefile' to tell the build system it needs to +fetch and compile Cowboy: + +[source,makefile] +---- +PROJECT = hello_erlang + +DEPS = cowboy +dep_cowboy_commit = 2.4.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.4/guide/getting_started/index.html b/docs/en/cowboy/2.4/guide/getting_started/index.html new file mode 100644 index 00000000..e4e30831 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/getting_started/index.html @@ -0,0 +1,321 @@ + + + + + + + + + + + + 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.4.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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/handlers.asciidoc b/docs/en/cowboy/2.4/guide/handlers.asciidoc new file mode 100644 index 00000000..fe6f4623 --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/handlers/index.html b/docs/en/cowboy/2.4/guide/handlers/index.html new file mode 100644 index 00000000..b0f7dae5 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/handlers/index.html @@ -0,0 +1,251 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/http_req_resp.png b/docs/en/cowboy/2.4/guide/http_req_resp.png new file mode 100644 index 00000000..41c17c8a Binary files /dev/null and b/docs/en/cowboy/2.4/guide/http_req_resp.png differ diff --git a/docs/en/cowboy/2.4/guide/http_req_resp.svg b/docs/en/cowboy/2.4/guide/http_req_resp.svg new file mode 100644 index 00000000..acedb152 --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/index.html b/docs/en/cowboy/2.4/guide/index.html new file mode 100644 index 00000000..54301a06 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/index.html @@ -0,0 +1,357 @@ + + + + + + + + + + + + Nine Nines: Cowboy User Guide + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    Cowboy User Guide

    + +
    +

    Rationale

    +
    +
    +
    +
    +
    +

    Introduction

    +
    +
    +
    +
    +
    +

    Configuration

    +
    +
    +
    +
    +
    +

    Handlers

    +
    +
    +
    +
    +
    +

    Request and response

    +
    +
    +
    +
    +
    +

    REST

    +
    +
    +
    +
    +
    +

    Websocket

    +
    +
    +
    +
    +
    +

    Advanced

    +
    +
    +
    +
    +
    +

    Additional information

    +
    +
    +
    +
    + + + + + +
    + +
    + + +

    + Cowboy + 2.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/introduction.asciidoc b/docs/en/cowboy/2.4/guide/introduction.asciidoc new file mode 100644 index 00000000..1f9b52e4 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/introduction.asciidoc @@ -0,0 +1,75 @@ +[[introduction]] +== Introduction + +Cowboy is a small, fast and modern HTTP server for Erlang/OTP. + +Cowboy aims to provide a complete xref:modern_web[modern Web stack]. +This includes HTTP/1.1, HTTP/2, Websocket, Server-Sent Events and +Webmachine-based REST. + +Cowboy comes with functions for introspection and tracing, enabling +developers to know precisely what is happening at any time. Its modular +design also easily enable developers to add instrumentation. + +Cowboy is a high quality project. It has a small code base, is very +efficient (both in latency and memory use) and can easily be embedded +in another application. + +Cowboy is clean Erlang code. It includes hundreds of tests and its code +is fully compliant with the Dialyzer. It is also well documented and +features a Function Reference, a User Guide and numerous Tutorials. + +=== Prerequisites + +Beginner Erlang knowledge is recommended for reading this guide. + +Knowledge of the HTTP protocol is recommended but not required, as it +will be detailed throughout the guide. + +=== Supported platforms + +Cowboy is tested and supported on Linux, FreeBSD, Windows and OSX. + +Cowboy has been reported to work on other platforms, but we make no +guarantee that the experience will be safe and smooth. You are advised +to perform the necessary testing and security audits prior to deploying +on other platforms. + +Cowboy is developed for Erlang/OTP 19.0 and newer. + +=== License + +Cowboy uses the ISC License. + +---- +Copyright (c) 2011-2017, Loïc Hoguin + +Permission to use, copy, modify, and/or distribute this software for any +purpose with or without fee is hereby granted, provided that the above +copyright notice and this permission notice appear in all copies. + +THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +---- + +=== Versioning + +Cowboy uses http://semver.org/[Semantic Versioning 2.0.0]. + +=== Conventions + +In the HTTP protocol, the method name is case sensitive. All standard +method names are uppercase. + +Header names are case insensitive. When using HTTP/1.1, Cowboy converts +all the request header names to lowercase. HTTP/2 requires clients to +send them as lowercase. Any other header name is expected to be provided +lowercased, including when querying information about the request or +when sending responses. + +The same applies to any other case insensitive value. diff --git a/docs/en/cowboy/2.4/guide/introduction/index.html b/docs/en/cowboy/2.4/guide/introduction/index.html new file mode 100644 index 00000000..b1d57ba0 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/introduction/index.html @@ -0,0 +1,239 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/listeners.asciidoc b/docs/en/cowboy/2.4/guide/listeners.asciidoc new file mode 100644 index 00000000..10ac4aad --- /dev/null +++ b/docs/en/cowboy/2.4/guide/listeners.asciidoc @@ -0,0 +1,115 @@ +[[listeners]] +== Listeners + +A listener is a set of processes that listens on a port for +new connections. Incoming connections get handled by Cowboy. +Depending on the connection handshake, one or another protocol +may be used. + +This chapter is specific to Cowboy. Please refer to the +https://ninenines.eu/docs/en/ranch/1.3/guide/listeners/[Ranch User Guide] +for more information about listeners. + +Cowboy provides two types of listeners: one listening for +clear TCP connections, and one listening for secure TLS +connections. Both of them support the HTTP/1.1 and HTTP/2 +protocols. + +=== Clear TCP listener + +The clear TCP listener will accept connections on the +given port. A typical HTTP server would listen on port 80. +Port 80 requires special permissions on most platforms +however so a common alternative is port 8080. + +The following snippet starts listening for connections +on port 8080: + +[source,erlang] +---- +start(_Type, _Args) -> + Dispatch = cowboy_router:compile([ + {'_', [{"/", hello_handler, []}]} + ]), + {ok, _} = cowboy:start_clear(my_http_listener, + [{port, 8080}], + #{env => #{dispatch => Dispatch}} + ), + hello_erlang_sup:start_link(). +---- + +The xref:getting_started[Getting Started] chapter uses a +clear TCP listener. + +Clients connecting to Cowboy on the clear listener port are +expected to use either HTTP/1.1 or HTTP/2. + +Cowboy supports both methods of initiating a clear +HTTP/2 connection: through the Upgrade mechanism +(https://tools.ietf.org/html/rfc7540#section-3.2[RFC 7540 3.2]) +or by sending the preface directly +(https://tools.ietf.org/html/rfc7540#section-3.4[RFC 7540 3.4]). + +Compatibility with HTTP/1.0 is provided by Cowboy's HTTP/1.1 +implementation. + +=== Secure TLS listener + +The secure TLS listener will accept connections on the +given port. A typical HTTPS server would listen on port 443. +Port 443 requires special permissions on most platforms +however so a common alternative is port 8443. + +// @todo Make a complete list of restrictions. + +The function provided by Cowboy will ensure that the TLS +options given are following the HTTP/2 RFC with regards +to security. For example some TLS extensions or ciphers +may be disabled. This also applies to HTTP/1.1 connections +on this listener. If this is not desirable, Ranch can be +used directly to setup a custom listener. + +[source,erlang] +---- +start(_Type, _Args) -> + Dispatch = cowboy_router:compile([ + {'_', [{"/", hello_handler, []}]} + ]), + {ok, _} = cowboy:start_tls(my_http_listener, + [ + {port, 8443}, + {certfile, "/path/to/certfile"}, + {keyfile, "/path/to/keyfile"} + ], + #{env => #{dispatch => Dispatch}} + ), + hello_erlang_sup:start_link(). +---- + +Clients connecting to Cowboy on the secure listener are +expected to use the ALPN TLS extension to indicate what +protocols they understand. Cowboy always prefers HTTP/2 +over HTTP/1.1 when both are supported. When neither are +supported by the client, or when the ALPN extension was +missing, Cowboy expects HTTP/1.1 to be used. + +Cowboy also advertises HTTP/2 support through the older +NPN TLS extension for compatibility. Note however that +this support will likely not be enabled by default when +Cowboy 2.0 gets released. + +Compatibility with HTTP/1.0 is provided by Cowboy's HTTP/1.1 +implementation. + +=== Protocol configuration + +The HTTP/1.1 and HTTP/2 protocols share the same semantics; +only their framing differs. The first is a text protocol and +the second a binary protocol. + +Cowboy doesn't separate the configuration for HTTP/1.1 and +HTTP/2. Everything goes into the same map. Many options are +shared. + +// @todo Describe good to know options for both protocols? +// Maybe do that in separate chapters? diff --git a/docs/en/cowboy/2.4/guide/listeners/index.html b/docs/en/cowboy/2.4/guide/listeners/index.html new file mode 100644 index 00000000..653b9c4a --- /dev/null +++ b/docs/en/cowboy/2.4/guide/listeners/index.html @@ -0,0 +1,269 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/loop_handlers.asciidoc b/docs/en/cowboy/2.4/guide/loop_handlers.asciidoc new file mode 100644 index 00000000..21bf8424 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/loop_handlers.asciidoc @@ -0,0 +1,128 @@ +[[loop_handlers]] +== Loop handlers + +Loop handlers are a special kind of HTTP handlers used when the +response can not be sent right away. The handler enters instead +a receive loop waiting for the right message before it can send +a response. + +Loop handlers are used for requests where a response might not +be immediately available, but where you would like to keep the +connection open for a while in case the response arrives. The +most known example of such practice is known as long polling. + +Loop handlers can also be used for requests where a response is +partially available and you need to stream the response body +while the connection is open. The most known example of such +practice is server-sent events. + +While the same can be accomplished using plain HTTP handlers, +it is recommended to use loop handlers because they are well-tested +and allow using built-in features like hibernation and timeouts. + +Loop handlers essentially wait for one or more Erlang messages +and feed these messages to the `info/3` callback. It also features +the `init/2` and `terminate/3` callbacks which work the same as +for plain HTTP handlers. + +=== Initialization + +The `init/2` function must return a `cowboy_loop` tuple to enable +loop handler behavior. This tuple may optionally contain +a timeout value and/or the atom `hibernate` to make the +process enter hibernation until a message is received. + +This snippet enables the loop handler: + +[source,erlang] +---- +init(Req, State) -> + {cowboy_loop, Req, State}. +---- + +This also makes the process hibernate: + +[source,erlang] +---- +init(Req, State) -> + {cowboy_loop, Req, State, hibernate}. +---- + +=== Receive loop + +Once initialized, Cowboy will wait for messages to arrive +in the process' mailbox. When a message arrives, Cowboy +calls the `info/3` function with the message, the Req object +and the handler's state. + +The following snippet sends a reply when it receives a +`reply` message from another process, or waits for another +message otherwise. + +[source,erlang] +---- +info({reply, Body}, Req, State) -> + cowboy_req:reply(200, #{}, Body, Req), + {stop, Req, State}; +info(_Msg, Req, State) -> + {ok, Req, State, hibernate}. +---- + +Do note that the `reply` tuple here may be any message +and is simply an example. + +This callback may perform any necessary operation including +sending all or parts of a reply, and will subsequently +return a tuple indicating if more messages are to be expected. + +The callback may also choose to do nothing at all and just +skip the message received. + +If a reply is sent, then the `stop` tuple should be returned. +This will instruct Cowboy to end the request. + +Otherwise an `ok` tuple should be returned. + +=== Streaming loop + +Another common case well suited for loop handlers is +streaming data received in the form of Erlang messages. +This can be done by initiating a chunked reply in the +`init/2` callback and then using `cowboy_req:chunk/2` +every time a message is received. + +The following snippet does exactly that. As you can see +a chunk is sent every time an `event` message is received, +and the loop is stopped by sending an `eof` message. + +[source,erlang] +---- +init(Req, State) -> + Req2 = cowboy_req:stream_reply(200, Req), + {cowboy_loop, Req2, State}. + +info(eof, Req, State) -> + {stop, Req, State}; +info({event, Data}, Req, State) -> + cowboy_req:stream_body(Data, nofin, Req), + {ok, Req, State}; +info(_Msg, Req, State) -> + {ok, Req, State}. +---- + +=== Cleaning up + +It is recommended that you set the connection header to +`close` when replying, as this process may be reused for +a subsequent request. + +Please refer to the xref:handlers[Handlers chapter] +for general instructions about cleaning up. + +=== Hibernate + +To save memory, you may hibernate the process in between +messages received. This is done by returning the atom +`hibernate` as part of the `loop` tuple callbacks normally +return. Just add the atom at the end and Cowboy will hibernate +accordingly. diff --git a/docs/en/cowboy/2.4/guide/loop_handlers/index.html b/docs/en/cowboy/2.4/guide/loop_handlers/index.html new file mode 100644 index 00000000..959178c4 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/loop_handlers/index.html @@ -0,0 +1,291 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/middlewares.asciidoc b/docs/en/cowboy/2.4/guide/middlewares.asciidoc new file mode 100644 index 00000000..e6be30dd --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/middlewares/index.html b/docs/en/cowboy/2.4/guide/middlewares/index.html new file mode 100644 index 00000000..28864e8c --- /dev/null +++ b/docs/en/cowboy/2.4/guide/middlewares/index.html @@ -0,0 +1,252 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/migrating_from_1.0.asciidoc b/docs/en/cowboy/2.4/guide/migrating_from_1.0.asciidoc new file mode 100644 index 00000000..4f4ea5bf --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.4/guide/migrating_from_1.0/index.html new file mode 100644 index 00000000..ac4fb23c --- /dev/null +++ b/docs/en/cowboy/2.4/guide/migrating_from_1.0/index.html @@ -0,0 +1,548 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/migrating_from_2.0.asciidoc b/docs/en/cowboy/2.4/guide/migrating_from_2.0.asciidoc new file mode 100644 index 00000000..c76430c2 --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.4/guide/migrating_from_2.0/index.html new file mode 100644 index 00000000..2cf43661 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/migrating_from_2.0/index.html @@ -0,0 +1,348 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/migrating_from_2.1.asciidoc b/docs/en/cowboy/2.4/guide/migrating_from_2.1.asciidoc new file mode 100644 index 00000000..3c0681ff --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/migrating_from_2.1/index.html b/docs/en/cowboy/2.4/guide/migrating_from_2.1/index.html new file mode 100644 index 00000000..937a559a --- /dev/null +++ b/docs/en/cowboy/2.4/guide/migrating_from_2.1/index.html @@ -0,0 +1,363 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/migrating_from_2.2.asciidoc b/docs/en/cowboy/2.4/guide/migrating_from_2.2.asciidoc new file mode 100644 index 00000000..dacf790e --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/migrating_from_2.2/index.html b/docs/en/cowboy/2.4/guide/migrating_from_2.2/index.html new file mode 100644 index 00000000..f73e43bd --- /dev/null +++ b/docs/en/cowboy/2.4/guide/migrating_from_2.2/index.html @@ -0,0 +1,268 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/migrating_from_2.3.asciidoc b/docs/en/cowboy/2.4/guide/migrating_from_2.3.asciidoc new file mode 100644 index 00000000..6a604f97 --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/migrating_from_2.3/index.html b/docs/en/cowboy/2.4/guide/migrating_from_2.3/index.html new file mode 100644 index 00000000..5cc37895 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/migrating_from_2.3/index.html @@ -0,0 +1,281 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/modern_web.asciidoc b/docs/en/cowboy/2.4/guide/modern_web.asciidoc new file mode 100644 index 00000000..48525732 --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/modern_web/index.html b/docs/en/cowboy/2.4/guide/modern_web/index.html new file mode 100644 index 00000000..2c6dd25b --- /dev/null +++ b/docs/en/cowboy/2.4/guide/modern_web/index.html @@ -0,0 +1,271 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/multipart.asciidoc b/docs/en/cowboy/2.4/guide/multipart.asciidoc new file mode 100644 index 00000000..0825244c --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/multipart/index.html b/docs/en/cowboy/2.4/guide/multipart/index.html new file mode 100644 index 00000000..ab97d71b --- /dev/null +++ b/docs/en/cowboy/2.4/guide/multipart/index.html @@ -0,0 +1,329 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/req.asciidoc b/docs/en/cowboy/2.4/guide/req.asciidoc new file mode 100644 index 00000000..53222cb4 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/req.asciidoc @@ -0,0 +1,364 @@ +[[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. + +=== 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.4/guide/req/index.html b/docs/en/cowboy/2.4/guide/req/index.html new file mode 100644 index 00000000..d6358c9d --- /dev/null +++ b/docs/en/cowboy/2.4/guide/req/index.html @@ -0,0 +1,567 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/req_body.asciidoc b/docs/en/cowboy/2.4/guide/req_body.asciidoc new file mode 100644 index 00000000..4906811e --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/req_body/index.html b/docs/en/cowboy/2.4/guide/req_body/index.html new file mode 100644 index 00000000..e329845c --- /dev/null +++ b/docs/en/cowboy/2.4/guide/req_body/index.html @@ -0,0 +1,304 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/resource_design.asciidoc b/docs/en/cowboy/2.4/guide/resource_design.asciidoc new file mode 100644 index 00000000..fa0c6122 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/resource_design.asciidoc @@ -0,0 +1,220 @@ +[[resource_design]] +== Designing a resource handler + +This chapter aims to provide you with a list of questions +you must answer in order to write a good resource handler. +It is meant to be usable as a step by step guide. + +=== The service + +Can the service become unavailable, and when it does, can +we detect it? For example, database connectivity problems +may be detected early. We may also have planned outages +of all or parts of the system. Implement the +`service_available` callback. + +What HTTP methods does the service implement? Do we need +more than the standard OPTIONS, HEAD, GET, PUT, POST, +PATCH and DELETE? Are we not using one of those at all? +Implement the `known_methods` callback. + +=== Type of resource handler + +Am I writing a handler for a collection of resources, +or for a single resource? + +The semantics for each of these are quite different. +You should not mix collection and single resource in +the same handler. + +=== Collection handler + +Skip this section if you are not doing a collection. + +Is the collection hardcoded or dynamic? For example, +if you use the route `/users` for the collection of +users then the collection is hardcoded; if you use +`/forums/:category` for the collection of threads +then it isn't. When the collection is hardcoded you +can safely assume the resource always exists. + +What methods should I implement? + +OPTIONS is used to get some information about the +collection. It is recommended to allow it even if you +do not implement it, as Cowboy has a default +implementation built-in. + +HEAD and GET are used to retrieve the collection. +If you allow GET, also allow HEAD as there's no extra +work required to make it work. + +POST is used to create a new resource inside the +collection. Creating a resource by using POST on +the collection is useful when resources may be +created before knowing their URI, usually because +parts of it are generated dynamically. A common +case is some kind of auto incremented integer +identifier. + +The next methods are more rarely allowed. + +PUT is used to create a new collection (when +the collection isn't hardcoded), or replace +the entire collection. + +DELETE is used to delete the entire collection. + +PATCH is used to modify the collection using +instructions given in the request body. A PATCH +operation is atomic. The PATCH operation may +be used for such things as reordering; adding, +modifying or deleting parts of the collection. + +=== Single resource handler + +Skip this section if you are doing a collection. + +What methods should I implement? + +OPTIONS is used to get some information about the +resource. It is recommended to allow it even if you +do not implement it, as Cowboy has a default +implementation built-in. + +HEAD and GET are used to retrieve the resource. +If you allow GET, also allow HEAD as there's no extra +work required to make it work. + +POST is used to update the resource. + +PUT is used to create a new resource (when it doesn't +already exist) or replace the resource. + +DELETE is used to delete the resource. + +PATCH is used to modify the resource using +instructions given in the request body. A PATCH +operation is atomic. The PATCH operation may +be used for adding, removing or modifying specific +values in the resource. + +=== The resource + +Following the above discussion, implement the +`allowed_methods` callback. + +Does the resource always exist? If it may not, implement +the `resource_exists` callback. + +Do I need to authenticate the client before they can +access the resource? What authentication mechanisms +should I provide? This may include form-based, token-based +(in the URL or a cookie), HTTP basic, HTTP digest, +SSL certificate or any other form of authentication. +Implement the `is_authorized` callback. + +Do I need fine-grained access control? How do I determine +that they are authorized access? Handle that in your +`is_authorized` callback. + +Can access to a resource be forbidden regardless of access +being authorized? A simple example of that is censorship +of a resource. Implement the `forbidden` callback. + +Are there any constraints on the length of the resource URI? +For example, the URI may be used as a key in storage and may +have a limit in length. Implement `uri_too_long`. + +=== Representations + +What media types do I provide? If text based, what charsets +are provided? What languages do I provide? + +Implement the mandatory `content_types_provided`. Prefix +the callbacks with `to_` for clarity. For example, `to_html` +or `to_text`. + +Implement the `languages_provided` or `charsets_provided` +callbacks if applicable. + +Is there any other header that may make the representation +of the resource vary? Implement the `variances` callback. + +Depending on your choices for caching content, you may +want to implement one or more of the `generate_etag`, +`last_modified` and `expires` callbacks. + +Do I want the user or user agent to actively choose a +representation available? Send a list of available +representations in the response body and implement +the `multiple_choices` callback. + +=== Redirections + +Do I need to keep track of what resources were deleted? +For example, you may have a mechanism where moving a +resource leaves a redirect link to its new location. +Implement the `previously_existed` callback. + +Was the resource moved, and is the move temporary? If +it is explicitly temporary, for example due to maintenance, +implement the `moved_temporarily` callback. Otherwise, +implement the `moved_permanently` callback. + +=== The request + +Do you need to read the query string? Individual headers? +Implement `malformed_request` and do all the parsing and +validation in this function. Note that the body should not +be read at this point. + +May there be a request body? Will I know its size? +What's the maximum size of the request body I'm willing +to accept? Implement `valid_entity_length`. + +Finally, take a look at the sections corresponding to the +methods you are implementing. + +=== OPTIONS method + +Cowboy by default will send back a list of allowed methods. +Do I need to add more information to the response? Implement +the `options` method. + +=== GET and HEAD methods + +If you implement the methods GET and/or HEAD, you must +implement one `ProvideResource` callback for each +content-type returned by the `content_types_provided` +callback. + +=== PUT, POST and PATCH methods + +If you implement the methods PUT, POST and/or PATCH, +you must implement the `content_types_accepted` callback, +and one `AcceptCallback` callback for each content-type +it returns. Prefix the `AcceptCallback` callback names +with `from_` for clarity. For example, `from_html` or +`from_json`. + +Do we want to allow the POST method to create individual +resources directly through their URI (like PUT)? Implement +the `allow_missing_post` callback. It is recommended to +explicitly use PUT in these cases instead. + +May there be conflicts when using PUT to create or replace +a resource? Do we want to make sure that two updates around +the same time are not cancelling one another? Implement the +`is_conflict` callback. + +=== DELETE methods + +If you implement the method DELETE, you must implement +the `delete_resource` callback. + +When `delete_resource` returns, is the resource completely +removed from the server, including from any caching service? +If not, and/or if the deletion is asynchronous and we have +no way of knowing it has been completed yet, implement the +`delete_completed` callback. diff --git a/docs/en/cowboy/2.4/guide/resource_design/index.html b/docs/en/cowboy/2.4/guide/resource_design/index.html new file mode 100644 index 00000000..e966aa4c --- /dev/null +++ b/docs/en/cowboy/2.4/guide/resource_design/index.html @@ -0,0 +1,373 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/resp.asciidoc b/docs/en/cowboy/2.4/guide/resp.asciidoc new file mode 100644 index 00000000..1664aefc --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/resp/index.html b/docs/en/cowboy/2.4/guide/resp/index.html new file mode 100644 index 00000000..e4608cf1 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/resp/index.html @@ -0,0 +1,533 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/rest_cond.png b/docs/en/cowboy/2.4/guide/rest_cond.png new file mode 100644 index 00000000..64cda347 Binary files /dev/null and b/docs/en/cowboy/2.4/guide/rest_cond.png differ diff --git a/docs/en/cowboy/2.4/guide/rest_cond.svg b/docs/en/cowboy/2.4/guide/rest_cond.svg new file mode 100644 index 00000000..542ae17d --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/rest_conneg.png b/docs/en/cowboy/2.4/guide/rest_conneg.png new file mode 100644 index 00000000..65ecdcf3 Binary files /dev/null and b/docs/en/cowboy/2.4/guide/rest_conneg.png differ diff --git a/docs/en/cowboy/2.4/guide/rest_conneg.svg b/docs/en/cowboy/2.4/guide/rest_conneg.svg new file mode 100644 index 00000000..247567a0 --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/rest_delete.png b/docs/en/cowboy/2.4/guide/rest_delete.png new file mode 100644 index 00000000..56a861c0 Binary files /dev/null and b/docs/en/cowboy/2.4/guide/rest_delete.png differ diff --git a/docs/en/cowboy/2.4/guide/rest_delete.svg b/docs/en/cowboy/2.4/guide/rest_delete.svg new file mode 100644 index 00000000..2f5513cd --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/rest_flowcharts.asciidoc b/docs/en/cowboy/2.4/guide/rest_flowcharts.asciidoc new file mode 100644 index 00000000..b5697825 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/rest_flowcharts.asciidoc @@ -0,0 +1,248 @@ +[[rest_flowcharts]] +== REST flowcharts + +This chapter will explain the REST handler state machine through +a number of different diagrams. + +There are four main paths that requests may follow. One for the +method OPTIONS; one for the methods GET and HEAD; one for the +methods PUT, POST and PATCH; and one for the method DELETE. + +All paths start with the "Start" diagram, and all paths excluding +the OPTIONS path go through the "Content negotiation" diagram +and optionally the "Conditional requests" diagram if the resource +exists. + +The red squares refer to another diagram. The light green squares +indicate a response. Other squares may be either a callback or a +question answered by Cowboy itself. Green arrows tend to indicate +the default behavior if the callback is undefined. + +=== Start + +All requests start from here. + +image::rest_start.png[REST starting flowchart] + +A series of callbacks are called in succession to perform +a general checkup of the service, the request line and +request headers. + +The request body, if any, is not expected to have been +received for any of these steps. It is only processed +at the end of the "PUT, POST and PATCH methods" diagram, +when all conditions have been met. + +The `known_methods` and `allowed_methods` callbacks +return a list of methods. Cowboy then checks if the request +method is in the list, and stops otherwise. + +The `is_authorized` callback may be used to check that +access to the resource is authorized. Authentication +may also be performed as needed. When authorization is +denied, the return value from the callback must include +a challenge applicable to the requested resource, which +will be sent back to the client in the www-authenticate +header. + +This diagram is immediately followed by either the +"OPTIONS method" diagram when the request method is +OPTIONS, or the "Content negotiation" diagram otherwise. + +=== OPTIONS method + +This diagram only applies to OPTIONS requests. + +image::rest_options.png[REST OPTIONS method flowchart] + +The `options` callback may be used to add information +about the resource, such as media types or languages +provided; allowed methods; any extra information. A +response body may also be set, although clients should +not be expected to read it. + +If the `options` callback is not defined, Cowboy will +send a response containing the list of allowed methods +by default. + +=== Content negotiation + +This diagram applies to all request methods other than +OPTIONS. It is executed right after the "Start" diagram +is completed. + +image::rest_conneg.png[REST content negotiation flowchart] + +The purpose of these steps is to determine an appropriate +representation to be sent back to the client. + +The request may contain any of the accept header; the +accept-language header; or the accept-charset header. +When present, Cowboy will parse the headers and then +call the corresponding callback to obtain the list +of provided content-type, language or charset for this +resource. It then automatically select the best match +based on the request. + +If a callback is not defined, Cowboy will select the +content-type, language or charset that the client +prefers. + +The `content_types_provided` also returns the name of +a callback for every content-type it accepts. This +callback will only be called at the end of the +"GET and HEAD methods" diagram, when all conditions +have been met. + +The selected content-type, language and charset are +saved as meta values in the Req object. You *should* +use the appropriate representation if you set a +response body manually (alongside an error code, +for example). + +This diagram is immediately followed by +the "GET and HEAD methods" diagram, +the "PUT, POST and PATCH methods" diagram, +or the "DELETE method" diagram, depending on the +method. + +=== GET and HEAD methods + +This diagram only applies to GET and HEAD requests. + +For a description of the `cond` step, please see +the "Conditional requests" diagram. + +image::rest_get_head.png[REST GET/HEAD methods flowchart] + +When the resource exists, and the conditional steps +succeed, the resource can be retrieved. + +Cowboy prepares the response by first retrieving +metadata about the representation, then by calling +the `ProvideResource` callback. This is the callback +you defined for each content-types you returned from +`content_types_provided`. This callback returns the body +that will be sent back to the client, or a fun if the +body must be streamed. + +When the resource does not exist, Cowboy will figure out +whether the resource existed previously, and if so whether +it was moved elsewhere in order to redirect the client to +the new URI. + +The `moved_permanently` and `moved_temporarily` callbacks +must return the new location of the resource if it was in +fact moved. + +=== PUT, POST and PATCH methods + +This diagram only applies to PUT, POST and PATCH requests. + +For a description of the `cond` step, please see +the "Conditional requests" diagram. + +image::rest_put_post_patch.png[REST PUT/POST/PATCH methods flowchart] + +When the resource exists, first the conditional steps +are executed. When that succeeds, and the method is PUT, +Cowboy will call the `is_conflict` callback. This function +can be used to prevent potential race conditions, by locking +the resource for example. + +Then all three methods reach the `content_types_accepted` +step that we will describe in a few paragraphs. + +When the resource does not exist, and the method is PUT, +Cowboy will check for conflicts and then move on to the +`content_types_accepted` step. For other methods, Cowboy +will figure out whether the resource existed previously, +and if so whether it was moved elsewhere. If the resource +is truly non-existent, the method is POST and the call +for `allow_missing_post` returns `true`, then Cowboy will +move on to the `content_types_accepted` step. Otherwise +the request processing ends there. + +The `moved_permanently` and `moved_temporarily` callbacks +must return the new location of the resource if it was in +fact moved. + +The `content_types_accepted` returns a list of +content-types it accepts, but also the name of a callback +for each of them. Cowboy will select the appropriate +callback for processing the request body and call it. + +This callback may return one of three different return +values. + +If an error occurred while processing the request body, +it must return `false` and Cowboy will send an +appropriate error response. + +If the method is POST, then you may return `true` with +an URI of where the resource has been created. This is +especially useful for writing handlers for collections. + +Otherwise, return `true` to indicate success. Cowboy +will select the appropriate response to be sent depending +on whether a resource has been created, rather than +modified, and on the availability of a location header +or a body in the response. + +=== DELETE method + +This diagram only applies to DELETE requests. + +For a description of the `cond` step, please see +the "Conditional requests" diagram. + +image::rest_delete.png[REST DELETE method flowchart] + +When the resource exists, and the conditional steps +succeed, the resource can be deleted. + +Deleting the resource is a two steps process. First +the callback `delete_resource` is executed. Use this +callback to delete the resource. + +Because the resource may be cached, you must also +delete all cached representations of this resource +in the system. This operation may take a while though, +so you may return before it finished. + +Cowboy will then call the `delete_completed` callback. +If you know that the resource has been completely +deleted from your system, including from caches, then +you can return `true`. If any doubts persist, return +`false`. Cowboy will assume `true` by default. + +To finish, Cowboy checks if you set a response body, +and depending on that, sends the appropriate response. + +When the resource does not exist, Cowboy will figure out +whether the resource existed previously, and if so whether +it was moved elsewhere in order to redirect the client to +the new URI. + +The `moved_permanently` and `moved_temporarily` callbacks +must return the new location of the resource if it was in +fact moved. + +=== Conditional requests + +This diagram applies to all request methods other than +OPTIONS. It is executed right after the `resource_exists` +callback, when the resource exists. + +image::rest_cond.png[REST conditional requests flowchart] + +A request becomes conditional when it includes either of +the if-match header; the if-unmodified-since header; the +if-none-match header; or the if-modified-since header. + +If the condition fails, the request ends immediately +without any retrieval or modification of the resource. + +The `generate_etag` and `last_modified` are called as +needed. Cowboy will only call them once and then cache +the results for subsequent use. diff --git a/docs/en/cowboy/2.4/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.4/guide/rest_flowcharts/index.html new file mode 100644 index 00000000..d8742da4 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/rest_flowcharts/index.html @@ -0,0 +1,404 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/rest_get_head.png b/docs/en/cowboy/2.4/guide/rest_get_head.png new file mode 100644 index 00000000..211ab603 Binary files /dev/null and b/docs/en/cowboy/2.4/guide/rest_get_head.png differ diff --git a/docs/en/cowboy/2.4/guide/rest_get_head.svg b/docs/en/cowboy/2.4/guide/rest_get_head.svg new file mode 100644 index 00000000..92030cf3 --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/rest_handlers.asciidoc b/docs/en/cowboy/2.4/guide/rest_handlers.asciidoc new file mode 100644 index 00000000..dab5bead --- /dev/null +++ b/docs/en/cowboy/2.4/guide/rest_handlers.asciidoc @@ -0,0 +1,138 @@ +[[rest_handlers]] +== REST handlers + +REST is implemented in Cowboy as a sub protocol. The request +is handled as a state machine with many optional callbacks +describing the resource and modifying the machine's behavior. + +The REST handler is the recommended way to handle HTTP requests. + +=== Initialization + +First, the `init/2` callback is called. This callback is common +to all handlers. To use REST for the current request, this function +must return a `cowboy_rest` tuple. + +[source,erlang] +---- +init(Req, State) -> + {cowboy_rest, Req, State}. +---- + +Cowboy will then switch to the REST protocol and start executing +the state machine. + +After reaching the end of the flowchart, the `terminate/3` callback +will be called if it is defined. + +=== Methods + +The REST component has code for handling the following HTTP methods: +HEAD, GET, POST, PATCH, PUT, DELETE and OPTIONS. + +Other methods can be accepted, however they have no specific callback +defined for them at this time. + +=== Callbacks + +All callbacks are optional. Some may become mandatory depending +on what other defined callbacks return. The various flowcharts +in the next chapter should be a useful to determine which callbacks +you need. + +All callbacks take two arguments, the Req object and the State, +and return a three-element tuple of the form `{Value, Req, State}`. + +Nearly all callbacks can also return `{stop, Req, State}` to +stop execution of the request, and +`{{switch_handler, Module}, Req, State}` or +`{{switch_handler, Module, Opts}, Req, State}` to switch to +a different handler type. The exceptions are `expires` +`generate_etag`, `last_modified` and `variances`. + +The following table summarizes the callbacks and their default values. +If the callback isn't defined, then the default value will be used. +Please look at the flowcharts to find out the result of each return +value. + +In the following table, "skip" means the callback is entirely skipped +if it is undefined, moving directly to the next step. Similarly, +"none" means there is no default value for this callback. + +[cols="<,^",options="header"] +|=== +| Callback name | Default value +| allowed_methods | `[<<"GET">>, <<"HEAD">>, <<"OPTIONS">>]` +| allow_missing_post | `true` +| charsets_provided | skip +| content_types_accepted | none +// @todo Space required for the time being: https://github.com/spf13/hugo/issues/2398 +| content_types_provided | `[{{ <<"text">>, <<"html">>, '*'}, to_html}]` +| delete_completed | `true` +| delete_resource | `false` +| expires | `undefined` +| forbidden | `false` +| generate_etag | `undefined` +| is_authorized | `true` +| is_conflict | `false` +| known_methods | `[<<"GET">>, <<"HEAD">>, <<"POST">>, <<"PUT">>, <<"PATCH">>, <<"DELETE">>, <<"OPTIONS">>]` +| languages_provided | skip +| last_modified | `undefined` +| malformed_request | `false` +| moved_permanently | `false` +| moved_temporarily | `false` +| multiple_choices | `false` +| options | `ok` +| previously_existed | `false` +| resource_exists | `true` +| service_available | `true` +| uri_too_long | `false` +| valid_content_headers | `true` +| valid_entity_length | `true` +| variances | `[]` +|=== + +As you can see, Cowboy tries to move on with the request whenever +possible by using well thought out default values. + +In addition to these, there can be any number of user-defined +callbacks that are specified through `content_types_accepted/2` +and `content_types_provided/2`. They can take any name, however +it is recommended to use a separate prefix for the callbacks of +each function. For example, `from_html` and `to_html` indicate +in the first case that we're accepting a resource given as HTML, +and in the second case that we send one as HTML. + +=== Meta data + +Cowboy will set informative values to the Req object at various +points of the execution. You can retrieve them by matching the +Req object directly. The values are defined in the following table: + +[cols="<,<",options="header"] +|=== +| Key | Details +| media_type | The content-type negotiated for the response entity. +| language | The language negotiated for the response entity. +| charset | The charset negotiated for the response entity. +|=== + +They can be used to send a proper body with the response to a +request that used a method other than HEAD or GET. + +=== Response headers + +Cowboy will set response headers automatically over the execution +of the REST code. They are listed in the following table. + +[cols="<,<",options="header"] +|=== +| Header name | Details +| content-language | Language used in the response body +| content-type | Media type and charset of the response body +| etag | Etag of the resource +| expires | Expiration date of the resource +| last-modified | Last modification date for the resource +| location | Relative or absolute URI to the requested resource +| vary | List of headers that may change the representation of the resource +|=== diff --git a/docs/en/cowboy/2.4/guide/rest_handlers/index.html b/docs/en/cowboy/2.4/guide/rest_handlers/index.html new file mode 100644 index 00000000..3489faec --- /dev/null +++ b/docs/en/cowboy/2.4/guide/rest_handlers/index.html @@ -0,0 +1,447 @@ + + + + + + + + + + + + Nine Nines: REST handlers + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    REST handlers

    + +

    REST is implemented in Cowboy as a sub protocol. The request +is handled as a state machine with many optional callbacks +describing the resource and modifying the machine’s behavior.

    +

    The REST handler is the recommended way to handle HTTP requests.

    +
    +

    Initialization

    +
    +

    First, the init/2 callback is called. This callback is common +to all handlers. To use REST for the current request, this function +must return a cowboy_rest tuple.

    +
    +
    +
    init(Req, State) ->
+    {cowboy_rest, Req, State}.
    +

    Cowboy will then switch to the REST protocol and start executing +the state machine.

    +

    After reaching the end of the flowchart, the terminate/3 callback +will be called if it is defined.

    +
    +
    +
    +

    Methods

    +
    +

    The REST component has code for handling the following HTTP methods: +HEAD, GET, POST, PATCH, PUT, DELETE and OPTIONS.

    +

    Other methods can be accepted, however they have no specific callback +defined for them at this time.

    +
    +
    +
    +

    Callbacks

    +
    +

    All callbacks are optional. Some may become mandatory depending +on what other defined callbacks return. The various flowcharts +in the next chapter should be a useful to determine which callbacks +you need.

    +

    All callbacks take two arguments, the Req object and the State, +and return a three-element tuple of the form {Value, Req, State}.

    +

    Nearly all callbacks can also return {stop, Req, State} to +stop execution of the request, and +{{switch_handler, Module}, Req, State} or +{{switch_handler, Module, Opts}, Req, State} to switch to +a different handler type. The exceptions are expires +generate_etag, last_modified and variances.

    +

    The following table summarizes the callbacks and their default values. +If the callback isn’t defined, then the default value will be used. +Please look at the flowcharts to find out the result of each return +value.

    +

    In the following table, "skip" means the callback is entirely skipped +if it is undefined, moving directly to the next step. Similarly, +"none" means there is no default value for this callback.

    +
    + +++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Callback name Default value

    allowed_methods

    [<<"GET">>, <<"HEAD">>, <<"OPTIONS">>]

    allow_missing_post

    true

    charsets_provided

    skip

    content_types_accepted

    none

    content_types_provided

    [{{ <<"text">>, <<"html">>, '*'}, to_html}]

    delete_completed

    true

    delete_resource

    false

    expires

    undefined

    forbidden

    false

    generate_etag

    undefined

    is_authorized

    true

    is_conflict

    false

    known_methods

    [<<"GET">>, <<"HEAD">>, <<"POST">>, <<"PUT">>, <<"PATCH">>, <<"DELETE">>, <<"OPTIONS">>]

    languages_provided

    skip

    last_modified

    undefined

    malformed_request

    false

    moved_permanently

    false

    moved_temporarily

    false

    multiple_choices

    false

    options

    ok

    previously_existed

    false

    resource_exists

    true

    service_available

    true

    uri_too_long

    false

    valid_content_headers

    true

    valid_entity_length

    true

    variances

    []

    +
    +

    As you can see, Cowboy tries to move on with the request whenever +possible by using well thought out default values.

    +

    In addition to these, there can be any number of user-defined +callbacks that are specified through content_types_accepted/2 +and content_types_provided/2. They can take any name, however +it is recommended to use a separate prefix for the callbacks of +each function. For example, from_html and to_html indicate +in the first case that we’re accepting a resource given as HTML, +and in the second case that we send one as HTML.

    +
    +
    +
    +

    Meta data

    +
    +

    Cowboy will set informative values to the Req object at various +points of the execution. You can retrieve them by matching the +Req object directly. The values are defined in the following table:

    +
    + +++ + + + + + + + + + + + + + + + + + + + +
    Key Details

    media_type

    The content-type negotiated for the response entity.

    language

    The language negotiated for the response entity.

    charset

    The charset negotiated for the response entity.

    +
    +

    They can be used to send a proper body with the response to a +request that used a method other than HEAD or GET.

    +
    +
    +
    +

    Response headers

    +
    +

    Cowboy will set response headers automatically over the execution +of the REST code. They are listed in the following table.

    +
    + +++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Header name Details

    content-language

    Language used in the response body

    content-type

    Media type and charset of the response body

    etag

    Etag of the resource

    expires

    Expiration date of the resource

    last-modified

    Last modification date for the resource

    location

    Relative or absolute URI to the requested resource

    vary

    List of headers that may change the representation of the resource

    +
    +
    +
    + + + + + + + + + + + + + + + +
    + +
    + + +

    + Cowboy + 2.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/rest_options.png b/docs/en/cowboy/2.4/guide/rest_options.png new file mode 100644 index 00000000..90fd6f06 Binary files /dev/null and b/docs/en/cowboy/2.4/guide/rest_options.png differ diff --git a/docs/en/cowboy/2.4/guide/rest_options.svg b/docs/en/cowboy/2.4/guide/rest_options.svg new file mode 100644 index 00000000..496c050c --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/rest_principles.asciidoc b/docs/en/cowboy/2.4/guide/rest_principles.asciidoc new file mode 100644 index 00000000..66939cb7 --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/rest_principles/index.html b/docs/en/cowboy/2.4/guide/rest_principles/index.html new file mode 100644 index 00000000..6ddb532b --- /dev/null +++ b/docs/en/cowboy/2.4/guide/rest_principles/index.html @@ -0,0 +1,313 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/rest_put_post_patch.png b/docs/en/cowboy/2.4/guide/rest_put_post_patch.png new file mode 100644 index 00000000..176650e9 Binary files /dev/null and b/docs/en/cowboy/2.4/guide/rest_put_post_patch.png differ diff --git a/docs/en/cowboy/2.4/guide/rest_put_post_patch.svg b/docs/en/cowboy/2.4/guide/rest_put_post_patch.svg new file mode 100644 index 00000000..06d55052 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/rest_put_post_patch.svg @@ -0,0 +1,2856 @@ + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + some text + some text + some text + conneg + resource_exists + + true + + + + + false + + + + + + middlewares + + + + + true + + + + + + + + + + + + + + + cond + + + + + + has if-match? + false + + + + + + method is POST/PATCH? + true + + + + + + + + + + + + + + + + + + + method is POST? + + 412 precondition failed + + + + + + + + + + + + + + previously_existed + + + + + + 404 not found + false + + + + + + + + + true* + false + + 301 moved permanently + + + + + + + + + + moved_temporarily + true* + false + + 307 moved temporarily + + 400 bad request + + + + + true + + + + + + allow_missing_post + + method is POST? + allow_missing_post + + + + + + method is PUT? + + + + + + + + + + is_conflict + true + + 409 conflict + + + + + + content_types_accepted + + AcceptCallback + + + + + + + + + + new resource? + + + + + + + + + + new resource? + + 201 created + + 303 see other + + + + + + + + + + has resp location? + + + + + + + + + + + has resp body? + + + + + + + + + + multiple_choices + false + + 300 multiple choices + + 200 OK + 204 no content + true + + + + + true + + moved_permanently + + 410 gone + false + true + false + false + false + false + + + + + true + + + + + true, URI* + + + + + true + false + true + true + false + true + false + true + false + false + false + + + + + + + + true + + + + + false + true + + diff --git a/docs/en/cowboy/2.4/guide/rest_start.png b/docs/en/cowboy/2.4/guide/rest_start.png new file mode 100644 index 00000000..1f1e312e Binary files /dev/null and b/docs/en/cowboy/2.4/guide/rest_start.png differ diff --git a/docs/en/cowboy/2.4/guide/rest_start.svg b/docs/en/cowboy/2.4/guide/rest_start.svg new file mode 100644 index 00000000..076c6195 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/rest_start.svg @@ -0,0 +1,1356 @@ + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + some text + some text + uri_too_long + malformed_request + some text + init + is_authorized + forbidden + valid_content_headers + valid_entity_length + ... + service_available + known_methods + allowed_methods + + true + known* + false + allowed* + false + true + false + true + true + + + + + false + unknown* + true + unallowed* + true + false* + true + false + false + + 503 service unavailable + + + + + + + + + 501 not implemented + 414 request URI too long + 405 method not allowed + 400 bad request + 401 unauthorized + 403 forbidden + 501 not implemented + 413 request entity too large + + middlewares + + diff --git a/docs/en/cowboy/2.4/guide/routing.asciidoc b/docs/en/cowboy/2.4/guide/routing.asciidoc new file mode 100644 index 00000000..47ef3c57 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/routing.asciidoc @@ -0,0 +1,222 @@ +[[routing]] +== Routing + +Cowboy does nothing by default. + +To make Cowboy useful, you need to map URIs to Erlang modules that will +handle the requests. This is called routing. + +When Cowboy receives a request, it tries to match the requested host and +path to the configured routes. When there's a match, the route's +associated handler is executed. + +Routes need to be compiled before they can be used by Cowboy. +The result of the compilation is the dispatch rules. + +=== Syntax + +The general structure for the routes is defined as follow. + +[source,erlang] +Routes = [Host1, Host2, ... HostN]. + +Each host contains matching rules for the host along with optional +constraints, and a list of routes for the path component. + +[source,erlang] +Host1 = {HostMatch, PathsList}. +Host2 = {HostMatch, Constraints, PathsList}. + +The list of routes for the path component is defined similar to the +list of hosts. + +[source,erlang] +PathsList = [Path1, Path2, ... PathN]. + +Finally, each path contains matching rules for the path along with +optional constraints, and gives us the handler module to be used +along with its initial state. + +[source,erlang] +Path1 = {PathMatch, Handler, InitialState}. +Path2 = {PathMatch, Constraints, Handler, InitialState}. + +Continue reading to learn more about the match syntax and the optional +constraints. + +=== Match syntax + +The match syntax is used to associate host names and paths with their +respective handlers. + +The match syntax is the same for host and path with a few subtleties. +Indeed, the segments separator is different, and the host is matched +starting from the last segment going to the first. All examples will +feature both host and path match rules and explain the differences +when encountered. + +Excluding special values that we will explain at the end of this section, +the simplest match value is a host or a path. It can be given as either +a `string()` or a `binary()`. + +[source,erlang] +---- +PathMatch1 = "/". +PathMatch2 = "/path/to/resource". + +HostMatch1 = "cowboy.example.org". +---- + +As you can see, all paths defined this way must start with a slash +character. Note that these two paths are identical as far as routing +is concerned. + +[source,erlang] +PathMatch2 = "/path/to/resource". +PathMatch3 = "/path/to/resource/". + +Hosts with and without a trailing dot are equivalent for routing. +Similarly, hosts with and without a leading dot are also equivalent. + +[source,erlang] +HostMatch1 = "cowboy.example.org". +HostMatch2 = "cowboy.example.org.". +HostMatch3 = ".cowboy.example.org". + +It is possible to extract segments of the host and path and to store +the values in the `Req` object for later use. We call these kind of +values bindings. + +The syntax for bindings is very simple. A segment that begins with +the `:` character means that what follows until the end of the segment +is the name of the binding in which the segment value will be stored. + +[source,erlang] +PathMatch = "/hats/:name/prices". +HostMatch = ":subdomain.example.org". + +If these two end up matching when routing, you will end up with two +bindings defined, `subdomain` and `name`, each containing the +segment value where they were defined. For example, the URL +`http://test.example.org/hats/wild_cowboy_legendary/prices` will +result in having the value `test` bound to the name `subdomain` +and the value `wild_cowboy_legendary` bound to the name `name`. +They can later be retrieved using `cowboy_req:binding/{2,3}`. The +binding name must be given as an atom. + +There is a special binding name you can use to mimic the underscore +variable in Erlang. Any match against the `_` binding will succeed +but the data will be discarded. This is especially useful for +matching against many domain names in one go. + +[source,erlang] +HostMatch = "ninenines.:_". + +Similarly, it is possible to have optional segments. Anything +between brackets is optional. + +[source,erlang] +PathMatch = "/hats/[page/:number]". +HostMatch = "[www.]ninenines.eu". + +You can also have imbricated optional segments. + +[source,erlang] +PathMatch = "/hats/[page/[:number]]". + +You can retrieve the rest of the host or path using `[...]`. +In the case of hosts it will match anything before, in the case +of paths anything after the previously matched segments. It is +a special case of optional segments, in that it can have +zero, one or many segments. You can then find the segments using +`cowboy_req:host_info/1` and `cowboy_req:path_info/1` respectively. +They will be represented as a list of segments. + +[source,erlang] +PathMatch = "/hats/[...]". +HostMatch = "[...]ninenines.eu". + +If a binding appears twice in the routing rules, then the match +will succeed only if they share the same value. This copies the +Erlang pattern matching behavior. + +[source,erlang] +PathMatch = "/hats/:name/:name". + +This is also true when an optional segment is present. In this +case the two values must be identical only if the segment is +available. + +[source,erlang] +PathMatch = "/hats/:name/[:name]". + +If a binding is defined in both the host and path, then they must +also share the same value. + +[source,erlang] +PathMatch = "/:user/[...]". +HostMatch = ":user.github.com". + +Finally, there are two special match values that can be used. The +first is the atom `'_'` which will match any host or path. + +[source,erlang] +PathMatch = '_'. +HostMatch = '_'. + +The second is the special host match `"*"` which will match the +wildcard path, generally used alongside the `OPTIONS` method. + +[source,erlang] +HostMatch = "*". + +=== Constraints + +After the matching has completed, the resulting bindings can be tested +against a set of constraints. Constraints are only tested when the +binding is defined. They run in the order you defined them. The match +will succeed only if they all succeed. If the match fails, then Cowboy +tries the next route in the list. + +The format used for constraints is the same as match functions in +`cowboy_req`: they are provided as a list of fields which may have +one or more constraints. While the router accepts the same format, +it will skip fields with no constraints and will also ignore default +values, if any. + +Read more about xref:constraints[constraints]. + +=== Compilation + +The routes must be compiled before Cowboy can use them. The compilation +step normalizes the routes to simplify the code and speed up the +execution, but the routes are still looked up one by one in the end. +Faster compilation strategies could be to compile the routes directly +to Erlang code, but would require heavier dependencies. + +To compile routes, just call the appropriate function: + +[source,erlang] +---- +Dispatch = cowboy_router:compile([ + %% {HostMatch, list({PathMatch, Handler, InitialState})} + {'_', [{'_', my_handler, #{}}]} +]), +%% Name, NbAcceptors, TransOpts, ProtoOpts +cowboy:start_clear(my_http_listener, + [{port, 8080}], + #{env => #{dispatch => Dispatch}} +). +---- + +=== Live update + +You can use the `cowboy:set_env/3` function for updating the dispatch +list used by routing. This will apply to all new connections accepted +by the listener: + +[source,erlang] +Dispatch = cowboy_router:compile(Routes), +cowboy:set_env(my_http_listener, dispatch, Dispatch). + +Note that you need to compile the routes again before updating. diff --git a/docs/en/cowboy/2.4/guide/routing/index.html b/docs/en/cowboy/2.4/guide/routing/index.html new file mode 100644 index 00000000..9ff91493 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/routing/index.html @@ -0,0 +1,421 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/specs.asciidoc b/docs/en/cowboy/2.4/guide/specs.asciidoc new file mode 100644 index 00000000..d1a0ab86 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/specs.asciidoc @@ -0,0 +1,193 @@ +[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.4/guide/specs/index.html b/docs/en/cowboy/2.4/guide/specs/index.html new file mode 100644 index 00000000..04f1ed02 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/specs/index.html @@ -0,0 +1,1015 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/static_files.asciidoc b/docs/en/cowboy/2.4/guide/static_files.asciidoc new file mode 100644 index 00000000..9d9b8cc2 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/static_files.asciidoc @@ -0,0 +1,163 @@ +[[static_files]] +== Static files + +Cowboy comes with a ready to use handler for serving static +files. It is provided as a convenience for serving files +during development. + +For systems in production, consider using one of the many +Content Distribution Network (CDN) available on the market, +as they are the best solution for serving files. + +The static handler can serve either one file or all files +from a given directory. The etag generation and mime types +can be configured. + +=== Serve one file + +You can use the static handler to serve one specific file +from an application's private directory. This is particularly +useful to serve an 'index.html' file when the client requests +the `/` path, for example. The path configured is relative +to the given application's private directory. + +The following rule will serve the file 'static/index.html' +from the application `my_app`'s priv directory whenever the +path `/` is accessed: + +[source,erlang] +{"/", cowboy_static, {priv_file, my_app, "static/index.html"}} + +You can also specify the absolute path to a file, or the +path to the file relative to the current directory: + +[source,erlang] +{"/", cowboy_static, {file, "/var/www/index.html"}} + +=== Serve all files from a directory + +You can also use the static handler to serve all files that +can be found in the configured directory. The handler will +use the `path_info` information to resolve the file location, +which means that your route must end with a `[...]` pattern +for it to work. All files are served, including the ones that +may be found in subfolders. + +You can specify the directory relative to an application's +private directory. + +The following rule will serve any file found in the application +`my_app`'s priv directory inside the `static/assets` folder +whenever the requested path begins with `/assets/`: + +[source,erlang] +{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets"}} + +You can also specify the absolute path to the directory or +set it relative to the current directory: + +[source,erlang] +{"/assets/[...]", cowboy_static, {dir, "/var/www/assets"}} + +=== Customize the mimetype detection + +By default, Cowboy will attempt to recognize the mimetype +of your static files by looking at the extension. + +You can override the function that figures out the mimetype +of the static files. It can be useful when Cowboy is missing +a mimetype you need to handle, or when you want to reduce +the list to make lookups faster. You can also give a +hard-coded mimetype that will be used unconditionally. + +Cowboy comes with two functions built-in. The default +function only handles common file types used when building +Web applications. The other function is an extensive list +of hundreds of mimetypes that should cover almost any need +you may have. You can of course create your own function. + +To use the default function, you should not have to configure +anything, as it is the default. If you insist, though, the +following will do the job: + +[source,erlang] +---- +{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets", + [{mimetypes, cow_mimetypes, web}]}} +---- + +As you can see, there is an optional field that may contain +a list of less used options, like mimetypes or etag. All option +types have this optional field. + +To use the function that will detect almost any mimetype, +the following configuration will do: + +[source,erlang] +---- +{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets", + [{mimetypes, cow_mimetypes, all}]}} +---- + +You probably noticed the pattern by now. The configuration +expects a module and a function name, so you can use any +of your own functions instead: + +[source,erlang] +---- +{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets", + [{mimetypes, Module, Function}]}} +---- + +The function that performs the mimetype detection receives +a single argument that is the path to the file on disk. It +is recommended to return the mimetype in tuple form, although +a binary string is also allowed (but will require extra +processing). If the function can't figure out the mimetype, +then it should return `{<<"application">>, <<"octet-stream">>, []}`. + +When the static handler fails to find the extension, +it will send the file as `application/octet-stream`. +A browser receiving such file will attempt to download it +directly to disk. + +Finally, the mimetype can be hard-coded for all files. +This is especially useful in combination with the `file` +and `priv_file` options as it avoids needless computation: + +[source,erlang] +---- +{"/", cowboy_static, {priv_file, my_app, "static/index.html", + [{mimetypes, {<<"text">>, <<"html">>, []}}]}} +---- + +=== Generate an etag + +By default, the static handler will generate an etag header +value based on the size and modified time. This solution +can not be applied to all systems though. It would perform +rather poorly over a cluster of nodes, for example, as the +file metadata will vary from server to server, giving a +different etag on each server. + +You can however change the way the etag is calculated: + +[source,erlang] +---- +{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets", + [{etag, Module, Function}]}} +---- + +This function will receive three arguments: the path to the +file on disk, the size of the file and the last modification +time. In a distributed setup, you would typically use the +file path to retrieve an etag value that is identical across +all your servers. + +You can also completely disable etag handling: + +[source,erlang] +---- +{"/assets/[...]", cowboy_static, {priv_dir, my_app, "static/assets", + [{etag, false}]}} +---- diff --git a/docs/en/cowboy/2.4/guide/static_files/index.html b/docs/en/cowboy/2.4/guide/static_files/index.html new file mode 100644 index 00000000..31db4c23 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/static_files/index.html @@ -0,0 +1,333 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/streams.asciidoc b/docs/en/cowboy/2.4/guide/streams.asciidoc new file mode 100644 index 00000000..841a9712 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/streams.asciidoc @@ -0,0 +1,65 @@ +[[streams]] +== Streams + +A stream is the set of messages that form an HTTP +request/response pair. + +The term stream comes from HTTP/2. In Cowboy, it is +also used when talking about HTTP/1.1 or HTTP/1.0. +It should not be confused with streaming the request +or response body. + +All versions of HTTP allow clients to initiate +streams. HTTP/2 is the only one also allowing servers, +through its server push feature. Both client and +server-initiated streams go through the same process +in Cowboy. + +=== Stream handlers + +Stream handlers must implement five different callbacks. +Four of them are directly related; one is special. + +All callbacks receives the stream ID as first argument. + +Most of them can return a list of commands to be executed +by Cowboy. When callbacks are chained, it is possible to +intercept and modify these commands. This can be useful +for modifying responses for example. + +The `init/3` callback is invoked when a new request +comes in. It receives the Req object and the protocol options +for this listener. + +The `data/4` callback is invoked when data from the request +body is received. It receives both this data and a flag +indicating whether more is to be expected. + +The `info/3` callback is invoked when an Erlang message is +received for this stream. They will typically be messages +sent by the request process. + +Finally the `terminate/3` callback is invoked with the +terminate reason for the stream. The return value is ignored. +Note that as with all terminate callbacks in Erlang, there +is no strong guarantee that it will be called. + +The special callback `early_error/5` is called when an error +occurs before the request headers were fully received and +Cowboy is sending a response. It receives the partial Req +object, the error reason, the protocol options and the response +Cowboy will send. This response must be returned, possibly +modified. + +=== Built-in handlers + +Cowboy comes with two handlers. + +`cowboy_stream_h` is the default stream handler. +It is the core of much of the functionality of Cowboy. +All chains of stream handlers should call it last. + +`cowboy_compress_h` will automatically compress +responses when possible. It is not enabled by default. +It is a good example for writing your own handlers +that will modify responses. diff --git a/docs/en/cowboy/2.4/guide/streams/index.html b/docs/en/cowboy/2.4/guide/streams/index.html new file mode 100644 index 00000000..ac9307c9 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/streams/index.html @@ -0,0 +1,221 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/ws_handlers.asciidoc b/docs/en/cowboy/2.4/guide/ws_handlers.asciidoc new file mode 100644 index 00000000..71165afb --- /dev/null +++ b/docs/en/cowboy/2.4/guide/ws_handlers.asciidoc @@ -0,0 +1,293 @@ +[[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.4/guide/ws_handlers/index.html b/docs/en/cowboy/2.4/guide/ws_handlers/index.html new file mode 100644 index 00000000..4f968880 --- /dev/null +++ b/docs/en/cowboy/2.4/guide/ws_handlers/index.html @@ -0,0 +1,457 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/guide/ws_protocol.asciidoc b/docs/en/cowboy/2.4/guide/ws_protocol.asciidoc new file mode 100644 index 00000000..8fa0673d --- /dev/null +++ b/docs/en/cowboy/2.4/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.4/guide/ws_protocol/index.html b/docs/en/cowboy/2.4/guide/ws_protocol/index.html new file mode 100644 index 00000000..a2d4940f --- /dev/null +++ b/docs/en/cowboy/2.4/guide/ws_protocol/index.html @@ -0,0 +1,230 @@ + + + + + + + + + + + + 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.4 + + User Guide +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..d75cfb58 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy.set_env/index.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..4cf35c19 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy.start_clear/index.html @@ -0,0 +1,286 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..5dda2be9 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy.start_tls/index.html @@ -0,0 +1,291 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..13508a00 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy.stop_listener/index.html @@ -0,0 +1,225 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy/index.html b/docs/en/cowboy/2.4/manual/cowboy/index.html new file mode 100644 index 00000000..d6eeeca0 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy/index.html @@ -0,0 +1,267 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_app/index.html b/docs/en/cowboy/2.4/manual/cowboy_app/index.html new file mode 100644 index 00000000..8c9d6efc --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_app/index.html @@ -0,0 +1,309 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..d3d6b650 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_constraints.int/index.html @@ -0,0 +1,230 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..2893057b --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_constraints.nonempty/index.html @@ -0,0 +1,229 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_constraints/index.html b/docs/en/cowboy/2.4/manual/cowboy_constraints/index.html new file mode 100644 index 00000000..cb1baf31 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_constraints/index.html @@ -0,0 +1,222 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..6708623a --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_handler.terminate/index.html @@ -0,0 +1,247 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_handler/index.html b/docs/en/cowboy/2.4/manual/cowboy_handler/index.html new file mode 100644 index 00000000..189b508a --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_handler/index.html @@ -0,0 +1,234 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_http/index.html b/docs/en/cowboy/2.4/manual/cowboy_http/index.html new file mode 100644 index 00000000..e1f64e6b --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_http/index.html @@ -0,0 +1,393 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_http2/index.html b/docs/en/cowboy/2.4/manual/cowboy_http2/index.html new file mode 100644 index 00000000..6812c92b --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_http2/index.html @@ -0,0 +1,375 @@ + + + + + + + + + + + + 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,
+    enable_connect_protocol        => boolean(),
+    env                            => cowboy_middleware:env(),
+    inactivity_timeout             => timeout(),
+    initial_connection_window_size => 65535..16#7fffffff,
+    initial_stream_window_size     => 0..16#7fffffff,
+    max_concurrent_streams         => non_neg_integer() | infinity,
+    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,
+    middlewares                    => [module()],
+    preface_timeout                => timeout(),
+    settings_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. +

    +
    +
    +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. +

    +
    +
    +env (#{}) +
    +
    +

    +Middleware environment. +

    +
    +
    +inactivity_timeout (300000) +
    +
    +

    +Time in ms with nothing received at all before Cowboy closes the connection. +

    +
    +
    +initial_connection_window_size (65535) +
    +
    +

    +Initial window size 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 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. +

    +
    +
    +max_concurrent_streams (infinity) +
    +
    +

    +Maximum number of concurrent streams allowed on the connection. +

    +
    +
    +max_decode_table_size (4096) +
    +
    +

    +Maximum header table size 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 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 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 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.

    +
    +
    +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. +

    +
    +
    +settings_timeout (5000) +
    +
    +

    +Time in ms Cowboy is willing to wait for a SETTINGS ack. +

    +
    +
    +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.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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_loop/index.html b/docs/en/cowboy/2.4/manual/cowboy_loop/index.html new file mode 100644 index 00000000..3e517be3 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_loop/index.html @@ -0,0 +1,258 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_middleware/index.html b/docs/en/cowboy/2.4/manual/cowboy_middleware/index.html new file mode 100644 index 00000000..4d70e3da --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_middleware/index.html @@ -0,0 +1,253 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..bf504c09 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.binding/index.html @@ -0,0 +1,254 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..e2747484 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.bindings/index.html @@ -0,0 +1,224 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..6fbda83b --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.body_length/index.html @@ -0,0 +1,227 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..5f761aaf --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.cert/index.html @@ -0,0 +1,242 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..b53e87d5 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.delete_resp_header/index.html @@ -0,0 +1,233 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..b2cfe7b1 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.has_body/index.html @@ -0,0 +1,218 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..13e1110a --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_body/index.html @@ -0,0 +1,220 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..a329a41b --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_header/index.html @@ -0,0 +1,233 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..ba2f448e --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.header/index.html @@ -0,0 +1,260 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..c872913f --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.headers/index.html @@ -0,0 +1,228 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..dabe2c0e --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.host/index.html @@ -0,0 +1,229 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..e7db77b8 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.host_info/index.html @@ -0,0 +1,225 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..2bf21662 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.inform/index.html @@ -0,0 +1,263 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..a7cc6a34 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.match_cookies/index.html @@ -0,0 +1,261 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..f468e0e2 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.match_qs/index.html @@ -0,0 +1,261 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..2993b906 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.method/index.html @@ -0,0 +1,238 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..21e81bd5 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.parse_cookies/index.html @@ -0,0 +1,229 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..b16bc351 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.parse_header/index.html @@ -0,0 +1,421 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..c373dfc3 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.parse_qs/index.html @@ -0,0 +1,255 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..71ac141b --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.path/index.html @@ -0,0 +1,228 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..cf44f2cc --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.path_info/index.html @@ -0,0 +1,225 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..1ab71723 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.peer/index.html @@ -0,0 +1,236 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..9afafb54 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.port/index.html @@ -0,0 +1,228 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..cde2c2a8 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.push/index.html @@ -0,0 +1,280 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..798c994a --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.qs/index.html @@ -0,0 +1,227 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..1e23391f --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.read_body/index.html @@ -0,0 +1,281 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..a85f4829 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.read_part/index.html @@ -0,0 +1,300 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..a50d2c0d --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.read_part_body/index.html @@ -0,0 +1,268 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..c16b1d95 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.read_urlencoded_body/index.html @@ -0,0 +1,264 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..3cc8b61b --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.reply/index.html @@ -0,0 +1,303 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..9b10d5d0 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.resp_header/index.html @@ -0,0 +1,251 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..d9094128 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.resp_headers/index.html @@ -0,0 +1,217 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..01d3cb92 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.scheme/index.html @@ -0,0 +1,227 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..5c01691e --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_body/index.html @@ -0,0 +1,276 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..61062274 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_cookie/index.html @@ -0,0 +1,305 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..0471a8cb --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_header/index.html @@ -0,0 +1,259 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..4f4a6243 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_headers/index.html @@ -0,0 +1,247 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..9d9fdbfb --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.sock/index.html @@ -0,0 +1,224 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..05f1a809 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.stream_body/index.html @@ -0,0 +1,257 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..d47053b0 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.stream_reply/index.html @@ -0,0 +1,290 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..baea4bd6 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.stream_trailers/index.html @@ -0,0 +1,245 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..f7842784 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.uri/index.html @@ -0,0 +1,315 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..bd56eff6 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req.version/index.html @@ -0,0 +1,226 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_req/index.html b/docs/en/cowboy/2.4/manual/cowboy_req/index.html new file mode 100644 index 00000000..1039c71d --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_req/index.html @@ -0,0 +1,552 @@ + + + + + + + + + + + + Nine Nines: cowboy_req(3) + + + + + + + + + + + + + + +
    +
    +
    +
    +

    99s

    +
    +
    + +
    + +
      +
    • + Github +
      • +
    • + +
      • +
    +
    +
    +
    +
    + + +
    + +
    +
    +
    +
    + +

    cowboy_req(3)

    + +
    +

    Name

    +
    +

    cowboy_req - HTTP request and response

    +
    +
    +
    +

    Description

    +
    +

    The module cowboy_req provides functions to access, manipulate +and respond to requests.

    +

    There are four types of functions in this module. They can be +differentiated by their name and their return type:

    +
    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Type Name pattern Return type

    access

    no verb, parse_*, match_*

    Value

    question

    has_*

    boolean()

    modification

    set_*

    Req

    action

    any other verb

    ok | {Result, Value, Req}

    +
    +

    Any Req returned must be used in place of the one passed as +argument. Functions that perform an action in particular write +state in the Req object to make sure you are using the function +correctly. For example, it’s only possible to send one response, +and to read the body once.

    +
    +
    +
    +

    Exports

    +
    +

    Connection:

    +
    +

    Raw request:

    +
    +

    Processed request:

    +
    +

    Request body:

    +
    +

    Response:

    +
    +
    +
    +
    +

    Types

    +
    +
    +

    push_opts()

    +
    +
    +
    push_opts() :: #{
+    method => binary(),            %% case sensitive
+    scheme => binary(),            %% lowercase; case insensitive
+    host   => binary(),            %% lowercase; case insensitive
+    port   => inet:port_number(),
+    qs     => binary()             %% case sensitive
+}
    +

    Push options.

    +

    By default, Cowboy will use the GET method, an empty query string, +and take the scheme, host and port directly from the current +request’s URI.

    +
    +
    +

    read_body_opts()

    +
    +
    +
    read_body_opts() :: #{
+    length  => non_neg_integer(),
+    period  => non_neg_integer(),
+    timeout => timeout()
+}
    +

    Body reading options.

    +

    The defaults are function-specific.

    +
    +
    +

    req()

    +
    +
    +
    req() :: #{
+    method  := binary(),               %% case sensitive
+    version := cowboy:http_version() | atom(),
+    scheme  := binary(),               %% lowercase; case insensitive
+    host    := binary(),               %% lowercase; case insensitive
+    port    := inet:port_number(),
+    path    := binary(),               %% case sensitive
+    qs      := binary(),               %% case sensitive
+    headers := cowboy:http_headers(),
+    peer    := {inet:ip_address(), inet:port_number()},
+    sock    := {inet:ip_address(), inet:port_number()},
+    cert    := binary() | undefined
+}
    +

    The Req object.

    +

    Contains information about the request and response. While +some fields are publicly documented, others aren’t and shouldn’t +be used.

    +

    You may add custom fields if required. Make sure to namespace +them by prepending an underscore and the name of your application:

    +
    +
    Setting a custom field
    +
    +
    Req#{_myapp_auth_method => pubkey}.
    +
    +
    +

    resp_body()

    +
    +
    +
    resp_body() :: iodata()
+    | {sendfile, Offset, Length, Filename}
+
+Offset   :: non_neg_integer()
+Length   :: non_neg_integer()
+Filename :: file:name_all()
    +

    Response body.

    +

    It can take two forms: the actual data to be sent or a +tuple indicating which file to send.

    +

    When sending data directly, the type is either a binary or +an iolist. Iolists are an efficient way to build output. +Instead of concatenating strings or binaries, you can simply +build a list containing the fragments you want to send in the +order they should be sent:

    +
    +
    Example iolists usage
    +
    +
    1> RespBody = ["Hello ", [<<"world">>, $!]].
+["Hello ",[<<"world">>,33]]
+2> io:format("~s~n", [RespBody]).
+Hello world!
    +

    Note that the length must be greater than zero for any data +to be sent. Cowboy will send an empty body when the length +is zero.

    +
    +
    +
    +
    +

    See also

    +
    +

    cowboy(7)

    +
    +
    + + + + + +
    + +
    + + +

    + Cowboy + 2.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_rest/index.html b/docs/en/cowboy/2.4/manual/cowboy_rest/index.html new file mode 100644 index 00000000..52e111b4 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_rest/index.html @@ -0,0 +1,808 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..88b75a84 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_router.compile/index.html @@ -0,0 +1,225 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_router/index.html b/docs/en/cowboy/2.4/manual/cowboy_router/index.html new file mode 100644 index 00000000..4e6dcd77 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_router/index.html @@ -0,0 +1,248 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_static/index.html b/docs/en/cowboy/2.4/manual/cowboy_static/index.html new file mode 100644 index 00000000..89cd6752 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_static/index.html @@ -0,0 +1,313 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_stream/index.html b/docs/en/cowboy/2.4/manual/cowboy_stream/index.html new file mode 100644 index 00000000..c42b4619 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_stream/index.html @@ -0,0 +1,590 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/cowboy_websocket/index.html b/docs/en/cowboy/2.4/manual/cowboy_websocket/index.html new file mode 100644 index 00000000..8f791a65 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/cowboy_websocket/index.html @@ -0,0 +1,446 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + 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 new file mode 100644 index 00000000..3fd73989 --- /dev/null +++ b/docs/en/cowboy/2.4/manual/http_status_codes/index.html @@ -0,0 +1,409 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/cowboy/2.4/manual/index.html b/docs/en/cowboy/2.4/manual/index.html new file mode 100644 index 00000000..34f7b08e --- /dev/null +++ b/docs/en/cowboy/2.4/manual/index.html @@ -0,0 +1,309 @@ + + + + + + + + + + + + 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.4 + Function Reference + +

    + + + +

    Navigation

    + +

    Version select

    + + +
    +
    +
    +
    + + + + + + + + + diff --git a/docs/en/erlang.mk/1/guide/app/index.html b/docs/en/erlang.mk/1/guide/app/index.html index 9c306556..efc60e99 100644 --- a/docs/en/erlang.mk/1/guide/app/index.html +++ b/docs/en/erlang.mk/1/guide/app/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/asciidoc/index.html b/docs/en/erlang.mk/1/guide/asciidoc/index.html index a04f5011..472047e8 100644 --- a/docs/en/erlang.mk/1/guide/asciidoc/index.html +++ b/docs/en/erlang.mk/1/guide/asciidoc/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/ci/index.html b/docs/en/erlang.mk/1/guide/ci/index.html index 69c44290..1edf4b3f 100644 --- a/docs/en/erlang.mk/1/guide/ci/index.html +++ b/docs/en/erlang.mk/1/guide/ci/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/common_test/index.html b/docs/en/erlang.mk/1/guide/common_test/index.html index 1b489117..796acdef 100644 --- a/docs/en/erlang.mk/1/guide/common_test/index.html +++ b/docs/en/erlang.mk/1/guide/common_test/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/compat/index.html b/docs/en/erlang.mk/1/guide/compat/index.html index 45670757..9f7facac 100644 --- a/docs/en/erlang.mk/1/guide/compat/index.html +++ b/docs/en/erlang.mk/1/guide/compat/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/contributing/index.html b/docs/en/erlang.mk/1/guide/contributing/index.html index 09bcefb0..8db4fccd 100644 --- a/docs/en/erlang.mk/1/guide/contributing/index.html +++ b/docs/en/erlang.mk/1/guide/contributing/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/coverage/index.html b/docs/en/erlang.mk/1/guide/coverage/index.html index e6c98550..34654df8 100644 --- a/docs/en/erlang.mk/1/guide/coverage/index.html +++ b/docs/en/erlang.mk/1/guide/coverage/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/deps/index.html b/docs/en/erlang.mk/1/guide/deps/index.html index d0eb0981..5ae07067 100644 --- a/docs/en/erlang.mk/1/guide/deps/index.html +++ b/docs/en/erlang.mk/1/guide/deps/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/dialyzer/index.html b/docs/en/erlang.mk/1/guide/dialyzer/index.html index 7e44242a..2871be37 100644 --- a/docs/en/erlang.mk/1/guide/dialyzer/index.html +++ b/docs/en/erlang.mk/1/guide/dialyzer/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/edoc/index.html b/docs/en/erlang.mk/1/guide/edoc/index.html index 246b02e8..a2d9768a 100644 --- a/docs/en/erlang.mk/1/guide/edoc/index.html +++ b/docs/en/erlang.mk/1/guide/edoc/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/escripts/index.html b/docs/en/erlang.mk/1/guide/escripts/index.html index 5499de50..db613287 100644 --- a/docs/en/erlang.mk/1/guide/escripts/index.html +++ b/docs/en/erlang.mk/1/guide/escripts/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/eunit/index.html b/docs/en/erlang.mk/1/guide/eunit/index.html index 3fcd1a18..400904eb 100644 --- a/docs/en/erlang.mk/1/guide/eunit/index.html +++ b/docs/en/erlang.mk/1/guide/eunit/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/external_plugins/index.html b/docs/en/erlang.mk/1/guide/external_plugins/index.html index 11bb6e6a..6926b076 100644 --- a/docs/en/erlang.mk/1/guide/external_plugins/index.html +++ b/docs/en/erlang.mk/1/guide/external_plugins/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/external_plugins_list/index.html b/docs/en/erlang.mk/1/guide/external_plugins_list/index.html index 237c4e1d..e0b98ca7 100644 --- a/docs/en/erlang.mk/1/guide/external_plugins_list/index.html +++ b/docs/en/erlang.mk/1/guide/external_plugins_list/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/getting_started.asciidoc b/docs/en/erlang.mk/1/guide/getting_started.asciidoc index ca1391d6..de40f364 100644 --- a/docs/en/erlang.mk/1/guide/getting_started.asciidoc +++ b/docs/en/erlang.mk/1/guide/getting_started.asciidoc @@ -242,7 +242,7 @@ target: [source,bash] $ make list-templates -Available templates: cowboy_http cowboy_loop cowboy_rest cowboy_ws gen_fsm gen_server ranch_protocol supervisor +Available templates: cowboy_http cowboy_loop cowboy_rest cowboy_ws gen_fsm gen_server gen_statem ranch_protocol supervisor To generate a module, let's say a `gen_server`, all you need to do is to call `make new` with the appropriate arguments: diff --git a/docs/en/erlang.mk/1/guide/getting_started/index.html b/docs/en/erlang.mk/1/guide/getting_started/index.html index b4b410f6..3392581e 100644 --- a/docs/en/erlang.mk/1/guide/getting_started/index.html +++ b/docs/en/erlang.mk/1/guide/getting_started/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • @@ -336,7 +333,7 @@ by Lorenzo Bettini http://www.lorenzobettini.it http://www.gnu.org/software/src-highlite --> 
    $ make list-templates
-Available templates: cowboy_http cowboy_loop cowboy_rest cowboy_ws gen_fsm gen_server ranch_protocol supervisor
    +Available templates: cowboy_http cowboy_loop cowboy_rest cowboy_ws gen_fsm gen_server gen_statem ranch_protocol supervisor

    To generate a module, let’s say a gen_server, all you need to do is to call make new with the appropriate arguments:

    diff --git a/docs/en/erlang.mk/1/guide/history/index.html b/docs/en/erlang.mk/1/guide/history/index.html index c4ab9746..44c6ad5a 100644 --- a/docs/en/erlang.mk/1/guide/history/index.html +++ b/docs/en/erlang.mk/1/guide/history/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/index.html b/docs/en/erlang.mk/1/guide/index.html index 27718631..b1cae2a3 100644 --- a/docs/en/erlang.mk/1/guide/index.html +++ b/docs/en/erlang.mk/1/guide/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/installation/index.html b/docs/en/erlang.mk/1/guide/installation/index.html index d17abc3d..98f3cabc 100644 --- a/docs/en/erlang.mk/1/guide/installation/index.html +++ b/docs/en/erlang.mk/1/guide/installation/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/kerl/index.html b/docs/en/erlang.mk/1/guide/kerl/index.html index 3915528b..f69bc861 100644 --- a/docs/en/erlang.mk/1/guide/kerl/index.html +++ b/docs/en/erlang.mk/1/guide/kerl/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/limitations/index.html b/docs/en/erlang.mk/1/guide/limitations/index.html index 2a035805..2ac12f31 100644 --- a/docs/en/erlang.mk/1/guide/limitations/index.html +++ b/docs/en/erlang.mk/1/guide/limitations/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/overview/index.html b/docs/en/erlang.mk/1/guide/overview/index.html index 3ca0d870..f2753d74 100644 --- a/docs/en/erlang.mk/1/guide/overview/index.html +++ b/docs/en/erlang.mk/1/guide/overview/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/ports/index.html b/docs/en/erlang.mk/1/guide/ports/index.html index 12e9f8f0..44ba67c1 100644 --- a/docs/en/erlang.mk/1/guide/ports/index.html +++ b/docs/en/erlang.mk/1/guide/ports/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/releases/index.html b/docs/en/erlang.mk/1/guide/releases/index.html index f920ba34..547a648f 100644 --- a/docs/en/erlang.mk/1/guide/releases/index.html +++ b/docs/en/erlang.mk/1/guide/releases/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/sfx/index.html b/docs/en/erlang.mk/1/guide/sfx/index.html index bb5312a4..e23a0856 100644 --- a/docs/en/erlang.mk/1/guide/sfx/index.html +++ b/docs/en/erlang.mk/1/guide/sfx/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/shell/index.html b/docs/en/erlang.mk/1/guide/shell/index.html index 89982b16..e4af2686 100644 --- a/docs/en/erlang.mk/1/guide/shell/index.html +++ b/docs/en/erlang.mk/1/guide/shell/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/sphinx/index.html b/docs/en/erlang.mk/1/guide/sphinx/index.html index 1f4a28a0..bcf2ac5a 100644 --- a/docs/en/erlang.mk/1/guide/sphinx/index.html +++ b/docs/en/erlang.mk/1/guide/sphinx/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/updating/index.html b/docs/en/erlang.mk/1/guide/updating/index.html index 9685e7a6..510f0a1c 100644 --- a/docs/en/erlang.mk/1/guide/updating/index.html +++ b/docs/en/erlang.mk/1/guide/updating/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/why/index.html b/docs/en/erlang.mk/1/guide/why/index.html index a5c5b2da..1318ed5f 100644 --- a/docs/en/erlang.mk/1/guide/why/index.html +++ b/docs/en/erlang.mk/1/guide/why/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/erlang.mk/1/guide/xref/index.html b/docs/en/erlang.mk/1/guide/xref/index.html index 17f40048..80960265 100644 --- a/docs/en/erlang.mk/1/guide/xref/index.html +++ b/docs/en/erlang.mk/1/guide/xref/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/gun/1.0/guide/connect/index.html b/docs/en/gun/1.0/guide/connect/index.html index 41c132f3..1e35e16b 100644 --- a/docs/en/gun/1.0/guide/connect/index.html +++ b/docs/en/gun/1.0/guide/connect/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/gun/1.0/guide/http/index.html b/docs/en/gun/1.0/guide/http/index.html index 6c492970..2753588e 100644 --- a/docs/en/gun/1.0/guide/http/index.html +++ b/docs/en/gun/1.0/guide/http/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/gun/1.0/guide/index.html b/docs/en/gun/1.0/guide/index.html index 2bf57faf..f7e4b26e 100644 --- a/docs/en/gun/1.0/guide/index.html +++ b/docs/en/gun/1.0/guide/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/gun/1.0/guide/introduction/index.html b/docs/en/gun/1.0/guide/introduction/index.html index ecf8144a..5a59d78a 100644 --- a/docs/en/gun/1.0/guide/introduction/index.html +++ b/docs/en/gun/1.0/guide/introduction/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/gun/1.0/guide/protocols/index.html b/docs/en/gun/1.0/guide/protocols/index.html index 05d5244b..b94891f0 100644 --- a/docs/en/gun/1.0/guide/protocols/index.html +++ b/docs/en/gun/1.0/guide/protocols/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/gun/1.0/guide/start/index.html b/docs/en/gun/1.0/guide/start/index.html index a72e47d7..d2e8f0aa 100644 --- a/docs/en/gun/1.0/guide/start/index.html +++ b/docs/en/gun/1.0/guide/start/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/gun/1.0/guide/websocket/index.html b/docs/en/gun/1.0/guide/websocket/index.html index a4c62add..b34a290d 100644 --- a/docs/en/gun/1.0/guide/websocket/index.html +++ b/docs/en/gun/1.0/guide/websocket/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/gun/1.0/manual/gun/index.html b/docs/en/gun/1.0/manual/gun/index.html index 89bee541..3ba36987 100644 --- a/docs/en/gun/1.0/manual/gun/index.html +++ b/docs/en/gun/1.0/manual/gun/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/gun/1.0/manual/gun_app/index.html b/docs/en/gun/1.0/manual/gun_app/index.html index 60387c9c..429cc0dd 100644 --- a/docs/en/gun/1.0/manual/gun_app/index.html +++ b/docs/en/gun/1.0/manual/gun_app/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/gun/1.0/manual/index.html b/docs/en/gun/1.0/manual/index.html index 3e091a83..d8304a20 100644 --- a/docs/en/gun/1.0/manual/index.html +++ b/docs/en/gun/1.0/manual/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/guide/embedded/index.html b/docs/en/ranch/1.2/guide/embedded/index.html index e4e3a11f..3ad4b2aa 100644 --- a/docs/en/ranch/1.2/guide/embedded/index.html +++ b/docs/en/ranch/1.2/guide/embedded/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/guide/index.html b/docs/en/ranch/1.2/guide/index.html index 0d5a6503..e01585e9 100644 --- a/docs/en/ranch/1.2/guide/index.html +++ b/docs/en/ranch/1.2/guide/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/guide/internals/index.html b/docs/en/ranch/1.2/guide/internals/index.html index 8ca29ae2..22fcd020 100644 --- a/docs/en/ranch/1.2/guide/internals/index.html +++ b/docs/en/ranch/1.2/guide/internals/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/guide/introduction/index.html b/docs/en/ranch/1.2/guide/introduction/index.html index fc0cf299..c553ea6b 100644 --- a/docs/en/ranch/1.2/guide/introduction/index.html +++ b/docs/en/ranch/1.2/guide/introduction/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/guide/listeners/index.html b/docs/en/ranch/1.2/guide/listeners/index.html index a0192ad5..0ae67746 100644 --- a/docs/en/ranch/1.2/guide/listeners/index.html +++ b/docs/en/ranch/1.2/guide/listeners/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/guide/parsers/index.html b/docs/en/ranch/1.2/guide/parsers/index.html index 9ac5d824..21fea8a2 100644 --- a/docs/en/ranch/1.2/guide/parsers/index.html +++ b/docs/en/ranch/1.2/guide/parsers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/guide/protocols/index.html b/docs/en/ranch/1.2/guide/protocols/index.html index 43055581..7f6d2368 100644 --- a/docs/en/ranch/1.2/guide/protocols/index.html +++ b/docs/en/ranch/1.2/guide/protocols/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/guide/ssl_auth/index.html b/docs/en/ranch/1.2/guide/ssl_auth/index.html index 1f1be24c..a8922b62 100644 --- a/docs/en/ranch/1.2/guide/ssl_auth/index.html +++ b/docs/en/ranch/1.2/guide/ssl_auth/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/guide/transports/index.html b/docs/en/ranch/1.2/guide/transports/index.html index 066b0352..b270d522 100644 --- a/docs/en/ranch/1.2/guide/transports/index.html +++ b/docs/en/ranch/1.2/guide/transports/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/manual/index.html b/docs/en/ranch/1.2/manual/index.html index 02a780cb..0ea115d0 100644 --- a/docs/en/ranch/1.2/manual/index.html +++ b/docs/en/ranch/1.2/manual/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/manual/ranch/index.html b/docs/en/ranch/1.2/manual/ranch/index.html index a6522789..308436b3 100644 --- a/docs/en/ranch/1.2/manual/ranch/index.html +++ b/docs/en/ranch/1.2/manual/ranch/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/manual/ranch_app/index.html b/docs/en/ranch/1.2/manual/ranch_app/index.html index 584334aa..29ede7bc 100644 --- a/docs/en/ranch/1.2/manual/ranch_app/index.html +++ b/docs/en/ranch/1.2/manual/ranch_app/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/manual/ranch_protocol/index.html b/docs/en/ranch/1.2/manual/ranch_protocol/index.html index 9e657680..7c67fbc1 100644 --- a/docs/en/ranch/1.2/manual/ranch_protocol/index.html +++ b/docs/en/ranch/1.2/manual/ranch_protocol/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/manual/ranch_ssl/index.html b/docs/en/ranch/1.2/manual/ranch_ssl/index.html index ae3e986c..d886d3d4 100644 --- a/docs/en/ranch/1.2/manual/ranch_ssl/index.html +++ b/docs/en/ranch/1.2/manual/ranch_ssl/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/manual/ranch_tcp/index.html b/docs/en/ranch/1.2/manual/ranch_tcp/index.html index eb0d7c12..a4602a83 100644 --- a/docs/en/ranch/1.2/manual/ranch_tcp/index.html +++ b/docs/en/ranch/1.2/manual/ranch_tcp/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.2/manual/ranch_transport/index.html b/docs/en/ranch/1.2/manual/ranch_transport/index.html index 5fbbca6f..149f24d8 100644 --- a/docs/en/ranch/1.2/manual/ranch_transport/index.html +++ b/docs/en/ranch/1.2/manual/ranch_transport/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/guide/embedded/index.html b/docs/en/ranch/1.3/guide/embedded/index.html index 3c69ff5e..ac979b84 100644 --- a/docs/en/ranch/1.3/guide/embedded/index.html +++ b/docs/en/ranch/1.3/guide/embedded/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/guide/index.html b/docs/en/ranch/1.3/guide/index.html index c265d403..8583e635 100644 --- a/docs/en/ranch/1.3/guide/index.html +++ b/docs/en/ranch/1.3/guide/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/guide/internals/index.html b/docs/en/ranch/1.3/guide/internals/index.html index 05faacd2..17910ebe 100644 --- a/docs/en/ranch/1.3/guide/internals/index.html +++ b/docs/en/ranch/1.3/guide/internals/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/guide/introduction/index.html b/docs/en/ranch/1.3/guide/introduction/index.html index 5da59da3..2edc19c0 100644 --- a/docs/en/ranch/1.3/guide/introduction/index.html +++ b/docs/en/ranch/1.3/guide/introduction/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/guide/listeners/index.html b/docs/en/ranch/1.3/guide/listeners/index.html index 8e8f43be..a1fc6723 100644 --- a/docs/en/ranch/1.3/guide/listeners/index.html +++ b/docs/en/ranch/1.3/guide/listeners/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/guide/parsers/index.html b/docs/en/ranch/1.3/guide/parsers/index.html index 0dd5880b..1b5f03a7 100644 --- a/docs/en/ranch/1.3/guide/parsers/index.html +++ b/docs/en/ranch/1.3/guide/parsers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/guide/protocols/index.html b/docs/en/ranch/1.3/guide/protocols/index.html index 3cc98ab5..ae30aa4a 100644 --- a/docs/en/ranch/1.3/guide/protocols/index.html +++ b/docs/en/ranch/1.3/guide/protocols/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/guide/ssl_auth/index.html b/docs/en/ranch/1.3/guide/ssl_auth/index.html index f9fb94cf..1f93cd9e 100644 --- a/docs/en/ranch/1.3/guide/ssl_auth/index.html +++ b/docs/en/ranch/1.3/guide/ssl_auth/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/guide/transports/index.html b/docs/en/ranch/1.3/guide/transports/index.html index e326d7f5..6d61fd72 100644 --- a/docs/en/ranch/1.3/guide/transports/index.html +++ b/docs/en/ranch/1.3/guide/transports/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/manual/index.html b/docs/en/ranch/1.3/manual/index.html index 3936e278..8c695c6e 100644 --- a/docs/en/ranch/1.3/manual/index.html +++ b/docs/en/ranch/1.3/manual/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/manual/ranch/index.html b/docs/en/ranch/1.3/manual/ranch/index.html index ac8589ac..e423a00a 100644 --- a/docs/en/ranch/1.3/manual/ranch/index.html +++ b/docs/en/ranch/1.3/manual/ranch/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/manual/ranch_app/index.html b/docs/en/ranch/1.3/manual/ranch_app/index.html index 983b57ae..7b1ff872 100644 --- a/docs/en/ranch/1.3/manual/ranch_app/index.html +++ b/docs/en/ranch/1.3/manual/ranch_app/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/manual/ranch_protocol/index.html b/docs/en/ranch/1.3/manual/ranch_protocol/index.html index dedef7c0..151d0289 100644 --- a/docs/en/ranch/1.3/manual/ranch_protocol/index.html +++ b/docs/en/ranch/1.3/manual/ranch_protocol/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/manual/ranch_ssl/index.html b/docs/en/ranch/1.3/manual/ranch_ssl/index.html index 321541fb..0ab6e4ad 100644 --- a/docs/en/ranch/1.3/manual/ranch_ssl/index.html +++ b/docs/en/ranch/1.3/manual/ranch_ssl/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/manual/ranch_tcp/index.html b/docs/en/ranch/1.3/manual/ranch_tcp/index.html index fd07e0f3..21a772c8 100644 --- a/docs/en/ranch/1.3/manual/ranch_tcp/index.html +++ b/docs/en/ranch/1.3/manual/ranch_tcp/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.3/manual/ranch_transport/index.html b/docs/en/ranch/1.3/manual/ranch_transport/index.html index 097d353a..03d6953e 100644 --- a/docs/en/ranch/1.3/manual/ranch_transport/index.html +++ b/docs/en/ranch/1.3/manual/ranch_transport/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/guide/embedded/index.html b/docs/en/ranch/1.4/guide/embedded/index.html index a3d5ef05..81bec935 100644 --- a/docs/en/ranch/1.4/guide/embedded/index.html +++ b/docs/en/ranch/1.4/guide/embedded/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/guide/index.html b/docs/en/ranch/1.4/guide/index.html index fdefd376..3d3edbdc 100644 --- a/docs/en/ranch/1.4/guide/index.html +++ b/docs/en/ranch/1.4/guide/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/guide/internals/index.html b/docs/en/ranch/1.4/guide/internals/index.html index 2cde8d96..53ba887a 100644 --- a/docs/en/ranch/1.4/guide/internals/index.html +++ b/docs/en/ranch/1.4/guide/internals/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/guide/introduction/index.html b/docs/en/ranch/1.4/guide/introduction/index.html index d379a374..6e7703c1 100644 --- a/docs/en/ranch/1.4/guide/introduction/index.html +++ b/docs/en/ranch/1.4/guide/introduction/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/guide/listeners/index.html b/docs/en/ranch/1.4/guide/listeners/index.html index 4c69115a..17b94deb 100644 --- a/docs/en/ranch/1.4/guide/listeners/index.html +++ b/docs/en/ranch/1.4/guide/listeners/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/guide/parsers/index.html b/docs/en/ranch/1.4/guide/parsers/index.html index c272bff7..7b8d3b1f 100644 --- a/docs/en/ranch/1.4/guide/parsers/index.html +++ b/docs/en/ranch/1.4/guide/parsers/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/guide/protocols/index.html b/docs/en/ranch/1.4/guide/protocols/index.html index f0d4dda7..44b4ae6b 100644 --- a/docs/en/ranch/1.4/guide/protocols/index.html +++ b/docs/en/ranch/1.4/guide/protocols/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/guide/ssl_auth/index.html b/docs/en/ranch/1.4/guide/ssl_auth/index.html index 81a08389..cbc2713a 100644 --- a/docs/en/ranch/1.4/guide/ssl_auth/index.html +++ b/docs/en/ranch/1.4/guide/ssl_auth/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/guide/transports/index.html b/docs/en/ranch/1.4/guide/transports/index.html index f1cc1691..d5256199 100644 --- a/docs/en/ranch/1.4/guide/transports/index.html +++ b/docs/en/ranch/1.4/guide/transports/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/manual/index.html b/docs/en/ranch/1.4/manual/index.html index ff76ea30..281520d0 100644 --- a/docs/en/ranch/1.4/manual/index.html +++ b/docs/en/ranch/1.4/manual/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/manual/ranch/index.html b/docs/en/ranch/1.4/manual/ranch/index.html index ec072088..33a3385b 100644 --- a/docs/en/ranch/1.4/manual/ranch/index.html +++ b/docs/en/ranch/1.4/manual/ranch/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/manual/ranch_app/index.html b/docs/en/ranch/1.4/manual/ranch_app/index.html index de65b0ec..9fb5af9c 100644 --- a/docs/en/ranch/1.4/manual/ranch_app/index.html +++ b/docs/en/ranch/1.4/manual/ranch_app/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/manual/ranch_protocol/index.html b/docs/en/ranch/1.4/manual/ranch_protocol/index.html index 6f42e1c4..ec8590a7 100644 --- a/docs/en/ranch/1.4/manual/ranch_protocol/index.html +++ b/docs/en/ranch/1.4/manual/ranch_protocol/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/manual/ranch_ssl/index.html b/docs/en/ranch/1.4/manual/ranch_ssl/index.html index 1c0ab925..7b53c4f7 100644 --- a/docs/en/ranch/1.4/manual/ranch_ssl/index.html +++ b/docs/en/ranch/1.4/manual/ranch_ssl/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/manual/ranch_tcp/index.html b/docs/en/ranch/1.4/manual/ranch_tcp/index.html index 3f38ea93..eb4e550b 100644 --- a/docs/en/ranch/1.4/manual/ranch_tcp/index.html +++ b/docs/en/ranch/1.4/manual/ranch_tcp/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • diff --git a/docs/en/ranch/1.4/manual/ranch_transport/index.html b/docs/en/ranch/1.4/manual/ranch_transport/index.html index 9e6c5c6b..f137aec4 100644 --- a/docs/en/ranch/1.4/manual/ranch_transport/index.html +++ b/docs/en/ranch/1.4/manual/ranch_transport/index.html @@ -45,9 +45,6 @@
  • Github
    • -
  • - -
    • -- cgit v1.2.3