diff options
| author | Loïc Hoguin <[email protected]> | 2018-06-13 09:54:12 +0200 |
|---|---|---|
| committer | Loïc Hoguin <[email protected]> | 2018-06-13 09:54:12 +0200 |
| commit | 92b54aacc0de5446dd5497c39897b0bbff72e626 (patch) | |
| tree | c3a98cfec636d1271f5804e5c19b35b208bba00d /docs/index.xml | |
| parent | 8b5c3dc972b99f174750123c9e4abc96259c34a9 (diff) | |
| download | ninenines.eu-92b54aacc0de5446dd5497c39897b0bbff72e626.tar.gz ninenines.eu-92b54aacc0de5446dd5497c39897b0bbff72e626.tar.bz2 ninenines.eu-92b54aacc0de5446dd5497c39897b0bbff72e626.zip | |
Rebuild using Asciideck
Diffstat (limited to 'docs/index.xml')
| -rw-r--r-- | docs/index.xml | 3634 |
1 files changed, 2048 insertions, 1586 deletions
diff --git a/docs/index.xml b/docs/index.xml index 1089c86f..33a58867 100644 --- a/docs/index.xml +++ b/docs/index.xml @@ -17,8 +17,9 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/installation/</guid> <description>On Unix Erlang.mk requires GNU Make to be installed. While it will currently work with GNU Make 3.81, support for this version is deprecated and will be removed in 2017. We recommend GNU Make 4.1 or later. - Git and Erlang/OTP must also be installed. - Some functionality requires that Autoconf 2.59 or later be installed, in order to compile Erlang/OTP. Erlang/OTP may have further requirements depending on your needs.</description> +Git and Erlang/OTP must also be installed. +Some functionality requires that Autoconf 2.59 or later be installed, in order to compile Erlang/OTP. Erlang/OTP may have further requirements depending on your needs. +Some packages may require additional libraries.</description> </item> <item> @@ -28,11 +29,12 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/guide/introduction/</guid> <description>Gun is an HTTP client for Erlang/OTP. - Gun supports the HTTP/2, HTTP/1.1 and Websocket protocols. - Prerequisites Knowledge of Erlang, but also of the HTTP/1.1, HTTP/2 and Websocket protocols is required in order to read this guide. - Supported platforms Gun is tested and supported on Linux, FreeBSD, Windows and OSX. - Gun is developed for Erlang/OTP 19.0 and newer. - License Gun uses the ISC License.</description> +Gun supports the HTTP/2, HTTP/1.1 and Websocket protocols. +Prerequisites Knowledge of Erlang, but also of the HTTP/1.1, HTTP/2 and Websocket protocols is required in order to read this guide. +Supported platforms Gun is tested and supported on Linux, FreeBSD, Windows and OSX. +Gun is developed for Erlang/OTP 19.0 and newer. +License Gun uses the ISC License. +Copyright (c) 2013-2018, Loïc Hoguin &lt;[email protected]&gt; 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.</description> </item> <item> @@ -42,9 +44,9 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/guide/introduction/</guid> <description>Ranch is a socket acceptor pool for TCP protocols. - Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own. - Prerequisites It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols. - Supported platforms Ranch is tested and supported on Linux.</description> +Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own. +Prerequisites It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols. +Supported platforms Ranch is tested and supported on Linux.</description> </item> <item> @@ -54,9 +56,9 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/guide/introduction/</guid> <description>Ranch is a socket acceptor pool for TCP protocols. - Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own. - Prerequisites It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols. - Supported platforms Ranch is tested and supported on Linux, FreeBSD, OSX and Windows.</description> +Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own. +Prerequisites It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols. +Supported platforms Ranch is tested and supported on Linux, FreeBSD, OSX and Windows.</description> </item> <item> @@ -66,9 +68,21 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/guide/introduction/</guid> <description>Ranch is a socket acceptor pool for TCP protocols. - Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own. - Prerequisites It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols. - Supported platforms Ranch is tested and supported on Linux, FreeBSD, OSX and Windows.</description> +Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own. +Prerequisites It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols. +Supported platforms Ranch is tested and supported on Linux, FreeBSD, OSX and Windows.</description> + </item> + + <item> + <title>Introduction</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/guide/introduction/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/guide/introduction/</guid> + <description>Ranch is a socket acceptor pool for TCP protocols. +Ranch aims to provide everything you need to accept TCP connections with a small code base and low latency while being easy to use directly as an application or to embed into your own. +Prerequisites It is assumed the developer already knows Erlang and has some experience with socket programming and TCP protocols. +Supported platforms Ranch is tested and supported on Linux, FreeBSD, OSX and Windows.</description> </item> <item> @@ -78,8 +92,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/modern_web/</guid> <description>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.</description> +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.</description> </item> <item> @@ -89,8 +103,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/modern_web/</guid> <description>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.</description> +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.</description> </item> <item> @@ -100,8 +114,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/modern_web/</guid> <description>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.</description> +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.</description> </item> <item> @@ -111,8 +125,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/modern_web/</guid> <description>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.</description> +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.</description> </item> <item> @@ -122,8 +136,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/modern_web/</guid> <description>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.</description> +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.</description> </item> <item> @@ -133,7 +147,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/erlang_web/</guid> <description>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.</description> +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.</description> </item> <item> @@ -143,7 +157,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/erlang_web/</guid> <description>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.</description> +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.</description> </item> <item> @@ -153,7 +167,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/erlang_web/</guid> <description>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.</description> +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.</description> </item> <item> @@ -163,7 +177,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/erlang_web/</guid> <description>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.</description> +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.</description> </item> <item> @@ -173,7 +187,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/erlang_web/</guid> <description>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.</description> +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.</description> </item> <item> @@ -183,8 +197,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/getting_started/</guid> <description>This chapter explains how to get started using Erlang.mk. - Creating a folder for your project The first step is always to create a new folder that will contain your project. - $ mkdir hello_joe $ cd hello_joe Most people tend to put all their projects side by side in a common folder. We recommend keeping an organization similar to your remote repositories. For example, for GitHub users, put all your projects in a common folder with the same name as your username.</description> +Creating a folder for your project The first step is always to create a new folder that will contain your project. +$ mkdir hello_joe $ cd hello_joe Most people tend to put all their projects side by side in a common folder. We recommend keeping an organization similar to your remote repositories. For example, for GitHub users, put all your projects in a common folder with the same name as your username.</description> </item> <item> @@ -194,7 +208,7 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/guide/listeners/</guid> <description>A listener is a set of processes whose role is to listen on a port for new connections. It manages a pool of acceptor processes, each of them indefinitely accepting connections. When it does, it starts a new process executing the protocol handler code. All the socket programming is abstracted through the user of transport handlers. - The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application.</description> +The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application.</description> </item> <item> @@ -204,7 +218,7 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/guide/listeners/</guid> <description>A listener is a set of processes whose role is to listen on a port for new connections. It manages a pool of acceptor processes, each of them indefinitely accepting connections. When it does, it starts a new process executing the protocol handler code. All the socket programming is abstracted through the use of transport handlers. - The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application.</description> +The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application.</description> </item> <item> @@ -214,7 +228,17 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/guide/listeners/</guid> <description>A listener is a set of processes whose role is to listen on a port for new connections. It manages a pool of acceptor processes, each of them indefinitely accepting connections. When it does, it starts a new process executing the protocol handler code. All the socket programming is abstracted through the use of transport handlers. - The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application.</description> +The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application.</description> + </item> + + <item> + <title>Listeners</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/guide/listeners/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/guide/listeners/</guid> + <description>A listener is a set of processes whose role is to listen on a port for new connections. It manages a pool of acceptor processes, each of them indefinitely accepting connections. When it does, it starts a new process executing the protocol handler code. All the socket programming is abstracted through the use of transport handlers. +The listener takes care of supervising all the acceptor and connection processes, allowing developers to focus on building their application.</description> </item> <item> @@ -224,9 +248,10 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/guide/start/</guid> <description>This chapter describes how to start and stop the Gun application. - Setting up Specify Gun as a dependency to your application in your favorite build tool. - With Erlang.mk this is done by adding gun to the DEPS variable in your Makefile. - Adding Gun as an Erlang.mk dependency DEPS = gun Starting Gun is an OTP application. It needs to be started before you can use it.</description> +Setting up Specify Gun as a dependency to your application in your favorite build tool. +With Erlang.mk this is done by adding gun to the DEPS variable in your Makefile. +Adding Gun as an Erlang.mk dependency DEPS = gun Starting Gun is an OTP application. It needs to be started before you can use it. +Starting Gun in an Erlang shell 1&gt; application:ensure_all_started(gun).</description> </item> <item> @@ -236,9 +261,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/guide/protocols/</guid> <description>This chapter describes the protocols supported and the operations available to them. - HTTP/1.1 HTTP/1.1 is a text request-response protocol. The client sends a request, the server sends back a response. - Gun provides convenience functions for performing GET, HEAD, OPTIONS, POST, PATCH, PUT, and DELETE requests. All these functions are aliases of gun:request/4,5,6 for the respective methods. Gun also provides a gun:data/4 function for streaming the request body. - Gun will send a gun_inform message for every intermediate informational responses received.</description> +HTTP/1.1 HTTP/1.1 is a text request-response protocol. The client sends a request, the server sends back a response. +Gun provides convenience functions for performing GET, HEAD, OPTIONS, POST, PATCH, PUT, and DELETE requests. All these functions are aliases of gun:request/4,5,6 for the respective methods. Gun also provides a gun:data/4 function for streaming the request body. +Gun will send a gun_inform message for every intermediate informational responses received.</description> </item> <item> @@ -248,9 +273,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/introduction/</guid> <description>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.</description> +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.</description> </item> <item> @@ -260,9 +285,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/introduction/</guid> <description>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.</description> +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.</description> </item> <item> @@ -272,9 +297,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/introduction/</guid> <description>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.</description> +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.</description> </item> <item> @@ -284,9 +309,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/introduction/</guid> <description>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.</description> +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.</description> </item> <item> @@ -296,9 +321,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/introduction/</guid> <description>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.</description> +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.</description> </item> <item> @@ -308,9 +333,9 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/guide/transports/</guid> <description>A transport defines the interface to interact with a socket. - Transports can be used for connecting, listening and accepting connections, but also for receiving and sending data. Both passive and active mode are supported, although all sockets are initialized as passive. - TCP transport The TCP transport is a thin wrapper around gen_tcp. - SSL transport The SSL transport is a thin wrapper around ssl. It requires the crypto, asn1, public_key and ssl applications to be started.</description> +Transports can be used for connecting, listening and accepting connections, but also for receiving and sending data. Both passive and active mode are supported, although all sockets are initialized as passive. +TCP transport The TCP transport is a thin wrapper around gen_tcp. +SSL transport The SSL transport is a thin wrapper around ssl. It requires the crypto, asn1, public_key and ssl applications to be started.</description> </item> <item> @@ -320,10 +345,10 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/guide/transports/</guid> <description>A transport defines the interface to interact with a socket. - Transports can be used for connecting, listening and accepting connections, but also for receiving and sending data. Both passive and active mode are supported, although all sockets are initialized as passive. - TCP transport The TCP transport is a thin wrapper around gen_tcp. - SSL transport The SSL transport is a thin wrapper around ssl. - Ranch depends on ssl by default so any necessary dependencies will start when Ranch is started.</description> +Transports can be used for connecting, listening and accepting connections, but also for receiving and sending data. Both passive and active mode are supported, although all sockets are initialized as passive. +TCP transport The TCP transport is a thin wrapper around gen_tcp. +SSL transport The SSL transport is a thin wrapper around ssl. +Ranch depends on ssl by default so any necessary dependencies will start when Ranch is started.</description> </item> <item> @@ -333,10 +358,23 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/guide/transports/</guid> <description>A transport defines the interface to interact with a socket. - Transports can be used for connecting, listening and accepting connections, but also for receiving and sending data. Both passive and active mode are supported, although all sockets are initialized as passive. - TCP transport The TCP transport is a thin wrapper around gen_tcp. - SSL transport The SSL transport is a thin wrapper around ssl. - Ranch depends on ssl by default so any necessary dependencies will start when Ranch is started.</description> +Transports can be used for connecting, listening and accepting connections, but also for receiving and sending data. Both passive and active mode are supported, although all sockets are initialized as passive. +TCP transport The TCP transport is a thin wrapper around gen_tcp. +SSL transport The SSL transport is a thin wrapper around ssl. +Ranch depends on ssl by default so any necessary dependencies will start when Ranch is started.</description> + </item> + + <item> + <title>Transports</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/guide/transports/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/guide/transports/</guid> + <description>A transport defines the interface to interact with a socket. +Transports can be used for connecting, listening and accepting connections, but also for receiving and sending data. Both passive and active mode are supported, although all sockets are initialized as passive. +TCP transport The TCP transport is a thin wrapper around gen_tcp. +SSL transport The SSL transport is a thin wrapper around ssl. +Ranch depends on ssl by default so any necessary dependencies will start when Ranch is started.</description> </item> <item> @@ -345,9 +383,9 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/overview/</guid> - <description>Now that you know how to get started, let&#8217;s take a look at what Erlang.mk can do for you. - Building your project Erlang.mk is first and foremost a build tool. It is especially tailored for Erlang developers and follows widely accepted practices in the Erlang community. - Erlang.mk will happily build all Erlang-specific files you throw at it. Other kinds of files too, like C or C++ code when you are working on a NIF or a port driver.</description> + <description>Now that you know how to get started, let&apos;s take a look at what Erlang.mk can do for you. +Building your project Erlang.mk is first and foremost a build tool. It is especially tailored for Erlang developers and follows widely accepted practices in the Erlang community. +Erlang.mk will happily build all Erlang-specific files you throw at it. Other kinds of files too, like C or C++ code when you are working on a NIF or a port driver.</description> </item> <item> @@ -357,8 +395,8 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/guide/connect/</guid> <description>This chapter describes how to open, monitor and close a connection using the Gun client. - Gun connections Gun is designed with the HTTP/2 and Websocket protocols in mind. They are built for long-running connections that allow concurrent exchange of data, either in the form of request/responses for HTTP/2 or in the form of messages for Websocket. - A Gun connection is an Erlang process that manages a socket to a remote endpoint.</description> +Gun connections Gun is designed with the HTTP/2 and Websocket protocols in mind. They are built for long-running connections that allow concurrent exchange of data, either in the form of request/responses for HTTP/2 or in the form of messages for Websocket. +A Gun connection is an Erlang process that manages a socket to a remote endpoint.</description> </item> <item> @@ -368,7 +406,7 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/guide/protocols/</guid> <description>A protocol handler starts a connection process and defines the protocol logic executed in this process. - Writing a protocol handler All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/4. This callback is responsible for spawning a new process for handling the connection. It receives four arguments: the name of the listener, the socket, the transport handler being used and the protocol options defined in the call to ranch:start_listener/6.</description> +Writing a protocol handler All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/4. This callback is responsible for spawning a new process for handling the connection. It receives four arguments: the name of the listener, the socket, the transport handler being used and the protocol options defined in the call to ranch:start_listener/6.</description> </item> <item> @@ -378,7 +416,7 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/guide/protocols/</guid> <description>A protocol handler starts a connection process and defines the protocol logic executed in this process. - Writing a protocol handler All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/4. This callback is responsible for spawning a new process for handling the connection. It receives four arguments: the name of the listener, the socket, the transport handler being used and the protocol options defined in the call to ranch:start_listener/6.</description> +Writing a protocol handler All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/4. This callback is responsible for spawning a new process for handling the connection. It receives four arguments: the name of the listener, the socket, the transport handler being used and the protocol options defined in the call to ranch:start_listener/6.</description> </item> <item> @@ -388,7 +426,17 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/guide/protocols/</guid> <description>A protocol handler starts a connection process and defines the protocol logic executed in this process. - Writing a protocol handler All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/4. This callback is responsible for spawning a new process for handling the connection. It receives four arguments: the name of the listener, the socket, the transport handler being used and the protocol options defined in the call to ranch:start_listener/5.</description> +Writing a protocol handler All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/4. This callback is responsible for spawning a new process for handling the connection. It receives four arguments: the name of the listener, the socket, the transport handler being used and the protocol options defined in the call to ranch:start_listener/5.</description> + </item> + + <item> + <title>Protocols</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/guide/protocols/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/guide/protocols/</guid> + <description>A protocol handler starts a connection process and defines the protocol logic executed in this process. +Writing a protocol handler All protocol handlers must implement the ranch_protocol behavior which defines a single callback, start_link/4. This callback is responsible for spawning a new process for handling the connection. It receives four arguments: the name of the listener, the socket, the transport handler being used and the protocol options defined in the call to ranch:start_listener/5.</description> </item> <item> @@ -398,7 +446,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/getting_started/</guid> <description>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.</description> +This chapter walks you through all the steps of setting up Cowboy, writing your first application and generating your first release.</description> </item> <item> @@ -408,7 +456,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/getting_started/</guid> <description>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.</description> +This chapter walks you through all the steps of setting up Cowboy, writing your first application and generating your first release.</description> </item> <item> @@ -418,7 +466,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/getting_started/</guid> <description>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.</description> +This chapter walks you through all the steps of setting up Cowboy, writing your first application and generating your first release.</description> </item> <item> @@ -428,7 +476,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/getting_started/</guid> <description>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.</description> +This chapter walks you through all the steps of setting up Cowboy, writing your first application and generating your first release.</description> </item> <item> @@ -438,7 +486,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/getting_started/</guid> <description>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.</description> +This chapter walks you through all the steps of setting up Cowboy, writing your first application and generating your first release.</description> </item> <item> @@ -448,8 +496,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/updating/</guid> <description>This chapter describes how to update the erlang.mk file in your repository. - Initial bootstrap The first time you use Erlang.mk, it will bootstrap itself. It always uses the most recent version for this, so you don&#8217;t have to update after creating your project. - Updating Later on though, updating becomes a necessity. Erlang.mk developers and contributors relentlessly improve the project and add new features; it would be a waste not to benefit from this.</description> +Initial bootstrap The first time you use Erlang.mk, it will bootstrap itself. It always uses the most recent version for this, so you don&apos;t have to update after creating your project. +Updating Later on though, updating becomes a necessity. Erlang.mk developers and contributors relentlessly improve the project and add new features; it would be a waste not to benefit from this.</description> </item> <item> @@ -459,9 +507,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/guide/http/</guid> <description>This chapter describes how to use the Gun client for communicating with an HTTP/1.1 or HTTP/2 server. - Streams Every time a request is initiated, Gun creates a stream. A stream reference uniquely identifies a set of request and response and must be used to perform additional operations with a stream or to identify its messages. - Stream references use the Erlang reference data type and are therefore unique. - Streams can be canceled at any time.</description> +Streams Every time a request is initiated, Gun creates a stream. A stream reference uniquely identifies a set of request and response and must be used to perform additional operations with a stream or to identify its messages. +Stream references use the Erlang reference data type and are therefore unique. +Streams can be canceled at any time.</description> </item> <item> @@ -471,7 +519,7 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/guide/embedded/</guid> <description>Embedded mode allows you to insert Ranch listeners directly in your supervision tree. This allows for greater fault tolerance control by permitting the shutdown of a listener due to the failure of another part of the application and vice versa. - Embedding To embed Ranch in your application you can simply add the child specs to your supervision tree. This can all be done in the init/1 function of one of your application supervisors.</description> +Embedding To embed Ranch in your application you can simply add the child specs to your supervision tree. This can all be done in the init/1 function of one of your application supervisors.</description> </item> <item> @@ -481,7 +529,7 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/guide/embedded/</guid> <description>Embedded mode allows you to insert Ranch listeners directly in your supervision tree. This allows for greater fault tolerance control by permitting the shutdown of a listener due to the failure of another part of the application and vice versa. - Embedding To embed Ranch in your application you can simply add the child specs to your supervision tree. This can all be done in the init/1 function of one of your application supervisors.</description> +Embedding To embed Ranch in your application you can simply add the child specs to your supervision tree. This can all be done in the init/1 function of one of your application supervisors.</description> </item> <item> @@ -491,7 +539,17 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/guide/embedded/</guid> <description>Embedded mode allows you to insert Ranch listeners directly in your supervision tree. This allows for greater fault tolerance control by permitting the shutdown of a listener due to the failure of another part of the application and vice versa. - Embedding To embed Ranch in your application you can simply add the child specs to your supervision tree. This can all be done in the init/1 function of one of your application supervisors.</description> +Embedding To embed Ranch in your application you can simply add the child specs to your supervision tree. This can all be done in the init/1 function of one of your application supervisors.</description> + </item> + + <item> + <title>Embedded mode</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/guide/embedded/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/guide/embedded/</guid> + <description>Embedded mode allows you to insert Ranch listeners directly in your supervision tree. This allows for greater fault tolerance control by permitting the shutdown of a listener due to the failure of another part of the application and vice versa. +Embedding To embed Ranch in your application you can simply add the child specs to your supervision tree. This can all be done in the init/1 function of one of your application supervisors.</description> </item> <item> @@ -501,9 +559,10 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/limitations/</guid> <description>No software is perfect. - It&#8217;s very important, when evaluating and when using a tool, to understand its limitations, so as to avoid making mistakes and wasting valuable time. - This chapter lists all known limitations of Erlang.mk. - Erlang must be available Currently Erlang.mk requires you to install Erlang beforehand. Installing Erlang is not always easy, particularly if you need a specific version of Erlang for a specific project.</description> +It&apos;s very important, when evaluating and when using a tool, to understand its limitations, so as to avoid making mistakes and wasting valuable time. +This chapter lists all known limitations of Erlang.mk. +Erlang must be available Currently Erlang.mk requires you to install Erlang beforehand. Installing Erlang is not always easy, particularly if you need a specific version of Erlang for a specific project. +In addition, the Erlang being used must be in your $PATH before you use Erlang.</description> </item> <item> @@ -513,8 +572,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/flow_diagram/</guid> <description>Cowboy is a lightweight HTTP server with support for HTTP/1.1, HTTP/2 and Websocket. - It is built on top of Ranch. Please see the Ranch guide for more information about how the network connections are handled. - Overview As you can see on the diagram, the client begins by connecting to the server. This step is handled by a Ranch acceptor, which is a process dedicated to accepting new connections.</description> +It is built on top of Ranch. Please see the Ranch guide for more information about how the network connections are handled. +Overview As you can see on the diagram, the client begins by connecting to the server. This step is handled by a Ranch acceptor, which is a process dedicated to accepting new connections. +After Ranch accepts a new connection, whether it is an HTTP/1.</description> </item> <item> @@ -524,8 +584,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/flow_diagram/</guid> <description>Cowboy is a lightweight HTTP server with support for HTTP/1.1, HTTP/2 and Websocket. - It is built on top of Ranch. Please see the Ranch guide for more information about how the network connections are handled. - Overview As you can see on the diagram, the client begins by connecting to the server. This step is handled by a Ranch acceptor, which is a process dedicated to accepting new connections.</description> +It is built on top of Ranch. Please see the Ranch guide for more information about how the network connections are handled. +Overview As you can see on the diagram, the client begins by connecting to the server. This step is handled by a Ranch acceptor, which is a process dedicated to accepting new connections. +After Ranch accepts a new connection, whether it is an HTTP/1.</description> </item> <item> @@ -535,8 +596,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/flow_diagram/</guid> <description>Cowboy is a lightweight HTTP server with support for HTTP/1.1, HTTP/2 and Websocket. - It is built on top of Ranch. Please see the Ranch guide for more information about how the network connections are handled. - Overview As you can see on the diagram, the client begins by connecting to the server. This step is handled by a Ranch acceptor, which is a process dedicated to accepting new connections.</description> +It is built on top of Ranch. Please see the Ranch guide for more information about how the network connections are handled. +Overview As you can see on the diagram, the client begins by connecting to the server. This step is handled by a Ranch acceptor, which is a process dedicated to accepting new connections. +After Ranch accepts a new connection, whether it is an HTTP/1.</description> </item> <item> @@ -546,8 +608,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/flow_diagram/</guid> <description>Cowboy is a lightweight HTTP server with support for HTTP/1.1, HTTP/2 and Websocket. - It is built on top of Ranch. Please see the Ranch guide for more information about how the network connections are handled. - Overview As you can see on the diagram, the client begins by connecting to the server. This step is handled by a Ranch acceptor, which is a process dedicated to accepting new connections.</description> +It is built on top of Ranch. Please see the Ranch guide for more information about how the network connections are handled. +Overview As you can see on the diagram, the client begins by connecting to the server. This step is handled by a Ranch acceptor, which is a process dedicated to accepting new connections. +After Ranch accepts a new connection, whether it is an HTTP/1.</description> </item> <item> @@ -557,8 +620,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/flow_diagram/</guid> <description>Cowboy is a lightweight HTTP server with support for HTTP/1.1, HTTP/2 and Websocket. - It is built on top of Ranch. Please see the Ranch guide for more information about how the network connections are handled. - Overview As you can see on the diagram, the client begins by connecting to the server. This step is handled by a Ranch acceptor, which is a process dedicated to accepting new connections.</description> +It is built on top of Ranch. Please see the Ranch guide for more information about how the network connections are handled. +Overview As you can see on the diagram, the client begins by connecting to the server. This step is handled by a Ranch acceptor, which is a process dedicated to accepting new connections. +After Ranch accepts a new connection, whether it is an HTTP/1.</description> </item> <item> @@ -568,8 +632,8 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/guide/websocket/</guid> <description>This chapter describes how to use the Gun client for communicating with a Websocket server. - HTTP upgrade Websocket is a protocol built on top of HTTP. To use Websocket, you must first request for the connection to be upgraded. Only HTTP/1.1 connections can be upgraded to Websocket, so you might need to restrict the protocol to HTTP/1.1 if you are planning to use Websocket over TLS. - You must use the gun:ws_upgrade/2,3,4 function to upgrade to Websocket.</description> +HTTP upgrade Websocket is a protocol built on top of HTTP. To use Websocket, you must first request for the connection to be upgraded. Only HTTP/1.1 connections can be upgraded to Websocket, so you might need to restrict the protocol to HTTP/1.1 if you are planning to use Websocket over TLS. +You must use the gun:ws_upgrade/2,3,4 function to upgrade to Websocket.</description> </item> <item> @@ -579,8 +643,8 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/guide/parsers/</guid> <description>There are three kinds of protocols: - Text protocols Schema-less binary protocols Schema-based binary protocols This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators. - This chapter isn&#8217;t specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn&#8217;t been parsed is saved in a buffer.</description> +Text protocols Schema-less binary protocols Schema-based binary protocols This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators. +This chapter isn&apos;t specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn&apos;t been parsed is saved in a buffer.</description> </item> <item> @@ -590,8 +654,8 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/guide/parsers/</guid> <description>There are three kinds of protocols: - Text protocols Schema-less binary protocols Schema-based binary protocols This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators. - This chapter isn&#8217;t specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn&#8217;t been parsed is saved in a buffer.</description> +Text protocols Schema-less binary protocols Schema-based binary protocols This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators. +This chapter isn&apos;t specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn&apos;t been parsed is saved in a buffer.</description> </item> <item> @@ -601,8 +665,19 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/guide/parsers/</guid> <description>There are three kinds of protocols: - Text protocols Schema-less binary protocols Schema-based binary protocols This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators. - This chapter isn&#8217;t specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn&#8217;t been parsed is saved in a buffer.</description> +Text protocols Schema-less binary protocols Schema-based binary protocols This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators. +This chapter isn&apos;t specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn&apos;t been parsed is saved in a buffer.</description> + </item> + + <item> + <title>Writing parsers</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/guide/parsers/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/guide/parsers/</guid> + <description>There are three kinds of protocols: +Text protocols Schema-less binary protocols Schema-based binary protocols This chapter introduces the first two kinds. It will not cover more advanced topics such as continuations or parser generators. +This chapter isn&apos;t specifically about Ranch, we assume here that you know how to read data from the socket. The data you read and the data that hasn&apos;t been parsed is saved in a buffer.</description> </item> <item> @@ -612,9 +687,9 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/app/</guid> <description>Erlang.mk can do a lot of things, but it is, first and foremost, a build tool. In this chapter we will cover the basics of building a project with Erlang.mk. - For most of this chapter, we will assume that you are using a project generated by Erlang.mk. - How to build To build a project, all you have to do is type make: - $ make It will work regardless of your project: OTP applications, library applications, NIFs, port drivers or even releases.</description> +For most of this chapter, we will assume that you are using a project generated by Erlang.mk. +How to build To build a project, all you have to do is type make: +$ make It will work regardless of your project: OTP applications, library applications, NIFs, port drivers or even releases.</description> </item> <item> @@ -624,8 +699,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/listeners/</guid> <description>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.</description> +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.</description> </item> <item> @@ -635,8 +710,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/listeners/</guid> <description>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.</description> +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.</description> </item> <item> @@ -646,8 +721,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/listeners/</guid> <description>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.</description> +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.</description> </item> <item> @@ -657,8 +732,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/listeners/</guid> <description>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.</description> +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.</description> </item> <item> @@ -668,8 +743,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/listeners/</guid> <description>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.</description> +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.</description> </item> <item> @@ -679,7 +754,7 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/guide/ssl_auth/</guid> <description>Purpose SSL client authentication is a mechanism allowing applications to identify certificates. This allows your application to make sure that the client is an authorized certificate, but makes no claim about whether the user can be trusted. This can be combined with a password based authentication to attain greater security. - The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate.</description> +The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate.</description> </item> <item> @@ -689,7 +764,7 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/guide/ssl_auth/</guid> <description>Purpose SSL client authentication is a mechanism allowing applications to identify certificates. This allows your application to make sure that the client is an authorized certificate, but makes no claim about whether the user can be trusted. This can be combined with a password based authentication to attain greater security. - The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate.</description> +The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate.</description> </item> <item> @@ -699,7 +774,17 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/guide/ssl_auth/</guid> <description>Purpose SSL client authentication is a mechanism allowing applications to identify certificates. This allows your application to make sure that the client is an authorized certificate, but makes no claim about whether the user can be trusted. This can be combined with a password based authentication to attain greater security. - The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate.</description> +The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate.</description> + </item> + + <item> + <title>SSL client authentication</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/guide/ssl_auth/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/guide/ssl_auth/</guid> + <description>Purpose SSL client authentication is a mechanism allowing applications to identify certificates. This allows your application to make sure that the client is an authorized certificate, but makes no claim about whether the user can be trusted. This can be combined with a password based authentication to attain greater security. +The server only needs to retain the certificate serial number and the certificate issuer to authenticate the certificate. Together, they can be used to uniquely identify a certicate.</description> </item> <item> @@ -709,8 +794,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/deps/</guid> <description>Erlang.mk can fetch and compile the dependencies that your project requires. Erlang.mk improves upon the concepts introduced by Rebar, so they should be familiar to many seasoned Erlang developers. - Erlang.mk is not a package manager, nor is it trying to be, but it does include an index of Erlang packages to make discovering useful projects easier. - This chapter will explain how to use packages, add dependencies to your project or bundle them directly in a single repository.</description> +Erlang.mk is not a package manager, nor is it trying to be, but it does include an index of Erlang packages to make discovering useful projects easier. +This chapter will explain how to use packages, add dependencies to your project or bundle them directly in a single repository.</description> </item> <item> @@ -720,9 +805,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/routing/</guid> <description>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&#8217;s a match, the route&#8217;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.</description> +To make Cowboy useful, you need to map URIs to Erlang modules that will handle the requests. This is called routing. +When Cowboy receives a request, it tries to match the requested host and path to the configured routes. When there&apos;s a match, the route&apos;s associated handler is executed. +Routes need to be compiled before they can be used by Cowboy. The result of the compilation is the dispatch rules.</description> </item> <item> @@ -732,9 +817,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/routing/</guid> <description>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&#8217;s a match, the route&#8217;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.</description> +To make Cowboy useful, you need to map URIs to Erlang modules that will handle the requests. This is called routing. +When Cowboy receives a request, it tries to match the requested host and path to the configured routes. When there&apos;s a match, the route&apos;s associated handler is executed. +Routes need to be compiled before they can be used by Cowboy. The result of the compilation is the dispatch rules.</description> </item> <item> @@ -744,9 +829,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/routing/</guid> <description>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&#8217;s a match, the route&#8217;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.</description> +To make Cowboy useful, you need to map URIs to Erlang modules that will handle the requests. This is called routing. +When Cowboy receives a request, it tries to match the requested host and path to the configured routes. When there&apos;s a match, the route&apos;s associated handler is executed. +Routes need to be compiled before they can be used by Cowboy. The result of the compilation is the dispatch rules.</description> </item> <item> @@ -756,9 +841,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/routing/</guid> <description>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&#8217;s a match, the route&#8217;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.</description> +To make Cowboy useful, you need to map URIs to Erlang modules that will handle the requests. This is called routing. +When Cowboy receives a request, it tries to match the requested host and path to the configured routes. When there&apos;s a match, the route&apos;s associated handler is executed. +Routes need to be compiled before they can be used by Cowboy. The result of the compilation is the dispatch rules.</description> </item> <item> @@ -768,9 +853,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/routing/</guid> <description>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&#8217;s a match, the route&#8217;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.</description> +To make Cowboy useful, you need to map URIs to Erlang modules that will handle the requests. This is called routing. +When Cowboy receives a request, it tries to match the requested host and path to the configured routes. When there&apos;s a match, the route&apos;s associated handler is executed. +Routes need to be compiled before they can be used by Cowboy. The result of the compilation is the dispatch rules.</description> </item> <item> @@ -780,8 +865,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/ports/</guid> <description>Erlang.mk can not only build Erlang projects, but also the C code that some projects come with, like NIFs and port drivers. - There are two ways to build the C code: using a custom Makefile, or making Erlang.mk do it directly. The C code will be built as needed when you run make. - C source code location and Erlang environment The C source code should be located in the $(C_SRC_DIR) directory.</description> +There are two ways to build the C code: using a custom Makefile, or making Erlang.mk do it directly. The C code will be built as needed when you run make. +C source code location and Erlang environment The C source code should be located in the $(C_SRC_DIR) directory.</description> </item> <item> @@ -791,7 +876,7 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/guide/internals/</guid> <description>This chapter may not apply to embedded Ranch as embedding allows you to use an architecture specific to your application, which may or may not be compatible with the description of the Ranch application. - Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system.</description> +Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system.</description> </item> <item> @@ -801,7 +886,7 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/guide/internals/</guid> <description>This chapter may not apply to embedded Ranch as embedding allows you to use an architecture specific to your application, which may or may not be compatible with the description of the Ranch application. - Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system.</description> +Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system.</description> </item> <item> @@ -811,7 +896,17 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/guide/internals/</guid> <description>This chapter may not apply to embedded Ranch as embedding allows you to use an architecture specific to your application, which may or may not be compatible with the description of the Ranch application. - Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system.</description> +Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system.</description> + </item> + + <item> + <title>Internals</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/guide/internals/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/guide/internals/</guid> + <description>This chapter may not apply to embedded Ranch as embedding allows you to use an architecture specific to your application, which may or may not be compatible with the description of the Ranch application. +Note that for everything related to efficiency and performance, you should perform the benchmarks yourself to get the numbers that matter to you. Generic benchmarks found on the web may or may not be of use to you, you can never know until you benchmark your own system.</description> </item> <item> @@ -821,9 +916,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/constraints/</guid> <description>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}.</description> +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}.</description> </item> <item> @@ -833,9 +928,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/constraints/</guid> <description>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}.</description> +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}.</description> </item> <item> @@ -845,9 +940,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/constraints/</guid> <description>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}.</description> +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}.</description> </item> <item> @@ -857,9 +952,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/constraints/</guid> <description>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}.</description> +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}.</description> </item> <item> @@ -869,9 +964,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/constraints/</guid> <description>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}.</description> +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}.</description> </item> <item> @@ -881,8 +976,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/releases/</guid> <description>Erlang.mk relies on Relx for generating releases. This chapter covers the Erlang.mk-specific bits. Consult the Relx website for more information. - Setup Erlang.mk will create a release if it detects a Relx configuration file in the $(RELX_CONFIG) location. This defaults to $(CURDIR)/relx.config. You can override it by defining the variable before including Erlang.mk: - RELX_CONFIG = $(CURDIR)/webchat.config Relx does not need to be installed. Erlang.mk will download and build it automatically.</description> +Setup Erlang.mk will create a release if it detects a Relx configuration file in the $(RELX_CONFIG) location. This defaults to $(CURDIR)/relx.config. You can override it by defining the variable before including Erlang.mk: +RELX_CONFIG = $(CURDIR)/webchat.config Relx does not need to be installed. Erlang.mk will download and build it automatically.</description> </item> <item> @@ -892,9 +987,9 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/sfx/</guid> <description>Erlang.mk allows you to package Relx releases as self-extracting archives. These archives contain all the files in the release and come in the form of a script that will extract and run the release automatically. - This allows you to package the release as a single file that can then be executed. - This feature is currently experimental. Feedback is much appreciated. - Generating the self-extracting archive To generate a self-extracting release, all you need to do is pass the SFX=1 variable to Make when you build the release:</description> +This allows you to package the release as a single file that can then be executed. +This feature is currently experimental. Feedback is much appreciated. +Generating the self-extracting archive To generate a self-extracting release, all you need to do is pass the SFX=1 variable to Make when you build the release:</description> </item> <item> @@ -904,10 +999,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/handlers/</guid> <description>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) -&gt; {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.</description> +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) -&gt; {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.</description> </item> <item> @@ -917,10 +1012,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/handlers/</guid> <description>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) -&gt; {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.</description> +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) -&gt; {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.</description> </item> <item> @@ -930,10 +1025,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/handlers/</guid> <description>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) -&gt; {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.</description> +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) -&gt; {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.</description> </item> <item> @@ -943,10 +1038,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/handlers/</guid> <description>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) -&gt; {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.</description> +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) -&gt; {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.</description> </item> <item> @@ -956,10 +1051,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/handlers/</guid> <description>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) -&gt; {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.</description> +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) -&gt; {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.</description> </item> <item> @@ -969,9 +1064,9 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/escripts/</guid> <description>Escripts are an alternative to release. They are meant to be used for small command line executables written in Erlang. - They are not self-contained, unlike releases. Erlang must be installed for them to run. This however means that they are fairly small compared to releases. - For self-contained executables, check self-extracting releases. - Requirements Erlang.mk uses p7zip by default to generate the escript archive. Make sure it is installed. On most systems the package is named p7zip; on Ubuntu you need p7zip-full.</description> +They are not self-contained, unlike releases. Erlang must be installed for them to run. This however means that they are fairly small compared to releases. +For self-contained executables, check self-extracting releases. +Requirements Erlang.mk uses p7zip by default to generate the escript archive. Make sure it is installed. On most systems the package is named p7zip; on Ubuntu you need p7zip-full.</description> </item> <item> @@ -981,7 +1076,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/loop_handlers/</guid> <description>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.</description> +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.</description> </item> <item> @@ -991,7 +1086,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/loop_handlers/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1001,7 +1096,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/loop_handlers/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1011,7 +1106,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/loop_handlers/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1021,7 +1116,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/loop_handlers/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1031,7 +1126,7 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/kerl/</guid> <description>Erlang.mk comes with integrated support for Kerl, a shell script that automates the downloading, building and installing of Erlang/OTP. It can be used to easily build a specific Erlang/OTP version (with or without custom build options) or maintain different versions side by side. - Erlang versions Erlang.mk uses the Git tags from Erlang/OTP to identify OTP versions. The most recent tag at the time of writing is OTP-20.0.4, which is a patch release of OTP-20.</description> +Erlang versions Erlang.mk uses the Git tags from Erlang/OTP to identify OTP versions. The most recent tag at the time of writing is OTP-20.0.4, which is a patch release of OTP-20.</description> </item> <item> @@ -1041,8 +1136,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/static_files/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1052,8 +1147,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/static_files/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1063,8 +1158,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/static_files/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1074,8 +1169,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/static_files/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1085,8 +1180,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/static_files/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1096,7 +1191,7 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/compat/</guid> <description>Erlang.mk tries its best to be compatible with the other Erlang build tools. It can use dependencies written with other build tools in mind, and can also make your projects usable by those build tools as well. Erlang.mk is like the cool kid that gets along with everybody. - In this chapter I will use the term Rebar project to refer to a project built using Rebar 2, Rebar 3 or Mad.</description> +In this chapter I will use the term Rebar project to refer to a project built using Rebar 2, Rebar 3 or Mad.</description> </item> <item> @@ -1106,8 +1201,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/asciidoc/</guid> <description>Erlang.mk provides rules for generating documentation from AsciiDoc files. It can automatically build a user guide PDF, chunked HTML documentation and Unix manual pages. - Requirements It is necessary to have AsciiDoc, xsltproc and dblatex installed on your system for Erlang.mk to generate documentation from AsciiDoc sources. - Writing AsciiDoc documentation AsciiDoc is a text document format for writing notes, documentation, articles, books, ebooks, slideshows, web pages, man pages and blogs.</description> +Requirements It is necessary to have AsciiDoc, xsltproc and dblatex installed on your system for Erlang.mk to generate documentation from AsciiDoc sources. +Writing AsciiDoc documentation AsciiDoc is a text document format for writing notes, documentation, articles, books, ebooks, slideshows, web pages, man pages and blogs. AsciiDoc files can be translated to many formats including HTML, PDF, EPUB, man page.</description> </item> <item> @@ -1117,8 +1212,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/req/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1128,8 +1223,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/req/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1139,8 +1234,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/req/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1150,8 +1245,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/req/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1161,8 +1256,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/req/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1172,9 +1267,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/req_body/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1184,9 +1279,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/req_body/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1196,9 +1291,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/req_body/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1208,9 +1303,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/req_body/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1220,9 +1315,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/req_body/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1232,9 +1327,9 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/edoc/</guid> <description>Erlang.mk provides a thin wrapper on top of EDoc, an application that generates documentation based on comments found in modules. - Writing EDoc comments The EDoc user guide explains everything you need to know about EDoc comments. - Configuration The EDOC_OPTS variable allows you to specify additional EDoc options. Options are documented in the EDoc manual. - A common use for this variable is to enable Markdown in doc comments, using the edown application:</description> +Writing EDoc comments The EDoc user guide explains everything you need to know about EDoc comments. +Configuration The EDOC_OPTS variable allows you to specify additional EDoc options. Options are documented in the EDoc manual. +A common use for this variable is to enable Markdown in doc comments, using the edown application:</description> </item> <item> @@ -1244,8 +1339,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/sphinx/</guid> <description>Erlang.mk includes targets for running the Sphinx documentation generator, which can produce documentation in various formats, like HTML, man pages, Texinfo, LaTeX, and others. - Writing Sphinx documentation Sphinx generates documentation from a set of reST documents. There is a quick start guide on Sphinx' website. For Erlang.mk, we&#8217;ll set up a minimal environment instead. - Basic setup By default, Erlang.mk expects Sphinx documentation to be placed in the doc directory, with doc/conf.</description> +Writing Sphinx documentation Sphinx generates documentation from a set of reST documents. There is a quick start guide on Sphinx&apos; website. For Erlang.mk, we&apos;ll set up a minimal environment instead. +Basic setup By default, Erlang.mk expects Sphinx documentation to be placed in the doc directory, with doc/conf.</description> </item> <item> @@ -1255,8 +1350,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/resp/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1266,8 +1362,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/resp/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1277,8 +1374,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/resp/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1288,8 +1386,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/resp/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1299,8 +1398,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/resp/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1310,8 +1410,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/shell/</guid> <description>Erlang.mk provides a convenient target for starting a shell with all the paths set properly to experiment with your code. - Configuration The SHELL_DEPS variable can be used to define dependencies that are only to be used when the make shell command is called. For example, if you want to use kjell as your shell: - SHELL_DEPS = kjell Dependencies are downloaded and compiled the first time you run the make shell command.</description> +Configuration The SHELL_DEPS variable can be used to define dependencies that are only to be used when the make shell command is called. For example, if you want to use kjell as your shell: +SHELL_DEPS = kjell Dependencies are downloaded and compiled the first time you run the make shell command.</description> </item> <item> @@ -1321,7 +1421,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/cookies/</guid> <description>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).</description> +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).</description> </item> <item> @@ -1331,7 +1431,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/cookies/</guid> <description>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).</description> +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).</description> </item> <item> @@ -1341,7 +1441,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/cookies/</guid> <description>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).</description> +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).</description> </item> <item> @@ -1351,7 +1451,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/cookies/</guid> <description>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).</description> +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).</description> </item> <item> @@ -1361,7 +1461,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/cookies/</guid> <description>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).</description> +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).</description> </item> <item> @@ -1371,8 +1471,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/eunit/</guid> <description>EUnit is the tool of choice for unit testing. Erlang.mk automates a few things on top of EUnit, including the discovery and running of unit tests. - Writing tests The EUnit user guide is the best place to learn how to write tests. Of note is that all functions ending with _test or _test_ will be picked up as EUnit test cases. - Erlang.mk will automatically pick up tests found in any of the Erlang modules of your application.</description> +Writing tests The EUnit user guide is the best place to learn how to write tests. Of note is that all functions ending with _test or _test_ will be picked up as EUnit test cases. +Erlang.mk will automatically pick up tests found in any of the Erlang modules of your application.</description> </item> <item> @@ -1382,8 +1482,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/multipart/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1393,8 +1493,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/multipart/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1404,8 +1504,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/multipart/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1415,8 +1515,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/multipart/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1426,8 +1526,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/multipart/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1436,9 +1536,9 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/common_test/</guid> - <description>Common Test is Erlang&#8217;s functional testing framework. Erlang.mk automates the discovery and running of Common Test suites. - Writing tests The Common Test user guide is the best place to learn how to write tests. Erlang.mk requires that file names for test suites end with _SUITE.erl and that the files be located in the $(TEST_DIR) directory. This defaults to test/. - Configuration The CT_OPTS variable allows you to set extra Common Test options.</description> + <description>Common Test is Erlang&apos;s functional testing framework. Erlang.mk automates the discovery and running of Common Test suites. +Writing tests The Common Test user guide is the best place to learn how to write tests. Erlang.mk requires that file names for test suites end with _SUITE.erl and that the files be located in the $(TEST_DIR) directory. This defaults to test/. +Configuration The CT_OPTS variable allows you to set extra Common Test options.</description> </item> <item> @@ -1448,8 +1548,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/rest_principles/</guid> <description>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&#8217;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.</description> +REST is often confused with performing a distinct operation depending on the HTTP method, while using more than the GET and POST methods. That&apos;s highly misguided at best. +We will first attempt to define REST and will look at what it means in the context of HTTP and the Web. For a more in-depth explanation of REST, you can read Roy T.</description> </item> <item> @@ -1459,8 +1559,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/rest_principles/</guid> <description>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&#8217;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.</description> +REST is often confused with performing a distinct operation depending on the HTTP method, while using more than the GET and POST methods. That&apos;s highly misguided at best. +We will first attempt to define REST and will look at what it means in the context of HTTP and the Web. For a more in-depth explanation of REST, you can read Roy T.</description> </item> <item> @@ -1470,8 +1570,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/rest_principles/</guid> <description>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&#8217;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.</description> +REST is often confused with performing a distinct operation depending on the HTTP method, while using more than the GET and POST methods. That&apos;s highly misguided at best. +We will first attempt to define REST and will look at what it means in the context of HTTP and the Web. For a more in-depth explanation of REST, you can read Roy T.</description> </item> <item> @@ -1481,8 +1581,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/rest_principles/</guid> <description>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&#8217;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.</description> +REST is often confused with performing a distinct operation depending on the HTTP method, while using more than the GET and POST methods. That&apos;s highly misguided at best. +We will first attempt to define REST and will look at what it means in the context of HTTP and the Web. For a more in-depth explanation of REST, you can read Roy T.</description> </item> <item> @@ -1492,8 +1592,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/rest_principles/</guid> <description>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&#8217;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.</description> +REST is often confused with performing a distinct operation depending on the HTTP method, while using more than the GET and POST methods. That&apos;s highly misguided at best. +We will first attempt to define REST and will look at what it means in the context of HTTP and the Web. For a more in-depth explanation of REST, you can read Roy T.</description> </item> <item> @@ -1503,12 +1603,12 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/triq/</guid> <description>Triq is a QuickCheck-like library for property-based testing. Erlang.mk automates discovery and checking of Triq properties. - To run all tests (including Triq): - $ make tests To run all tests and static checks (including Triq): - $ make check You can also run Triq separately: - $ make triq To check properties from a single module: - $ make triq t=foo_tests To check a single property: - $ make triq t=foo_tests:bar </description> +To run all tests (including Triq): +$ make tests To run all tests and static checks (including Triq): +$ make check You can also run Triq separately: +$ make triq To check properties from a single module: +$ make triq t=foo_tests To check a single property: +$ make triq t=foo_tests:bar </description> </item> <item> @@ -1517,9 +1617,10 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/rest_handlers/</guid> - <description>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&#8217;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.</description> + <description>REST is implemented in Cowboy as a sub protocol. The request is handled as a state machine with many optional callbacks describing the resource and modifying the machine&apos;s behavior. +The REST handler is the recommended way to handle HTTP requests. +Initialization First, the init/2 callback is called. This callback is common to all handlers. To use REST for the current request, this function must return a cowboy_rest tuple. +init(Req, State) -&gt; {cowboy_rest, Req, State}.</description> </item> <item> @@ -1528,9 +1629,10 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/rest_handlers/</guid> - <description>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&#8217;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.</description> + <description>REST is implemented in Cowboy as a sub protocol. The request is handled as a state machine with many optional callbacks describing the resource and modifying the machine&apos;s behavior. +The REST handler is the recommended way to handle HTTP requests. +Initialization First, the init/2 callback is called. This callback is common to all handlers. To use REST for the current request, this function must return a cowboy_rest tuple. +init(Req, State) -&gt; {cowboy_rest, Req, State}.</description> </item> <item> @@ -1539,9 +1641,10 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/rest_handlers/</guid> - <description>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&#8217;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.</description> + <description>REST is implemented in Cowboy as a sub protocol. The request is handled as a state machine with many optional callbacks describing the resource and modifying the machine&apos;s behavior. +The REST handler is the recommended way to handle HTTP requests. +Initialization First, the init/2 callback is called. This callback is common to all handlers. To use REST for the current request, this function must return a cowboy_rest tuple. +init(Req, State) -&gt; {cowboy_rest, Req, State}.</description> </item> <item> @@ -1550,9 +1653,10 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/rest_handlers/</guid> - <description>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&#8217;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.</description> + <description>REST is implemented in Cowboy as a sub protocol. The request is handled as a state machine with many optional callbacks describing the resource and modifying the machine&apos;s behavior. +The REST handler is the recommended way to handle HTTP requests. +Initialization First, the init/2 callback is called. This callback is common to all handlers. To use REST for the current request, this function must return a cowboy_rest tuple. +init(Req, State) -&gt; {cowboy_rest, Req, State}.</description> </item> <item> @@ -1561,9 +1665,10 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/rest_handlers/</guid> - <description>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&#8217;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.</description> + <description>REST is implemented in Cowboy as a sub protocol. The request is handled as a state machine with many optional callbacks describing the resource and modifying the machine&apos;s behavior. +The REST handler is the recommended way to handle HTTP requests. +Initialization First, the init/2 callback is called. This callback is common to all handlers. To use REST for the current request, this function must return a cowboy_rest tuple. +init(Req, State) -&gt; {cowboy_rest, Req, State}.</description> </item> <item> @@ -1572,8 +1677,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/coverage/</guid> - <description>Placeholder chapter. - </description> + <description>Placeholder chapter.</description> </item> <item> @@ -1583,7 +1687,7 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/ci/</guid> <description>Erlang.mk comes with some support for continuous integration, aimed at open source projects that need to support more than one specific Erlang/OTP release. (If you target one specific release, check the OTP version pinning section of the OTP version management chapter.) - Configuring Erlang/OTP versions to test To use the CI plugin you must first configure which versions of Erlang/OTP will be used. Erlang.mk provides three separate configuration variables depending on whether you need a normal OTP release, a HiPE-enabled release or an ErLLVM-enabled release.</description> +Configuring Erlang/OTP versions to test To use the CI plugin you must first configure which versions of Erlang/OTP will be used. Erlang.mk provides three separate configuration variables depending on whether you need a normal OTP release, a HiPE-enabled release or an ErLLVM-enabled release.</description> </item> <item> @@ -1593,8 +1697,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/rest_flowcharts/</guid> <description>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"</description> +There are four main paths that requests may follow. One for the method OPTIONS; one for the methods GET and HEAD; one for the methods PUT, POST and PATCH; and one for the method DELETE. +All paths start with the &quot;Start&quot; diagram, and all paths excluding the OPTIONS path go through the &quot;Content negotiation&quot; diagram and optionally the &quot;Conditional requests&quot; diagram if the resource exists.</description> </item> <item> @@ -1604,8 +1708,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/rest_flowcharts/</guid> <description>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"</description> +There are four main paths that requests may follow. One for the method OPTIONS; one for the methods GET and HEAD; one for the methods PUT, POST and PATCH; and one for the method DELETE. +All paths start with the &quot;Start&quot; diagram, and all paths excluding the OPTIONS path go through the &quot;Content negotiation&quot; diagram and optionally the &quot;Conditional requests&quot; diagram if the resource exists.</description> </item> <item> @@ -1615,8 +1719,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/rest_flowcharts/</guid> <description>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"</description> +There are four main paths that requests may follow. One for the method OPTIONS; one for the methods GET and HEAD; one for the methods PUT, POST and PATCH; and one for the method DELETE. +All paths start with the &quot;Start&quot; diagram, and all paths excluding the OPTIONS path go through the &quot;Content negotiation&quot; diagram and optionally the &quot;Conditional requests&quot; diagram if the resource exists.</description> </item> <item> @@ -1626,8 +1730,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/rest_flowcharts/</guid> <description>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"</description> +There are four main paths that requests may follow. One for the method OPTIONS; one for the methods GET and HEAD; one for the methods PUT, POST and PATCH; and one for the method DELETE. +All paths start with the &quot;Start&quot; diagram, and all paths excluding the OPTIONS path go through the &quot;Content negotiation&quot; diagram and optionally the &quot;Conditional requests&quot; diagram if the resource exists.</description> </item> <item> @@ -1637,8 +1741,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/rest_flowcharts/</guid> <description>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"</description> +There are four main paths that requests may follow. One for the method OPTIONS; one for the methods GET and HEAD; one for the methods PUT, POST and PATCH; and one for the method DELETE. +All paths start with the &quot;Start&quot; diagram, and all paths excluding the OPTIONS path go through the &quot;Content negotiation&quot; diagram and optionally the &quot;Conditional requests&quot; diagram if the resource exists.</description> </item> <item> @@ -1648,8 +1752,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/dialyzer/</guid> <description>Dialyzer is a tool that will detect discrepancies in your program. It does so using a technique known as success typing analysis which has the advantage of providing no false positives. Dialyzer is able to detect type errors, dead code and more. - Erlang.mk provides a wrapper around Dialyzer. - How it works Dialyzer requires a PLT file to work. The PLT file contains the analysis information from all applications which are not expected to change, or rarely do.</description> +Erlang.mk provides a wrapper around Dialyzer. +How it works Dialyzer requires a PLT file to work. The PLT file contains the analysis information from all applications which are not expected to change, or rarely do.</description> </item> <item> @@ -1659,7 +1763,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/resource_design/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1669,7 +1773,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/resource_design/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1679,7 +1783,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/resource_design/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1689,7 +1793,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/resource_design/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1699,7 +1803,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/resource_design/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1708,8 +1812,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/xref/</guid> - <description>Placeholder chapter. - </description> + <description>Placeholder chapter.</description> </item> <item> @@ -1719,8 +1822,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/external_plugins/</guid> <description>It is often convenient to be able to keep the build files used by all your projects in one place. Those files could be Makefiles, configuration files, templates and more. - Erlang.mk allows you to automatically load plugins from dependencies. Plugins can do anything, including defining new variables, defining file templates, hooking themselves inside the normal Erlang.mk processing or even adding new rules. - You can load plugins using one of two methods.</description> +Erlang.mk allows you to automatically load plugins from dependencies. Plugins can do anything, including defining new variables, defining file templates, hooking themselves inside the normal Erlang.mk processing or even adding new rules. +You can load plugins using one of two methods.</description> </item> <item> @@ -1730,8 +1833,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/ws_protocol/</guid> <description>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).</description> +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).</description> </item> <item> @@ -1741,8 +1844,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/ws_protocol/</guid> <description>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).</description> +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).</description> </item> <item> @@ -1752,8 +1855,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/ws_protocol/</guid> <description>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).</description> +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).</description> </item> <item> @@ -1763,8 +1866,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/ws_protocol/</guid> <description>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).</description> +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).</description> </item> <item> @@ -1774,8 +1877,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/ws_protocol/</guid> <description>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).</description> +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).</description> </item> <item> @@ -1785,10 +1888,11 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/external_plugins_list/</guid> <description>This is a non-exhaustive list of Erlang.mk plugins, sorted alphabetically. - efene.mk An Efene plugin for Erlang.mk. Efene is an alternative language for the BEAM. - elixir.mk An Elixir plugin for Erlang.mk. Elixir is an alternative language for the BEAM. - elvis.mk An Elvis plugin for Erlang.mk. Elvis is an Erlang style reviewer. - geas Geas gives aggregated information on a project and its dependencies, and is available as an Erlang.</description> +efene.mk An Efene plugin for Erlang.mk. Efene is an alternative language for the BEAM. +elixir.mk An Elixir plugin for Erlang.mk. Elixir is an alternative language for the BEAM. +elvis.mk An Elvis plugin for Erlang.mk. Elvis is an Erlang style reviewer. +geas Geas gives aggregated information on a project and its dependencies, and is available as an Erlang.mk plugin. +hexer.mk An Hex plugin for Erlang.</description> </item> <item> @@ -1798,7 +1902,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/ws_handlers/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1808,7 +1912,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/ws_handlers/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1818,7 +1922,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/ws_handlers/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1828,7 +1932,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/ws_handlers/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1838,7 +1942,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/ws_handlers/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1848,8 +1952,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/streams/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1859,8 +1963,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/streams/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1870,8 +1974,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/streams/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1881,8 +1985,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/streams/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1892,8 +1996,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/streams/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1903,9 +2007,9 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/why/</guid> <description>Why would you choose Erlang.mk, if not for its many features? This chapter will attempt to answer that. - Erlang.mk is fast Erlang.mk is as fast as it gets. - Erlang.mk will group the compilation of files so as to avoid running the BEAM more than necessary. This saves many seconds compared to traditional Makefiles, even on small projects. - Erlang.mk will not try to be too smart. It provides a simple solution that works for most people, and gives additional options for projects that run into edge cases, often in the form of extra variables or rules to be defined.</description> +Erlang.mk is fast Erlang.mk is as fast as it gets. +Erlang.mk will group the compilation of files so as to avoid running the BEAM more than necessary. This saves many seconds compared to traditional Makefiles, even on small projects. +Erlang.mk will not try to be too smart. It provides a simple solution that works for most people, and gives additional options for projects that run into edge cases, often in the form of extra variables or rules to be defined.</description> </item> <item> @@ -1915,8 +2019,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/middlewares/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1926,8 +2030,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/middlewares/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1937,8 +2041,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/middlewares/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1948,8 +2052,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/middlewares/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1959,8 +2063,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/middlewares/</guid> <description>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.</description> +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.</description> </item> <item> @@ -1970,8 +2074,8 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/history/</guid> <description>This chapter aims to be a brief record of the life of the Erlang.mk project. - Before Erlang.mk Erlang.mk originates from the Cowboy project. Cowboy started as a Rebar project and I, Loïc Hoguin, was very happy with it for a couple years. Over time however I started getting annoyed and frustrated by a number of things, including bad defaults, changing defaults and overall slowness. - In particular, at the time I gave up on Rebar, the Cowboy test suite was taking about five minutes to run.</description> +Before Erlang.mk Erlang.mk originates from the Cowboy project. Cowboy started as a Rebar project and I, Loïc Hoguin, was very happy with it for a couple years. Over time however I started getting annoyed and frustrated by a number of things, including bad defaults, changing defaults and overall slowness. +In particular, at the time I gave up on Rebar, the Cowboy test suite was taking about five minutes to run.</description> </item> <item> @@ -1981,9 +2085,10 @@ <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/contributing/</guid> <description>You are welcome and encouraged to contribute. - This is how. - Priorities From the most important to the least important: - Bugs Package issues/additions Refactoring Features Bugs If you have found a bug, you should open a ticket. Include everything relevant including the command you used, output, a link to the code that triggers the issue, why you think this is a bug, etc.</description> +This is how. +Priorities From the most important to the least important: +Bugs Package issues/additions Refactoring Features Bugs If you have found a bug, you should open a ticket. Include everything relevant including the command you used, output, a link to the code that triggers the issue, why you think this is a bug, etc. +If you think you have found a bug but you are not sure, you should open a ticket as previously explained.</description> </item> <item> @@ -1993,7 +2098,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/migrating_from_2.2/</guid> <description>The following patch versions were released since Cowboy 2.2: - Cowboy 2.2.2 While fixing the miscount in the previous patch release an issue was introduced where HTTP/2 bodies could be sent out of orders when using iolists. This has been corrected. Cowboy 2.2.1 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.</description> +Cowboy 2.2.2 While fixing the miscount in the previous patch release an issue was introduced where HTTP/2 bodies could be sent out of orders when using iolists. This has been corrected. Cowboy 2.2.1 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.</description> </item> <item> @@ -2003,8 +2108,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/migrating_from_1.0/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2014,7 +2119,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/migrating_from_2.0/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2024,7 +2129,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_2.2/</guid> <description>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.</description> +Features added Add support for all functions from the module sys. Note that Cowboy currently does not implement the sys debugging mechanisms as tracing is recommended instead. Add a max_frame_size option for Websocket handlers to close the connection when the client attempts to send a frame that&apos;s too large.</description> </item> <item> @@ -2034,7 +2139,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/migrating_from_2.3/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2044,7 +2149,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/specs/</guid> <description>This chapter intends to list all the specification documents for or related to HTTP. - HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol Registries Current CORS: Cross-Origin Resource Sharing CSP2: Content Security Policy Level 2 DNT: Tracking Preference Expression (DNT) eventsource: Server-Sent Events Form content types: Form content types Preload: Preload REST: Fielding&#8217;s Dissertation RFC 1945: HTTP/1.</description> +HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol Registries Current CORS: Cross-Origin Resource Sharing CSP2: Content Security Policy Level 2 DNT: Tracking Preference Expression (DNT) eventsource: Server-Sent Events Form content types: Form content types Preload: Preload REST: Fielding&apos;s Dissertation RFC 1945: HTTP/1.</description> </item> <item> @@ -2054,8 +2159,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/migrating_from_1.0/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2065,7 +2170,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/migrating_from_2.1/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2075,7 +2180,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_2.1/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2085,7 +2190,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/migrating_from_2.2/</guid> <description>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.</description> +Features added Add support for all functions from the module sys. Note that Cowboy currently does not implement the sys debugging mechanisms as tracing is recommended instead. Add a max_frame_size option for Websocket handlers to close the connection when the client attempts to send a frame that&apos;s too large.</description> </item> <item> @@ -2095,7 +2200,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/specs/</guid> <description>This chapter intends to list all the specification documents for or related to HTTP. - HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol Registries Current CORS: Cross-Origin Resource Sharing CSP2: Content Security Policy Level 2 DNT: Tracking Preference Expression (DNT) eventsource: Server-Sent Events Form content types: Form content types Preload: Preload REST: Fielding&#8217;s Dissertation RFC 1945: HTTP/1.</description> +HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol Registries Current CORS: Cross-Origin Resource Sharing CSP2: Content Security Policy Level 2 DNT: Tracking Preference Expression (DNT) eventsource: Server-Sent Events Form content types: Form content types Preload: Preload REST: Fielding&apos;s Dissertation RFC 1945: HTTP/1.</description> </item> <item> @@ -2105,7 +2210,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/migrating_from_2.0/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2115,7 +2220,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_2.0/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2125,7 +2230,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/migrating_from_2.1/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2135,8 +2240,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/migrating_from_1.0/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2146,8 +2251,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/migrating_from_1.0/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2157,7 +2262,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/migrating_from_2.0/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2167,7 +2272,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/specs/</guid> <description>This chapter intends to list all the specification documents for or related to HTTP. - HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol Registries Current CORS: Cross-Origin Resource Sharing CSP2: Content Security Policy Level 2 DNT: Tracking Preference Expression (DNT) eventsource: Server-Sent Events Form content types: Form content types Preload: Preload REST: Fielding&#8217;s Dissertation RFC 1945: HTTP/1.</description> +HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol Registries Current CORS: Cross-Origin Resource Sharing CSP2: Content Security Policy Level 2 DNT: Tracking Preference Expression (DNT) eventsource: Server-Sent Events Form content types: Form content types Preload: Preload REST: Fielding&apos;s Dissertation RFC 1945: HTTP/1.</description> </item> <item> @@ -2177,7 +2282,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/specs/</guid> <description>This chapter intends to list all the specification documents for or related to HTTP. - HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol Registries Current CORS: Cross-Origin Resource Sharing CSP2: Content Security Policy Level 2 DNT: Tracking Preference Expression (DNT) eventsource: Server-Sent Events Form content types: Form content types Preload: Preload PROXY: The PROXY protocol REST: Fielding&#8217;s Dissertation RFC 1945: HTTP/1.</description> +HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol Registries Current CORS: Cross-Origin Resource Sharing CSP2: Content Security Policy Level 2 DNT: Tracking Preference Expression (DNT) eventsource: Server-Sent Events Form content types: Form content types Preload: Preload PROXY: The PROXY protocol REST: Fielding&apos;s Dissertation RFC 1945: HTTP/1.</description> </item> <item> @@ -2187,8 +2292,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/migrating_from_1.0/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2198,7 +2303,7 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/specs/</guid> <description>This chapter intends to list all the specification documents for or related to HTTP. - HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol Registries Current CORS: Cross-Origin Resource Sharing CSP2: Content Security Policy Level 2 DNT: Tracking Preference Expression (DNT) eventsource: Server-Sent Events Form content types: Form content types Preload: Preload PROXY: The PROXY protocol REST: Fielding&#8217;s Dissertation RFC 1945: HTTP/1.</description> +HTTP IANA Registries HTTP Method Registry HTTP Status Code Registry Message Headers HTTP Parameters HTTP Alt-Svc Parameter Registry HTTP Authentication Scheme Registry HTTP Cache Directive Registry HTTP Digest Algorithm Values HTTP Origin-Bound Authentication Device Identifier Types HTTP Upgrade Token Registry HTTP Warn Codes HTTP/2 Parameters WebSocket Protocol Registries Current CORS: Cross-Origin Resource Sharing CSP2: Content Security Policy Level 2 DNT: Tracking Preference Expression (DNT) eventsource: Server-Sent Events Form content types: Form content types Preload: Preload PROXY: The PROXY protocol REST: Fielding&apos;s Dissertation RFC 1945: HTTP/1.</description> </item> <item> @@ -2208,10 +2313,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/</guid> <description>Name cowboy - Small, fast, modern HTTP server for Erlang/OTP - Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. - Modules Functions: - cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> +Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. +Modules Functions: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> </item> <item> @@ -2221,10 +2326,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/</guid> <description>Name cowboy - Small, fast, modern HTTP server for Erlang/OTP - Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. - Modules Functions: - cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> +Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. +Modules Functions: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> </item> <item> @@ -2234,10 +2339,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/</guid> <description>Name cowboy - Small, fast, modern HTTP server for Erlang/OTP - Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. - Modules Functions: - cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> +Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. +Modules Functions: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> </item> <item> @@ -2247,10 +2352,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/</guid> <description>Name cowboy - Small, fast, modern HTTP server for Erlang/OTP - Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. - Modules Functions: - cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> +Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. +Modules Functions: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> </item> <item> @@ -2260,10 +2365,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/</guid> <description>Name cowboy - Small, fast, modern HTTP server for Erlang/OTP - Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. - Modules Functions: - cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> +Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. +Modules Functions: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> </item> <item> @@ -2272,7 +2377,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.0/guide/</guid> - <description>Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Additional information Migrating from Cowboy 1.</description> + <description>Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Additional information Migrating from Cowboy 1.</description> </item> <item> @@ -2281,7 +2386,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.1/guide/</guid> - <description>Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Additional information Migrating from Cowboy 2.</description> + <description>Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Additional information Migrating from Cowboy 2.</description> </item> <item> @@ -2290,7 +2395,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.2/guide/</guid> - <description>Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Additional information Changes since Cowboy 2.</description> + <description>Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Additional information Changes since Cowboy 2.</description> </item> <item> @@ -2299,7 +2404,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.3/guide/</guid> - <description>Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Additional information Migrating from Cowboy 2.</description> + <description>Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Additional information Migrating from Cowboy 2.</description> </item> <item> @@ -2308,7 +2413,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.4/guide/</guid> - <description>Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Additional information Migrating from Cowboy 2.</description> + <description>Rationale The modern Web Erlang and the Web Introduction Introduction Getting started Flow diagram Configuration Listeners Routing Constraints Handlers Handlers Loop handlers Static files Request and response Request details Reading the request body Sending a response Using cookies Multipart REST REST principles Handling REST requests REST flowcharts Designing a resource handler Websocket The Websocket protocol Websocket handlers Advanced Streams Middlewares Additional information Migrating from Cowboy 2.</description> </item> <item> @@ -2317,7 +2422,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/erlang.mk/1/guide/</guid> - <description>Installation Getting started Overview Updating Erlang.mk Limitations Code Building Packages and dependencies NIFs and port drivers Releases Self-extracting releases Escripts OTP version management Compatibility with other build tools Documentation Asciidoc documentation EDoc comments Sphinx documentation Tests Erlang shell EUnit Common Test Triq Code coverage Continuous integration Dialyzer Xref Third-party plugins External plugins List of plugins About Erlang.</description> + <description>Installation Getting started Overview Updating Erlang.mk Limitations Code Building Packages and dependencies NIFs and port drivers Releases Self-extracting releases Escripts OTP version management Compatibility with other build tools Documentation Asciidoc documentation EDoc comments Sphinx documentation Tests Erlang shell EUnit Common Test Triq Code coverage Continuous integration Dialyzer Xref Third-party plugins External plugins List of plugins About Erlang.</description> </item> <item> @@ -2327,9 +2432,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/</guid> <description>Name gun - HTTP/1.1, HTTP/2 and Websocket client for Erlang/OTP - Description Gun is an HTTP client for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Gun aims to provide an easy to use, asynchronous and always-connected client. It maintains a permanent connection to the server and reconnects automatically when necessary. - Modules gun(3) - Asynchronous HTTP client Dependencies cowlib(7) - Support library for manipulating Web protocols ssl - Secure communication over sockets All these applications must be started before the gun application.</description> +Description Gun is an HTTP client for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Gun aims to provide an easy to use, asynchronous and always-connected client. It maintains a permanent connection to the server and reconnects automatically when necessary. +Modules gun(3) - Asynchronous HTTP client Dependencies cowlib(7) - Support library for manipulating Web protocols ssl - Secure communication over sockets All these applications must be started before the gun application.</description> </item> <item> @@ -2338,7 +2443,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/gun/1.0/guide/</guid> - <description> Introduction Starting and stopping Supported protocols Connection Using HTTP Using Websocket </description> + <description>Introduction Starting and stopping Supported protocols Connection Using HTTP Using Websocket </description> </item> <item> @@ -2348,8 +2453,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/http_status_codes/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2359,8 +2464,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/http_status_codes/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2370,8 +2475,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/http_status_codes/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2381,8 +2486,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/http_status_codes/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2392,8 +2497,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/http_status_codes/</guid> <description>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.</description> +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.</description> </item> <item> @@ -2402,7 +2507,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/ranch/1.2/manual/</guid> - <description> ranch(7) ranch(3) ranch_protocol(3) ranch_ssl(3) ranch_tcp(3) ranch_transport(3) </description> + <description>ranch(7) ranch(3) ranch_protocol(3) ranch_ssl(3) ranch_tcp(3) ranch_transport(3) </description> </item> <item> @@ -2411,7 +2516,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/ranch/1.3/manual/</guid> - <description> ranch(7) ranch(3) ranch_protocol(3) ranch_ssl(3) ranch_tcp(3) ranch_transport(3) </description> + <description>ranch(7) ranch(3) ranch_protocol(3) ranch_ssl(3) ranch_tcp(3) ranch_transport(3) </description> </item> <item> @@ -2420,7 +2525,16 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/ranch/1.4/manual/</guid> - <description> ranch(7) ranch(3) ranch_protocol(3) ranch_ssl(3) ranch_tcp(3) ranch_transport(3) </description> + <description>ranch(7) ranch(3) ranch_protocol(3) ranch_ssl(3) ranch_tcp(3) ranch_transport(3) </description> + </item> + + <item> + <title>Ranch Function Reference</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/manual/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/manual/</guid> + <description>ranch(7) ranch(3) ranch_protocol(3) ranch_ssl(3) ranch_tcp(3) ranch_transport(3) </description> </item> <item> @@ -2429,7 +2543,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/ranch/1.2/guide/</guid> - <description> Introduction Listeners Transports Protocols Embedded mode Writing parsers SSL client authentication Internals </description> + <description>Introduction Listeners Transports Protocols Embedded mode Writing parsers SSL client authentication Internals </description> </item> <item> @@ -2438,7 +2552,7 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/ranch/1.3/guide/</guid> - <description> Introduction Listeners Transports Protocols Embedded mode Writing parsers SSL client authentication Internals </description> + <description>Introduction Listeners Transports Protocols Embedded mode Writing parsers SSL client authentication Internals </description> </item> <item> @@ -2447,7 +2561,16 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/ranch/1.4/guide/</guid> - <description> Introduction Listeners Transports Protocols Embedded mode Writing parsers SSL client authentication Internals </description> + <description>Introduction Listeners Transports Protocols Embedded mode Writing parsers SSL client authentication Internals </description> + </item> + + <item> + <title>Ranch User Guide</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/guide/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/guide/</guid> + <description>Introduction Listeners Transports Protocols Embedded mode Writing parsers SSL client authentication Internals </description> </item> <item> @@ -2457,8 +2580,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy/</guid> <description>Name cowboy - HTTP server - Description The module cowboy provides convenience functions for manipulating Ranch listeners. - Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&#8217;s environment value Types fields() fields() :: [Name | {Name, Constraints} | {Name, Constraints, Default}] Name :: atom() Constraints :: Constraint | [Constraint] Constraint :: cowboy_constraints:constraint() Default :: any() Fields description for match operations.</description> +Description The module cowboy provides convenience functions for manipulating Ranch listeners. +Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&apos;s environment value Types fields() fields() :: [Name | {Name, Constraints} | {Name, Constraints, Default}] Name :: atom() Constraints :: Constraint | [Constraint] Constraint :: cowboy_constraints:constraint() Default :: any() Fields description for match operations.</description> </item> <item> @@ -2468,8 +2591,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy/</guid> <description>Name cowboy - HTTP server - Description The module cowboy provides convenience functions for manipulating Ranch listeners. - Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&#8217;s environment value Types fields() fields() :: [Name | {Name, Constraints} | {Name, Constraints, Default}] Name :: atom() Constraints :: Constraint | [Constraint] Constraint :: cowboy_constraints:constraint() Default :: any() Fields description for match operations.</description> +Description The module cowboy provides convenience functions for manipulating Ranch listeners. +Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&apos;s environment value Types fields() fields() :: [Name | {Name, Constraints} | {Name, Constraints, Default}] Name :: atom() Constraints :: Constraint | [Constraint] Constraint :: cowboy_constraints:constraint() Default :: any() Fields description for match operations.</description> </item> <item> @@ -2479,8 +2602,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy/</guid> <description>Name cowboy - HTTP server - Description The module cowboy provides convenience functions for manipulating Ranch listeners. - Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&#8217;s environment value Types fields() fields() :: [Name | {Name, Constraints} | {Name, Constraints, Default}] Name :: atom() Constraints :: Constraint | [Constraint] Constraint :: cowboy_constraints:constraint() Default :: any() Fields description for match operations.</description> +Description The module cowboy provides convenience functions for manipulating Ranch listeners. +Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&apos;s environment value Types fields() fields() :: [Name | {Name, Constraints} | {Name, Constraints, Default}] Name :: atom() Constraints :: Constraint | [Constraint] Constraint :: cowboy_constraints:constraint() Default :: any() Fields description for match operations.</description> </item> <item> @@ -2490,8 +2613,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy/</guid> <description>Name cowboy - HTTP server - Description The module cowboy provides convenience functions for manipulating Ranch listeners. - Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&#8217;s environment value Types fields() fields() :: [Name | {Name, Constraints} | {Name, Constraints, Default}] Name :: atom() Constraints :: Constraint | [Constraint] Constraint :: cowboy_constraints:constraint() Default :: any() Fields description for match operations.</description> +Description The module cowboy provides convenience functions for manipulating Ranch listeners. +Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&apos;s environment value Types fields() fields() :: [Name | {Name, Constraints} | {Name, Constraints, Default}] Name :: atom() Constraints :: Constraint | [Constraint] Constraint :: cowboy_constraints:constraint() Default :: any() Fields description for match operations.</description> </item> <item> @@ -2501,8 +2624,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy/</guid> <description>Name cowboy - HTTP server - Description The module cowboy provides convenience functions for manipulating Ranch listeners. - Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&#8217;s environment value Types fields() fields() :: [Name | {Name, Constraints} | {Name, Constraints, Default}] Name :: atom() Constraints :: Constraint | [Constraint] Constraint :: cowboy_constraints:constraint() Default :: any() Fields description for match operations.</description> +Description The module cowboy provides convenience functions for manipulating Ranch listeners. +Exports cowboy:start_clear(3) - Listen for connections using plain TCP cowboy:start_tls(3) - Listen for connections using TLS cowboy:stop_listener(3) - Stop the given listener cowboy:set_env(3) - Update a listener&apos;s environment value Types fields() fields() :: [Name | {Name, Constraints} | {Name, Constraints, Default}] Name :: atom() Constraints :: Constraint | [Constraint] Constraint :: cowboy_constraints:constraint() Default :: any() Fields description for match operations.</description> </item> <item> @@ -2512,10 +2635,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_app/</guid> <description>Name cowboy - Small, fast, modern HTTP server for Erlang/OTP - Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. - Modules Functions: - cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> +Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. +Modules Functions: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> </item> <item> @@ -2525,10 +2648,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_app/</guid> <description>Name cowboy - Small, fast, modern HTTP server for Erlang/OTP - Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. - Modules Functions: - cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> +Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. +Modules Functions: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> </item> <item> @@ -2538,10 +2661,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_app/</guid> <description>Name cowboy - Small, fast, modern HTTP server for Erlang/OTP - Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. - Modules Functions: - cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> +Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. +Modules Functions: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> </item> <item> @@ -2551,10 +2674,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_app/</guid> <description>Name cowboy - Small, fast, modern HTTP server for Erlang/OTP - Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. - Modules Functions: - cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> +Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. +Modules Functions: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> </item> <item> @@ -2564,10 +2687,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_app/</guid> <description>Name cowboy - Small, fast, modern HTTP server for Erlang/OTP - Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. - Modules Functions: - cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> +Description Cowboy is an HTTP server for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Cowboy aims to provide a complete HTTP stack. This includes the implementation of the HTTP RFCs but also any directly related standards, like Websocket or Server-Sent Events. +Modules Functions: +cowboy(3) - Listener management cowboy_req(3) - Request and response cowboy_router(3) - Router cowboy_constraints(3) - Constraints Protocols:</description> </item> <item> @@ -2576,11 +2699,11 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy.set_env/</guid> - <description>Name cowboy:set_env - Update a listener&#8217;s environment value - Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; ok Set or update an environment value for a previously started listener. - This is most useful for updating the routes dynamically, without having to restart the listener. - The new value will only be available to new connections. Pre-existing connections will still use the old value. - Arguments Name The name of the listener to update.</description> + <description>Name cowboy:set_env - Update a listener&apos;s environment value +Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; ok Set or update an environment value for a previously started listener. +This is most useful for updating the routes dynamically, without having to restart the listener. +The new value will only be available to new connections. Pre-existing connections will still use the old value. +Arguments Name The name of the listener to update.</description> </item> <item> @@ -2589,11 +2712,11 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy.set_env/</guid> - <description>Name cowboy:set_env - Update a listener&#8217;s environment value - Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; ok Set or update an environment value for a previously started listener. - This is most useful for updating the routes dynamically, without having to restart the listener. - The new value will only be available to new connections. Pre-existing connections will still use the old value. - Arguments Name The name of the listener to update.</description> + <description>Name cowboy:set_env - Update a listener&apos;s environment value +Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; ok Set or update an environment value for a previously started listener. +This is most useful for updating the routes dynamically, without having to restart the listener. +The new value will only be available to new connections. Pre-existing connections will still use the old value. +Arguments Name The name of the listener to update.</description> </item> <item> @@ -2602,11 +2725,11 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy.set_env/</guid> - <description>Name cowboy:set_env - Update a listener&#8217;s environment value - Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; ok Set or update an environment value for a previously started listener. - This is most useful for updating the routes dynamically, without having to restart the listener. - The new value will only be available to new connections. Pre-existing connections will still use the old value. - Arguments Name The name of the listener to update.</description> + <description>Name cowboy:set_env - Update a listener&apos;s environment value +Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; ok Set or update an environment value for a previously started listener. +This is most useful for updating the routes dynamically, without having to restart the listener. +The new value will only be available to new connections. Pre-existing connections will still use the old value. +Arguments Name The name of the listener to update.</description> </item> <item> @@ -2615,11 +2738,11 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.set_env/</guid> - <description>Name cowboy:set_env - Update a listener&#8217;s environment value - Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; ok Set or update an environment value for a previously started listener. - This is most useful for updating the routes dynamically, without having to restart the listener. - The new value will only be available to new connections. Pre-existing connections will still use the old value. - Arguments Name The name of the listener to update.</description> + <description>Name cowboy:set_env - Update a listener&apos;s environment value +Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; ok Set or update an environment value for a previously started listener. +This is most useful for updating the routes dynamically, without having to restart the listener. +The new value will only be available to new connections. Pre-existing connections will still use the old value. +Arguments Name The name of the listener to update.</description> </item> <item> @@ -2628,11 +2751,11 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy.set_env/</guid> - <description>Name cowboy:set_env - Update a listener&#8217;s environment value - Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; ok Set or update an environment value for a previously started listener. - This is most useful for updating the routes dynamically, without having to restart the listener. - The new value will only be available to new connections. Pre-existing connections will still use the old value. - Arguments Name The name of the listener to update.</description> + <description>Name cowboy:set_env - Update a listener&apos;s environment value +Description set_env(Name :: ranch:ref(), Key :: atom(), Value :: any()) -&gt; ok Set or update an environment value for a previously started listener. +This is most useful for updating the routes dynamically, without having to restart the listener. +The new value will only be available to new connections. Pre-existing connections will still use the old value. +Arguments Name The name of the listener to update.</description> </item> <item> @@ -2642,8 +2765,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy.start_clear/</guid> <description>Name cowboy:start_clear - Listen for connections using plain TCP - Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a clear TCP channel. - Both HTTP/1.1 and HTTP/2 are supported on this listener. HTTP/2 has two methods of establishing a connection over a clear TCP channel. Both the upgrade and the prior knowledge methods are supported.</description> +Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a clear TCP channel. +Both HTTP/1.1 and HTTP/2 are supported on this listener. HTTP/2 has two methods of establishing a connection over a clear TCP channel. Both the upgrade and the prior knowledge methods are supported. +Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> </item> <item> @@ -2653,8 +2777,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy.start_clear/</guid> <description>Name cowboy:start_clear - Listen for connections using plain TCP - Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a clear TCP channel. - Both HTTP/1.1 and HTTP/2 are supported on this listener. HTTP/2 has two methods of establishing a connection over a clear TCP channel. Both the upgrade and the prior knowledge methods are supported.</description> +Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a clear TCP channel. +Both HTTP/1.1 and HTTP/2 are supported on this listener. HTTP/2 has two methods of establishing a connection over a clear TCP channel. Both the upgrade and the prior knowledge methods are supported. +Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> </item> <item> @@ -2664,8 +2789,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy.start_clear/</guid> <description>Name cowboy:start_clear - Listen for connections using plain TCP - Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a clear TCP channel. - Both HTTP/1.1 and HTTP/2 are supported on this listener. HTTP/2 has two methods of establishing a connection over a clear TCP channel. Both the upgrade and the prior knowledge methods are supported.</description> +Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a clear TCP channel. +Both HTTP/1.1 and HTTP/2 are supported on this listener. HTTP/2 has two methods of establishing a connection over a clear TCP channel. Both the upgrade and the prior knowledge methods are supported. +Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> </item> <item> @@ -2675,8 +2801,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.start_clear/</guid> <description>Name cowboy:start_clear - Listen for connections using plain TCP - Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a clear TCP channel. - Both HTTP/1.1 and HTTP/2 are supported on this listener. HTTP/2 has two methods of establishing a connection over a clear TCP channel. Both the upgrade and the prior knowledge methods are supported.</description> +Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a clear TCP channel. +Both HTTP/1.1 and HTTP/2 are supported on this listener. HTTP/2 has two methods of establishing a connection over a clear TCP channel. Both the upgrade and the prior knowledge methods are supported. +Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> </item> <item> @@ -2686,8 +2813,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy.start_clear/</guid> <description>Name cowboy:start_clear - Listen for connections using plain TCP - Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a clear TCP channel. - Both HTTP/1.1 and HTTP/2 are supported on this listener. HTTP/2 has two methods of establishing a connection over a clear TCP channel. Both the upgrade and the prior knowledge methods are supported.</description> +Description start_clear(Name :: ranch:ref(), TransportOpts :: ranch_tcp:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a clear TCP channel. +Both HTTP/1.1 and HTTP/2 are supported on this listener. HTTP/2 has two methods of establishing a connection over a clear TCP channel. Both the upgrade and the prior knowledge methods are supported. +Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> </item> <item> @@ -2697,9 +2825,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy.start_tls/</guid> <description>Name cowboy:start_tls - Listen for connections using TLS - Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a secure TLS channel. - Both HTTP/1.1 and HTTP/2 are supported on this listener. The ALPN TLS extension must be used to initiate an HTTP/2 connection. - Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> +Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a secure TLS channel. +Both HTTP/1.1 and HTTP/2 are supported on this listener. The ALPN TLS extension must be used to initiate an HTTP/2 connection. +Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> </item> <item> @@ -2709,9 +2837,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy.start_tls/</guid> <description>Name cowboy:start_tls - Listen for connections using TLS - Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a secure TLS channel. - Both HTTP/1.1 and HTTP/2 are supported on this listener. The ALPN TLS extension must be used to initiate an HTTP/2 connection. - Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> +Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a secure TLS channel. +Both HTTP/1.1 and HTTP/2 are supported on this listener. The ALPN TLS extension must be used to initiate an HTTP/2 connection. +Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> </item> <item> @@ -2721,9 +2849,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy.start_tls/</guid> <description>Name cowboy:start_tls - Listen for connections using TLS - Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a secure TLS channel. - Both HTTP/1.1 and HTTP/2 are supported on this listener. The ALPN TLS extension must be used to initiate an HTTP/2 connection. - Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> +Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a secure TLS channel. +Both HTTP/1.1 and HTTP/2 are supported on this listener. The ALPN TLS extension must be used to initiate an HTTP/2 connection. +Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> </item> <item> @@ -2733,9 +2861,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.start_tls/</guid> <description>Name cowboy:start_tls - Listen for connections using TLS - Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a secure TLS channel. - Both HTTP/1.1 and HTTP/2 are supported on this listener. The ALPN TLS extension must be used to initiate an HTTP/2 connection. - Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> +Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a secure TLS channel. +Both HTTP/1.1 and HTTP/2 are supported on this listener. The ALPN TLS extension must be used to initiate an HTTP/2 connection. +Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> </item> <item> @@ -2745,9 +2873,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy.start_tls/</guid> <description>Name cowboy:start_tls - Listen for connections using TLS - Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a secure TLS channel. - Both HTTP/1.1 and HTTP/2 are supported on this listener. The ALPN TLS extension must be used to initiate an HTTP/2 connection. - Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> +Description start_tls(Name :: ranch:ref(), TransportOpts :: ranch_ssl:opts(), ProtocolOpts :: opts()) -&gt; {ok, ListenerPid :: pid()} | {error, any()} Start listening for connections over a secure TLS channel. +Both HTTP/1.1 and HTTP/2 are supported on this listener. The ALPN TLS extension must be used to initiate an HTTP/2 connection. +Arguments Name The listener name is used to refer to this listener in future calls, for example when stopping it or when updating the routes defined.</description> </item> <item> @@ -2757,10 +2885,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy.stop_listener/</guid> <description>Name cowboy:stop_listener - Stop the given listener - Description stop_listener(Name :: ranch:ref()) -&gt; ok | {error, not_found}. Stop a previously started listener. - Alias of ranch:stop_listener(3). - Arguments Name The name of the listener to be stopped. The name of the listener is the first argument given to the cowboy:start_clear(3), cowboy:start_tls(3) or ranch:start_listener(3) function. - Return value The atom ok is returned on success.</description> +Description stop_listener(Name :: ranch:ref()) -&gt; ok | {error, not_found}. Stop a previously started listener. +Alias of ranch:stop_listener(3). +Arguments Name The name of the listener to be stopped. +The name of the listener is the first argument given to the cowboy:start_clear(3), cowboy:start_tls(3) or ranch:start_listener(3) function. + Return value The atom ok is returned on success. +The {error, not_found} tuple is returned when the listener does not exist.</description> </item> <item> @@ -2770,10 +2900,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy.stop_listener/</guid> <description>Name cowboy:stop_listener - Stop the given listener - Description stop_listener(Name :: ranch:ref()) -&gt; ok | {error, not_found}. Stop a previously started listener. - Alias of ranch:stop_listener(3). - Arguments Name The name of the listener to be stopped. The name of the listener is the first argument given to the cowboy:start_clear(3), cowboy:start_tls(3) or ranch:start_listener(3) function. - Return value The atom ok is returned on success.</description> +Description stop_listener(Name :: ranch:ref()) -&gt; ok | {error, not_found}. Stop a previously started listener. +Alias of ranch:stop_listener(3). +Arguments Name The name of the listener to be stopped. +The name of the listener is the first argument given to the cowboy:start_clear(3), cowboy:start_tls(3) or ranch:start_listener(3) function. + Return value The atom ok is returned on success. +The {error, not_found} tuple is returned when the listener does not exist.</description> </item> <item> @@ -2783,10 +2915,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy.stop_listener/</guid> <description>Name cowboy:stop_listener - Stop the given listener - Description stop_listener(Name :: ranch:ref()) -&gt; ok | {error, not_found}. Stop a previously started listener. - Alias of ranch:stop_listener(3). - Arguments Name The name of the listener to be stopped. The name of the listener is the first argument given to the cowboy:start_clear(3), cowboy:start_tls(3) or ranch:start_listener(3) function. - Return value The atom ok is returned on success.</description> +Description stop_listener(Name :: ranch:ref()) -&gt; ok | {error, not_found}. Stop a previously started listener. +Alias of ranch:stop_listener(3). +Arguments Name The name of the listener to be stopped. +The name of the listener is the first argument given to the cowboy:start_clear(3), cowboy:start_tls(3) or ranch:start_listener(3) function. + Return value The atom ok is returned on success. +The {error, not_found} tuple is returned when the listener does not exist.</description> </item> <item> @@ -2796,10 +2930,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy.stop_listener/</guid> <description>Name cowboy:stop_listener - Stop the given listener - Description stop_listener(Name :: ranch:ref()) -&gt; ok | {error, not_found}. Stop a previously started listener. - Alias of ranch:stop_listener(3). - Arguments Name The name of the listener to be stopped. The name of the listener is the first argument given to the cowboy:start_clear(3), cowboy:start_tls(3) or ranch:start_listener(3) function. - Return value The atom ok is returned on success.</description> +Description stop_listener(Name :: ranch:ref()) -&gt; ok | {error, not_found}. Stop a previously started listener. +Alias of ranch:stop_listener(3). +Arguments Name The name of the listener to be stopped. +The name of the listener is the first argument given to the cowboy:start_clear(3), cowboy:start_tls(3) or ranch:start_listener(3) function. + Return value The atom ok is returned on success. +The {error, not_found} tuple is returned when the listener does not exist.</description> </item> <item> @@ -2809,10 +2945,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy.stop_listener/</guid> <description>Name cowboy:stop_listener - Stop the given listener - Description stop_listener(Name :: ranch:ref()) -&gt; ok | {error, not_found}. Stop a previously started listener. - Alias of ranch:stop_listener(3). - Arguments Name The name of the listener to be stopped. The name of the listener is the first argument given to the cowboy:start_clear(3), cowboy:start_tls(3) or ranch:start_listener(3) function. - Return value The atom ok is returned on success.</description> +Description stop_listener(Name :: ranch:ref()) -&gt; ok | {error, not_found}. Stop a previously started listener. +Alias of ranch:stop_listener(3). +Arguments Name The name of the listener to be stopped. +The name of the listener is the first argument given to the cowboy:start_clear(3), cowboy:start_tls(3) or ranch:start_listener(3) function. + Return value The atom ok is returned on success. +The {error, not_found} tuple is returned when the listener does not exist.</description> </item> <item> @@ -2822,10 +2960,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_constraints/</guid> <description>Name cowboy_constraints - Constraints - Description The module cowboy_constraints defines the built-in constraints in Cowboy and provides an interface for manipulating these constraints. - Constraints are functions that define what type of input is allowed. They are used throughout Cowboy, from the router to query strings to cookies. - Exports Built-in constraints: - cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function.</description> +Description The module cowboy_constraints defines the built-in constraints in Cowboy and provides an interface for manipulating these constraints. +Constraints are functions that define what type of input is allowed. They are used throughout Cowboy, from the router to query strings to cookies. +Exports Built-in constraints: +cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function.</description> </item> <item> @@ -2835,10 +2973,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_constraints/</guid> <description>Name cowboy_constraints - Constraints - Description The module cowboy_constraints defines the built-in constraints in Cowboy and provides an interface for manipulating these constraints. - Constraints are functions that define what type of input is allowed. They are used throughout Cowboy, from the router to query strings to cookies. - Exports Built-in constraints: - cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function.</description> +Description The module cowboy_constraints defines the built-in constraints in Cowboy and provides an interface for manipulating these constraints. +Constraints are functions that define what type of input is allowed. They are used throughout Cowboy, from the router to query strings to cookies. +Exports Built-in constraints: +cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function.</description> </item> <item> @@ -2848,10 +2986,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_constraints/</guid> <description>Name cowboy_constraints - Constraints - Description The module cowboy_constraints defines the built-in constraints in Cowboy and provides an interface for manipulating these constraints. - Constraints are functions that define what type of input is allowed. They are used throughout Cowboy, from the router to query strings to cookies. - Exports Built-in constraints: - cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function.</description> +Description The module cowboy_constraints defines the built-in constraints in Cowboy and provides an interface for manipulating these constraints. +Constraints are functions that define what type of input is allowed. They are used throughout Cowboy, from the router to query strings to cookies. +Exports Built-in constraints: +cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function.</description> </item> <item> @@ -2861,10 +2999,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_constraints/</guid> <description>Name cowboy_constraints - Constraints - Description The module cowboy_constraints defines the built-in constraints in Cowboy and provides an interface for manipulating these constraints. - Constraints are functions that define what type of input is allowed. They are used throughout Cowboy, from the router to query strings to cookies. - Exports Built-in constraints: - cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function.</description> +Description The module cowboy_constraints defines the built-in constraints in Cowboy and provides an interface for manipulating these constraints. +Constraints are functions that define what type of input is allowed. They are used throughout Cowboy, from the router to query strings to cookies. +Exports Built-in constraints: +cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function.</description> </item> <item> @@ -2874,10 +3012,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_constraints/</guid> <description>Name cowboy_constraints - Constraints - Description The module cowboy_constraints defines the built-in constraints in Cowboy and provides an interface for manipulating these constraints. - Constraints are functions that define what type of input is allowed. They are used throughout Cowboy, from the router to query strings to cookies. - Exports Built-in constraints: - cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function.</description> +Description The module cowboy_constraints defines the built-in constraints in Cowboy and provides an interface for manipulating these constraints. +Constraints are functions that define what type of input is allowed. They are used throughout Cowboy, from the router to query strings to cookies. +Exports Built-in constraints: +cowboy_constraints:int(3) - Integer constraint cowboy_constraints:nonempty(3) - Non-empty constraint Types constraint() constraint() :: int | nonempty | fun() A constraint function.</description> </item> <item> @@ -2887,10 +3025,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_constraints.int/</guid> <description>Name cowboy_constraints:int - Integer constraint - Description Constraint functions implement a number of different operations. - int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. - int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. - int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message.</description> +Description Constraint functions implement a number of different operations. +int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. +int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. +int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message.</description> </item> <item> @@ -2900,10 +3038,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_constraints.int/</guid> <description>Name cowboy_constraints:int - Integer constraint - Description Constraint functions implement a number of different operations. - int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. - int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. - int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message.</description> +Description Constraint functions implement a number of different operations. +int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. +int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. +int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message.</description> </item> <item> @@ -2913,10 +3051,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_constraints.int/</guid> <description>Name cowboy_constraints:int - Integer constraint - Description Constraint functions implement a number of different operations. - int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. - int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. - int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message.</description> +Description Constraint functions implement a number of different operations. +int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. +int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. +int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message.</description> </item> <item> @@ -2926,10 +3064,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_constraints.int/</guid> <description>Name cowboy_constraints:int - Integer constraint - Description Constraint functions implement a number of different operations. - int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. - int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. - int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message.</description> +Description Constraint functions implement a number of different operations. +int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. +int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. +int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message.</description> </item> <item> @@ -2939,10 +3077,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_constraints.int/</guid> <description>Name cowboy_constraints:int - Integer constraint - Description Constraint functions implement a number of different operations. - int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. - int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. - int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message.</description> +Description Constraint functions implement a number of different operations. +int(forward, Bin) -&gt; {ok, Int} | {error, not_an_integer} Bin :: binary() Int :: integer() Validate and convert the text representation of an integer. +int(reverse, Int) -&gt; {ok, Bin} | {error, not_an_integer} Convert an integer back to its text representation. +int(format_error, Error) -&gt; HumanReadable Error :: {not_an_integer, Bin | Int} HumanReadable :: iolist() Generate a human-readable error message.</description> </item> <item> @@ -2952,11 +3090,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_constraints.nonempty/</guid> <description>Name cowboy_constraints:nonempty - Non-empty constraint - Description Constraint functions implement a number of different operations. - nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. - nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. - nonempty(format_error, Error) -&gt; HumanReadable Error :: {empty, Bin} HumanReadable :: iolist() Generate a human-readable error message. - Arguments Arguments vary depending on the operation.</description> +Description Constraint functions implement a number of different operations. +nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. +nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. +nonempty(format_error, Error) -&gt; HumanReadable Error :: {empty, Bin} HumanReadable :: iolist() Generate a human-readable error message. +Arguments Arguments vary depending on the operation. Constraint functions always take the operation type as first argument, and the value as second argument.</description> </item> <item> @@ -2966,11 +3104,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_constraints.nonempty/</guid> <description>Name cowboy_constraints:nonempty - Non-empty constraint - Description Constraint functions implement a number of different operations. - nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. - nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. - nonempty(format_error, Error) -&gt; HumanReadable Error :: {empty, Bin} HumanReadable :: iolist() Generate a human-readable error message. - Arguments Arguments vary depending on the operation.</description> +Description Constraint functions implement a number of different operations. +nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. +nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. +nonempty(format_error, Error) -&gt; HumanReadable Error :: {empty, Bin} HumanReadable :: iolist() Generate a human-readable error message. +Arguments Arguments vary depending on the operation. Constraint functions always take the operation type as first argument, and the value as second argument.</description> </item> <item> @@ -2980,11 +3118,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_constraints.nonempty/</guid> <description>Name cowboy_constraints:nonempty - Non-empty constraint - Description Constraint functions implement a number of different operations. - nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. - nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. - nonempty(format_error, Error) -&gt; HumanReadable Error :: {empty, Bin} HumanReadable :: iolist() Generate a human-readable error message. - Arguments Arguments vary depending on the operation.</description> +Description Constraint functions implement a number of different operations. +nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. +nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. +nonempty(format_error, Error) -&gt; HumanReadable Error :: {empty, Bin} HumanReadable :: iolist() Generate a human-readable error message. +Arguments Arguments vary depending on the operation. Constraint functions always take the operation type as first argument, and the value as second argument.</description> </item> <item> @@ -2994,11 +3132,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_constraints.nonempty/</guid> <description>Name cowboy_constraints:nonempty - Non-empty constraint - Description Constraint functions implement a number of different operations. - nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. - nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. - nonempty(format_error, Error) -&gt; HumanReadable Error :: {empty, Bin} HumanReadable :: iolist() Generate a human-readable error message. - Arguments Arguments vary depending on the operation.</description> +Description Constraint functions implement a number of different operations. +nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. +nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. +nonempty(format_error, Error) -&gt; HumanReadable Error :: {empty, Bin} HumanReadable :: iolist() Generate a human-readable error message. +Arguments Arguments vary depending on the operation. Constraint functions always take the operation type as first argument, and the value as second argument.</description> </item> <item> @@ -3008,11 +3146,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_constraints.nonempty/</guid> <description>Name cowboy_constraints:nonempty - Non-empty constraint - Description Constraint functions implement a number of different operations. - nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. - nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. - nonempty(format_error, Error) -&gt; HumanReadable Error :: {empty, Bin} HumanReadable :: iolist() Generate a human-readable error message. - Arguments Arguments vary depending on the operation.</description> +Description Constraint functions implement a number of different operations. +nonempty(forward | reverse, &lt;&lt;&gt;&gt;) -&gt; {error, empty} Reject empty values. +nonempty(forward | reverse, Bin) -&gt; {ok, Bin} Bin :: binary() Accept any other binary values. +nonempty(format_error, Error) -&gt; HumanReadable Error :: {empty, Bin} HumanReadable :: iolist() Generate a human-readable error message. +Arguments Arguments vary depending on the operation. Constraint functions always take the operation type as first argument, and the value as second argument.</description> </item> <item> @@ -3022,9 +3160,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_handler/</guid> <description>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.</description> +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.</description> </item> <item> @@ -3034,9 +3172,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_handler/</guid> <description>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.</description> +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.</description> </item> <item> @@ -3046,9 +3184,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_handler/</guid> <description>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.</description> +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.</description> </item> <item> @@ -3058,9 +3196,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_handler/</guid> <description>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.</description> +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.</description> </item> <item> @@ -3070,9 +3208,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_handler/</guid> <description>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.</description> +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.</description> </item> <item> @@ -3082,9 +3220,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_handler.terminate/</guid> <description>Name cowboy_handler:terminate - Terminate the handler - Description terminate(Reason, PartialReq, State, Handler) -&gt; ok Reason :: any() PartialReq :: map() State :: any() Handler :: module() Call the optional terminate callback if it is defined. - Make sure to use this function at the end of the execution of modules that implement custom handler behaviors. - Arguments Reason Reason for termination. PartialReq The Req object.</description> +Description terminate(Reason, PartialReq, State, Handler) -&gt; ok Reason :: any() PartialReq :: map() State :: any() Handler :: module() Call the optional terminate callback if it is defined. +Make sure to use this function at the end of the execution of modules that implement custom handler behaviors. +Arguments Reason Reason for termination. + PartialReq The Req object. +It is possible to remove fields from the Req object to save memory when the handler has no concept of requests/responses.</description> </item> <item> @@ -3094,9 +3234,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_handler.terminate/</guid> <description>Name cowboy_handler:terminate - Terminate the handler - Description terminate(Reason, PartialReq, State, Handler) -&gt; ok Reason :: any() PartialReq :: map() State :: any() Handler :: module() Call the optional terminate callback if it is defined. - Make sure to use this function at the end of the execution of modules that implement custom handler behaviors. - Arguments Reason Reason for termination. PartialReq The Req object.</description> +Description terminate(Reason, PartialReq, State, Handler) -&gt; ok Reason :: any() PartialReq :: map() State :: any() Handler :: module() Call the optional terminate callback if it is defined. +Make sure to use this function at the end of the execution of modules that implement custom handler behaviors. +Arguments Reason Reason for termination. + PartialReq The Req object. +It is possible to remove fields from the Req object to save memory when the handler has no concept of requests/responses.</description> </item> <item> @@ -3106,9 +3248,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_handler.terminate/</guid> <description>Name cowboy_handler:terminate - Terminate the handler - Description terminate(Reason, PartialReq, State, Handler) -&gt; ok Reason :: any() PartialReq :: map() State :: any() Handler :: module() Call the optional terminate callback if it is defined. - Make sure to use this function at the end of the execution of modules that implement custom handler behaviors. - Arguments Reason Reason for termination. PartialReq The Req object.</description> +Description terminate(Reason, PartialReq, State, Handler) -&gt; ok Reason :: any() PartialReq :: map() State :: any() Handler :: module() Call the optional terminate callback if it is defined. +Make sure to use this function at the end of the execution of modules that implement custom handler behaviors. +Arguments Reason Reason for termination. + PartialReq The Req object. +It is possible to remove fields from the Req object to save memory when the handler has no concept of requests/responses.</description> </item> <item> @@ -3118,9 +3262,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_handler.terminate/</guid> <description>Name cowboy_handler:terminate - Terminate the handler - Description terminate(Reason, PartialReq, State, Handler) -&gt; ok Reason :: any() PartialReq :: map() State :: any() Handler :: module() Call the optional terminate callback if it is defined. - Make sure to use this function at the end of the execution of modules that implement custom handler behaviors. - Arguments Reason Reason for termination. PartialReq The Req object.</description> +Description terminate(Reason, PartialReq, State, Handler) -&gt; ok Reason :: any() PartialReq :: map() State :: any() Handler :: module() Call the optional terminate callback if it is defined. +Make sure to use this function at the end of the execution of modules that implement custom handler behaviors. +Arguments Reason Reason for termination. + PartialReq The Req object. +It is possible to remove fields from the Req object to save memory when the handler has no concept of requests/responses.</description> </item> <item> @@ -3130,9 +3276,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_handler.terminate/</guid> <description>Name cowboy_handler:terminate - Terminate the handler - Description terminate(Reason, PartialReq, State, Handler) -&gt; ok Reason :: any() PartialReq :: map() State :: any() Handler :: module() Call the optional terminate callback if it is defined. - Make sure to use this function at the end of the execution of modules that implement custom handler behaviors. - Arguments Reason Reason for termination. PartialReq The Req object.</description> +Description terminate(Reason, PartialReq, State, Handler) -&gt; ok Reason :: any() PartialReq :: map() State :: any() Handler :: module() Call the optional terminate callback if it is defined. +Make sure to use this function at the end of the execution of modules that implement custom handler behaviors. +Arguments Reason Reason for termination. + PartialReq The Req object. +It is possible to remove fields from the Req object to save memory when the handler has no concept of requests/responses.</description> </item> <item> @@ -3142,8 +3290,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_http/</guid> <description>Name cowboy_http - HTTP/1.1 - Description The module cowboy_http implements HTTP/1.1 and HTTP/1.0 as a Ranch protocol. - Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), middlewares =&gt; [module()], request_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1.</description> +Description The module cowboy_http implements HTTP/1.1 and HTTP/1.0 as a Ranch protocol. +Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), middlewares =&gt; [module()], request_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1.</description> </item> <item> @@ -3153,8 +3301,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_http/</guid> <description>Name cowboy_http - HTTP/1.1 - Description The module cowboy_http implements HTTP/1.1 and HTTP/1.0 as a Ranch protocol. - Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), middlewares =&gt; [module()], request_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1.</description> +Description The module cowboy_http implements HTTP/1.1 and HTTP/1.0 as a Ranch protocol. +Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), middlewares =&gt; [module()], request_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1.</description> </item> <item> @@ -3164,8 +3312,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_http/</guid> <description>Name cowboy_http - HTTP/1.1 - Description The module cowboy_http implements HTTP/1.1 and HTTP/1.0 as a Ranch protocol. - Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), max_skip_body_length =&gt; non_neg_integer(), middlewares =&gt; [module()], request_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1.</description> +Description The module cowboy_http implements HTTP/1.1 and HTTP/1.0 as a Ranch protocol. +Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), max_skip_body_length =&gt; non_neg_integer(), middlewares =&gt; [module()], request_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1.</description> </item> <item> @@ -3175,8 +3323,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_http/</guid> <description>Name cowboy_http - HTTP/1.1 - Description The module cowboy_http implements HTTP/1.1 and HTTP/1.0 as a Ranch protocol. - Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), max_skip_body_length =&gt; non_neg_integer(), middlewares =&gt; [module()], request_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1.</description> +Description The module cowboy_http implements HTTP/1.1 and HTTP/1.0 as a Ranch protocol. +Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), max_skip_body_length =&gt; non_neg_integer(), middlewares =&gt; [module()], request_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1.</description> </item> <item> @@ -3186,8 +3334,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_http/</guid> <description>Name cowboy_http - HTTP/1.1 - Description The module cowboy_http implements HTTP/1.1 and HTTP/1.0 as a Ranch protocol. - Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), max_skip_body_length =&gt; non_neg_integer(), middlewares =&gt; [module()], request_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1.</description> +Description The module cowboy_http implements HTTP/1.1 and HTTP/1.0 as a Ranch protocol. +Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), idle_timeout =&gt; timeout(), inactivity_timeout =&gt; timeout(), max_empty_lines =&gt; non_neg_integer(), max_header_name_length =&gt; non_neg_integer(), max_header_value_length =&gt; non_neg_integer(), max_headers =&gt; non_neg_integer(), max_keepalive =&gt; non_neg_integer(), max_method_length =&gt; non_neg_integer(), max_request_line_length =&gt; non_neg_integer(), max_skip_body_length =&gt; non_neg_integer(), middlewares =&gt; [module()], request_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/1.</description> </item> <item> @@ -3197,10 +3345,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_http2/</guid> <description>Name cowboy_http2 - HTTP/2 - Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. - Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), inactivity_timeout =&gt; timeout(), middlewares =&gt; [module()], preface_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/2 protocol. - This configuration is passed to Cowboy when starting listeners using cowboy:start_clear/3 or cowboy:start_tls/3 functions. - It can be updated without restarting listeners using the Ranch functions ranch:get_protocol_options/1 and ranch:set_protocol_options/2.</description> +Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. +Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), inactivity_timeout =&gt; timeout(), middlewares =&gt; [module()], preface_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/2 protocol. +This configuration is passed to Cowboy when starting listeners using cowboy:start_clear/3 or cowboy:start_tls/3 functions. +It can be updated without restarting listeners using the Ranch functions ranch:get_protocol_options/1 and ranch:set_protocol_options/2.</description> </item> <item> @@ -3210,10 +3358,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_http2/</guid> <description>Name cowboy_http2 - HTTP/2 - Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. - Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), inactivity_timeout =&gt; timeout(), middlewares =&gt; [module()], preface_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/2 protocol. - This configuration is passed to Cowboy when starting listeners using cowboy:start_clear/3 or cowboy:start_tls/3 functions. - It can be updated without restarting listeners using the Ranch functions ranch:get_protocol_options/1 and ranch:set_protocol_options/2.</description> +Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. +Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), inactivity_timeout =&gt; timeout(), middlewares =&gt; [module()], preface_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/2 protocol. +This configuration is passed to Cowboy when starting listeners using cowboy:start_clear/3 or cowboy:start_tls/3 functions. +It can be updated without restarting listeners using the Ranch functions ranch:get_protocol_options/1 and ranch:set_protocol_options/2.</description> </item> <item> @@ -3223,10 +3371,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_http2/</guid> <description>Name cowboy_http2 - HTTP/2 - Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. - Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), inactivity_timeout =&gt; timeout(), middlewares =&gt; [module()], preface_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/2 protocol. - This configuration is passed to Cowboy when starting listeners using cowboy:start_clear/3 or cowboy:start_tls/3 functions. - It can be updated without restarting listeners using the Ranch functions ranch:get_protocol_options/1 and ranch:set_protocol_options/2.</description> +Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. +Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), inactivity_timeout =&gt; timeout(), middlewares =&gt; [module()], preface_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/2 protocol. +This configuration is passed to Cowboy when starting listeners using cowboy:start_clear/3 or cowboy:start_tls/3 functions. +It can be updated without restarting listeners using the Ranch functions ranch:get_protocol_options/1 and ranch:set_protocol_options/2.</description> </item> <item> @@ -3236,10 +3384,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_http2/</guid> <description>Name cowboy_http2 - HTTP/2 - Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. - Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), inactivity_timeout =&gt; timeout(), middlewares =&gt; [module()], preface_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/2 protocol. - This configuration is passed to Cowboy when starting listeners using cowboy:start_clear/3 or cowboy:start_tls/3 functions. - It can be updated without restarting listeners using the Ranch functions ranch:get_protocol_options/1 and ranch:set_protocol_options/2.</description> +Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. +Options opts() :: #{ connection_type =&gt; worker | supervisor, env =&gt; cowboy_middleware:env(), inactivity_timeout =&gt; timeout(), middlewares =&gt; [module()], preface_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/2 protocol. +This configuration is passed to Cowboy when starting listeners using cowboy:start_clear/3 or cowboy:start_tls/3 functions. +It can be updated without restarting listeners using the Ranch functions ranch:get_protocol_options/1 and ranch:set_protocol_options/2.</description> </item> <item> @@ -3249,8 +3397,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_http2/</guid> <description>Name cowboy_http2 - HTTP/2 - Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. - Options opts() :: #{ connection_type =&gt; worker | supervisor, enable_connect_protocol =&gt; boolean(), env =&gt; cowboy_middleware:env(), inactivity_timeout =&gt; timeout(), initial_connection_window_size =&gt; 65535..16#7fffffff, initial_stream_window_size =&gt; 0..16#7fffffff, max_concurrent_streams =&gt; non_neg_integer() | infinity, max_decode_table_size =&gt; non_neg_integer(), max_encode_table_size =&gt; non_neg_integer(), max_frame_size_received =&gt; 16384..16777215, max_frame_size_sent =&gt; 16384..16777215 | infinity, middlewares =&gt; [module()], preface_timeout =&gt; timeout(), settings_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/2 protocol.</description> +Description The module cowboy_http2 implements HTTP/2 as a Ranch protocol. +Options opts() :: #{ connection_type =&gt; worker | supervisor, enable_connect_protocol =&gt; boolean(), env =&gt; cowboy_middleware:env(), inactivity_timeout =&gt; timeout(), initial_connection_window_size =&gt; 65535..16#7fffffff, initial_stream_window_size =&gt; 0..16#7fffffff, max_concurrent_streams =&gt; non_neg_integer() | infinity, max_decode_table_size =&gt; non_neg_integer(), max_encode_table_size =&gt; non_neg_integer(), max_frame_size_received =&gt; 16384..16777215, max_frame_size_sent =&gt; 16384..16777215 | infinity, middlewares =&gt; [module()], preface_timeout =&gt; timeout(), settings_timeout =&gt; timeout(), shutdown_timeout =&gt; timeout(), stream_handlers =&gt; [module()] } Configuration for the HTTP/2 protocol.</description> </item> <item> @@ -3260,10 +3408,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_loop/</guid> <description>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).</description> +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).</description> </item> <item> @@ -3273,10 +3421,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_loop/</guid> <description>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).</description> +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).</description> </item> <item> @@ -3286,10 +3434,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_loop/</guid> <description>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).</description> +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).</description> </item> <item> @@ -3299,10 +3447,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_loop/</guid> <description>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).</description> +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).</description> </item> <item> @@ -3312,10 +3460,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_loop/</guid> <description>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).</description> +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).</description> </item> <item> @@ -3325,10 +3473,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_middleware/</guid> <description>Name cowboy_middleware - Middlewares - Description The module cowboy_middleware defines a callback interface for Cowboy middlewares. - Middlewares process the request sequentially in the order they are configured. - Callbacks Middlewares implement the following interface: - execute(Req, Env) -&gt; {ok, Req, Env} | {suspend, module(), atom(), [any()]} | {stop, Req} Req :: cowboy_req:req() Env :: cowboy_middleware:env() The execute/2 is the only callback that needs to be implemented.</description> +Description The module cowboy_middleware defines a callback interface for Cowboy middlewares. +Middlewares process the request sequentially in the order they are configured. +Callbacks Middlewares implement the following interface: +execute(Req, Env) -&gt; {ok, Req, Env} | {suspend, module(), atom(), [any()]} | {stop, Req} Req :: cowboy_req:req() Env :: cowboy_middleware:env() The execute/2 is the only callback that needs to be implemented. It must execute the middleware and return with instructions for Cowboy.</description> </item> <item> @@ -3338,10 +3486,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_middleware/</guid> <description>Name cowboy_middleware - Middlewares - Description The module cowboy_middleware defines a callback interface for Cowboy middlewares. - Middlewares process the request sequentially in the order they are configured. - Callbacks Middlewares implement the following interface: - execute(Req, Env) -&gt; {ok, Req, Env} | {suspend, module(), atom(), [any()]} | {stop, Req} Req :: cowboy_req:req() Env :: cowboy_middleware:env() The execute/2 is the only callback that needs to be implemented.</description> +Description The module cowboy_middleware defines a callback interface for Cowboy middlewares. +Middlewares process the request sequentially in the order they are configured. +Callbacks Middlewares implement the following interface: +execute(Req, Env) -&gt; {ok, Req, Env} | {suspend, module(), atom(), [any()]} | {stop, Req} Req :: cowboy_req:req() Env :: cowboy_middleware:env() The execute/2 is the only callback that needs to be implemented. It must execute the middleware and return with instructions for Cowboy.</description> </item> <item> @@ -3351,10 +3499,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_middleware/</guid> <description>Name cowboy_middleware - Middlewares - Description The module cowboy_middleware defines a callback interface for Cowboy middlewares. - Middlewares process the request sequentially in the order they are configured. - Callbacks Middlewares implement the following interface: - execute(Req, Env) -&gt; {ok, Req, Env} | {suspend, module(), atom(), [any()]} | {stop, Req} Req :: cowboy_req:req() Env :: cowboy_middleware:env() The execute/2 is the only callback that needs to be implemented.</description> +Description The module cowboy_middleware defines a callback interface for Cowboy middlewares. +Middlewares process the request sequentially in the order they are configured. +Callbacks Middlewares implement the following interface: +execute(Req, Env) -&gt; {ok, Req, Env} | {suspend, module(), atom(), [any()]} | {stop, Req} Req :: cowboy_req:req() Env :: cowboy_middleware:env() The execute/2 is the only callback that needs to be implemented. It must execute the middleware and return with instructions for Cowboy.</description> </item> <item> @@ -3364,10 +3512,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_middleware/</guid> <description>Name cowboy_middleware - Middlewares - Description The module cowboy_middleware defines a callback interface for Cowboy middlewares. - Middlewares process the request sequentially in the order they are configured. - Callbacks Middlewares implement the following interface: - execute(Req, Env) -&gt; {ok, Req, Env} | {suspend, module(), atom(), [any()]} | {stop, Req} Req :: cowboy_req:req() Env :: cowboy_middleware:env() The execute/2 is the only callback that needs to be implemented.</description> +Description The module cowboy_middleware defines a callback interface for Cowboy middlewares. +Middlewares process the request sequentially in the order they are configured. +Callbacks Middlewares implement the following interface: +execute(Req, Env) -&gt; {ok, Req, Env} | {suspend, module(), atom(), [any()]} | {stop, Req} Req :: cowboy_req:req() Env :: cowboy_middleware:env() The execute/2 is the only callback that needs to be implemented. It must execute the middleware and return with instructions for Cowboy.</description> </item> <item> @@ -3377,10 +3525,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_middleware/</guid> <description>Name cowboy_middleware - Middlewares - Description The module cowboy_middleware defines a callback interface for Cowboy middlewares. - Middlewares process the request sequentially in the order they are configured. - Callbacks Middlewares implement the following interface: - execute(Req, Env) -&gt; {ok, Req, Env} | {suspend, module(), atom(), [any()]} | {stop, Req} Req :: cowboy_req:req() Env :: cowboy_middleware:env() The execute/2 is the only callback that needs to be implemented.</description> +Description The module cowboy_middleware defines a callback interface for Cowboy middlewares. +Middlewares process the request sequentially in the order they are configured. +Callbacks Middlewares implement the following interface: +execute(Req, Env) -&gt; {ok, Req, Env} | {suspend, module(), atom(), [any()]} | {stop, Req} Req :: cowboy_req:req() Env :: cowboy_middleware:env() The execute/2 is the only callback that needs to be implemented. It must execute the middleware and return with instructions for Cowboy.</description> </item> <item> @@ -3390,12 +3538,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req/</guid> <description>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</description> +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.</description> </item> <item> @@ -3405,12 +3550,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req/</guid> <description>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</description> +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.</description> </item> <item> @@ -3420,12 +3562,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req/</guid> <description>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</description> +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.</description> </item> <item> @@ -3435,12 +3574,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req/</guid> <description>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</description> +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.</description> </item> <item> @@ -3450,12 +3586,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req/</guid> <description>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</description> +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.</description> </item> <item> @@ -3465,8 +3598,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.binding/</guid> <description>Name cowboy_req:binding - Access a value bound from the route - Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; any() | Default Name :: atom() Req :: cowboy_req:req() Default :: any() Return the value for the given binding. - Arguments Name Desired binding name as an atom. Req The Req object. Default Default value returned when the binding is missing.</description> +Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; any() | Default Name :: atom() Req :: cowboy_req:req() Default :: any() Return the value for the given binding. +Arguments Name Desired binding name as an atom. + Req The Req object. + Default Default value returned when the binding is missing. + Return value By default the value is a case sensitive binary string, however constraints may change the type of this value (for example automatically converting numbers to integer).</description> </item> <item> @@ -3476,8 +3612,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.binding/</guid> <description>Name cowboy_req:binding - Access a value bound from the route - Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; any() | Default Name :: atom() Req :: cowboy_req:req() Default :: any() Return the value for the given binding. - Arguments Name Desired binding name as an atom. Req The Req object. Default Default value returned when the binding is missing.</description> +Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; any() | Default Name :: atom() Req :: cowboy_req:req() Default :: any() Return the value for the given binding. +Arguments Name Desired binding name as an atom. + Req The Req object. + Default Default value returned when the binding is missing. + Return value By default the value is a case sensitive binary string, however constraints may change the type of this value (for example automatically converting numbers to integer).</description> </item> <item> @@ -3487,8 +3626,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.binding/</guid> <description>Name cowboy_req:binding - Access a value bound from the route - Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; any() | Default Name :: atom() Req :: cowboy_req:req() Default :: any() Return the value for the given binding. - Arguments Name Desired binding name as an atom. Req The Req object. Default Default value returned when the binding is missing.</description> +Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; any() | Default Name :: atom() Req :: cowboy_req:req() Default :: any() Return the value for the given binding. +Arguments Name Desired binding name as an atom. + Req The Req object. + Default Default value returned when the binding is missing. + Return value By default the value is a case sensitive binary string, however constraints may change the type of this value (for example automatically converting numbers to integer).</description> </item> <item> @@ -3498,8 +3640,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.binding/</guid> <description>Name cowboy_req:binding - Access a value bound from the route - Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; any() | Default Name :: atom() Req :: cowboy_req:req() Default :: any() Return the value for the given binding. - Arguments Name Desired binding name as an atom. Req The Req object. Default Default value returned when the binding is missing.</description> +Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; any() | Default Name :: atom() Req :: cowboy_req:req() Default :: any() Return the value for the given binding. +Arguments Name Desired binding name as an atom. + Req The Req object. + Default Default value returned when the binding is missing. + Return value By default the value is a case sensitive binary string, however constraints may change the type of this value (for example automatically converting numbers to integer).</description> </item> <item> @@ -3509,8 +3654,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.binding/</guid> <description>Name cowboy_req:binding - Access a value bound from the route - Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; any() | Default Name :: atom() Req :: cowboy_req:req() Default :: any() Return the value for the given binding. - Arguments Name Desired binding name as an atom. Req The Req object. Default Default value returned when the binding is missing.</description> +Description binding(Name, Req) -&gt; binding(Name, Req, undefined) binding(Name, Req, Default) -&gt; any() | Default Name :: atom() Req :: cowboy_req:req() Default :: any() Return the value for the given binding. +Arguments Name Desired binding name as an atom. + Req The Req object. + Default Default value returned when the binding is missing. + Return value By default the value is a case sensitive binary string, however constraints may change the type of this value (for example automatically converting numbers to integer).</description> </item> <item> @@ -3520,9 +3668,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.bindings/</guid> <description>Name cowboy_req:bindings - Access all values bound from the route - Description bindings(Req :: cowboy_req:req()) -&gt; cowboy_router:bindings() Return a map containing all bindings. - Arguments Req The Req object. Return value By default values are case sensitive binary strings, however constraints may change the type of this value (for example automatically converting numbers to integer). - Changelog 2.</description> +Description bindings(Req :: cowboy_req:req()) -&gt; cowboy_router:bindings() Return a map containing all bindings. +Arguments Req The Req object. + Return value By default values are case sensitive binary strings, however constraints may change the type of this value (for example automatically converting numbers to integer). +Changelog 2.0: Only the values are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -3532,9 +3681,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.bindings/</guid> <description>Name cowboy_req:bindings - Access all values bound from the route - Description bindings(Req :: cowboy_req:req()) -&gt; cowboy_router:bindings() Return a map containing all bindings. - Arguments Req The Req object. Return value By default values are case sensitive binary strings, however constraints may change the type of this value (for example automatically converting numbers to integer). - Changelog 2.</description> +Description bindings(Req :: cowboy_req:req()) -&gt; cowboy_router:bindings() Return a map containing all bindings. +Arguments Req The Req object. + Return value By default values are case sensitive binary strings, however constraints may change the type of this value (for example automatically converting numbers to integer). +Changelog 2.0: Only the values are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -3544,9 +3694,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.bindings/</guid> <description>Name cowboy_req:bindings - Access all values bound from the route - Description bindings(Req :: cowboy_req:req()) -&gt; cowboy_router:bindings() Return a map containing all bindings. - Arguments Req The Req object. Return value By default values are case sensitive binary strings, however constraints may change the type of this value (for example automatically converting numbers to integer). - Changelog 2.</description> +Description bindings(Req :: cowboy_req:req()) -&gt; cowboy_router:bindings() Return a map containing all bindings. +Arguments Req The Req object. + Return value By default values are case sensitive binary strings, however constraints may change the type of this value (for example automatically converting numbers to integer). +Changelog 2.0: Only the values are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -3556,9 +3707,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.bindings/</guid> <description>Name cowboy_req:bindings - Access all values bound from the route - Description bindings(Req :: cowboy_req:req()) -&gt; cowboy_router:bindings() Return a map containing all bindings. - Arguments Req The Req object. Return value By default values are case sensitive binary strings, however constraints may change the type of this value (for example automatically converting numbers to integer). - Changelog 2.</description> +Description bindings(Req :: cowboy_req:req()) -&gt; cowboy_router:bindings() Return a map containing all bindings. +Arguments Req The Req object. + Return value By default values are case sensitive binary strings, however constraints may change the type of this value (for example automatically converting numbers to integer). +Changelog 2.0: Only the values are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -3568,9 +3720,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.bindings/</guid> <description>Name cowboy_req:bindings - Access all values bound from the route - Description bindings(Req :: cowboy_req:req()) -&gt; cowboy_router:bindings() Return a map containing all bindings. - Arguments Req The Req object. Return value By default values are case sensitive binary strings, however constraints may change the type of this value (for example automatically converting numbers to integer). - Changelog 2.</description> +Description bindings(Req :: cowboy_req:req()) -&gt; cowboy_router:bindings() Return a map containing all bindings. +Arguments Req The Req object. + Return value By default values are case sensitive binary strings, however constraints may change the type of this value (for example automatically converting numbers to integer). +Changelog 2.0: Only the values are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -3580,9 +3733,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.body_length/</guid> <description>Name cowboy_req:body_length - Body length - Description body_length(Req :: cowboy_req:req()) -&gt; undefined | non_neg_integer() Return the length of the request body. - The length is not always known before reading the body. In those cases Cowboy will return undefined. The body length is available after the body has been fully read. - Arguments Req The Req object. Return value The length of the request body, or undefined if it is not known.</description> +Description body_length(Req :: cowboy_req:req()) -&gt; undefined | non_neg_integer() Return the length of the request body. +The length is not always known before reading the body. In those cases Cowboy will return undefined. The body length is available after the body has been fully read. +Arguments Req The Req object. + Return value The length of the request body, or undefined if it is not known.</description> </item> <item> @@ -3592,9 +3746,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.body_length/</guid> <description>Name cowboy_req:body_length - Body length - Description body_length(Req :: cowboy_req:req()) -&gt; undefined | non_neg_integer() Return the length of the request body. - The length is not always known before reading the body. In those cases Cowboy will return undefined. The body length is available after the body has been fully read. - Arguments Req The Req object. Return value The length of the request body, or undefined if it is not known.</description> +Description body_length(Req :: cowboy_req:req()) -&gt; undefined | non_neg_integer() Return the length of the request body. +The length is not always known before reading the body. In those cases Cowboy will return undefined. The body length is available after the body has been fully read. +Arguments Req The Req object. + Return value The length of the request body, or undefined if it is not known.</description> </item> <item> @@ -3604,9 +3759,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.body_length/</guid> <description>Name cowboy_req:body_length - Body length - Description body_length(Req :: cowboy_req:req()) -&gt; undefined | non_neg_integer() Return the length of the request body. - The length is not always known before reading the body. In those cases Cowboy will return undefined. The body length is available after the body has been fully read. - Arguments Req The Req object. Return value The length of the request body, or undefined if it is not known.</description> +Description body_length(Req :: cowboy_req:req()) -&gt; undefined | non_neg_integer() Return the length of the request body. +The length is not always known before reading the body. In those cases Cowboy will return undefined. The body length is available after the body has been fully read. +Arguments Req The Req object. + Return value The length of the request body, or undefined if it is not known.</description> </item> <item> @@ -3616,9 +3772,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.body_length/</guid> <description>Name cowboy_req:body_length - Body length - Description body_length(Req :: cowboy_req:req()) -&gt; undefined | non_neg_integer() Return the length of the request body. - The length is not always known before reading the body. In those cases Cowboy will return undefined. The body length is available after the body has been fully read. - Arguments Req The Req object. Return value The length of the request body, or undefined if it is not known.</description> +Description body_length(Req :: cowboy_req:req()) -&gt; undefined | non_neg_integer() Return the length of the request body. +The length is not always known before reading the body. In those cases Cowboy will return undefined. The body length is available after the body has been fully read. +Arguments Req The Req object. + Return value The length of the request body, or undefined if it is not known.</description> </item> <item> @@ -3628,9 +3785,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.body_length/</guid> <description>Name cowboy_req:body_length - Body length - Description body_length(Req :: cowboy_req:req()) -&gt; undefined | non_neg_integer() Return the length of the request body. - The length is not always known before reading the body. In those cases Cowboy will return undefined. The body length is available after the body has been fully read. - Arguments Req The Req object. Return value The length of the request body, or undefined if it is not known.</description> +Description body_length(Req :: cowboy_req:req()) -&gt; undefined | non_neg_integer() Return the length of the request body. +The length is not always known before reading the body. In those cases Cowboy will return undefined. The body length is available after the body has been fully read. +Arguments Req The Req object. + Return value The length of the request body, or undefined if it is not known.</description> </item> <item> @@ -3640,9 +3798,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.cert/</guid> <description>Name cowboy_req:cert - Client TLS certificate - Description cert(Req :: cowboy_req:req()) -&gt; binary() | undefined Return the peer&#8217;s TLS certificate. - Using the default configuration this function will always return undefined. You need to explicitly configure Cowboy to request the client certificate. To do this you need to set the verify transport option to verify_peer: - {ok, _} = cowboy:start_tls(example, [ {port, 8443}, {cert, "path/to/cert.pem"}, {verify, verify_peer} ], #{ env =&gt; #{dispatch =&gt; Dispatch} }).</description> +Description cert(Req :: cowboy_req:req()) -&gt; binary() | undefined Return the peer&apos;s TLS certificate. +Using the default configuration this function will always return undefined. You need to explicitly configure Cowboy to request the client certificate. To do this you need to set the verify transport option to verify_peer: +{ok, _} = cowboy:start_tls(example, [ {port, 8443}, {cert, "path/to/cert.pem"}, {verify, verify_peer} ], #{ env =&gt; #{dispatch =&gt; Dispatch} }).</description> </item> <item> @@ -3652,9 +3810,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.cert/</guid> <description>Name cowboy_req:cert - Client TLS certificate - Description cert(Req :: cowboy_req:req()) -&gt; binary() | undefined Return the peer&#8217;s TLS certificate. - Using the default configuration this function will always return undefined. You need to explicitly configure Cowboy to request the client certificate. To do this you need to set the verify transport option to verify_peer: - {ok, _} = cowboy:start_tls(example, [ {port, 8443}, {cert, "path/to/cert.pem"}, {verify, verify_peer} ], #{ env =&gt; #{dispatch =&gt; Dispatch} }).</description> +Description cert(Req :: cowboy_req:req()) -&gt; binary() | undefined Return the peer&apos;s TLS certificate. +Using the default configuration this function will always return undefined. You need to explicitly configure Cowboy to request the client certificate. To do this you need to set the verify transport option to verify_peer: +{ok, _} = cowboy:start_tls(example, [ {port, 8443}, {cert, "path/to/cert.pem"}, {verify, verify_peer} ], #{ env =&gt; #{dispatch =&gt; Dispatch} }).</description> </item> <item> @@ -3664,9 +3822,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.cert/</guid> <description>Name cowboy_req:cert - Client TLS certificate - Description cert(Req :: cowboy_req:req()) -&gt; binary() | undefined Return the peer&#8217;s TLS certificate. - Using the default configuration this function will always return undefined. You need to explicitly configure Cowboy to request the client certificate. To do this you need to set the verify transport option to verify_peer: - {ok, _} = cowboy:start_tls(example, [ {port, 8443}, {cert, "path/to/cert.pem"}, {verify, verify_peer} ], #{ env =&gt; #{dispatch =&gt; Dispatch} }).</description> +Description cert(Req :: cowboy_req:req()) -&gt; binary() | undefined Return the peer&apos;s TLS certificate. +Using the default configuration this function will always return undefined. You need to explicitly configure Cowboy to request the client certificate. To do this you need to set the verify transport option to verify_peer: +{ok, _} = cowboy:start_tls(example, [ {port, 8443}, {cert, "path/to/cert.pem"}, {verify, verify_peer} ], #{ env =&gt; #{dispatch =&gt; Dispatch} }).</description> </item> <item> @@ -3676,9 +3834,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.cert/</guid> <description>Name cowboy_req:cert - Client TLS certificate - Description cert(Req :: cowboy_req:req()) -&gt; binary() | undefined Return the peer&#8217;s TLS certificate. - Using the default configuration this function will always return undefined. You need to explicitly configure Cowboy to request the client certificate. To do this you need to set the verify transport option to verify_peer: - {ok, _} = cowboy:start_tls(example, [ {port, 8443}, {cert, "path/to/cert.pem"}, {verify, verify_peer} ], #{ env =&gt; #{dispatch =&gt; Dispatch} }).</description> +Description cert(Req :: cowboy_req:req()) -&gt; binary() | undefined Return the peer&apos;s TLS certificate. +Using the default configuration this function will always return undefined. You need to explicitly configure Cowboy to request the client certificate. To do this you need to set the verify transport option to verify_peer: +{ok, _} = cowboy:start_tls(example, [ {port, 8443}, {cert, "path/to/cert.pem"}, {verify, verify_peer} ], #{ env =&gt; #{dispatch =&gt; Dispatch} }).</description> </item> <item> @@ -3688,9 +3846,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.delete_resp_header/</guid> <description>Name cowboy_req:delete_resp_header - Delete a response header - Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Delete the given response header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Arguments Name Header name as a lowercase binary string.</description> +Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Delete the given response header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Arguments Name Header name as a lowercase binary string. + Req The Req object. + Return value A new Req object is returned.</description> </item> <item> @@ -3700,9 +3860,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.delete_resp_header/</guid> <description>Name cowboy_req:delete_resp_header - Delete a response header - Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Delete the given response header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Arguments Name Header name as a lowercase binary string.</description> +Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Delete the given response header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Arguments Name Header name as a lowercase binary string. + Req The Req object. + Return value A new Req object is returned.</description> </item> <item> @@ -3712,9 +3874,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.delete_resp_header/</guid> <description>Name cowboy_req:delete_resp_header - Delete a response header - Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Delete the given response header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Arguments Name Header name as a lowercase binary string.</description> +Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Delete the given response header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Arguments Name Header name as a lowercase binary string. + Req The Req object. + Return value A new Req object is returned.</description> </item> <item> @@ -3724,9 +3888,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.delete_resp_header/</guid> <description>Name cowboy_req:delete_resp_header - Delete a response header - Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Delete the given response header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Arguments Name Header name as a lowercase binary string.</description> +Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Delete the given response header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Arguments Name Header name as a lowercase binary string. + Req The Req object. + Return value A new Req object is returned.</description> </item> <item> @@ -3736,9 +3902,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.delete_resp_header/</guid> <description>Name cowboy_req:delete_resp_header - Delete a response header - Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Delete the given response header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Arguments Name Header name as a lowercase binary string.</description> +Description delete_resp_header(Name, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Delete the given response header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Arguments Name Header name as a lowercase binary string. + Req The Req object. + Return value A new Req object is returned.</description> </item> <item> @@ -3748,9 +3916,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.has_body/</guid> <description>Name cowboy_req:has_body - Is there a request body? - Description has_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether the request has a body. - Arguments Req The Req object. Return value A boolean indicating whether the request has a body. - Changelog 1.0: Function introduced. Examples Ensure the request has a body true = cowboy_req:has_body(Req).</description> +Description has_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether the request has a body. +Arguments Req The Req object. + Return value A boolean indicating whether the request has a body. +Changelog 1.0: Function introduced. Examples Ensure the request has a body true = cowboy_req:has_body(Req). See also cowboy_req(3), cowboy_req:body_length(3), cowboy_req:read_body(3), cowboy_req:read_urlencoded_body(3), cowboy_req:read_part(3), cowboy_req:read_part_body(3)</description> </item> <item> @@ -3760,9 +3929,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.has_body/</guid> <description>Name cowboy_req:has_body - Is there a request body? - Description has_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether the request has a body. - Arguments Req The Req object. Return value A boolean indicating whether the request has a body. - Changelog 1.0: Function introduced. Examples Ensure the request has a body true = cowboy_req:has_body(Req).</description> +Description has_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether the request has a body. +Arguments Req The Req object. + Return value A boolean indicating whether the request has a body. +Changelog 1.0: Function introduced. Examples Ensure the request has a body true = cowboy_req:has_body(Req). See also cowboy_req(3), cowboy_req:body_length(3), cowboy_req:read_body(3), cowboy_req:read_urlencoded_body(3), cowboy_req:read_part(3), cowboy_req:read_part_body(3)</description> </item> <item> @@ -3772,9 +3942,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.has_body/</guid> <description>Name cowboy_req:has_body - Is there a request body? - Description has_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether the request has a body. - Arguments Req The Req object. Return value A boolean indicating whether the request has a body. - Changelog 1.0: Function introduced. Examples Ensure the request has a body true = cowboy_req:has_body(Req).</description> +Description has_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether the request has a body. +Arguments Req The Req object. + Return value A boolean indicating whether the request has a body. +Changelog 1.0: Function introduced. Examples Ensure the request has a body true = cowboy_req:has_body(Req). See also cowboy_req(3), cowboy_req:body_length(3), cowboy_req:read_body(3), cowboy_req:read_urlencoded_body(3), cowboy_req:read_part(3), cowboy_req:read_part_body(3)</description> </item> <item> @@ -3784,9 +3955,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.has_body/</guid> <description>Name cowboy_req:has_body - Is there a request body? - Description has_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether the request has a body. - Arguments Req The Req object. Return value A boolean indicating whether the request has a body. - Changelog 1.0: Function introduced. Examples Ensure the request has a body true = cowboy_req:has_body(Req).</description> +Description has_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether the request has a body. +Arguments Req The Req object. + Return value A boolean indicating whether the request has a body. +Changelog 1.0: Function introduced. Examples Ensure the request has a body true = cowboy_req:has_body(Req). See also cowboy_req(3), cowboy_req:body_length(3), cowboy_req:read_body(3), cowboy_req:read_urlencoded_body(3), cowboy_req:read_part(3), cowboy_req:read_part_body(3)</description> </item> <item> @@ -3796,9 +3968,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.has_body/</guid> <description>Name cowboy_req:has_body - Is there a request body? - Description has_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether the request has a body. - Arguments Req The Req object. Return value A boolean indicating whether the request has a body. - Changelog 1.0: Function introduced. Examples Ensure the request has a body true = cowboy_req:has_body(Req).</description> +Description has_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether the request has a body. +Arguments Req The Req object. + Return value A boolean indicating whether the request has a body. +Changelog 1.0: Function introduced. Examples Ensure the request has a body true = cowboy_req:has_body(Req). See also cowboy_req(3), cowboy_req:body_length(3), cowboy_req:read_body(3), cowboy_req:read_urlencoded_body(3), cowboy_req:read_part(3), cowboy_req:read_part_body(3)</description> </item> <item> @@ -3808,10 +3981,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_body/</guid> <description>Name cowboy_req:has_resp_body - Is there a response body? - Description has_resp_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether a response body has been set. - Arguments Req The Req object. Return value A boolean indicating whether a response body has been set. - This function will return false when an empty response body has been set. - Changelog 1.</description> +Description has_resp_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether a response body has been set. +Arguments Req The Req object. + Return value A boolean indicating whether a response body has been set. +This function will return false when an empty response body has been set. +Changelog 1.0: Function introduced. Examples Check whether a body has been set false = cowboy_req:has_resp_body(Req0), Req1 = cowboy_req:set_resp_body(&lt;&lt;"</description> </item> <item> @@ -3821,10 +3995,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_body/</guid> <description>Name cowboy_req:has_resp_body - Is there a response body? - Description has_resp_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether a response body has been set. - Arguments Req The Req object. Return value A boolean indicating whether a response body has been set. - This function will return false when an empty response body has been set. - Changelog 1.</description> +Description has_resp_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether a response body has been set. +Arguments Req The Req object. + Return value A boolean indicating whether a response body has been set. +This function will return false when an empty response body has been set. +Changelog 1.0: Function introduced. Examples Check whether a body has been set false = cowboy_req:has_resp_body(Req0), Req1 = cowboy_req:set_resp_body(&lt;&lt;"</description> </item> <item> @@ -3834,10 +4009,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.has_resp_body/</guid> <description>Name cowboy_req:has_resp_body - Is there a response body? - Description has_resp_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether a response body has been set. - Arguments Req The Req object. Return value A boolean indicating whether a response body has been set. - This function will return false when an empty response body has been set. - Changelog 1.</description> +Description has_resp_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether a response body has been set. +Arguments Req The Req object. + Return value A boolean indicating whether a response body has been set. +This function will return false when an empty response body has been set. +Changelog 1.0: Function introduced. Examples Check whether a body has been set false = cowboy_req:has_resp_body(Req0), Req1 = cowboy_req:set_resp_body(&lt;&lt;"</description> </item> <item> @@ -3847,10 +4023,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_body/</guid> <description>Name cowboy_req:has_resp_body - Is there a response body? - Description has_resp_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether a response body has been set. - Arguments Req The Req object. Return value A boolean indicating whether a response body has been set. - This function will return false when an empty response body has been set. - Changelog 1.</description> +Description has_resp_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether a response body has been set. +Arguments Req The Req object. + Return value A boolean indicating whether a response body has been set. +This function will return false when an empty response body has been set. +Changelog 1.0: Function introduced. Examples Check whether a body has been set false = cowboy_req:has_resp_body(Req0), Req1 = cowboy_req:set_resp_body(&lt;&lt;"</description> </item> <item> @@ -3860,10 +4037,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_body/</guid> <description>Name cowboy_req:has_resp_body - Is there a response body? - Description has_resp_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether a response body has been set. - Arguments Req The Req object. Return value A boolean indicating whether a response body has been set. - This function will return false when an empty response body has been set. - Changelog 1.</description> +Description has_resp_body(Req :: cowboy_req:req()) -&gt; boolean() Return whether a response body has been set. +Arguments Req The Req object. + Return value A boolean indicating whether a response body has been set. +This function will return false when an empty response body has been set. +Changelog 1.0: Function introduced. Examples Check whether a body has been set false = cowboy_req:has_resp_body(Req0), Req1 = cowboy_req:set_resp_body(&lt;&lt;"</description> </item> <item> @@ -3873,9 +4051,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_header/</guid> <description>Name cowboy_req:has_resp_header - Is the given response header set? - Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; boolean() Name :: binary() %% lowercase; case insensitive Return whether the given response header has been set. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Arguments Name Header name as a lowercase binary string.</description> +Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; boolean() Name :: binary() %% lowercase; case insensitive Return whether the given response header has been set. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Arguments Name Header name as a lowercase binary string.</description> </item> <item> @@ -3885,9 +4063,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.has_resp_header/</guid> <description>Name cowboy_req:has_resp_header - Is the given response header set? - Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; boolean() Name :: binary() %% lowercase; case insensitive Return whether the given response header has been set. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Arguments Name Header name as a lowercase binary string.</description> +Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; boolean() Name :: binary() %% lowercase; case insensitive Return whether the given response header has been set. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Arguments Name Header name as a lowercase binary string.</description> </item> <item> @@ -3897,9 +4075,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.has_resp_header/</guid> <description>Name cowboy_req:has_resp_header - Is the given response header set? - Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; boolean() Name :: binary() %% lowercase; case insensitive Return whether the given response header has been set. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Arguments Name Header name as a lowercase binary string.</description> +Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; boolean() Name :: binary() %% lowercase; case insensitive Return whether the given response header has been set. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Arguments Name Header name as a lowercase binary string.</description> </item> <item> @@ -3909,9 +4087,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.has_resp_header/</guid> <description>Name cowboy_req:has_resp_header - Is the given response header set? - Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; boolean() Name :: binary() %% lowercase; case insensitive Return whether the given response header has been set. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Arguments Name Header name as a lowercase binary string.</description> +Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; boolean() Name :: binary() %% lowercase; case insensitive Return whether the given response header has been set. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Arguments Name Header name as a lowercase binary string.</description> </item> <item> @@ -3921,9 +4099,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.has_resp_header/</guid> <description>Name cowboy_req:has_resp_header - Is the given response header set? - Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; boolean() Name :: binary() %% lowercase; case insensitive Return whether the given response header has been set. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Arguments Name Header name as a lowercase binary string.</description> +Description has_resp_header(Name, Req :: cowboy_req:req()) -&gt; boolean() Name :: binary() %% lowercase; case insensitive Return whether the given response header has been set. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Arguments Name Header name as a lowercase binary string.</description> </item> <item> @@ -3933,8 +4111,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.header/</guid> <description>Name cowboy_req:header - HTTP header - Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given HTTP header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given HTTP header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Headers can also be obtained using pattern matching:</description> </item> <item> @@ -3944,8 +4123,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.header/</guid> <description>Name cowboy_req:header - HTTP header - Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given HTTP header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given HTTP header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Headers can also be obtained using pattern matching:</description> </item> <item> @@ -3955,8 +4135,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.header/</guid> <description>Name cowboy_req:header - HTTP header - Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given HTTP header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given HTTP header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Headers can also be obtained using pattern matching:</description> </item> <item> @@ -3966,8 +4147,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.header/</guid> <description>Name cowboy_req:header - HTTP header - Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given HTTP header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given HTTP header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Headers can also be obtained using pattern matching:</description> </item> <item> @@ -3977,8 +4159,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.header/</guid> <description>Name cowboy_req:header - HTTP header - Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given HTTP header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description header(Name, Req) -&gt; header(Name, Req, undefined) header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given HTTP header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Headers can also be obtained using pattern matching:</description> </item> <item> @@ -3988,10 +4171,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.headers/</guid> <description>Name cowboy_req:headers - HTTP headers - Description headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all request headers. - Request headers can also be obtained using pattern matching: - #{headers := Headers} = Req. Arguments Req The Req object. Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. - Changelog 2.</description> +Description headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all request headers. +Request headers can also be obtained using pattern matching: +#{headers := Headers} = Req. Arguments Req The Req object. + Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. +Changelog 2.0: Only the headers are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4001,10 +4185,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.headers/</guid> <description>Name cowboy_req:headers - HTTP headers - Description headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all request headers. - Request headers can also be obtained using pattern matching: - #{headers := Headers} = Req. Arguments Req The Req object. Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. - Changelog 2.</description> +Description headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all request headers. +Request headers can also be obtained using pattern matching: +#{headers := Headers} = Req. Arguments Req The Req object. + Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. +Changelog 2.0: Only the headers are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4014,10 +4199,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.headers/</guid> <description>Name cowboy_req:headers - HTTP headers - Description headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all request headers. - Request headers can also be obtained using pattern matching: - #{headers := Headers} = Req. Arguments Req The Req object. Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. - Changelog 2.</description> +Description headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all request headers. +Request headers can also be obtained using pattern matching: +#{headers := Headers} = Req. Arguments Req The Req object. + Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. +Changelog 2.0: Only the headers are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4027,10 +4213,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.headers/</guid> <description>Name cowboy_req:headers - HTTP headers - Description headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all request headers. - Request headers can also be obtained using pattern matching: - #{headers := Headers} = Req. Arguments Req The Req object. Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. - Changelog 2.</description> +Description headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all request headers. +Request headers can also be obtained using pattern matching: +#{headers := Headers} = Req. Arguments Req The Req object. + Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. +Changelog 2.0: Only the headers are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4040,10 +4227,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.headers/</guid> <description>Name cowboy_req:headers - HTTP headers - Description headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all request headers. - Request headers can also be obtained using pattern matching: - #{headers := Headers} = Req. Arguments Req The Req object. Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. - Changelog 2.</description> +Description headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all request headers. +Request headers can also be obtained using pattern matching: +#{headers := Headers} = Req. Arguments Req The Req object. + Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. +Changelog 2.0: Only the headers are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4053,9 +4241,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.host/</guid> <description>Name cowboy_req:host - URI host name - Description host(Req :: cowboy_req:req()) -&gt; Host :: binary() Return the host name of the effective request URI. - The host name can also be obtained using pattern matching: - #{host := Host} = Req. Arguments Req The Req object. Return value The host name is returned as a lowercase binary string. It is case insensitive.</description> +Description host(Req :: cowboy_req:req()) -&gt; Host :: binary() Return the host name of the effective request URI. +The host name can also be obtained using pattern matching: +#{host := Host} = Req. Arguments Req The Req object. + Return value The host name is returned as a lowercase binary string. It is case insensitive. +Changelog 2.0: Only the host name is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4065,9 +4255,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.host/</guid> <description>Name cowboy_req:host - URI host name - Description host(Req :: cowboy_req:req()) -&gt; Host :: binary() Return the host name of the effective request URI. - The host name can also be obtained using pattern matching: - #{host := Host} = Req. Arguments Req The Req object. Return value The host name is returned as a lowercase binary string. It is case insensitive.</description> +Description host(Req :: cowboy_req:req()) -&gt; Host :: binary() Return the host name of the effective request URI. +The host name can also be obtained using pattern matching: +#{host := Host} = Req. Arguments Req The Req object. + Return value The host name is returned as a lowercase binary string. It is case insensitive. +Changelog 2.0: Only the host name is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4077,9 +4269,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.host/</guid> <description>Name cowboy_req:host - URI host name - Description host(Req :: cowboy_req:req()) -&gt; Host :: binary() Return the host name of the effective request URI. - The host name can also be obtained using pattern matching: - #{host := Host} = Req. Arguments Req The Req object. Return value The host name is returned as a lowercase binary string. It is case insensitive.</description> +Description host(Req :: cowboy_req:req()) -&gt; Host :: binary() Return the host name of the effective request URI. +The host name can also be obtained using pattern matching: +#{host := Host} = Req. Arguments Req The Req object. + Return value The host name is returned as a lowercase binary string. It is case insensitive. +Changelog 2.0: Only the host name is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4089,9 +4283,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.host/</guid> <description>Name cowboy_req:host - URI host name - Description host(Req :: cowboy_req:req()) -&gt; Host :: binary() Return the host name of the effective request URI. - The host name can also be obtained using pattern matching: - #{host := Host} = Req. Arguments Req The Req object. Return value The host name is returned as a lowercase binary string. It is case insensitive.</description> +Description host(Req :: cowboy_req:req()) -&gt; Host :: binary() Return the host name of the effective request URI. +The host name can also be obtained using pattern matching: +#{host := Host} = Req. Arguments Req The Req object. + Return value The host name is returned as a lowercase binary string. It is case insensitive. +Changelog 2.0: Only the host name is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4101,9 +4297,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.host/</guid> <description>Name cowboy_req:host - URI host name - Description host(Req :: cowboy_req:req()) -&gt; Host :: binary() Return the host name of the effective request URI. - The host name can also be obtained using pattern matching: - #{host := Host} = Req. Arguments Req The Req object. Return value The host name is returned as a lowercase binary string. It is case insensitive.</description> +Description host(Req :: cowboy_req:req()) -&gt; Host :: binary() Return the host name of the effective request URI. +The host name can also be obtained using pattern matching: +#{host := Host} = Req. Arguments Req The Req object. + Return value The host name is returned as a lowercase binary string. It is case insensitive. +Changelog 2.0: Only the host name is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4112,10 +4310,12 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.host_info/</guid> - <description>Name cowboy_req:host_info - Access the route&#8217;s heading host segments - Description host_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the heading host segments. - This is the part of the host name that was matched using the ... notation. - Arguments Req The Req object. Return value The tokens are returned as a list of case insensitive binary strings.</description> + <description>Name cowboy_req:host_info - Access the route&apos;s heading host segments +Description host_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the heading host segments. +This is the part of the host name that was matched using the ... notation. +Arguments Req The Req object. + Return value The tokens are returned as a list of case insensitive binary strings. +Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4124,10 +4324,12 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.host_info/</guid> - <description>Name cowboy_req:host_info - Access the route&#8217;s heading host segments - Description host_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the heading host segments. - This is the part of the host name that was matched using the ... notation. - Arguments Req The Req object. Return value The tokens are returned as a list of case insensitive binary strings.</description> + <description>Name cowboy_req:host_info - Access the route&apos;s heading host segments +Description host_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the heading host segments. +This is the part of the host name that was matched using the ... notation. +Arguments Req The Req object. + Return value The tokens are returned as a list of case insensitive binary strings. +Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4136,10 +4338,12 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.host_info/</guid> - <description>Name cowboy_req:host_info - Access the route&#8217;s heading host segments - Description host_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the heading host segments. - This is the part of the host name that was matched using the ... notation. - Arguments Req The Req object. Return value The tokens are returned as a list of case insensitive binary strings.</description> + <description>Name cowboy_req:host_info - Access the route&apos;s heading host segments +Description host_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the heading host segments. +This is the part of the host name that was matched using the ... notation. +Arguments Req The Req object. + Return value The tokens are returned as a list of case insensitive binary strings. +Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4148,10 +4352,12 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.host_info/</guid> - <description>Name cowboy_req:host_info - Access the route&#8217;s heading host segments - Description host_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the heading host segments. - This is the part of the host name that was matched using the ... notation. - Arguments Req The Req object. Return value The tokens are returned as a list of case insensitive binary strings.</description> + <description>Name cowboy_req:host_info - Access the route&apos;s heading host segments +Description host_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the heading host segments. +This is the part of the host name that was matched using the ... notation. +Arguments Req The Req object. + Return value The tokens are returned as a list of case insensitive binary strings. +Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4160,10 +4366,12 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.host_info/</guid> - <description>Name cowboy_req:host_info - Access the route&#8217;s heading host segments - Description host_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the heading host segments. - This is the part of the host name that was matched using the ... notation. - Arguments Req The Req object. Return value The tokens are returned as a list of case insensitive binary strings.</description> + <description>Name cowboy_req:host_info - Access the route&apos;s heading host segments +Description host_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the heading host segments. +This is the part of the host name that was matched using the ... notation. +Arguments Req The Req object. + Return value The tokens are returned as a list of case insensitive binary strings. +Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4173,8 +4381,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.inform/</guid> <description>Name cowboy_req:inform - Send an informational response - Description inform(Status, Req :: cowboy_req:req()) -&gt; inform(StatusCode, #{}, Req) inform(Status, Headers, Req :: cowboy_req:req()) -&gt; ok Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send an informational response. - Informational responses use a status code between 100 and 199. They cannot include a body. This function will not use any of the previously set headers. All headers to be sent must be given directly.</description> +Description inform(Status, Req :: cowboy_req:req()) -&gt; inform(StatusCode, #{}, Req) inform(Status, Headers, Req :: cowboy_req:req()) -&gt; ok Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send an informational response. +Informational responses use a status code between 100 and 199. They cannot include a body. This function will not use any of the previously set headers. All headers to be sent must be given directly. +Any number of informational responses can be sent as long as they are sent before the proper response.</description> </item> <item> @@ -4184,8 +4393,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.inform/</guid> <description>Name cowboy_req:inform - Send an informational response - Description inform(Status, Req :: cowboy_req:req()) -&gt; inform(StatusCode, #{}, Req) inform(Status, Headers, Req :: cowboy_req:req()) -&gt; ok Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send an informational response. - Informational responses use a status code between 100 and 199. They cannot include a body. This function will not use any of the previously set headers. All headers to be sent must be given directly.</description> +Description inform(Status, Req :: cowboy_req:req()) -&gt; inform(StatusCode, #{}, Req) inform(Status, Headers, Req :: cowboy_req:req()) -&gt; ok Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send an informational response. +Informational responses use a status code between 100 and 199. They cannot include a body. This function will not use any of the previously set headers. All headers to be sent must be given directly. +Any number of informational responses can be sent as long as they are sent before the proper response.</description> </item> <item> @@ -4195,8 +4405,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.inform/</guid> <description>Name cowboy_req:inform - Send an informational response - Description inform(Status, Req :: cowboy_req:req()) -&gt; inform(StatusCode, #{}, Req) inform(Status, Headers, Req :: cowboy_req:req()) -&gt; ok Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send an informational response. - Informational responses use a status code between 100 and 199. They cannot include a body. This function will not use any of the previously set headers. All headers to be sent must be given directly.</description> +Description inform(Status, Req :: cowboy_req:req()) -&gt; inform(StatusCode, #{}, Req) inform(Status, Headers, Req :: cowboy_req:req()) -&gt; ok Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send an informational response. +Informational responses use a status code between 100 and 199. They cannot include a body. This function will not use any of the previously set headers. All headers to be sent must be given directly. +Any number of informational responses can be sent as long as they are sent before the proper response.</description> </item> <item> @@ -4206,8 +4417,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.inform/</guid> <description>Name cowboy_req:inform - Send an informational response - Description inform(Status, Req :: cowboy_req:req()) -&gt; inform(StatusCode, #{}, Req) inform(Status, Headers, Req :: cowboy_req:req()) -&gt; ok Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send an informational response. - Informational responses use a status code between 100 and 199. They cannot include a body. This function will not use any of the previously set headers. All headers to be sent must be given directly.</description> +Description inform(Status, Req :: cowboy_req:req()) -&gt; inform(StatusCode, #{}, Req) inform(Status, Headers, Req :: cowboy_req:req()) -&gt; ok Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send an informational response. +Informational responses use a status code between 100 and 199. They cannot include a body. This function will not use any of the previously set headers. All headers to be sent must be given directly. +Any number of informational responses can be sent as long as they are sent before the proper response.</description> </item> <item> @@ -4217,8 +4429,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.match_cookies/</guid> <description>Name cowboy_req:match_cookies - Match cookies against constraints - Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the cookies and match specific values against constraints. - Cowboy will only return the cookie values specified in the fields list, and ignore all others. Fields can be either the name of the cookie requested; the name along with a list of constraints; or the name, a list of constraints and a default value in case the cookie is missing.</description> +Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the cookies and match specific values against constraints. +Cowboy will only return the cookie values specified in the fields list, and ignore all others. Fields can be either the name of the cookie requested; the name along with a list of constraints; or the name, a list of constraints and a default value in case the cookie is missing.</description> </item> <item> @@ -4228,8 +4440,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.match_cookies/</guid> <description>Name cowboy_req:match_cookies - Match cookies against constraints - Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the cookies and match specific values against constraints. - Cowboy will only return the cookie values specified in the fields list, and ignore all others. Fields can be either the name of the cookie requested; the name along with a list of constraints; or the name, a list of constraints and a default value in case the cookie is missing.</description> +Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the cookies and match specific values against constraints. +Cowboy will only return the cookie values specified in the fields list, and ignore all others. Fields can be either the name of the cookie requested; the name along with a list of constraints; or the name, a list of constraints and a default value in case the cookie is missing.</description> </item> <item> @@ -4239,8 +4451,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.match_cookies/</guid> <description>Name cowboy_req:match_cookies - Match cookies against constraints - Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the cookies and match specific values against constraints. - Cowboy will only return the cookie values specified in the fields list, and ignore all others. Fields can be either the name of the cookie requested; the name along with a list of constraints; or the name, a list of constraints and a default value in case the cookie is missing.</description> +Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the cookies and match specific values against constraints. +Cowboy will only return the cookie values specified in the fields list, and ignore all others. Fields can be either the name of the cookie requested; the name along with a list of constraints; or the name, a list of constraints and a default value in case the cookie is missing.</description> </item> <item> @@ -4250,8 +4462,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.match_cookies/</guid> <description>Name cowboy_req:match_cookies - Match cookies against constraints - Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the cookies and match specific values against constraints. - Cowboy will only return the cookie values specified in the fields list, and ignore all others. Fields can be either the name of the cookie requested; the name along with a list of constraints; or the name, a list of constraints and a default value in case the cookie is missing.</description> +Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the cookies and match specific values against constraints. +Cowboy will only return the cookie values specified in the fields list, and ignore all others. Fields can be either the name of the cookie requested; the name along with a list of constraints; or the name, a list of constraints and a default value in case the cookie is missing.</description> </item> <item> @@ -4261,8 +4473,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.match_cookies/</guid> <description>Name cowboy_req:match_cookies - Match cookies against constraints - Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the cookies and match specific values against constraints. - Cowboy will only return the cookie values specified in the fields list, and ignore all others. Fields can be either the name of the cookie requested; the name along with a list of constraints; or the name, a list of constraints and a default value in case the cookie is missing.</description> +Description match_cookies(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the cookies and match specific values against constraints. +Cowboy will only return the cookie values specified in the fields list, and ignore all others. Fields can be either the name of the cookie requested; the name along with a list of constraints; or the name, a list of constraints and a default value in case the cookie is missing.</description> </item> <item> @@ -4272,8 +4484,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.match_qs/</guid> <description>Name cowboy_req:match_qs - Match the query string against constraints - Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the query string and match specific values against constraints. - Cowboy will only return the query string values specified in the fields list, and ignore all others. Fields can be either the key requested; the key along with a list of constraints; or the key, a list of constraints and a default value in case the key is missing.</description> +Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the query string and match specific values against constraints. +Cowboy will only return the query string values specified in the fields list, and ignore all others. Fields can be either the key requested; the key along with a list of constraints; or the key, a list of constraints and a default value in case the key is missing.</description> </item> <item> @@ -4283,8 +4495,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.match_qs/</guid> <description>Name cowboy_req:match_qs - Match the query string against constraints - Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the query string and match specific values against constraints. - Cowboy will only return the query string values specified in the fields list, and ignore all others. Fields can be either the key requested; the key along with a list of constraints; or the key, a list of constraints and a default value in case the key is missing.</description> +Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the query string and match specific values against constraints. +Cowboy will only return the query string values specified in the fields list, and ignore all others. Fields can be either the key requested; the key along with a list of constraints; or the key, a list of constraints and a default value in case the key is missing.</description> </item> <item> @@ -4294,8 +4506,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.match_qs/</guid> <description>Name cowboy_req:match_qs - Match the query string against constraints - Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the query string and match specific values against constraints. - Cowboy will only return the query string values specified in the fields list, and ignore all others. Fields can be either the key requested; the key along with a list of constraints; or the key, a list of constraints and a default value in case the key is missing.</description> +Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the query string and match specific values against constraints. +Cowboy will only return the query string values specified in the fields list, and ignore all others. Fields can be either the key requested; the key along with a list of constraints; or the key, a list of constraints and a default value in case the key is missing.</description> </item> <item> @@ -4305,8 +4517,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.match_qs/</guid> <description>Name cowboy_req:match_qs - Match the query string against constraints - Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the query string and match specific values against constraints. - Cowboy will only return the query string values specified in the fields list, and ignore all others. Fields can be either the key requested; the key along with a list of constraints; or the key, a list of constraints and a default value in case the key is missing.</description> +Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the query string and match specific values against constraints. +Cowboy will only return the query string values specified in the fields list, and ignore all others. Fields can be either the key requested; the key along with a list of constraints; or the key, a list of constraints and a default value in case the key is missing.</description> </item> <item> @@ -4316,8 +4528,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.match_qs/</guid> <description>Name cowboy_req:match_qs - Match the query string against constraints - Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the query string and match specific values against constraints. - Cowboy will only return the query string values specified in the fields list, and ignore all others. Fields can be either the key requested; the key along with a list of constraints; or the key, a list of constraints and a default value in case the key is missing.</description> +Description match_qs(Fields :: cowboy:fields(), Req :: cowboy_req:req()) -&gt; #{atom() =&gt; any()} Parse the query string and match specific values against constraints. +Cowboy will only return the query string values specified in the fields list, and ignore all others. Fields can be either the key requested; the key along with a list of constraints; or the key, a list of constraints and a default value in case the key is missing.</description> </item> <item> @@ -4327,9 +4539,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.method/</guid> <description>Name cowboy_req:method - HTTP method - Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&#8217;s HTTP method. - The method can also be obtained using pattern matching: - #{method := Method} = Req. Arguments Req The Req object. Return value The request&#8217;s HTTP method is returned as a binary string. While methods are case sensitive, standard methods are always uppercase.</description> +Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&apos;s HTTP method. +The method can also be obtained using pattern matching: +#{method := Method} = Req. Arguments Req The Req object. + Return value The request&apos;s HTTP method is returned as a binary string. While methods are case sensitive, standard methods are always uppercase. +Changelog 2.0: Only the method is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4339,9 +4553,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.method/</guid> <description>Name cowboy_req:method - HTTP method - Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&#8217;s HTTP method. - The method can also be obtained using pattern matching: - #{method := Method} = Req. Arguments Req The Req object. Return value The request&#8217;s HTTP method is returned as a binary string. While methods are case sensitive, standard methods are always uppercase.</description> +Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&apos;s HTTP method. +The method can also be obtained using pattern matching: +#{method := Method} = Req. Arguments Req The Req object. + Return value The request&apos;s HTTP method is returned as a binary string. While methods are case sensitive, standard methods are always uppercase. +Changelog 2.0: Only the method is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4351,9 +4567,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.method/</guid> <description>Name cowboy_req:method - HTTP method - Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&#8217;s HTTP method. - The method can also be obtained using pattern matching: - #{method := Method} = Req. Arguments Req The Req object. Return value The request&#8217;s HTTP method is returned as a binary string. While methods are case sensitive, standard methods are always uppercase.</description> +Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&apos;s HTTP method. +The method can also be obtained using pattern matching: +#{method := Method} = Req. Arguments Req The Req object. + Return value The request&apos;s HTTP method is returned as a binary string. While methods are case sensitive, standard methods are always uppercase. +Changelog 2.0: Only the method is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4363,9 +4581,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.method/</guid> <description>Name cowboy_req:method - HTTP method - Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&#8217;s HTTP method. - The method can also be obtained using pattern matching: - #{method := Method} = Req. Arguments Req The Req object. Return value The request&#8217;s HTTP method is returned as a binary string. While methods are case sensitive, standard methods are always uppercase.</description> +Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&apos;s HTTP method. +The method can also be obtained using pattern matching: +#{method := Method} = Req. Arguments Req The Req object. + Return value The request&apos;s HTTP method is returned as a binary string. While methods are case sensitive, standard methods are always uppercase. +Changelog 2.0: Only the method is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4375,9 +4595,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.method/</guid> <description>Name cowboy_req:method - HTTP method - Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&#8217;s HTTP method. - The method can also be obtained using pattern matching: - #{method := Method} = Req. Arguments Req The Req object. Return value The request&#8217;s HTTP method is returned as a binary string. While methods are case sensitive, standard methods are always uppercase.</description> +Description method(Req :: cowboy_req:req()) -&gt; Method :: binary() Return the request&apos;s HTTP method. +The method can also be obtained using pattern matching: +#{method := Method} = Req. Arguments Req The Req object. + Return value The request&apos;s HTTP method is returned as a binary string. While methods are case sensitive, standard methods are always uppercase. +Changelog 2.0: Only the method is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4387,11 +4609,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.parse_cookies/</guid> <description>Name cowboy_req:parse_cookies - Parse cookie headers - Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. - Alias for cowboy_req:parse_header([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.</description> +Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. +Alias for cowboy_req:parse_header(&lt;&lt;&quot;cookie&quot;&gt;&gt;, Req). +When the cookie header is missing, [] is returned. +While an empty cookie header is not valid, some clients do send it. Cowboy will in this case also return []. +Arguments Req The Req object. + Return value The cookies are returned as a list of key/values.</description> </item> <item> @@ -4401,11 +4624,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.parse_cookies/</guid> <description>Name cowboy_req:parse_cookies - Parse cookie headers - Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. - Alias for cowboy_req:parse_header([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.</description> +Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. +Alias for cowboy_req:parse_header(&lt;&lt;&quot;cookie&quot;&gt;&gt;, Req). +When the cookie header is missing, [] is returned. +While an empty cookie header is not valid, some clients do send it. Cowboy will in this case also return []. +Arguments Req The Req object. + Return value The cookies are returned as a list of key/values.</description> </item> <item> @@ -4415,11 +4639,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.parse_cookies/</guid> <description>Name cowboy_req:parse_cookies - Parse cookie headers - Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. - Alias for cowboy_req:parse_header([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.</description> +Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. +Alias for cowboy_req:parse_header(&lt;&lt;&quot;cookie&quot;&gt;&gt;, Req). +When the cookie header is missing, [] is returned. +While an empty cookie header is not valid, some clients do send it. Cowboy will in this case also return []. +Arguments Req The Req object. + Return value The cookies are returned as a list of key/values.</description> </item> <item> @@ -4429,11 +4654,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.parse_cookies/</guid> <description>Name cowboy_req:parse_cookies - Parse cookie headers - Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. - Alias for cowboy_req:parse_header([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.</description> +Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. +Alias for cowboy_req:parse_header(&lt;&lt;&quot;cookie&quot;&gt;&gt;, Req). +When the cookie header is missing, [] is returned. +While an empty cookie header is not valid, some clients do send it. Cowboy will in this case also return []. +Arguments Req The Req object. + Return value The cookies are returned as a list of key/values.</description> </item> <item> @@ -4443,11 +4669,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.parse_cookies/</guid> <description>Name cowboy_req:parse_cookies - Parse cookie headers - Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. - Alias for cowboy_req:parse_header([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.</description> +Description parse_cookies(Req) -&gt; [{Name, Value}] Name :: binary() %% case sensitive Value :: binary() %% case sensitive Parse cookie headers. +Alias for cowboy_req:parse_header(&lt;&lt;&quot;cookie&quot;&gt;&gt;, Req). +When the cookie header is missing, [] is returned. +While an empty cookie header is not valid, some clients do send it. Cowboy will in this case also return []. +Arguments Req The Req object. + Return value The cookies are returned as a list of key/values.</description> </item> <item> @@ -4457,8 +4684,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.parse_header/</guid> <description>Name cowboy_req:parse_header - Parse the given HTTP header - Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; ParsedValue | Default Name :: binary() Req :: cowboy_req:req() ParsedValue :: any() Default :: any() Parse the given HTTP header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; ParsedValue | Default Name :: binary() Req :: cowboy_req:req() ParsedValue :: any() Default :: any() Parse the given HTTP header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +The type of the parsed value varies depending on the header.</description> </item> <item> @@ -4468,8 +4696,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.parse_header/</guid> <description>Name cowboy_req:parse_header - Parse the given HTTP header - Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; ParsedValue | Default Name :: binary() Req :: cowboy_req:req() ParsedValue :: any() Default :: any() Parse the given HTTP header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; ParsedValue | Default Name :: binary() Req :: cowboy_req:req() ParsedValue :: any() Default :: any() Parse the given HTTP header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +The type of the parsed value varies depending on the header.</description> </item> <item> @@ -4479,8 +4708,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.parse_header/</guid> <description>Name cowboy_req:parse_header - Parse the given HTTP header - Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; ParsedValue | Default Name :: binary() Req :: cowboy_req:req() ParsedValue :: any() Default :: any() Parse the given HTTP header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; ParsedValue | Default Name :: binary() Req :: cowboy_req:req() ParsedValue :: any() Default :: any() Parse the given HTTP header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +The type of the parsed value varies depending on the header.</description> </item> <item> @@ -4490,8 +4720,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.parse_header/</guid> <description>Name cowboy_req:parse_header - Parse the given HTTP header - Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; ParsedValue | Default Name :: binary() Req :: cowboy_req:req() ParsedValue :: any() Default :: any() Parse the given HTTP header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; ParsedValue | Default Name :: binary() Req :: cowboy_req:req() ParsedValue :: any() Default :: any() Parse the given HTTP header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +The type of the parsed value varies depending on the header.</description> </item> <item> @@ -4501,8 +4732,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.parse_header/</guid> <description>Name cowboy_req:parse_header - Parse the given HTTP header - Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; ParsedValue | Default Name :: binary() Req :: cowboy_req:req() ParsedValue :: any() Default :: any() Parse the given HTTP header. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description parse_header(Name, Req) -&gt; ParsedValue | Default parse_header(Name, Req, Default) -&gt; ParsedValue | Default Name :: binary() Req :: cowboy_req:req() ParsedValue :: any() Default :: any() Parse the given HTTP header. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +The type of the parsed value varies depending on the header.</description> </item> <item> @@ -4512,8 +4744,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.parse_qs/</guid> <description>Name cowboy_req:parse_qs - Parse the query string - Description parse_qs(Req :: cowboy_req:req()) -&gt; [{Key :: binary(), Value :: binary() | true}] Parse the query string as a list of key/value pairs. - Arguments Req The Req object. Return value The parsed query string is returned as a list of key/value pairs. The key is a binary string. The value is either a binary string, or the atom true.</description> +Description parse_qs(Req :: cowboy_req:req()) -&gt; [{Key :: binary(), Value :: binary() | true}] Parse the query string as a list of key/value pairs. +Arguments Req The Req object. + Return value The parsed query string is returned as a list of key/value pairs. The key is a binary string. The value is either a binary string, or the atom true. Both key and value are case sensitive.</description> </item> <item> @@ -4523,8 +4756,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.parse_qs/</guid> <description>Name cowboy_req:parse_qs - Parse the query string - Description parse_qs(Req :: cowboy_req:req()) -&gt; [{Key :: binary(), Value :: binary() | true}] Parse the query string as a list of key/value pairs. - Arguments Req The Req object. Return value The parsed query string is returned as a list of key/value pairs. The key is a binary string. The value is either a binary string, or the atom true.</description> +Description parse_qs(Req :: cowboy_req:req()) -&gt; [{Key :: binary(), Value :: binary() | true}] Parse the query string as a list of key/value pairs. +Arguments Req The Req object. + Return value The parsed query string is returned as a list of key/value pairs. The key is a binary string. The value is either a binary string, or the atom true. Both key and value are case sensitive.</description> </item> <item> @@ -4534,8 +4768,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.parse_qs/</guid> <description>Name cowboy_req:parse_qs - Parse the query string - Description parse_qs(Req :: cowboy_req:req()) -&gt; [{Key :: binary(), Value :: binary() | true}] Parse the query string as a list of key/value pairs. - Arguments Req The Req object. Return value The parsed query string is returned as a list of key/value pairs. The key is a binary string. The value is either a binary string, or the atom true.</description> +Description parse_qs(Req :: cowboy_req:req()) -&gt; [{Key :: binary(), Value :: binary() | true}] Parse the query string as a list of key/value pairs. +Arguments Req The Req object. + Return value The parsed query string is returned as a list of key/value pairs. The key is a binary string. The value is either a binary string, or the atom true. Both key and value are case sensitive.</description> </item> <item> @@ -4545,8 +4780,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.parse_qs/</guid> <description>Name cowboy_req:parse_qs - Parse the query string - Description parse_qs(Req :: cowboy_req:req()) -&gt; [{Key :: binary(), Value :: binary() | true}] Parse the query string as a list of key/value pairs. - Arguments Req The Req object. Return value The parsed query string is returned as a list of key/value pairs. The key is a binary string. The value is either a binary string, or the atom true.</description> +Description parse_qs(Req :: cowboy_req:req()) -&gt; [{Key :: binary(), Value :: binary() | true}] Parse the query string as a list of key/value pairs. +Arguments Req The Req object. + Return value The parsed query string is returned as a list of key/value pairs. The key is a binary string. The value is either a binary string, or the atom true. Both key and value are case sensitive.</description> </item> <item> @@ -4556,8 +4792,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.parse_qs/</guid> <description>Name cowboy_req:parse_qs - Parse the query string - Description parse_qs(Req :: cowboy_req:req()) -&gt; [{Key :: binary(), Value :: binary() | true}] Parse the query string as a list of key/value pairs. - Arguments Req The Req object. Return value The parsed query string is returned as a list of key/value pairs. The key is a binary string. The value is either a binary string, or the atom true.</description> +Description parse_qs(Req :: cowboy_req:req()) -&gt; [{Key :: binary(), Value :: binary() | true}] Parse the query string as a list of key/value pairs. +Arguments Req The Req object. + Return value The parsed query string is returned as a list of key/value pairs. The key is a binary string. The value is either a binary string, or the atom true. Both key and value are case sensitive.</description> </item> <item> @@ -4567,10 +4804,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.path/</guid> <description>Name cowboy_req:path - URI path - Description path(Req :: cowboy_req:req()) -&gt; Path :: binary() Return the path of the effective request URI. - The path can also be obtained using pattern matching: - #{path := Path} = Req. Arguments Req The Req object. Return value The path is returned as a binary string. It is case sensitive. - Changelog 2.</description> +Description path(Req :: cowboy_req:req()) -&gt; Path :: binary() Return the path of the effective request URI. +The path can also be obtained using pattern matching: +#{path := Path} = Req. Arguments Req The Req object. + Return value The path is returned as a binary string. It is case sensitive. +Changelog 2.0: Only the path is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4580,10 +4818,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.path/</guid> <description>Name cowboy_req:path - URI path - Description path(Req :: cowboy_req:req()) -&gt; Path :: binary() Return the path of the effective request URI. - The path can also be obtained using pattern matching: - #{path := Path} = Req. Arguments Req The Req object. Return value The path is returned as a binary string. It is case sensitive. - Changelog 2.</description> +Description path(Req :: cowboy_req:req()) -&gt; Path :: binary() Return the path of the effective request URI. +The path can also be obtained using pattern matching: +#{path := Path} = Req. Arguments Req The Req object. + Return value The path is returned as a binary string. It is case sensitive. +Changelog 2.0: Only the path is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4593,10 +4832,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.path/</guid> <description>Name cowboy_req:path - URI path - Description path(Req :: cowboy_req:req()) -&gt; Path :: binary() Return the path of the effective request URI. - The path can also be obtained using pattern matching: - #{path := Path} = Req. Arguments Req The Req object. Return value The path is returned as a binary string. It is case sensitive. - Changelog 2.</description> +Description path(Req :: cowboy_req:req()) -&gt; Path :: binary() Return the path of the effective request URI. +The path can also be obtained using pattern matching: +#{path := Path} = Req. Arguments Req The Req object. + Return value The path is returned as a binary string. It is case sensitive. +Changelog 2.0: Only the path is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4606,10 +4846,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.path/</guid> <description>Name cowboy_req:path - URI path - Description path(Req :: cowboy_req:req()) -&gt; Path :: binary() Return the path of the effective request URI. - The path can also be obtained using pattern matching: - #{path := Path} = Req. Arguments Req The Req object. Return value The path is returned as a binary string. It is case sensitive. - Changelog 2.</description> +Description path(Req :: cowboy_req:req()) -&gt; Path :: binary() Return the path of the effective request URI. +The path can also be obtained using pattern matching: +#{path := Path} = Req. Arguments Req The Req object. + Return value The path is returned as a binary string. It is case sensitive. +Changelog 2.0: Only the path is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4619,10 +4860,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.path/</guid> <description>Name cowboy_req:path - URI path - Description path(Req :: cowboy_req:req()) -&gt; Path :: binary() Return the path of the effective request URI. - The path can also be obtained using pattern matching: - #{path := Path} = Req. Arguments Req The Req object. Return value The path is returned as a binary string. It is case sensitive. - Changelog 2.</description> +Description path(Req :: cowboy_req:req()) -&gt; Path :: binary() Return the path of the effective request URI. +The path can also be obtained using pattern matching: +#{path := Path} = Req. Arguments Req The Req object. + Return value The path is returned as a binary string. It is case sensitive. +Changelog 2.0: Only the path is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4631,10 +4873,12 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.path_info/</guid> - <description>Name cowboy_req:path_info - Access the route&#8217;s trailing path segments - Description path_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the trailing path segments. - This is the part of the host name that was matched using the ... notation. - Arguments Req The Req object. Return value The tokens are returned as a list of case sensitive binary strings.</description> + <description>Name cowboy_req:path_info - Access the route&apos;s trailing path segments +Description path_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the trailing path segments. +This is the part of the host name that was matched using the ... notation. +Arguments Req The Req object. + Return value The tokens are returned as a list of case sensitive binary strings. +Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4643,10 +4887,12 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.path_info/</guid> - <description>Name cowboy_req:path_info - Access the route&#8217;s trailing path segments - Description path_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the trailing path segments. - This is the part of the host name that was matched using the ... notation. - Arguments Req The Req object. Return value The tokens are returned as a list of case sensitive binary strings.</description> + <description>Name cowboy_req:path_info - Access the route&apos;s trailing path segments +Description path_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the trailing path segments. +This is the part of the host name that was matched using the ... notation. +Arguments Req The Req object. + Return value The tokens are returned as a list of case sensitive binary strings. +Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4655,10 +4901,12 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.path_info/</guid> - <description>Name cowboy_req:path_info - Access the route&#8217;s trailing path segments - Description path_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the trailing path segments. - This is the part of the host name that was matched using the ... notation. - Arguments Req The Req object. Return value The tokens are returned as a list of case sensitive binary strings.</description> + <description>Name cowboy_req:path_info - Access the route&apos;s trailing path segments +Description path_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the trailing path segments. +This is the part of the host name that was matched using the ... notation. +Arguments Req The Req object. + Return value The tokens are returned as a list of case sensitive binary strings. +Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4667,10 +4915,12 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.path_info/</guid> - <description>Name cowboy_req:path_info - Access the route&#8217;s trailing path segments - Description path_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the trailing path segments. - This is the part of the host name that was matched using the ... notation. - Arguments Req The Req object. Return value The tokens are returned as a list of case sensitive binary strings.</description> + <description>Name cowboy_req:path_info - Access the route&apos;s trailing path segments +Description path_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the trailing path segments. +This is the part of the host name that was matched using the ... notation. +Arguments Req The Req object. + Return value The tokens are returned as a list of case sensitive binary strings. +Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4679,10 +4929,12 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.path_info/</guid> - <description>Name cowboy_req:path_info - Access the route&#8217;s trailing path segments - Description path_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the trailing path segments. - This is the part of the host name that was matched using the ... notation. - Arguments Req The Req object. Return value The tokens are returned as a list of case sensitive binary strings.</description> + <description>Name cowboy_req:path_info - Access the route&apos;s trailing path segments +Description path_info(Req :: cowboy_req:req()) -&gt; cowboy_router:tokens() Return the tokens for the trailing path segments. +This is the part of the host name that was matched using the ... notation. +Arguments Req The Req object. + Return value The tokens are returned as a list of case sensitive binary strings. +Changelog 2.0: Only the tokens are returned, they are no longer wrapped in a tuple.</description> </item> <item> @@ -4692,10 +4944,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.peer/</guid> <description>Name cowboy_req:peer - Peer address and port - Description peer(Req :: cowboy_req:req()) -&gt; Peer Peer :: {inet:ip_address(), inet:port_number()} Return the peer&#8217;s IP address and port number. - The peer can also be obtained using pattern matching: - #{peer := {IP, Port}} = Req. Arguments Req The Req object. Return value The peer&#8217;s IP address and port number. - The peer is not necessarily the client&#8217;s IP address and port.</description> +Description peer(Req :: cowboy_req:req()) -&gt; Peer Peer :: {inet:ip_address(), inet:port_number()} Return the peer&apos;s IP address and port number. +The peer can also be obtained using pattern matching: +#{peer := {IP, Port}} = Req. Arguments Req The Req object. + Return value The peer&apos;s IP address and port number. +The peer is not necessarily the client&apos;s IP address and port. It is the IP address of the endpoint connecting directly to the server, which may be a gateway or a proxy.</description> </item> <item> @@ -4705,9 +4958,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.peer/</guid> <description>Name cowboy_req:peer - Peer address and port - Description peer(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the peer&#8217;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&#8217;s IP address and port number.</description> +Description peer(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the peer&apos;s IP address and port number. +The peer information can also be obtained using pattern matching: +#{peer := {IP, Port}} = Req. Arguments Req The Req object. + Return value The peer&apos;s IP address and port number. +The peer is not necessarily the client&apos;s IP address and port. It is the IP address of the endpoint connecting directly to the server, which may be a gateway or a proxy.</description> </item> <item> @@ -4717,9 +4972,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.peer/</guid> <description>Name cowboy_req:peer - Peer address and port - Description peer(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the peer&#8217;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&#8217;s IP address and port number.</description> +Description peer(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the peer&apos;s IP address and port number. +The peer information can also be obtained using pattern matching: +#{peer := {IP, Port}} = Req. Arguments Req The Req object. + Return value The peer&apos;s IP address and port number. +The peer is not necessarily the client&apos;s IP address and port. It is the IP address of the endpoint connecting directly to the server, which may be a gateway or a proxy.</description> </item> <item> @@ -4729,9 +4986,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.peer/</guid> <description>Name cowboy_req:peer - Peer address and port - Description peer(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the peer&#8217;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&#8217;s IP address and port number.</description> +Description peer(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the peer&apos;s IP address and port number. +The peer information can also be obtained using pattern matching: +#{peer := {IP, Port}} = Req. Arguments Req The Req object. + Return value The peer&apos;s IP address and port number. +The peer is not necessarily the client&apos;s IP address and port. It is the IP address of the endpoint connecting directly to the server, which may be a gateway or a proxy.</description> </item> <item> @@ -4741,9 +5000,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.peer/</guid> <description>Name cowboy_req:peer - Peer address and port - Description peer(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the peer&#8217;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&#8217;s IP address and port number.</description> +Description peer(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the peer&apos;s IP address and port number. +The peer information can also be obtained using pattern matching: +#{peer := {IP, Port}} = Req. Arguments Req The Req object. + Return value The peer&apos;s IP address and port number. +The peer is not necessarily the client&apos;s IP address and port. It is the IP address of the endpoint connecting directly to the server, which may be a gateway or a proxy.</description> </item> <item> @@ -4753,10 +5014,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.port/</guid> <description>Name cowboy_req:port - URI port number - Description port(Req :: cowboy_req:req()) -&gt; Port :: inet:port_number() Return the port number of the effective request URI. - Note that the port number returned by this function is obtained by parsing the host header. It may be different from the port the peer used to connect to Cowboy. - The port number can also be obtained using pattern matching: - #{port := Port} = Req.</description> +Description port(Req :: cowboy_req:req()) -&gt; Port :: inet:port_number() Return the port number of the effective request URI. +Note that the port number returned by this function is obtained by parsing the host header. It may be different from the port the peer used to connect to Cowboy. +The port number can also be obtained using pattern matching: +#{port := Port} = Req. Arguments Req The Req object.</description> </item> <item> @@ -4766,10 +5027,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.port/</guid> <description>Name cowboy_req:port - URI port number - Description port(Req :: cowboy_req:req()) -&gt; Port :: inet:port_number() Return the port number of the effective request URI. - Note that the port number returned by this function is obtained by parsing the host header. It may be different from the port the peer used to connect to Cowboy. - The port number can also be obtained using pattern matching: - #{port := Port} = Req.</description> +Description port(Req :: cowboy_req:req()) -&gt; Port :: inet:port_number() Return the port number of the effective request URI. +Note that the port number returned by this function is obtained by parsing the host header. It may be different from the port the peer used to connect to Cowboy. +The port number can also be obtained using pattern matching: +#{port := Port} = Req. Arguments Req The Req object.</description> </item> <item> @@ -4779,10 +5040,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.port/</guid> <description>Name cowboy_req:port - URI port number - Description port(Req :: cowboy_req:req()) -&gt; Port :: inet:port_number() Return the port number of the effective request URI. - Note that the port number returned by this function is obtained by parsing the host header. It may be different from the port the peer used to connect to Cowboy. - The port number can also be obtained using pattern matching: - #{port := Port} = Req.</description> +Description port(Req :: cowboy_req:req()) -&gt; Port :: inet:port_number() Return the port number of the effective request URI. +Note that the port number returned by this function is obtained by parsing the host header. It may be different from the port the peer used to connect to Cowboy. +The port number can also be obtained using pattern matching: +#{port := Port} = Req. Arguments Req The Req object.</description> </item> <item> @@ -4792,10 +5053,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.port/</guid> <description>Name cowboy_req:port - URI port number - Description port(Req :: cowboy_req:req()) -&gt; Port :: inet:port_number() Return the port number of the effective request URI. - Note that the port number returned by this function is obtained by parsing the host header. It may be different from the port the peer used to connect to Cowboy. - The port number can also be obtained using pattern matching: - #{port := Port} = Req.</description> +Description port(Req :: cowboy_req:req()) -&gt; Port :: inet:port_number() Return the port number of the effective request URI. +Note that the port number returned by this function is obtained by parsing the host header. It may be different from the port the peer used to connect to Cowboy. +The port number can also be obtained using pattern matching: +#{port := Port} = Req. Arguments Req The Req object.</description> </item> <item> @@ -4805,10 +5066,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.port/</guid> <description>Name cowboy_req:port - URI port number - Description port(Req :: cowboy_req:req()) -&gt; Port :: inet:port_number() Return the port number of the effective request URI. - Note that the port number returned by this function is obtained by parsing the host header. It may be different from the port the peer used to connect to Cowboy. - The port number can also be obtained using pattern matching: - #{port := Port} = Req.</description> +Description port(Req :: cowboy_req:req()) -&gt; Port :: inet:port_number() Return the port number of the effective request URI. +Note that the port number returned by this function is obtained by parsing the host header. It may be different from the port the peer used to connect to Cowboy. +The port number can also be obtained using pattern matching: +#{port := Port} = Req. Arguments Req The Req object.</description> </item> <item> @@ -4818,8 +5079,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.push/</guid> <description>Name cowboy_req:push - Push a resource to the client - Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; ok Path :: iodata() %% case sensitive Headers :: cowboy:http_headers() Opts :: cowboy_req:push_opts() Push a resource to the client. - Cowboy handles push requests the same way as if they came from the client, including the creation of a request handling process, routing and middlewares and so on.</description> +Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; ok Path :: iodata() %% case sensitive Headers :: cowboy:http_headers() Opts :: cowboy_req:push_opts() Push a resource to the client. +Cowboy handles push requests the same way as if they came from the client, including the creation of a request handling process, routing and middlewares and so on.</description> </item> <item> @@ -4829,8 +5090,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.push/</guid> <description>Name cowboy_req:push - Push a resource to the client - Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; ok Path :: iodata() %% case sensitive Headers :: cowboy:http_headers() Opts :: cowboy_req:push_opts() Push a resource to the client. - Cowboy handles push requests the same way as if they came from the client, including the creation of a request handling process, routing and middlewares and so on.</description> +Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; ok Path :: iodata() %% case sensitive Headers :: cowboy:http_headers() Opts :: cowboy_req:push_opts() Push a resource to the client. +Cowboy handles push requests the same way as if they came from the client, including the creation of a request handling process, routing and middlewares and so on.</description> </item> <item> @@ -4840,8 +5101,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.push/</guid> <description>Name cowboy_req:push - Push a resource to the client - Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; ok Path :: iodata() %% case sensitive Headers :: cowboy:http_headers() Opts :: cowboy_req:push_opts() Push a resource to the client. - Cowboy handles push requests the same way as if they came from the client, including the creation of a request handling process, routing and middlewares and so on.</description> +Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; ok Path :: iodata() %% case sensitive Headers :: cowboy:http_headers() Opts :: cowboy_req:push_opts() Push a resource to the client. +Cowboy handles push requests the same way as if they came from the client, including the creation of a request handling process, routing and middlewares and so on.</description> </item> <item> @@ -4851,8 +5112,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.push/</guid> <description>Name cowboy_req:push - Push a resource to the client - Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; ok Path :: iodata() %% case sensitive Headers :: cowboy:http_headers() Opts :: cowboy_req:push_opts() Push a resource to the client. - Cowboy handles push requests the same way as if they came from the client, including the creation of a request handling process, routing and middlewares and so on.</description> +Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; ok Path :: iodata() %% case sensitive Headers :: cowboy:http_headers() Opts :: cowboy_req:push_opts() Push a resource to the client. +Cowboy handles push requests the same way as if they came from the client, including the creation of a request handling process, routing and middlewares and so on.</description> </item> <item> @@ -4862,8 +5123,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.push/</guid> <description>Name cowboy_req:push - Push a resource to the client - Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; ok Path :: iodata() %% case sensitive Headers :: cowboy:http_headers() Opts :: cowboy_req:push_opts() Push a resource to the client. - Cowboy handles push requests the same way as if they came from the client, including the creation of a request handling process, routing and middlewares and so on.</description> +Description push(Path, Headers, Req :: cowboy_req:req()) -&gt; push(Path, Headers, Req, #{}) push(Path, Headers, Req :: cowboy_req:req(), Opts) -&gt; ok Path :: iodata() %% case sensitive Headers :: cowboy:http_headers() Opts :: cowboy_req:push_opts() Push a resource to the client. +Cowboy handles push requests the same way as if they came from the client, including the creation of a request handling process, routing and middlewares and so on.</description> </item> <item> @@ -4873,9 +5134,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.qs/</guid> <description>Name cowboy_req:qs - URI query string - Description qs(Req :: cowboy_req:req()) -&gt; Qs :: binary() Return the query string of the effective request URI. - The query string can also be obtained using pattern matching: - #{qs := Qs} = Req. Arguments Req The Req object. Return value The query string is returned as a binary string. It is case sensitive.</description> +Description qs(Req :: cowboy_req:req()) -&gt; Qs :: binary() Return the query string of the effective request URI. +The query string can also be obtained using pattern matching: +#{qs := Qs} = Req. Arguments Req The Req object. + Return value The query string is returned as a binary string. It is case sensitive. +Changelog 2.0: Only the query string is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4885,9 +5148,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.qs/</guid> <description>Name cowboy_req:qs - URI query string - Description qs(Req :: cowboy_req:req()) -&gt; Qs :: binary() Return the query string of the effective request URI. - The query string can also be obtained using pattern matching: - #{qs := Qs} = Req. Arguments Req The Req object. Return value The query string is returned as a binary string. It is case sensitive.</description> +Description qs(Req :: cowboy_req:req()) -&gt; Qs :: binary() Return the query string of the effective request URI. +The query string can also be obtained using pattern matching: +#{qs := Qs} = Req. Arguments Req The Req object. + Return value The query string is returned as a binary string. It is case sensitive. +Changelog 2.0: Only the query string is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4897,9 +5162,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.qs/</guid> <description>Name cowboy_req:qs - URI query string - Description qs(Req :: cowboy_req:req()) -&gt; Qs :: binary() Return the query string of the effective request URI. - The query string can also be obtained using pattern matching: - #{qs := Qs} = Req. Arguments Req The Req object. Return value The query string is returned as a binary string. It is case sensitive.</description> +Description qs(Req :: cowboy_req:req()) -&gt; Qs :: binary() Return the query string of the effective request URI. +The query string can also be obtained using pattern matching: +#{qs := Qs} = Req. Arguments Req The Req object. + Return value The query string is returned as a binary string. It is case sensitive. +Changelog 2.0: Only the query string is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4909,9 +5176,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.qs/</guid> <description>Name cowboy_req:qs - URI query string - Description qs(Req :: cowboy_req:req()) -&gt; Qs :: binary() Return the query string of the effective request URI. - The query string can also be obtained using pattern matching: - #{qs := Qs} = Req. Arguments Req The Req object. Return value The query string is returned as a binary string. It is case sensitive.</description> +Description qs(Req :: cowboy_req:req()) -&gt; Qs :: binary() Return the query string of the effective request URI. +The query string can also be obtained using pattern matching: +#{qs := Qs} = Req. Arguments Req The Req object. + Return value The query string is returned as a binary string. It is case sensitive. +Changelog 2.0: Only the query string is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4921,9 +5190,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.qs/</guid> <description>Name cowboy_req:qs - URI query string - Description qs(Req :: cowboy_req:req()) -&gt; Qs :: binary() Return the query string of the effective request URI. - The query string can also be obtained using pattern matching: - #{qs := Qs} = Req. Arguments Req The Req object. Return value The query string is returned as a binary string. It is case sensitive.</description> +Description qs(Req :: cowboy_req:req()) -&gt; Qs :: binary() Return the query string of the effective request URI. +The query string can also be obtained using pattern matching: +#{qs := Qs} = Req. Arguments Req The Req object. + Return value The query string is returned as a binary string. It is case sensitive. +Changelog 2.0: Only the query string is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -4933,8 +5204,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.read_body/</guid> <description>Name cowboy_req:read_body - Read the request body - Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the request body. - This function reads a chunk of the request body. A more tuple is returned when more data remains to be read. Call the function repeatedly until an ok tuple is returned to read the entire body.</description> +Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the request body. +This function reads a chunk of the request body. A more tuple is returned when more data remains to be read. Call the function repeatedly until an ok tuple is returned to read the entire body.</description> </item> <item> @@ -4944,8 +5215,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.read_body/</guid> <description>Name cowboy_req:read_body - Read the request body - Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the request body. - This function reads a chunk of the request body. A more tuple is returned when more data remains to be read. Call the function repeatedly until an ok tuple is returned to read the entire body.</description> +Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the request body. +This function reads a chunk of the request body. A more tuple is returned when more data remains to be read. Call the function repeatedly until an ok tuple is returned to read the entire body.</description> </item> <item> @@ -4955,8 +5226,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.read_body/</guid> <description>Name cowboy_req:read_body - Read the request body - Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the request body. - This function reads a chunk of the request body. A more tuple is returned when more data remains to be read. Call the function repeatedly until an ok tuple is returned to read the entire body.</description> +Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the request body. +This function reads a chunk of the request body. A more tuple is returned when more data remains to be read. Call the function repeatedly until an ok tuple is returned to read the entire body.</description> </item> <item> @@ -4966,8 +5237,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_body/</guid> <description>Name cowboy_req:read_body - Read the request body - Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the request body. - This function reads a chunk of the request body. A more tuple is returned when more data remains to be read. Call the function repeatedly until an ok tuple is returned to read the entire body.</description> +Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the request body. +This function reads a chunk of the request body. A more tuple is returned when more data remains to be read. Call the function repeatedly until an ok tuple is returned to read the entire body.</description> </item> <item> @@ -4977,8 +5248,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.read_body/</guid> <description>Name cowboy_req:read_body - Read the request body - Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the request body. - This function reads a chunk of the request body. A more tuple is returned when more data remains to be read. Call the function repeatedly until an ok tuple is returned to read the entire body.</description> +Description read_body(Req :: cowboy_req:req()) -&gt; read_body(Req, #{}) read_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the request body. +This function reads a chunk of the request body. A more tuple is returned when more data remains to be read. Call the function repeatedly until an ok tuple is returned to read the entire body.</description> </item> <item> @@ -4988,8 +5259,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.read_part/</guid> <description>Name cowboy_req:read_part - Read the next multipart headers - Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; binary()} Read the next part of a multipart body. - This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function parses and returns headers.</description> +Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; binary()} Read the next part of a multipart body. +This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function parses and returns headers.</description> </item> <item> @@ -4999,8 +5270,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.read_part/</guid> <description>Name cowboy_req:read_part - Read the next multipart headers - Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; binary()} Read the next part of a multipart body. - This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function parses and returns headers.</description> +Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; binary()} Read the next part of a multipart body. +This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function parses and returns headers.</description> </item> <item> @@ -5010,8 +5281,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.read_part/</guid> <description>Name cowboy_req:read_part - Read the next multipart headers - Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; binary()} Read the next part of a multipart body. - This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function parses and returns headers.</description> +Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; binary()} Read the next part of a multipart body. +This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function parses and returns headers.</description> </item> <item> @@ -5021,8 +5292,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_part/</guid> <description>Name cowboy_req:read_part - Read the next multipart headers - Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; binary()} Read the next part of a multipart body. - This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function parses and returns headers.</description> +Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; binary()} Read the next part of a multipart body. +This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function parses and returns headers.</description> </item> <item> @@ -5032,8 +5303,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.read_part/</guid> <description>Name cowboy_req:read_part - Read the next multipart headers - Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; binary()} Read the next part of a multipart body. - This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function parses and returns headers.</description> +Description read_part(Req :: cowboy_req:req()) -&gt; read_part(Req, #{}) read_part(Req :: cowboy_req:req(), Opts) -&gt; {ok, Headers, Req} | {done, Req} Opts :: cowboy_req:read_body_opts() Headers :: #{binary() =&gt; binary()} Read the next part of a multipart body. +This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function parses and returns headers.</description> </item> <item> @@ -5042,9 +5313,9 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.read_part_body/</guid> - <description>Name cowboy_req:read_part_body - Read the current part&#8217;s body - Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the body of the current part of the multipart message. - This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body.</description> + <description>Name cowboy_req:read_part_body - Read the current part&apos;s body +Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the body of the current part of the multipart message. +This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function returns the body of the current part.</description> </item> <item> @@ -5053,9 +5324,9 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.read_part_body/</guid> - <description>Name cowboy_req:read_part_body - Read the current part&#8217;s body - Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the body of the current part of the multipart message. - This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body.</description> + <description>Name cowboy_req:read_part_body - Read the current part&apos;s body +Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the body of the current part of the multipart message. +This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function returns the body of the current part.</description> </item> <item> @@ -5064,9 +5335,9 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.read_part_body/</guid> - <description>Name cowboy_req:read_part_body - Read the current part&#8217;s body - Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the body of the current part of the multipart message. - This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body.</description> + <description>Name cowboy_req:read_part_body - Read the current part&apos;s body +Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the body of the current part of the multipart message. +This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function returns the body of the current part.</description> </item> <item> @@ -5075,9 +5346,9 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_part_body/</guid> - <description>Name cowboy_req:read_part_body - Read the current part&#8217;s body - Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the body of the current part of the multipart message. - This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body.</description> + <description>Name cowboy_req:read_part_body - Read the current part&apos;s body +Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the body of the current part of the multipart message. +This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function returns the body of the current part.</description> </item> <item> @@ -5086,9 +5357,9 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.read_part_body/</guid> - <description>Name cowboy_req:read_part_body - Read the current part&#8217;s body - Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the body of the current part of the multipart message. - This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body.</description> + <description>Name cowboy_req:read_part_body - Read the current part&apos;s body +Description read_part_body(Req :: cowboy_req:req()) -&gt; read_part_body(Req, #{}) read_part_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Data :: binary(), Req} | {more, Data :: binary(), Req} Opts :: cowboy_req:read_body_opts() Read the body of the current part of the multipart message. +This function reads the request body and parses it as multipart. Each parts of a multipart representation have their own headers and body. This function returns the body of the current part.</description> </item> <item> @@ -5098,9 +5369,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.read_urlencoded_body/</guid> <description>Name cowboy_req:read_urlencoded_body - Read and parse a urlencoded request body - Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Body, Req} Opts :: cowboy_req:read_body_opts() Body :: [{Key :: binary(), Value :: binary() | true}] Read and parse a urlencoded request body. - This function reads the request body and parses it as application/x-www-form-urlencoded. It returns a list of key/values. - The urlencoded media type is used by Web browsers when submitting HTML forms using the POST method.</description> +Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Body, Req} Opts :: cowboy_req:read_body_opts() Body :: [{Key :: binary(), Value :: binary() | true}] Read and parse a urlencoded request body. +This function reads the request body and parses it as application/x-www-form-urlencoded. It returns a list of key/values. +The urlencoded media type is used by Web browsers when submitting HTML forms using the POST method.</description> </item> <item> @@ -5110,9 +5381,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.read_urlencoded_body/</guid> <description>Name cowboy_req:read_urlencoded_body - Read and parse a urlencoded request body - Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Body, Req} Opts :: cowboy_req:read_body_opts() Body :: [{Key :: binary(), Value :: binary() | true}] Read and parse a urlencoded request body. - This function reads the request body and parses it as application/x-www-form-urlencoded. It returns a list of key/values. - The urlencoded media type is used by Web browsers when submitting HTML forms using the POST method.</description> +Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Body, Req} Opts :: cowboy_req:read_body_opts() Body :: [{Key :: binary(), Value :: binary() | true}] Read and parse a urlencoded request body. +This function reads the request body and parses it as application/x-www-form-urlencoded. It returns a list of key/values. +The urlencoded media type is used by Web browsers when submitting HTML forms using the POST method.</description> </item> <item> @@ -5122,9 +5393,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.read_urlencoded_body/</guid> <description>Name cowboy_req:read_urlencoded_body - Read and parse a urlencoded request body - Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Body, Req} Opts :: cowboy_req:read_body_opts() Body :: [{Key :: binary(), Value :: binary() | true}] Read and parse a urlencoded request body. - This function reads the request body and parses it as application/x-www-form-urlencoded. It returns a list of key/values. - The urlencoded media type is used by Web browsers when submitting HTML forms using the POST method.</description> +Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Body, Req} Opts :: cowboy_req:read_body_opts() Body :: [{Key :: binary(), Value :: binary() | true}] Read and parse a urlencoded request body. +This function reads the request body and parses it as application/x-www-form-urlencoded. It returns a list of key/values. +The urlencoded media type is used by Web browsers when submitting HTML forms using the POST method.</description> </item> <item> @@ -5134,9 +5405,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.read_urlencoded_body/</guid> <description>Name cowboy_req:read_urlencoded_body - Read and parse a urlencoded request body - Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Body, Req} Opts :: cowboy_req:read_body_opts() Body :: [{Key :: binary(), Value :: binary() | true}] Read and parse a urlencoded request body. - This function reads the request body and parses it as application/x-www-form-urlencoded. It returns a list of key/values. - The urlencoded media type is used by Web browsers when submitting HTML forms using the POST method.</description> +Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Body, Req} Opts :: cowboy_req:read_body_opts() Body :: [{Key :: binary(), Value :: binary() | true}] Read and parse a urlencoded request body. +This function reads the request body and parses it as application/x-www-form-urlencoded. It returns a list of key/values. +The urlencoded media type is used by Web browsers when submitting HTML forms using the POST method.</description> </item> <item> @@ -5146,9 +5417,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.read_urlencoded_body/</guid> <description>Name cowboy_req:read_urlencoded_body - Read and parse a urlencoded request body - Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Body, Req} Opts :: cowboy_req:read_body_opts() Body :: [{Key :: binary(), Value :: binary() | true}] Read and parse a urlencoded request body. - This function reads the request body and parses it as application/x-www-form-urlencoded. It returns a list of key/values. - The urlencoded media type is used by Web browsers when submitting HTML forms using the POST method.</description> +Description read_urlencoded_body(Req :: cowboy_req:req()) -&gt; read_urlencoded_body(Req, #{}) read_urlencoded_body(Req :: cowboy_req:req(), Opts) -&gt; {ok, Body, Req} Opts :: cowboy_req:read_body_opts() Body :: [{Key :: binary(), Value :: binary() | true}] Read and parse a urlencoded request body. +This function reads the request body and parses it as application/x-www-form-urlencoded. It returns a list of key/values. +The urlencoded media type is used by Web browsers when submitting HTML forms using the POST method.</description> </item> <item> @@ -5158,8 +5429,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.reply/</guid> <description>Name cowboy_req:reply - Send the response - Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Body :: cowboy_req:resp_body() Send the response. - The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Body :: cowboy_req:resp_body() Send the response. +The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> </item> <item> @@ -5169,8 +5440,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.reply/</guid> <description>Name cowboy_req:reply - Send the response - Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Body :: cowboy_req:resp_body() Send the response. - The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Body :: cowboy_req:resp_body() Send the response. +The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> </item> <item> @@ -5180,8 +5451,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.reply/</guid> <description>Name cowboy_req:reply - Send the response - Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Body :: cowboy_req:resp_body() Send the response. - The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Body :: cowboy_req:resp_body() Send the response. +The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> </item> <item> @@ -5191,8 +5462,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.reply/</guid> <description>Name cowboy_req:reply - Send the response - Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Body :: cowboy_req:resp_body() Send the response. - The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Body :: cowboy_req:resp_body() Send the response. +The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> </item> <item> @@ -5202,8 +5473,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.reply/</guid> <description>Name cowboy_req:reply - Send the response - Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Body :: cowboy_req:resp_body() Send the response. - The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description reply(Status, Req :: cowboy_req:req()) -&gt; reply(StatusCode, #{}, Req) reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req reply(Status, Headers, Body, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Body :: cowboy_req:resp_body() Send the response. +The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> </item> <item> @@ -5213,9 +5484,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.resp_header/</guid> <description>Name cowboy_req:resp_header - Response header - Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given response header. - The response header must have been set previously using cowboy_req:set_resp_header(3) or cowboy_req:set_resp_headers(3). - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given response header. +The response header must have been set previously using cowboy_req:set_resp_header(3) or cowboy_req:set_resp_headers(3). +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> </item> <item> @@ -5225,9 +5496,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.resp_header/</guid> <description>Name cowboy_req:resp_header - Response header - Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given response header. - The response header must have been set previously using cowboy_req:set_resp_header(3) or cowboy_req:set_resp_headers(3). - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given response header. +The response header must have been set previously using cowboy_req:set_resp_header(3) or cowboy_req:set_resp_headers(3). +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> </item> <item> @@ -5237,9 +5508,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.resp_header/</guid> <description>Name cowboy_req:resp_header - Response header - Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given response header. - The response header must have been set previously using cowboy_req:set_resp_header(3) or cowboy_req:set_resp_headers(3). - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given response header. +The response header must have been set previously using cowboy_req:set_resp_header(3) or cowboy_req:set_resp_headers(3). +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> </item> <item> @@ -5249,9 +5520,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.resp_header/</guid> <description>Name cowboy_req:resp_header - Response header - Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given response header. - The response header must have been set previously using cowboy_req:set_resp_header(3) or cowboy_req:set_resp_headers(3). - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given response header. +The response header must have been set previously using cowboy_req:set_resp_header(3) or cowboy_req:set_resp_headers(3). +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> </item> <item> @@ -5261,9 +5532,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.resp_header/</guid> <description>Name cowboy_req:resp_header - Response header - Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given response header. - The response header must have been set previously using cowboy_req:set_resp_header(3) or cowboy_req:set_resp_headers(3). - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description resp_header(Name, Req) -&gt; resp_header(Name, Req, undefined) resp_header(Name, Req, Default) -&gt; binary() | Default Name :: binary() %% lowercase; case insensitive Req :: cowboy_req:req() Default :: any() Return the value for the given response header. +The response header must have been set previously using cowboy_req:set_resp_header(3) or cowboy_req:set_resp_headers(3). +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> </item> <item> @@ -5273,9 +5544,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.resp_headers/</guid> <description>Name cowboy_req:resp_headers - Response headers - Description resp_headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all response headers. - Arguments Req The Req object. Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. - Changelog 2.0: Function introduced. Examples Get all response headers Headers = cowboy_req:resp_headers(Req).</description> +Description resp_headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all response headers. +Arguments Req The Req object. + Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. +Changelog 2.0: Function introduced. Examples Get all response headers Headers = cowboy_req:resp_headers(Req). See also cowboy_req(3), cowboy_req:resp_header(3), cowboy_req:set_resp_header(3), cowboy_req:set_resp_headers(3)</description> </item> <item> @@ -5285,9 +5557,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.resp_headers/</guid> <description>Name cowboy_req:resp_headers - Response headers - Description resp_headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all response headers. - Arguments Req The Req object. Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. - Changelog 2.0: Function introduced. Examples Get all response headers Headers = cowboy_req:resp_headers(Req).</description> +Description resp_headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all response headers. +Arguments Req The Req object. + Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. +Changelog 2.0: Function introduced. Examples Get all response headers Headers = cowboy_req:resp_headers(Req). See also cowboy_req(3), cowboy_req:resp_header(3), cowboy_req:set_resp_header(3), cowboy_req:set_resp_headers(3)</description> </item> <item> @@ -5297,9 +5570,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.resp_headers/</guid> <description>Name cowboy_req:resp_headers - Response headers - Description resp_headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all response headers. - Arguments Req The Req object. Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. - Changelog 2.0: Function introduced. Examples Get all response headers Headers = cowboy_req:resp_headers(Req).</description> +Description resp_headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all response headers. +Arguments Req The Req object. + Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. +Changelog 2.0: Function introduced. Examples Get all response headers Headers = cowboy_req:resp_headers(Req). See also cowboy_req(3), cowboy_req:resp_header(3), cowboy_req:set_resp_header(3), cowboy_req:set_resp_headers(3)</description> </item> <item> @@ -5309,9 +5583,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.resp_headers/</guid> <description>Name cowboy_req:resp_headers - Response headers - Description resp_headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all response headers. - Arguments Req The Req object. Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. - Changelog 2.0: Function introduced. Examples Get all response headers Headers = cowboy_req:resp_headers(Req).</description> +Description resp_headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all response headers. +Arguments Req The Req object. + Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. +Changelog 2.0: Function introduced. Examples Get all response headers Headers = cowboy_req:resp_headers(Req). See also cowboy_req(3), cowboy_req:resp_header(3), cowboy_req:set_resp_header(3), cowboy_req:set_resp_headers(3)</description> </item> <item> @@ -5321,9 +5596,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.resp_headers/</guid> <description>Name cowboy_req:resp_headers - Response headers - Description resp_headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all response headers. - Arguments Req The Req object. Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. - Changelog 2.0: Function introduced. Examples Get all response headers Headers = cowboy_req:resp_headers(Req).</description> +Description resp_headers(Req :: cowboy_req:req()) -&gt; cowboy:http_headers() Return all response headers. +Arguments Req The Req object. + Return value Headers are returned as a map with keys being lowercase binary strings, and values as binary strings. +Changelog 2.0: Function introduced. Examples Get all response headers Headers = cowboy_req:resp_headers(Req). See also cowboy_req(3), cowboy_req:resp_header(3), cowboy_req:set_resp_header(3), cowboy_req:set_resp_headers(3)</description> </item> <item> @@ -5333,10 +5609,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.scheme/</guid> <description>Name cowboy_req:scheme - URI scheme - Description scheme(Req :: cowboy_req:req()) -&gt; Scheme :: binary() Return the scheme of the effective request URI. - The scheme can also be obtained using pattern matching: - #{scheme := Scheme} = Req. Arguments Req The Req object. Return value The scheme is returned as a binary. It is case insensitive. - Cowboy will only set the scheme to &lt;&lt;"</description> +Description scheme(Req :: cowboy_req:req()) -&gt; Scheme :: binary() Return the scheme of the effective request URI. +The scheme can also be obtained using pattern matching: +#{scheme := Scheme} = Req. Arguments Req The Req object. + Return value The scheme is returned as a binary. It is case insensitive. +Cowboy will only set the scheme to &lt;&lt;&quot;http&quot;&gt;&gt; or &lt;&lt;&quot;https&quot;&gt;&gt;. +Changelog 2.0: Function introduced.</description> </item> <item> @@ -5346,10 +5624,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.scheme/</guid> <description>Name cowboy_req:scheme - URI scheme - Description scheme(Req :: cowboy_req:req()) -&gt; Scheme :: binary() Return the scheme of the effective request URI. - The scheme can also be obtained using pattern matching: - #{scheme := Scheme} = Req. Arguments Req The Req object. Return value The scheme is returned as a binary. It is case insensitive. - Cowboy will only set the scheme to &lt;&lt;"</description> +Description scheme(Req :: cowboy_req:req()) -&gt; Scheme :: binary() Return the scheme of the effective request URI. +The scheme can also be obtained using pattern matching: +#{scheme := Scheme} = Req. Arguments Req The Req object. + Return value The scheme is returned as a binary. It is case insensitive. +Cowboy will only set the scheme to &lt;&lt;&quot;http&quot;&gt;&gt; or &lt;&lt;&quot;https&quot;&gt;&gt;. +Changelog 2.0: Function introduced.</description> </item> <item> @@ -5359,10 +5639,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.scheme/</guid> <description>Name cowboy_req:scheme - URI scheme - Description scheme(Req :: cowboy_req:req()) -&gt; Scheme :: binary() Return the scheme of the effective request URI. - The scheme can also be obtained using pattern matching: - #{scheme := Scheme} = Req. Arguments Req The Req object. Return value The scheme is returned as a binary. It is case insensitive. - Cowboy will only set the scheme to &lt;&lt;"</description> +Description scheme(Req :: cowboy_req:req()) -&gt; Scheme :: binary() Return the scheme of the effective request URI. +The scheme can also be obtained using pattern matching: +#{scheme := Scheme} = Req. Arguments Req The Req object. + Return value The scheme is returned as a binary. It is case insensitive. +Cowboy will only set the scheme to &lt;&lt;&quot;http&quot;&gt;&gt; or &lt;&lt;&quot;https&quot;&gt;&gt;. +Changelog 2.0: Function introduced.</description> </item> <item> @@ -5372,10 +5654,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.scheme/</guid> <description>Name cowboy_req:scheme - URI scheme - Description scheme(Req :: cowboy_req:req()) -&gt; Scheme :: binary() Return the scheme of the effective request URI. - The scheme can also be obtained using pattern matching: - #{scheme := Scheme} = Req. Arguments Req The Req object. Return value The scheme is returned as a binary. It is case insensitive. - Cowboy will only set the scheme to &lt;&lt;"</description> +Description scheme(Req :: cowboy_req:req()) -&gt; Scheme :: binary() Return the scheme of the effective request URI. +The scheme can also be obtained using pattern matching: +#{scheme := Scheme} = Req. Arguments Req The Req object. + Return value The scheme is returned as a binary. It is case insensitive. +Cowboy will only set the scheme to &lt;&lt;&quot;http&quot;&gt;&gt; or &lt;&lt;&quot;https&quot;&gt;&gt;. +Changelog 2.0: Function introduced.</description> </item> <item> @@ -5385,10 +5669,12 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.scheme/</guid> <description>Name cowboy_req:scheme - URI scheme - Description scheme(Req :: cowboy_req:req()) -&gt; Scheme :: binary() Return the scheme of the effective request URI. - The scheme can also be obtained using pattern matching: - #{scheme := Scheme} = Req. Arguments Req The Req object. Return value The scheme is returned as a binary. It is case insensitive. - Cowboy will only set the scheme to &lt;&lt;"</description> +Description scheme(Req :: cowboy_req:req()) -&gt; Scheme :: binary() Return the scheme of the effective request URI. +The scheme can also be obtained using pattern matching: +#{scheme := Scheme} = Req. Arguments Req The Req object. + Return value The scheme is returned as a binary. It is case insensitive. +Cowboy will only set the scheme to &lt;&lt;&quot;http&quot;&gt;&gt; or &lt;&lt;&quot;https&quot;&gt;&gt;. +Changelog 2.0: Function introduced.</description> </item> <item> @@ -5398,9 +5684,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_body/</guid> <description>Name cowboy_req:set_resp_body - Set the response body - Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; Req Body :: cowboy_req:resp_body() Set the response body. - The response body will be sent when a reply is initiated. Note that the functions stream_reply/2,3 and reply/4 will override the body set by this function. - This function can also be used to remove a response body that was set previously. To do so, simply call this function with an empty body.</description> +Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; Req Body :: cowboy_req:resp_body() Set the response body. +The response body will be sent when a reply is initiated. Note that the functions stream_reply/2,3 and reply/4 will override the body set by this function. +This function can also be used to remove a response body that was set previously. To do so, simply call this function with an empty body.</description> </item> <item> @@ -5410,9 +5696,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_body/</guid> <description>Name cowboy_req:set_resp_body - Set the response body - Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; Req Body :: cowboy_req:resp_body() Set the response body. - The response body will be sent when a reply is initiated. Note that the functions stream_reply/2,3 and reply/4 will override the body set by this function. - This function can also be used to remove a response body that was set previously. To do so, simply call this function with an empty body.</description> +Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; Req Body :: cowboy_req:resp_body() Set the response body. +The response body will be sent when a reply is initiated. Note that the functions stream_reply/2,3 and reply/4 will override the body set by this function. +This function can also be used to remove a response body that was set previously. To do so, simply call this function with an empty body.</description> </item> <item> @@ -5422,9 +5708,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_body/</guid> <description>Name cowboy_req:set_resp_body - Set the response body - Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; Req Body :: cowboy_req:resp_body() Set the response body. - The response body will be sent when a reply is initiated. Note that the functions stream_reply/2,3 and reply/4 will override the body set by this function. - This function can also be used to remove a response body that was set previously. To do so, simply call this function with an empty body.</description> +Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; Req Body :: cowboy_req:resp_body() Set the response body. +The response body will be sent when a reply is initiated. Note that the functions stream_reply/2,3 and reply/4 will override the body set by this function. +This function can also be used to remove a response body that was set previously. To do so, simply call this function with an empty body.</description> </item> <item> @@ -5434,9 +5720,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_body/</guid> <description>Name cowboy_req:set_resp_body - Set the response body - Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; Req Body :: cowboy_req:resp_body() Set the response body. - The response body will be sent when a reply is initiated. Note that the functions stream_reply/2,3 and reply/4 will override the body set by this function. - This function can also be used to remove a response body that was set previously. To do so, simply call this function with an empty body.</description> +Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; Req Body :: cowboy_req:resp_body() Set the response body. +The response body will be sent when a reply is initiated. Note that the functions stream_reply/2,3 and reply/4 will override the body set by this function. +This function can also be used to remove a response body that was set previously. To do so, simply call this function with an empty body.</description> </item> <item> @@ -5446,9 +5732,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_body/</guid> <description>Name cowboy_req:set_resp_body - Set the response body - Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; Req Body :: cowboy_req:resp_body() Set the response body. - The response body will be sent when a reply is initiated. Note that the functions stream_reply/2,3 and reply/4 will override the body set by this function. - This function can also be used to remove a response body that was set previously. To do so, simply call this function with an empty body.</description> +Description set_resp_body(Body, Req :: cowboy_req:req()) -&gt; Req Body :: cowboy_req:resp_body() Set the response body. +The response body will be sent when a reply is initiated. Note that the functions stream_reply/2,3 and reply/4 will override the body set by this function. +This function can also be used to remove a response body that was set previously. To do so, simply call this function with an empty body.</description> </item> <item> @@ -5458,9 +5744,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_cookie/</guid> <description>Name cowboy_req:set_resp_cookie - Set a cookie - Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, [], Req) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; Req Name :: binary() %% case sensitive Value :: iodata() %% case sensitive Opts :: cow_cookie:cookie_opts() Set a cookie to be sent with the response. - Note that cookie names are case sensitive. - Arguments Name Cookie name.</description> +Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, [], Req) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; Req Name :: binary() %% case sensitive Value :: iodata() %% case sensitive Opts :: cow_cookie:cookie_opts() Set a cookie to be sent with the response. +Note that cookie names are case sensitive. +Arguments Name Cookie name. + Value Cookie value. + Req The Req object.</description> </item> <item> @@ -5470,9 +5758,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_cookie/</guid> <description>Name cowboy_req:set_resp_cookie - Set a cookie - Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, [], Req) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; Req Name :: binary() %% case sensitive Value :: iodata() %% case sensitive Opts :: cow_cookie:cookie_opts() Set a cookie to be sent with the response. - Note that cookie names are case sensitive. - Arguments Name Cookie name.</description> +Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, [], Req) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; Req Name :: binary() %% case sensitive Value :: iodata() %% case sensitive Opts :: cow_cookie:cookie_opts() Set a cookie to be sent with the response. +Note that cookie names are case sensitive. +Arguments Name Cookie name. + Value Cookie value. + Req The Req object.</description> </item> <item> @@ -5482,9 +5772,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_cookie/</guid> <description>Name cowboy_req:set_resp_cookie - Set a cookie - Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, [], Req) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; Req Name :: binary() %% case sensitive Value :: iodata() %% case sensitive Opts :: cow_cookie:cookie_opts() Set a cookie to be sent with the response. - Note that cookie names are case sensitive. - Arguments Name Cookie name.</description> +Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, [], Req) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; Req Name :: binary() %% case sensitive Value :: iodata() %% case sensitive Opts :: cow_cookie:cookie_opts() Set a cookie to be sent with the response. +Note that cookie names are case sensitive. +Arguments Name Cookie name. + Value Cookie value. + Req The Req object.</description> </item> <item> @@ -5494,9 +5786,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_cookie/</guid> <description>Name cowboy_req:set_resp_cookie - Set a cookie - Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, [], Req) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; Req Name :: binary() %% case sensitive Value :: iodata() %% case sensitive Opts :: cow_cookie:cookie_opts() Set a cookie to be sent with the response. - Note that cookie names are case sensitive. - Arguments Name Cookie name.</description> +Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, [], Req) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; Req Name :: binary() %% case sensitive Value :: iodata() %% case sensitive Opts :: cow_cookie:cookie_opts() Set a cookie to be sent with the response. +Note that cookie names are case sensitive. +Arguments Name Cookie name. + Value Cookie value. + Req The Req object.</description> </item> <item> @@ -5506,9 +5800,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_cookie/</guid> <description>Name cowboy_req:set_resp_cookie - Set a cookie - Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, [], Req) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; Req Name :: binary() %% case sensitive Value :: iodata() %% case sensitive Opts :: cow_cookie:cookie_opts() Set a cookie to be sent with the response. - Note that cookie names are case sensitive. - Arguments Name Cookie name.</description> +Description set_resp_cookie(Name, Value, Req :: cowboy_req:req()) -&gt; set_resp_cookie(Name, Value, [], Req) set_resp_cookie(Name, Value, Req :: cowboy_req:req(), Opts) -&gt; Req Name :: binary() %% case sensitive Value :: iodata() %% case sensitive Opts :: cow_cookie:cookie_opts() Set a cookie to be sent with the response. +Note that cookie names are case sensitive. +Arguments Name Cookie name. + Value Cookie value. + Req The Req object.</description> </item> <item> @@ -5518,8 +5814,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_header/</guid> <description>Name cowboy_req:set_resp_header - Set a response header - Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Value :: iodata() %% case depends on header Set a header to be sent with the response. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Value :: iodata() %% case depends on header Set a header to be sent with the response. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names.</description> </item> <item> @@ -5529,8 +5826,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_header/</guid> <description>Name cowboy_req:set_resp_header - Set a response header - Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Value :: iodata() %% case depends on header Set a header to be sent with the response. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Value :: iodata() %% case depends on header Set a header to be sent with the response. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names.</description> </item> <item> @@ -5540,8 +5838,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_header/</guid> <description>Name cowboy_req:set_resp_header - Set a response header - Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Value :: iodata() %% case depends on header Set a header to be sent with the response. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Value :: iodata() %% case depends on header Set a header to be sent with the response. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names.</description> </item> <item> @@ -5551,8 +5850,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_header/</guid> <description>Name cowboy_req:set_resp_header - Set a response header - Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Value :: iodata() %% case depends on header Set a header to be sent with the response. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Value :: iodata() %% case depends on header Set a header to be sent with the response. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names.</description> </item> <item> @@ -5562,8 +5862,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_header/</guid> <description>Name cowboy_req:set_resp_header - Set a response header - Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Value :: iodata() %% case depends on header Set a header to be sent with the response. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly.</description> +Description set_resp_header(Name, Value, Req :: cowboy_req:req()) -&gt; Req Name :: binary() %% lowercase; case insensitive Value :: iodata() %% case depends on header Set a header to be sent with the response. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names.</description> </item> <item> @@ -5573,9 +5874,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_headers/</guid> <description>Name cowboy_req:set_resp_headers - Set several response headers - Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; Req Headers :: cowboy:http_headers() Set several headers to be sent with the response. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Cowboy does not allow duplicate header names. Headers set by this function may be overwritten by those set from the reply functions.</description> +Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; Req Headers :: cowboy:http_headers() Set several headers to be sent with the response. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names. Headers set by this function may be overwritten by those set from the reply functions.</description> </item> <item> @@ -5585,9 +5886,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.set_resp_headers/</guid> <description>Name cowboy_req:set_resp_headers - Set several response headers - Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; Req Headers :: cowboy:http_headers() Set several headers to be sent with the response. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Cowboy does not allow duplicate header names. Headers set by this function may be overwritten by those set from the reply functions.</description> +Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; Req Headers :: cowboy:http_headers() Set several headers to be sent with the response. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names. Headers set by this function may be overwritten by those set from the reply functions.</description> </item> <item> @@ -5597,9 +5898,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.set_resp_headers/</guid> <description>Name cowboy_req:set_resp_headers - Set several response headers - Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; Req Headers :: cowboy:http_headers() Set several headers to be sent with the response. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Cowboy does not allow duplicate header names. Headers set by this function may be overwritten by those set from the reply functions.</description> +Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; Req Headers :: cowboy:http_headers() Set several headers to be sent with the response. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names. Headers set by this function may be overwritten by those set from the reply functions.</description> </item> <item> @@ -5609,9 +5910,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.set_resp_headers/</guid> <description>Name cowboy_req:set_resp_headers - Set several response headers - Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; Req Headers :: cowboy:http_headers() Set several headers to be sent with the response. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Cowboy does not allow duplicate header names. Headers set by this function may be overwritten by those set from the reply functions.</description> +Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; Req Headers :: cowboy:http_headers() Set several headers to be sent with the response. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names. Headers set by this function may be overwritten by those set from the reply functions.</description> </item> <item> @@ -5621,9 +5922,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.set_resp_headers/</guid> <description>Name cowboy_req:set_resp_headers - Set several response headers - Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; Req Headers :: cowboy:http_headers() Set several headers to be sent with the response. - The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Cowboy does not allow duplicate header names. Headers set by this function may be overwritten by those set from the reply functions.</description> +Description set_resp_headers(Headers, Req :: cowboy_req:req()) -&gt; Req Headers :: cowboy:http_headers() Set several headers to be sent with the response. +The header name must be given as a lowercase binary string. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names. Headers set by this function may be overwritten by those set from the reply functions.</description> </item> <item> @@ -5633,9 +5934,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.sock/</guid> <description>Name cowboy_req:sock - Socket address and port - Description sock(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the socket&#8217;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&#8217;s local IP address and port number.</description> +Description sock(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the socket&apos;s IP address and port number. +The socket information can also be obtained using pattern matching: +#{sock := {IP, Port}} = Req. Arguments Req The Req object. + Return value The socket&apos;s local IP address and port number. +Changelog 2.1: Function introduced. Examples Get the socket&apos;s IP address and port number.</description> </item> <item> @@ -5645,9 +5948,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.sock/</guid> <description>Name cowboy_req:sock - Socket address and port - Description sock(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the socket&#8217;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&#8217;s local IP address and port number.</description> +Description sock(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the socket&apos;s IP address and port number. +The socket information can also be obtained using pattern matching: +#{sock := {IP, Port}} = Req. Arguments Req The Req object. + Return value The socket&apos;s local IP address and port number. +Changelog 2.1: Function introduced. Examples Get the socket&apos;s IP address and port number.</description> </item> <item> @@ -5657,9 +5962,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.sock/</guid> <description>Name cowboy_req:sock - Socket address and port - Description sock(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the socket&#8217;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&#8217;s local IP address and port number.</description> +Description sock(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the socket&apos;s IP address and port number. +The socket information can also be obtained using pattern matching: +#{sock := {IP, Port}} = Req. Arguments Req The Req object. + Return value The socket&apos;s local IP address and port number. +Changelog 2.1: Function introduced. Examples Get the socket&apos;s IP address and port number.</description> </item> <item> @@ -5669,9 +5976,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.sock/</guid> <description>Name cowboy_req:sock - Socket address and port - Description sock(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the socket&#8217;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&#8217;s local IP address and port number.</description> +Description sock(Req :: cowboy_req:req()) -&gt; Info Info :: {inet:ip_address(), inet:port_number()} Return the socket&apos;s IP address and port number. +The socket information can also be obtained using pattern matching: +#{sock := {IP, Port}} = Req. Arguments Req The Req object. + Return value The socket&apos;s local IP address and port number. +Changelog 2.1: Function introduced. Examples Get the socket&apos;s IP address and port number.</description> </item> <item> @@ -5681,9 +5990,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.stream_body/</guid> <description>Name cowboy_req:stream_body - Stream the response body - Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; ok Data :: iodata() IsFin :: fin | nofin Stream the response body. - This function may be called as many times as needed after initiating a response using the cowboy_req:stream_reply(3) function. - The second argument indicates if this call is the final call. Use the nofin value until you know no more data will be sent.</description> +Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; ok Data :: iodata() IsFin :: fin | nofin Stream the response body. +This function may be called as many times as needed after initiating a response using the cowboy_req:stream_reply(3) function. +The second argument indicates if this call is the final call. Use the nofin value until you know no more data will be sent. The final call should use fin (possibly with an empty data value).</description> </item> <item> @@ -5693,9 +6002,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.stream_body/</guid> <description>Name cowboy_req:stream_body - Stream the response body - Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; ok Data :: iodata() IsFin :: fin | nofin Stream the response body. - This function may be called as many times as needed after initiating a response using the cowboy_req:stream_reply(3) function. - The second argument indicates if this call is the final call. Use the nofin value until you know no more data will be sent.</description> +Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; ok Data :: iodata() IsFin :: fin | nofin Stream the response body. +This function may be called as many times as needed after initiating a response using the cowboy_req:stream_reply(3) function. +The second argument indicates if this call is the final call. Use the nofin value until you know no more data will be sent. The final call should use fin (possibly with an empty data value).</description> </item> <item> @@ -5705,9 +6014,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.stream_body/</guid> <description>Name cowboy_req:stream_body - Stream the response body - Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; ok Data :: iodata() IsFin :: fin | nofin Stream the response body. - This function may be called as many times as needed after initiating a response using the cowboy_req:stream_reply(3) function. - The second argument indicates if this call is the final call. Use the nofin value until you know no more data will be sent.</description> +Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; ok Data :: iodata() IsFin :: fin | nofin Stream the response body. +This function may be called as many times as needed after initiating a response using the cowboy_req:stream_reply(3) function. +The second argument indicates if this call is the final call. Use the nofin value until you know no more data will be sent. The final call should use fin (possibly with an empty data value) or be a call to the cowboy_req:stream_trailers(3) function.</description> </item> <item> @@ -5717,9 +6026,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.stream_body/</guid> <description>Name cowboy_req:stream_body - Stream the response body - Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; ok Data :: iodata() IsFin :: fin | nofin Stream the response body. - This function may be called as many times as needed after initiating a response using the cowboy_req:stream_reply(3) function. - The second argument indicates if this call is the final call. Use the nofin value until you know no more data will be sent.</description> +Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; ok Data :: iodata() IsFin :: fin | nofin Stream the response body. +This function may be called as many times as needed after initiating a response using the cowboy_req:stream_reply(3) function. +The second argument indicates if this call is the final call. Use the nofin value until you know no more data will be sent. The final call should use fin (possibly with an empty data value) or be a call to the cowboy_req:stream_trailers(3) function.</description> </item> <item> @@ -5729,9 +6038,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.stream_body/</guid> <description>Name cowboy_req:stream_body - Stream the response body - Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; ok Data :: iodata() IsFin :: fin | nofin Stream the response body. - This function may be called as many times as needed after initiating a response using the cowboy_req:stream_reply(3) function. - The second argument indicates if this call is the final call. Use the nofin value until you know no more data will be sent.</description> +Description stream_body(Data, IsFin, Req :: cowboy_req:req()) -&gt; ok Data :: iodata() IsFin :: fin | nofin Stream the response body. +This function may be called as many times as needed after initiating a response using the cowboy_req:stream_reply(3) function. +The second argument indicates if this call is the final call. Use the nofin value until you know no more data will be sent. The final call should use fin (possibly with an empty data value) or be a call to the cowboy_req:stream_trailers(3) function.</description> </item> <item> @@ -5741,9 +6050,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.stream_reply/</guid> <description>Name cowboy_req:stream_reply - Send the response headers - Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send the response headers. - The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Cowboy does not allow duplicate header names.</description> +Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send the response headers. +The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names. Headers set by this function may overwrite those set by set_resp_header/3.</description> </item> <item> @@ -5753,9 +6062,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.stream_reply/</guid> <description>Name cowboy_req:stream_reply - Send the response headers - Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send the response headers. - The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Cowboy does not allow duplicate header names.</description> +Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send the response headers. +The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names. Headers set by this function may overwrite those set by set_resp_header/3.</description> </item> <item> @@ -5765,9 +6074,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.stream_reply/</guid> <description>Name cowboy_req:stream_reply - Send the response headers - Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send the response headers. - The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Cowboy does not allow duplicate header names.</description> +Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send the response headers. +The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names. Headers set by this function may overwrite those set by set_resp_header/3.</description> </item> <item> @@ -5777,9 +6086,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.stream_reply/</guid> <description>Name cowboy_req:stream_reply - Send the response headers - Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send the response headers. - The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Cowboy does not allow duplicate header names.</description> +Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send the response headers. +The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names. Headers set by this function may overwrite those set by set_resp_header/3.</description> </item> <item> @@ -5789,9 +6098,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.stream_reply/</guid> <description>Name cowboy_req:stream_reply - Send the response headers - Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send the response headers. - The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. - Cowboy does not allow duplicate header names.</description> +Description stream_reply(Status, Req :: cowboy_req:req()) -&gt; stream_reply(StatusCode, #{}, Req) stream_reply(Status, Headers, Req :: cowboy_req:req()) -&gt; Req Status :: cowboy:http_status() Headers :: cowboy:http_headers() Send the response headers. +The header names must be given as lowercase binary strings. While header names are case insensitive, Cowboy requires them to be given as lowercase to function properly. +Cowboy does not allow duplicate header names. Headers set by this function may overwrite those set by set_resp_header/3.</description> </item> <item> @@ -5801,9 +6110,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.stream_trailers/</guid> <description>Name cowboy_req:stream_trailers - Send the response trailers - Description stream_trailers(Trailers, Req :: cowboy_req:req()) -&gt; ok Trailers :: cowboy:http_headers() Send the response trailers and terminate the stream. - This function can only be called once, after initiating a response using cowboy_req:stream_reply(3) and sending zero or more body chunks using cowboy_req:stream_body(3) with the nofin argument set. The function stream_trailers/2 implies fin and automatically terminate the response. - You must list all field names sent in trailers in the trailer header, otherwise they might be dropped by intermediaries or clients.</description> +Description stream_trailers(Trailers, Req :: cowboy_req:req()) -&gt; ok Trailers :: cowboy:http_headers() Send the response trailers and terminate the stream. +This function can only be called once, after initiating a response using cowboy_req:stream_reply(3) and sending zero or more body chunks using cowboy_req:stream_body(3) with the nofin argument set. The function stream_trailers/2 implies fin and automatically terminate the response. +You must list all field names sent in trailers in the trailer header, otherwise they might be dropped by intermediaries or clients.</description> </item> <item> @@ -5813,9 +6122,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.stream_trailers/</guid> <description>Name cowboy_req:stream_trailers - Send the response trailers - Description stream_trailers(Trailers, Req :: cowboy_req:req()) -&gt; ok Trailers :: cowboy:http_headers() Send the response trailers and terminate the stream. - This function can only be called once, after initiating a response using cowboy_req:stream_reply(3) and sending zero or more body chunks using cowboy_req:stream_body(3) with the nofin argument set. The function stream_trailers/2 implies fin and automatically terminate the response. - You must list all field names sent in trailers in the trailer header, otherwise they might be dropped by intermediaries or clients.</description> +Description stream_trailers(Trailers, Req :: cowboy_req:req()) -&gt; ok Trailers :: cowboy:http_headers() Send the response trailers and terminate the stream. +This function can only be called once, after initiating a response using cowboy_req:stream_reply(3) and sending zero or more body chunks using cowboy_req:stream_body(3) with the nofin argument set. The function stream_trailers/2 implies fin and automatically terminate the response. +You must list all field names sent in trailers in the trailer header, otherwise they might be dropped by intermediaries or clients.</description> </item> <item> @@ -5825,9 +6134,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.stream_trailers/</guid> <description>Name cowboy_req:stream_trailers - Send the response trailers - Description stream_trailers(Trailers, Req :: cowboy_req:req()) -&gt; ok Trailers :: cowboy:http_headers() Send the response trailers and terminate the stream. - This function can only be called once, after initiating a response using cowboy_req:stream_reply(3) and sending zero or more body chunks using cowboy_req:stream_body(3) with the nofin argument set. The function stream_trailers/2 implies fin and automatically terminate the response. - You must list all field names sent in trailers in the trailer header, otherwise they might be dropped by intermediaries or clients.</description> +Description stream_trailers(Trailers, Req :: cowboy_req:req()) -&gt; ok Trailers :: cowboy:http_headers() Send the response trailers and terminate the stream. +This function can only be called once, after initiating a response using cowboy_req:stream_reply(3) and sending zero or more body chunks using cowboy_req:stream_body(3) with the nofin argument set. The function stream_trailers/2 implies fin and automatically terminate the response. +You must list all field names sent in trailers in the trailer header, otherwise they might be dropped by intermediaries or clients.</description> </item> <item> @@ -5837,8 +6146,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.uri/</guid> <description>Name cowboy_req:uri - Reconstructed URI - Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. - By default Cowboy will build a URI using the components found in the request.</description> +Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. +By default Cowboy will build a URI using the components found in the request.</description> </item> <item> @@ -5848,8 +6157,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.uri/</guid> <description>Name cowboy_req:uri - Reconstructed URI - Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. - By default Cowboy will build a URI using the components found in the request.</description> +Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. +By default Cowboy will build a URI using the components found in the request.</description> </item> <item> @@ -5859,8 +6168,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.uri/</guid> <description>Name cowboy_req:uri - Reconstructed URI - Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. - By default Cowboy will build a URI using the components found in the request.</description> +Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. +By default Cowboy will build a URI using the components found in the request.</description> </item> <item> @@ -5870,8 +6179,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.uri/</guid> <description>Name cowboy_req:uri - Reconstructed URI - Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. - By default Cowboy will build a URI using the components found in the request.</description> +Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. +By default Cowboy will build a URI using the components found in the request.</description> </item> <item> @@ -5881,8 +6190,8 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.uri/</guid> <description>Name cowboy_req:uri - Reconstructed URI - Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. - By default Cowboy will build a URI using the components found in the request.</description> +Description uri(Req :: cowboy_req:req()) -&gt; uri(Req, #{}) uri(Req :: cowboy_req:req(), Opts) -&gt; URI :: iodata() Opts :: #{ scheme =&gt; iodata() | undefined, host =&gt; iodata() | undefined, port =&gt; inet:port_number() | undefined, path =&gt; iodata() | undefined, qs =&gt; iodata() | undefined, fragment =&gt; iodata() | undefined } Reconstruct the effective request URI, optionally modifying components. +By default Cowboy will build a URI using the components found in the request.</description> </item> <item> @@ -5892,9 +6201,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.version/</guid> <description>Name cowboy_req:version - HTTP version - Description version(Req :: cowboy_req:req()) -&gt; Version :: cowboy:http_version() Return the HTTP version used for the request. - The version can also be obtained using pattern matching: - #{version := Version} = Req. Arguments Req The Req object. Return value The HTTP version used for the request is returned as an atom. It is provided for informative purposes only.</description> +Description version(Req :: cowboy_req:req()) -&gt; Version :: cowboy:http_version() Return the HTTP version used for the request. +The version can also be obtained using pattern matching: +#{version := Version} = Req. Arguments Req The Req object. + Return value The HTTP version used for the request is returned as an atom. It is provided for informative purposes only. +Changelog 2.0: Only the version is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -5904,9 +6215,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_req.version/</guid> <description>Name cowboy_req:version - HTTP version - Description version(Req :: cowboy_req:req()) -&gt; Version :: cowboy:http_version() Return the HTTP version used for the request. - The version can also be obtained using pattern matching: - #{version := Version} = Req. Arguments Req The Req object. Return value The HTTP version used for the request is returned as an atom. It is provided for informative purposes only.</description> +Description version(Req :: cowboy_req:req()) -&gt; Version :: cowboy:http_version() Return the HTTP version used for the request. +The version can also be obtained using pattern matching: +#{version := Version} = Req. Arguments Req The Req object. + Return value The HTTP version used for the request is returned as an atom. It is provided for informative purposes only. +Changelog 2.0: Only the version is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -5916,9 +6229,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_req.version/</guid> <description>Name cowboy_req:version - HTTP version - Description version(Req :: cowboy_req:req()) -&gt; Version :: cowboy:http_version() Return the HTTP version used for the request. - The version can also be obtained using pattern matching: - #{version := Version} = Req. Arguments Req The Req object. Return value The HTTP version used for the request is returned as an atom. It is provided for informative purposes only.</description> +Description version(Req :: cowboy_req:req()) -&gt; Version :: cowboy:http_version() Return the HTTP version used for the request. +The version can also be obtained using pattern matching: +#{version := Version} = Req. Arguments Req The Req object. + Return value The HTTP version used for the request is returned as an atom. It is provided for informative purposes only. +Changelog 2.0: Only the version is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -5928,9 +6243,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_req.version/</guid> <description>Name cowboy_req:version - HTTP version - Description version(Req :: cowboy_req:req()) -&gt; Version :: cowboy:http_version() Return the HTTP version used for the request. - The version can also be obtained using pattern matching: - #{version := Version} = Req. Arguments Req The Req object. Return value The HTTP version used for the request is returned as an atom. It is provided for informative purposes only.</description> +Description version(Req :: cowboy_req:req()) -&gt; Version :: cowboy:http_version() Return the HTTP version used for the request. +The version can also be obtained using pattern matching: +#{version := Version} = Req. Arguments Req The Req object. + Return value The HTTP version used for the request is returned as an atom. It is provided for informative purposes only. +Changelog 2.0: Only the version is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -5940,9 +6257,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_req.version/</guid> <description>Name cowboy_req:version - HTTP version - Description version(Req :: cowboy_req:req()) -&gt; Version :: cowboy:http_version() Return the HTTP version used for the request. - The version can also be obtained using pattern matching: - #{version := Version} = Req. Arguments Req The Req object. Return value The HTTP version used for the request is returned as an atom. It is provided for informative purposes only.</description> +Description version(Req :: cowboy_req:req()) -&gt; Version :: cowboy:http_version() Return the HTTP version used for the request. +The version can also be obtained using pattern matching: +#{version := Version} = Req. Arguments Req The Req object. + Return value The HTTP version used for the request is returned as an atom. It is provided for informative purposes only. +Changelog 2.0: Only the version is returned, it is no longer wrapped in a tuple.</description> </item> <item> @@ -5952,10 +6271,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_rest/</guid> <description>Name cowboy_rest - REST handlers - Description The module cowboy_rest implements the HTTP state machine. - Implementing REST handlers is not enough to provide a REST interface; this interface must also follow the REST constraints including HATEOAS (hypermedia as the engine of application state). - Callbacks REST handlers implement the following interface: - init(Req, State) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} terminate(Reason, Req, State) -&gt; ok %% optional Req :: cowboy_req:req() State :: 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.</description> +Description The module cowboy_rest implements the HTTP state machine. +Implementing REST handlers is not enough to provide a REST interface; this interface must also follow the REST constraints including HATEOAS (hypermedia as the engine of application state). +Callbacks REST handlers implement the following interface: +init(Req, State) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} terminate(Reason, Req, State) -&gt; ok %% optional Req :: cowboy_req:req() State :: 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.</description> </item> <item> @@ -5965,10 +6284,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_rest/</guid> <description>Name cowboy_rest - REST handlers - Description The module cowboy_rest implements the HTTP state machine. - Implementing REST handlers is not enough to provide a REST interface; this interface must also follow the REST constraints including HATEOAS (hypermedia as the engine of application state). - Callbacks REST handlers implement the following interface: - init(Req, State) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} | {{switch_handler, Module}, Req, State} | {{switch_handler, Module, Opts}, Req, State} terminate(Reason, Req, State) -&gt; ok %% optional Req :: cowboy_req:req() State :: any() Module :: module() Opts :: any() Reason :: normal | {crash, error | exit | throw, any()} Callback - see below Result - see below Default - see below The init/2 callback is common to all handlers.</description> +Description The module cowboy_rest implements the HTTP state machine. +Implementing REST handlers is not enough to provide a REST interface; this interface must also follow the REST constraints including HATEOAS (hypermedia as the engine of application state). +Callbacks REST handlers implement the following interface: +init(Req, State) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} | {{switch_handler, Module}, Req, State} | {{switch_handler, Module, Opts}, Req, State} terminate(Reason, Req, State) -&gt; ok %% optional Req :: cowboy_req:req() State :: any() Module :: module() Opts :: any() Reason :: normal | {crash, error | exit | throw, any()} Callback - see below Result - see below Default - see below The init/2 callback is common to all handlers.</description> </item> <item> @@ -5978,10 +6297,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_rest/</guid> <description>Name cowboy_rest - REST handlers - Description The module cowboy_rest implements the HTTP state machine. - Implementing REST handlers is not enough to provide a REST interface; this interface must also follow the REST constraints including HATEOAS (hypermedia as the engine of application state). - Callbacks REST handlers implement the following interface: - init(Req, State) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} | {{switch_handler, Module}, Req, State} | {{switch_handler, Module, Opts}, Req, State} terminate(Reason, Req, State) -&gt; ok %% optional Req :: cowboy_req:req() State :: any() Module :: module() Opts :: any() Reason :: normal | {crash, error | exit | throw, any()} Callback - see below Result - see below Default - see below The init/2 callback is common to all handlers.</description> +Description The module cowboy_rest implements the HTTP state machine. +Implementing REST handlers is not enough to provide a REST interface; this interface must also follow the REST constraints including HATEOAS (hypermedia as the engine of application state). +Callbacks REST handlers implement the following interface: +init(Req, State) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} | {{switch_handler, Module}, Req, State} | {{switch_handler, Module, Opts}, Req, State} terminate(Reason, Req, State) -&gt; ok %% optional Req :: cowboy_req:req() State :: any() Module :: module() Opts :: any() Reason :: normal | {crash, error | exit | throw, any()} Callback - see below Result - see below Default - see below The init/2 callback is common to all handlers.</description> </item> <item> @@ -5991,10 +6310,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_rest/</guid> <description>Name cowboy_rest - REST handlers - Description The module cowboy_rest implements the HTTP state machine. - Implementing REST handlers is not enough to provide a REST interface; this interface must also follow the REST constraints including HATEOAS (hypermedia as the engine of application state). - Callbacks REST handlers implement the following interface: - init(Req, State) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} | {{switch_handler, Module}, Req, State} | {{switch_handler, Module, Opts}, Req, State} terminate(Reason, Req, State) -&gt; ok %% optional Req :: cowboy_req:req() State :: any() Module :: module() Opts :: any() Reason :: normal | {crash, error | exit | throw, any()} Callback - see below Result - see below Default - see below The init/2 callback is common to all handlers.</description> +Description The module cowboy_rest implements the HTTP state machine. +Implementing REST handlers is not enough to provide a REST interface; this interface must also follow the REST constraints including HATEOAS (hypermedia as the engine of application state). +Callbacks REST handlers implement the following interface: +init(Req, State) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} | {{switch_handler, Module}, Req, State} | {{switch_handler, Module, Opts}, Req, State} terminate(Reason, Req, State) -&gt; ok %% optional Req :: cowboy_req:req() State :: any() Module :: module() Opts :: any() Reason :: normal | {crash, error | exit | throw, any()} Callback - see below Result - see below Default - see below The init/2 callback is common to all handlers.</description> </item> <item> @@ -6004,10 +6323,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_rest/</guid> <description>Name cowboy_rest - REST handlers - Description The module cowboy_rest implements the HTTP state machine. - Implementing REST handlers is not enough to provide a REST interface; this interface must also follow the REST constraints including HATEOAS (hypermedia as the engine of application state). - Callbacks REST handlers implement the following interface: - init(Req, State) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} | {{switch_handler, Module}, Req, State} | {{switch_handler, Module, Opts}, Req, State} terminate(Reason, Req, State) -&gt; ok %% optional Req :: cowboy_req:req() State :: any() Module :: module() Opts :: any() Reason :: normal | {crash, error | exit | throw, any()} Callback - see below Result - see below Default - see below The init/2 callback is common to all handlers.</description> +Description The module cowboy_rest implements the HTTP state machine. +Implementing REST handlers is not enough to provide a REST interface; this interface must also follow the REST constraints including HATEOAS (hypermedia as the engine of application state). +Callbacks REST handlers implement the following interface: +init(Req, State) -&gt; {cowboy_rest, Req, State} Callback(Req, State) -&gt; {Result, Req, State} | {stop, Req, State} | {{switch_handler, Module}, Req, State} | {{switch_handler, Module, Opts}, Req, State} terminate(Reason, Req, State) -&gt; ok %% optional Req :: cowboy_req:req() State :: any() Module :: module() Opts :: any() Reason :: normal | {crash, error | exit | throw, any()} Callback - see below Result - see below Default - see below The init/2 callback is common to all handlers.</description> </item> <item> @@ -6017,9 +6336,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_router/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6029,9 +6349,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_router/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6041,9 +6362,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_router/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6053,9 +6375,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_router/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6065,9 +6388,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_router/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6077,9 +6401,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_router.compile/</guid> <description>Name cowboy_router:compile - Compile routes to the resources - Description compile(cowboy_router:routes()) -&gt; cowboy_router:dispatch_rules() Compile routes to the resources. - Takes a human readable list of routes and transforms it into a form more efficient to process. - Arguments Routes Human readable list of routes. Return value An opaque dispatch rules value is returned. This value must be given to Cowboy as a middleware environment value.</description> +Description compile(cowboy_router:routes()) -&gt; cowboy_router:dispatch_rules() Compile routes to the resources. +Takes a human readable list of routes and transforms it into a form more efficient to process. +Arguments Routes Human readable list of routes. + Return value An opaque dispatch rules value is returned. This value must be given to Cowboy as a middleware environment value. +Changelog 1.0: Function introduced. Examples Compile routes and start a listener Dispatch = cowboy_router:compile([ {'_', [ {"</description> </item> <item> @@ -6089,9 +6415,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_router.compile/</guid> <description>Name cowboy_router:compile - Compile routes to the resources - Description compile(cowboy_router:routes()) -&gt; cowboy_router:dispatch_rules() Compile routes to the resources. - Takes a human readable list of routes and transforms it into a form more efficient to process. - Arguments Routes Human readable list of routes. Return value An opaque dispatch rules value is returned. This value must be given to Cowboy as a middleware environment value.</description> +Description compile(cowboy_router:routes()) -&gt; cowboy_router:dispatch_rules() Compile routes to the resources. +Takes a human readable list of routes and transforms it into a form more efficient to process. +Arguments Routes Human readable list of routes. + Return value An opaque dispatch rules value is returned. This value must be given to Cowboy as a middleware environment value. +Changelog 1.0: Function introduced. Examples Compile routes and start a listener Dispatch = cowboy_router:compile([ {'_', [ {"</description> </item> <item> @@ -6101,9 +6429,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_router.compile/</guid> <description>Name cowboy_router:compile - Compile routes to the resources - Description compile(cowboy_router:routes()) -&gt; cowboy_router:dispatch_rules() Compile routes to the resources. - Takes a human readable list of routes and transforms it into a form more efficient to process. - Arguments Routes Human readable list of routes. Return value An opaque dispatch rules value is returned. This value must be given to Cowboy as a middleware environment value.</description> +Description compile(cowboy_router:routes()) -&gt; cowboy_router:dispatch_rules() Compile routes to the resources. +Takes a human readable list of routes and transforms it into a form more efficient to process. +Arguments Routes Human readable list of routes. + Return value An opaque dispatch rules value is returned. This value must be given to Cowboy as a middleware environment value. +Changelog 1.0: Function introduced. Examples Compile routes and start a listener Dispatch = cowboy_router:compile([ {'_', [ {"</description> </item> <item> @@ -6113,9 +6443,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_router.compile/</guid> <description>Name cowboy_router:compile - Compile routes to the resources - Description compile(cowboy_router:routes()) -&gt; cowboy_router:dispatch_rules() Compile routes to the resources. - Takes a human readable list of routes and transforms it into a form more efficient to process. - Arguments Routes Human readable list of routes. Return value An opaque dispatch rules value is returned. This value must be given to Cowboy as a middleware environment value.</description> +Description compile(cowboy_router:routes()) -&gt; cowboy_router:dispatch_rules() Compile routes to the resources. +Takes a human readable list of routes and transforms it into a form more efficient to process. +Arguments Routes Human readable list of routes. + Return value An opaque dispatch rules value is returned. This value must be given to Cowboy as a middleware environment value. +Changelog 1.0: Function introduced. Examples Compile routes and start a listener Dispatch = cowboy_router:compile([ {'_', [ {"</description> </item> <item> @@ -6125,9 +6457,11 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_router.compile/</guid> <description>Name cowboy_router:compile - Compile routes to the resources - Description compile(cowboy_router:routes()) -&gt; cowboy_router:dispatch_rules() Compile routes to the resources. - Takes a human readable list of routes and transforms it into a form more efficient to process. - Arguments Routes Human readable list of routes. Return value An opaque dispatch rules value is returned. This value must be given to Cowboy as a middleware environment value.</description> +Description compile(cowboy_router:routes()) -&gt; cowboy_router:dispatch_rules() Compile routes to the resources. +Takes a human readable list of routes and transforms it into a form more efficient to process. +Arguments Routes Human readable list of routes. + Return value An opaque dispatch rules value is returned. This value must be given to Cowboy as a middleware environment value. +Changelog 1.0: Function introduced. Examples Compile routes and start a listener Dispatch = cowboy_router:compile([ {'_', [ {"</description> </item> <item> @@ -6137,9 +6471,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_static/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6149,9 +6483,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_static/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6161,9 +6495,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_static/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6173,9 +6507,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_static/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6185,9 +6519,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_static/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6197,9 +6531,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_stream/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6209,9 +6544,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_stream/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6221,9 +6557,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_stream/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6233,9 +6570,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_stream/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6245,9 +6583,10 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_stream/</guid> <description>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.</description> +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.</description> </item> <item> @@ -6257,9 +6596,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_websocket/</guid> <description>Name cowboy_websocket - Websocket - Description The module cowboy_websocket implements Websocket as a Ranch protocol. It also defines a callback interface for handling Websocket connections. - Callbacks Websocket handlers must implement the following callback interface: - init(Req, State) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: {text | binary | ping | pong, binary()} OutFrame :: cow_ws:frame() %% see types below Info :: any() CallResult :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} Reason :: normal | stop | timeout | remote | {remote, cow_ws:close_code(), binary()} | {error, badencoding | badframe | closed | atom()} | {crash, error | exit | throw, any()} The init/2 callback is common to all handlers.</description> +Description The module cowboy_websocket implements Websocket as a Ranch protocol. It also defines a callback interface for handling Websocket connections. +Callbacks Websocket handlers must implement the following callback interface: +init(Req, State) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: {text | binary | ping | pong, binary()} OutFrame :: cow_ws:frame() %% see types below Info :: any() CallResult :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} Reason :: normal | stop | timeout | remote | {remote, cow_ws:close_code(), binary()} | {error, badencoding | badframe | closed | atom()} | {crash, error | exit | throw, any()} The init/2 callback is common to all handlers.</description> </item> <item> @@ -6269,9 +6608,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.1/manual/cowboy_websocket/</guid> <description>Name cowboy_websocket - Websocket - Description The module cowboy_websocket implements Websocket as a Ranch protocol. It also defines a callback interface for handling Websocket connections. - Callbacks Websocket handlers must implement the following callback interface: - init(Req, State) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: {text | binary | ping | pong, binary()} OutFrame :: cow_ws:frame() %% see types below Info :: any() CallResult :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} Reason :: normal | stop | timeout | remote | {remote, cow_ws:close_code(), binary()} | {error, badencoding | badframe | closed | atom()} | {crash, error | exit | throw, any()} The init/2 callback is common to all handlers.</description> +Description The module cowboy_websocket implements Websocket as a Ranch protocol. It also defines a callback interface for handling Websocket connections. +Callbacks Websocket handlers must implement the following callback interface: +init(Req, State) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: {text | binary | ping | pong, binary()} OutFrame :: cow_ws:frame() %% see types below Info :: any() CallResult :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} Reason :: normal | stop | timeout | remote | {remote, cow_ws:close_code(), binary()} | {error, badencoding | badframe | closed | atom()} | {crash, error | exit | throw, any()} The init/2 callback is common to all handlers.</description> </item> <item> @@ -6281,9 +6620,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.2/manual/cowboy_websocket/</guid> <description>Name cowboy_websocket - Websocket - Description The module cowboy_websocket implements Websocket as a Ranch protocol. It also defines a callback interface for handling Websocket connections. - Callbacks Websocket handlers must implement the following callback interface: - init(Req, State) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: {text | binary | ping | pong, binary()} OutFrame :: cow_ws:frame() %% see types below Info :: any() CallResult :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} Reason :: normal | stop | timeout | remote | {remote, cow_ws:close_code(), binary()} | {error, badencoding | badframe | closed | atom()} | {crash, error | exit | throw, any()} The init/2 callback is common to all handlers.</description> +Description The module cowboy_websocket implements Websocket as a Ranch protocol. It also defines a callback interface for handling Websocket connections. +Callbacks Websocket handlers must implement the following callback interface: +init(Req, State) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: {text | binary | ping | pong, binary()} OutFrame :: cow_ws:frame() %% see types below Info :: any() CallResult :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} Reason :: normal | stop | timeout | remote | {remote, cow_ws:close_code(), binary()} | {error, badencoding | badframe | closed | atom()} | {crash, error | exit | throw, any()} The init/2 callback is common to all handlers.</description> </item> <item> @@ -6293,9 +6632,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.3/manual/cowboy_websocket/</guid> <description>Name cowboy_websocket - Websocket - Description The module cowboy_websocket implements Websocket as a Ranch protocol. It also defines a callback interface for handling Websocket connections. - Callbacks Websocket handlers must implement the following callback interface: - init(Req, State) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: {text | binary | ping | pong, binary()} OutFrame :: cow_ws:frame() %% see types below Info :: any() CallResult :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} Reason :: normal | stop | timeout | remote | {remote, cow_ws:close_code(), binary()} | {error, badencoding | badframe | closed | atom()} | {crash, error | exit | throw, any()} The init/2 callback is common to all handlers.</description> +Description The module cowboy_websocket implements Websocket as a Ranch protocol. It also defines a callback interface for handling Websocket connections. +Callbacks Websocket handlers must implement the following callback interface: +init(Req, State) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: {text | binary | ping | pong, binary()} OutFrame :: cow_ws:frame() %% see types below Info :: any() CallResult :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} Reason :: normal | stop | timeout | remote | {remote, cow_ws:close_code(), binary()} | {error, badencoding | badframe | closed | atom()} | {crash, error | exit | throw, any()} The init/2 callback is common to all handlers.</description> </item> <item> @@ -6305,9 +6644,9 @@ <guid>https://ninenines.eu/docs/en/cowboy/2.4/manual/cowboy_websocket/</guid> <description>Name cowboy_websocket - Websocket - Description The module cowboy_websocket implements Websocket as a Ranch protocol. It also defines a callback interface for handling Websocket connections. - Callbacks Websocket handlers must implement the following callback interface: - init(Req, State) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: {text | binary | ping | pong, binary()} OutFrame :: cow_ws:frame() %% see types below Info :: any() CallResult :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} Reason :: normal | stop | timeout | remote | {remote, cow_ws:close_code(), binary()} | {error, badencoding | badframe | closed | atom()} | {crash, error | exit | throw, any()} The init/2 callback is common to all handlers.</description> +Description The module cowboy_websocket implements Websocket as a Ranch protocol. It also defines a callback interface for handling Websocket connections. +Callbacks Websocket handlers must implement the following callback interface: +init(Req, State) -&gt; {cowboy_websocket, Req, State} | {cowboy_websocket, Req, State, Opts} websocket_init(State) -&gt; CallResult %% optional websocket_handle(InFrame, State) -&gt; CallResult websocket_info(Info, State) -&gt; CallResult terminate(Reason, PartialReq, State) -&gt; ok %% optional Req :: cowboy_req:req() PartialReq :: map() State :: any() Opts :: cowboy_websocket:opts() InFrame :: {text | binary | ping | pong, binary()} OutFrame :: cow_ws:frame() %% see types below Info :: any() CallResult :: {ok, State} | {ok, State, hibernate} | {reply, OutFrame | [OutFrame], State} | {reply, OutFrame | [OutFrame], State, hibernate} | {stop, State} Reason :: normal | stop | timeout | remote | {remote, cow_ws:close_code(), binary()} | {error, badencoding | badframe | closed | atom()} | {crash, error | exit | throw, any()} The init/2 callback is common to all handlers.</description> </item> <item> @@ -6317,9 +6656,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun/</guid> <description>Name gun - Asynchronous HTTP client - Description The gun module provides an asynchronous interface for connecting and communicating with Web servers over HTTP, HTTP/2 or Websocket. - Exports Connection: - gun:open(3) - Open a connection to the given host and port gun:open_unix(3) - Open a connection to the given Unix domain socket gun:close(3) - Brutally close the connection gun:info(3) - Obtain information about the connection Requests:</description> +Description The gun module provides an asynchronous interface for connecting and communicating with Web servers over HTTP, HTTP/2 or Websocket. +Exports Connection: +gun:open(3) - Open a connection to the given host and port gun:open_unix(3) - Open a connection to the given Unix domain socket gun:close(3) - Brutally close the connection gun:info(3) - Obtain information about the connection Requests:</description> </item> <item> @@ -6329,9 +6668,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_app/</guid> <description>Name gun - HTTP/1.1, HTTP/2 and Websocket client for Erlang/OTP - Description Gun is an HTTP client for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. - Gun aims to provide an easy to use, asynchronous and always-connected client. It maintains a permanent connection to the server and reconnects automatically when necessary. - Modules gun(3) - Asynchronous HTTP client Dependencies cowlib(7) - Support library for manipulating Web protocols ssl - Secure communication over sockets All these applications must be started before the gun application.</description> +Description Gun is an HTTP client for Erlang/OTP with support for the HTTP/1.1, HTTP/2 and Websocket protocols. +Gun aims to provide an easy to use, asynchronous and always-connected client. It maintains a permanent connection to the server and reconnects automatically when necessary. +Modules gun(3) - Asynchronous HTTP client Dependencies cowlib(7) - Support library for manipulating Web protocols ssl - Secure communication over sockets All these applications must be started before the gun application.</description> </item> <item> @@ -6341,8 +6680,8 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.await/</guid> <description>Name gun:await - Wait for a response - Description await(ConnPid, StreamRef) -&gt; await(ConnPid, StreamRef, 5000, MonitorRef) await(ConnPid, StreamRef, MonitorRef) -&gt; await(ConnPid, StreamRef, 5000, MonitorRef) await(ConnPid, StreamRef, Timeout) -&gt; await(ConnPid, StreamRef, Timeout, MonitorRef) await(ConnPid, StreamRef, Timeout, MonitorRef) -&gt; Result ConnPid :: pid() StreamRef :: reference() MonitorRef :: reference() Timeout :: timeout() Result :: tuple() - see below Wait for a response. - This function waits for a message from the given stream and returns it as a tuple.</description> +Description await(ConnPid, StreamRef) -&gt; await(ConnPid, StreamRef, 5000, MonitorRef) await(ConnPid, StreamRef, MonitorRef) -&gt; await(ConnPid, StreamRef, 5000, MonitorRef) await(ConnPid, StreamRef, Timeout) -&gt; await(ConnPid, StreamRef, Timeout, MonitorRef) await(ConnPid, StreamRef, Timeout, MonitorRef) -&gt; Result ConnPid :: pid() StreamRef :: reference() MonitorRef :: reference() Timeout :: timeout() Result :: tuple() - see below Wait for a response. +This function waits for a message from the given stream and returns it as a tuple.</description> </item> <item> @@ -6352,7 +6691,7 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.await_body/</guid> <description>Name gun:await_body - Wait for the complete response body - Description await_body(ConnPid, StreamRef) -&gt; await_body(ConnPid, StreamRef, 5000, MonitorRef) await_body(ConnPid, StreamRef, MonitorRef) -&gt; await_body(ConnPid, StreamRef, 5000, MonitorRef) await_body(ConnPid, StreamRef, Timeout) -&gt; await_body(ConnPid, StreamRef, Timeout, MonitorRef) await_body(ConnPid, StreamRef, Timeout, MonitorRef) -&gt; {ok, Body} | {ok, Body, Trailers} | {error, Reason} ConnPid :: pid() StreamRef :: reference() MonitorRef :: reference() Timeout :: timeout() Body :: binary() Trailers :: [{binary(), binary()}] Reason :: timeout | any() Wait for the complete response body.</description> +Description await_body(ConnPid, StreamRef) -&gt; await_body(ConnPid, StreamRef, 5000, MonitorRef) await_body(ConnPid, StreamRef, MonitorRef) -&gt; await_body(ConnPid, StreamRef, 5000, MonitorRef) await_body(ConnPid, StreamRef, Timeout) -&gt; await_body(ConnPid, StreamRef, Timeout, MonitorRef) await_body(ConnPid, StreamRef, Timeout, MonitorRef) -&gt; {ok, Body} | {ok, Body, Trailers} | {error, Reason} ConnPid :: pid() StreamRef :: reference() MonitorRef :: reference() Timeout :: timeout() Body :: binary() Trailers :: [{binary(), binary()}] Reason :: timeout | any() Wait for the complete response body.</description> </item> <item> @@ -6362,8 +6701,8 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.await_up/</guid> <description>Name gun:await_up - Wait for the connection to be up - Description await_up(ConnPid) -&gt; await_up(ConnPid, 5000, MonitorRef) await_up(ConnPid, MonitorRef) -&gt; await_up(ConnPid, 5000, MonitorRef) await_up(ConnPid, Timeout) -&gt; await_up(ConnPid, Timeout, MonitorRef) await_up(ConnPid, Timeout, MonitorRef) -&gt; {ok, Protocol} | {error, Reason} ConnPid :: pid() MonitorRef :: reference() Timeout :: timeout() Protocol :: http | http2 Reason :: timeout | any() Wait for the connection to be up. - Arguments ConnPid The pid of the Gun connection process.</description> +Description await_up(ConnPid) -&gt; await_up(ConnPid, 5000, MonitorRef) await_up(ConnPid, MonitorRef) -&gt; await_up(ConnPid, 5000, MonitorRef) await_up(ConnPid, Timeout) -&gt; await_up(ConnPid, Timeout, MonitorRef) await_up(ConnPid, Timeout, MonitorRef) -&gt; {ok, Protocol} | {error, Reason} ConnPid :: pid() MonitorRef :: reference() Timeout :: timeout() Protocol :: http | http2 Reason :: timeout | any() Wait for the connection to be up. +Arguments ConnPid The pid of the Gun connection process.</description> </item> <item> @@ -6373,9 +6712,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.cancel/</guid> <description>Name gun:cancel - Cancel the given stream - Description cancel(ConnPid, StreamRef) -&gt; ok ConnPid :: pid() StreamRef :: reference() Cancel the given stream. - The behavior of this function depends on the protocol selected. - HTTP/1.1 does not support this feature. Gun will simply silence the stream and stop relaying messages. Gun may also decide to close the connection if the response body is too large, to avoid wasting time and bandwidth.</description> +Description cancel(ConnPid, StreamRef) -&gt; ok ConnPid :: pid() StreamRef :: reference() Cancel the given stream. +The behavior of this function depends on the protocol selected. +HTTP/1.1 does not support this feature. Gun will simply silence the stream and stop relaying messages. Gun may also decide to close the connection if the response body is too large, to avoid wasting time and bandwidth.</description> </item> <item> @@ -6385,9 +6724,10 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.close/</guid> <description>Name gun:close - Brutally close the connection - Description close(ConnPid) -&gt; ok ConnPid :: pid() Brutally close the connection. - Arguments ConnPid The pid of the Gun connection process. Return value The atom ok is returned. - Changelog 1.0: Function introduced. Examples Close the connection ok = gun:close(ConnPid). See also gun(3), gun:open(3), gun:open_unix(3)</description> +Description close(ConnPid) -&gt; ok ConnPid :: pid() Brutally close the connection. +Arguments ConnPid The pid of the Gun connection process. + Return value The atom ok is returned. +Changelog 1.0: Function introduced. Examples Close the connection ok = gun:close(ConnPid). See also gun(3), gun:open(3), gun:open_unix(3)</description> </item> <item> @@ -6397,9 +6737,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.data/</guid> <description>Name gun:data - Stream the body of a request - Description data(ConnPid, StreamRef, IsFin, Data) -&gt; ok ConnPid :: pid() StreamRef :: reference() IsFin :: fin | nofin Data :: iodata() Stream the body of a request. - This function can only be used if the original request had headers indicating that a body would be streamed. - All calls to this function must use the nofin flag except for the last which must use fin to indicate the end of the request body.</description> +Description data(ConnPid, StreamRef, IsFin, Data) -&gt; ok ConnPid :: pid() StreamRef :: reference() IsFin :: fin | nofin Data :: iodata() Stream the body of a request. +This function can only be used if the original request had headers indicating that a body would be streamed. +All calls to this function must use the nofin flag except for the last which must use fin to indicate the end of the request body.</description> </item> <item> @@ -6409,8 +6749,11 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.delete/</guid> <description>Name gun:delete - Delete a resource - Description delete(ConnPid, Path) -&gt; delete(ConnPid, Path, [], #{}). delete(ConnPid, Path, Headers) -&gt; delete(ConnPid, Path, Headers, #{}) delete(ConnPid, Path, Headers, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] ReqOpts :: gun:req_opts() StreamRef :: reference() Delete a resource. - Arguments ConnPid The pid of the Gun connection process. Path Path to the resource.</description> +Description delete(ConnPid, Path) -&gt; delete(ConnPid, Path, [], #{}). delete(ConnPid, Path, Headers) -&gt; delete(ConnPid, Path, Headers, #{}) delete(ConnPid, Path, Headers, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] ReqOpts :: gun:req_opts() StreamRef :: reference() Delete a resource. +Arguments ConnPid The pid of the Gun connection process. + Path Path to the resource. + Headers Additional request headers. + ReqOpts Request options.</description> </item> <item> @@ -6420,9 +6763,11 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.flush/</guid> <description>Name gun:flush - Flush all messages related to a connection or a stream - Description flush(ConnPid) -&gt; ok flush(StreamRef) -&gt; ok ConnPid :: pid() StreamRef :: reference() Flush all messages related to a connection or a stream. - Arguments Either of these arguments may be provided: - ConnPid The pid of the Gun connection process. StreamRef Identifier of the stream for the original request.</description> +Description flush(ConnPid) -&gt; ok flush(StreamRef) -&gt; ok ConnPid :: pid() StreamRef :: reference() Flush all messages related to a connection or a stream. +Arguments Either of these arguments may be provided: +ConnPid The pid of the Gun connection process. + StreamRef Identifier of the stream for the original request. + Return value The atom ok is returned.</description> </item> <item> @@ -6432,8 +6777,10 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.get/</guid> <description>Name gun:get - Get a resource representation - Description get(ConnPid, Path) -&gt; get(ConnPid, Path, [], #{}). get(ConnPid, Path, Headers) -&gt; get(ConnPid, Path, Headers, #{}) get(ConnPid, Path, Headers, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] ReqOpts :: gun:req_opts() StreamRef :: reference() Get a resource representation. - Arguments ConnPid The pid of the Gun connection process. Path Path to the resource.</description> +Description get(ConnPid, Path) -&gt; get(ConnPid, Path, [], #{}). get(ConnPid, Path, Headers) -&gt; get(ConnPid, Path, Headers, #{}) get(ConnPid, Path, Headers, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] ReqOpts :: gun:req_opts() StreamRef :: reference() Get a resource representation. +Arguments ConnPid The pid of the Gun connection process. + Path Path to the resource. + Headers Additional request headers.</description> </item> <item> @@ -6443,8 +6790,8 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.head/</guid> <description>Name gun:head - Get headers of a resource representation - Description head(ConnPid, Path) -&gt; head(ConnPid, Path, [], #{}). head(ConnPid, Path, Headers) -&gt; head(ConnPid, Path, Headers, #{}) head(ConnPid, Path, Headers, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] ReqOpts :: gun:req_opts() StreamRef :: reference() Get headers of a resource representation. - This function performs the same operation as gun:get(3), except the server will not send the resource representation, only the response&#8217;s status code and headers.</description> +Description head(ConnPid, Path) -&gt; head(ConnPid, Path, [], #{}). head(ConnPid, Path, Headers) -&gt; head(ConnPid, Path, Headers, #{}) head(ConnPid, Path, Headers, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] ReqOpts :: gun:req_opts() StreamRef :: reference() Get headers of a resource representation. +This function performs the same operation as gun:get(3), except the server will not send the resource representation, only the response&apos;s status code and headers.</description> </item> <item> @@ -6454,9 +6801,10 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.info/</guid> <description>Name gun:info - Obtain information about the connection - Description info(ConnPid) -&gt; Info ConnPid :: pid() Info :: #{ sock_ip =&gt; inet:ip_address(), sock_port =&gt; inet:port_number() } Obtain information about the connection. - Arguments ConnPid The pid of the Gun connection process. Return value A map is returned containing various informations about the connection. - Changelog 1.</description> +Description info(ConnPid) -&gt; Info ConnPid :: pid() Info :: #{ sock_ip =&gt; inet:ip_address(), sock_port =&gt; inet:port_number() } Obtain information about the connection. +Arguments ConnPid The pid of the Gun connection process. + Return value A map is returned containing various informations about the connection. +Changelog 1.0: Function introduced. Examples Obtain information about the connection Info = gun:info(ConnPid). See also gun(3), gun:open(3), gun:open_unix(3)</description> </item> <item> @@ -6466,8 +6814,10 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.open/</guid> <description>Name gun:open - Open a connection to the given host and port - Description open(Host, Port) -&gt; open(Host, Port, #{}) open(Host, Port, Opts) -&gt; {ok, pid()} | {error, any()} Host :: inet:hostname() | inet:ip_address() Port :: inet:port_number() Opts :: gun:opts() Open a connection to the given host and port. - Arguments Host Host or IP address to connect to. Port Port to connect to.</description> +Description open(Host, Port) -&gt; open(Host, Port, #{}) open(Host, Port, Opts) -&gt; {ok, pid()} | {error, any()} Host :: inet:hostname() | inet:ip_address() Port :: inet:port_number() Opts :: gun:opts() Open a connection to the given host and port. +Arguments Host Host or IP address to connect to. + Port Port to connect to. + Opts Options for this connection.</description> </item> <item> @@ -6477,8 +6827,10 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.open_unix/</guid> <description>Name gun:open_unix - Open a connection to the given Unix domain socket - Description open_unix(SocketPath, Opts) -&gt; {ok, pid()} | {error, any()} SocketPath :: string() Opts :: gun:opts() Open a connection to the given Unix domain socket. - Arguments SocketPath Path to the Unix domain socket to connect to. Opts Options for this connection. Return value The pid of the newly created Gun process is returned.</description> +Description open_unix(SocketPath, Opts) -&gt; {ok, pid()} | {error, any()} SocketPath :: string() Opts :: gun:opts() Open a connection to the given Unix domain socket. +Arguments SocketPath Path to the Unix domain socket to connect to. + Opts Options for this connection. + Return value The pid of the newly created Gun process is returned. Note that this does not indicate that the connection has been successfully opened; the gun_up(3) message will be sent for that.</description> </item> <item> @@ -6488,8 +6840,8 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.options/</guid> <description>Name gun:options - Query the capabilities of the server or a resource - Description options(ConnPid, Path) -&gt; options(ConnPid, Path, [], #{}). options(ConnPid, Path, Headers) -&gt; options(ConnPid, Path, Headers, #{}) options(ConnPid, Path, Headers, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] ReqOpts :: gun:req_opts() StreamRef :: reference() Query the capabilities of the server or a resource. - The special path "*" can be used to obtain information about the server as a whole.</description> +Description options(ConnPid, Path) -&gt; options(ConnPid, Path, [], #{}). options(ConnPid, Path, Headers) -&gt; options(ConnPid, Path, Headers, #{}) options(ConnPid, Path, Headers, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] ReqOpts :: gun:req_opts() StreamRef :: reference() Query the capabilities of the server or a resource. +The special path &quot;*&quot; can be used to obtain information about the server as a whole.</description> </item> <item> @@ -6499,8 +6851,8 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.patch/</guid> <description>Name gun:patch - Apply a set of changes to a resource - Description patch(ConnPid, Path, Headers) -&gt; StreamRef patch(ConnPid, Path, Headers, Body) -&gt; patch(ConnPid, Path, Headers, Body, #{}) patch(ConnPid, Path, Headers, Body, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] Body :: iodata() ReqOpts :: gun:req_opts() StreamRef :: reference() Apply a set of changes to a resource. - The behavior of this function varies depending on whether a body is provided.</description> +Description patch(ConnPid, Path, Headers) -&gt; StreamRef patch(ConnPid, Path, Headers, Body) -&gt; patch(ConnPid, Path, Headers, Body, #{}) patch(ConnPid, Path, Headers, Body, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] Body :: iodata() ReqOpts :: gun:req_opts() StreamRef :: reference() Apply a set of changes to a resource. +The behavior of this function varies depending on whether a body is provided.</description> </item> <item> @@ -6509,9 +6861,9 @@ <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.post/</guid> - <description>Name gun:post - Process the enclosed representation according to a resource&#8217;s own semantics - Description post(ConnPid, Path, Headers) -&gt; StreamRef post(ConnPid, Path, Headers, Body) -&gt; post(ConnPid, Path, Headers, Body, #{}) post(ConnPid, Path, Headers, Body, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] Body :: iodata() ReqOpts :: gun:req_opts() StreamRef :: reference() Process the enclosed representation according to a resource&#8217;s own semantics. - The behavior of this function varies depending on whether a body is provided.</description> + <description>Name gun:post - Process the enclosed representation according to a resource&apos;s own semantics +Description post(ConnPid, Path, Headers) -&gt; StreamRef post(ConnPid, Path, Headers, Body) -&gt; post(ConnPid, Path, Headers, Body, #{}) post(ConnPid, Path, Headers, Body, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] Body :: iodata() ReqOpts :: gun:req_opts() StreamRef :: reference() Process the enclosed representation according to a resource&apos;s own semantics. +The behavior of this function varies depending on whether a body is provided.</description> </item> <item> @@ -6521,8 +6873,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.put/</guid> <description>Name gun:put - Create or replace a resource - Description put(ConnPid, Path, Headers) -&gt; StreamRef put(ConnPid, Path, Headers, Body) -&gt; put(ConnPid, Path, Headers, Body, #{}) put(ConnPid, Path, Headers, Body, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] Body :: iodata() ReqOpts :: gun:req_opts() StreamRef :: reference() Create or replace a resource. - The behavior of this function varies depending on whether a body is provided.</description> +Description put(ConnPid, Path, Headers) -&gt; StreamRef put(ConnPid, Path, Headers, Body) -&gt; put(ConnPid, Path, Headers, Body, #{}) put(ConnPid, Path, Headers, Body, ReqOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] Body :: iodata() ReqOpts :: gun:req_opts() StreamRef :: reference() Create or replace a resource. +The behavior of this function varies depending on whether a body is provided. +The function put/3 expects either a content-length or content-type header to indicate that a body will be sent afterwards.</description> </item> <item> @@ -6532,8 +6885,8 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.request/</guid> <description>Name gun:request - Perform the given request - Description request(ConnPid, Method, Path, Headers) -&gt; StreamRef request(ConnPid, Method, Path, Headers, Body) -&gt; request(ConnPid, Method, Path, Headers, Body, #{}) request(ConnPid, Method, Path, Headers, Body, ReqOpts) -&gt; StreamRef ConnPid :: pid() Method :: binary() Path :: iodata() Headers :: [{binary(), iodata()}] Body :: iodata() ReqOpts :: gun:req_opts() StreamRef :: reference() Perform the given request. - This is a general purpose function that should only be used when other method-specific functions do not apply.</description> +Description request(ConnPid, Method, Path, Headers) -&gt; StreamRef request(ConnPid, Method, Path, Headers, Body) -&gt; request(ConnPid, Method, Path, Headers, Body, #{}) request(ConnPid, Method, Path, Headers, Body, ReqOpts) -&gt; StreamRef ConnPid :: pid() Method :: binary() Path :: iodata() Headers :: [{binary(), iodata()}] Body :: iodata() ReqOpts :: gun:req_opts() StreamRef :: reference() Perform the given request. +This is a general purpose function that should only be used when other method-specific functions do not apply.</description> </item> <item> @@ -6543,9 +6896,10 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.ws_send/</guid> <description>Name gun:ws_send - Send Websocket frames - Description ws_send(ConnPid, Frames) -&gt; ok ConnPid :: pid() Frames :: Frame | [Frame] Frame :: close | ping | pong | {text | binary | close | ping | pong, iodata()} | {close, non_neg_integer(), iodata()} Send Websocket frames. - The connection must first be upgraded to Websocket using the function gun:ws_upgrade(3). - Arguments ConnPid The pid of the Gun connection process.</description> +Description ws_send(ConnPid, Frames) -&gt; ok ConnPid :: pid() Frames :: Frame | [Frame] Frame :: close | ping | pong | {text | binary | close | ping | pong, iodata()} | {close, non_neg_integer(), iodata()} Send Websocket frames. +The connection must first be upgraded to Websocket using the function gun:ws_upgrade(3). +Arguments ConnPid The pid of the Gun connection process. + Frames A Websocket frame.</description> </item> <item> @@ -6555,9 +6909,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun.ws_upgrade/</guid> <description>Name gun:ws_upgrade - Upgrade to Websocket - Description ws_upgrade(ConnPid, Path) -&gt; ws_upgrade(ConnPid, Path, []) ws_upgrade(ConnPid, Path, Headers) -&gt; StreamRef ws_upgrade(ConnPid, Path, Headers, WsOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] WsOpts :: gun:ws_opts StreamRef :: reference() Upgrade to Websocket. - The behavior of this function depends on the protocol selected. - HTTP/1.1 cannot handle Websocket and HTTP requests concurrently. The upgrade, if successful, will result in the complete takeover of the connection.</description> +Description ws_upgrade(ConnPid, Path) -&gt; ws_upgrade(ConnPid, Path, []) ws_upgrade(ConnPid, Path, Headers) -&gt; StreamRef ws_upgrade(ConnPid, Path, Headers, WsOpts) -&gt; StreamRef ConnPid :: pid() Path :: iodata() Headers :: [{binary(), iodata()}] WsOpts :: gun:ws_opts StreamRef :: reference() Upgrade to Websocket. +The behavior of this function depends on the protocol selected. +HTTP/1.1 cannot handle Websocket and HTTP requests concurrently. The upgrade, if successful, will result in the complete takeover of the connection.</description> </item> <item> @@ -6567,10 +6921,10 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_data/</guid> <description>Name gun_data - Response body - Description {gun_data, ConnPid, StreamRef, IsFin, Data} ConnPid :: pid() StreamRef :: reference() IsFin :: fin | nofin Data :: binary() Response body. - This message informs the relevant process that the server sent a all or part of the body for the response to the original request. - A data message is always preceded by a response message. - The response body may be terminated either by a data message with the flag fin set or by a gun_trailers(3) message.</description> +Description {gun_data, ConnPid, StreamRef, IsFin, Data} ConnPid :: pid() StreamRef :: reference() IsFin :: fin | nofin Data :: binary() Response body. +This message informs the relevant process that the server sent a all or part of the body for the response to the original request. +A data message is always preceded by a response message. +The response body may be terminated either by a data message with the flag fin set or by a gun_trailers(3) message.</description> </item> <item> @@ -6580,9 +6934,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_down/</guid> <description>Name gun_down - The connection is down - Description {gun_down, ConnPid, Protocol, Reason, KilledStreams, UnprocessedStreams} ConnPid :: pid() Protocol :: http | http2 | ws Reason :: any() KilledStreams :: [reference()] UnprocessedStreams :: [reference()] The connection is down. - This message informs the owner process that the connection was lost. Depending on the retry and retry_timeout options Gun may automatically attempt to reconnect. - When the connection goes back up, Gun will not attempt to retry requests.</description> +Description {gun_down, ConnPid, Protocol, Reason, KilledStreams, UnprocessedStreams} ConnPid :: pid() Protocol :: http | http2 | ws Reason :: any() KilledStreams :: [reference()] UnprocessedStreams :: [reference()] The connection is down. +This message informs the owner process that the connection was lost. Depending on the retry and retry_timeout options Gun may automatically attempt to reconnect. +When the connection goes back up, Gun will not attempt to retry requests.</description> </item> <item> @@ -6592,8 +6946,8 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_error/</guid> <description>Name gun_error - Stream or connection-wide error - Description {gun_error, ConnPid, StreamRef, Reason} {gun_error, ConnPid, Reason} ConnPid :: pid() StreamRef :: reference() Reason :: any() Stream or connection-wide error. - These messages inform the relevant process that an error occurred. A reference is given when the error pertains to a specific stream. Connection-wide errors do not imply that the connection is no longer usable, they are used for all errors that are not specific to a stream.</description> +Description {gun_error, ConnPid, StreamRef, Reason} {gun_error, ConnPid, Reason} ConnPid :: pid() StreamRef :: reference() Reason :: any() Stream or connection-wide error. +These messages inform the relevant process that an error occurred. A reference is given when the error pertains to a specific stream. Connection-wide errors do not imply that the connection is no longer usable, they are used for all errors that are not specific to a stream.</description> </item> <item> @@ -6603,9 +6957,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_inform/</guid> <description>Name gun_inform - Informational response - Description {gun_inform, ConnPid, StreamRef, Status, Headers} ConnPid :: pid() StreamRef :: reference() Status :: 100..199 Headers :: [{binary(), binary()}] Informational response. - This message informs the relevant process that the server sent an informational response to the original request. - Informational responses are only intermediate responses and provide no guarantees as to what the final response will be. An informational response always precedes the response to the original request.</description> +Description {gun_inform, ConnPid, StreamRef, Status, Headers} ConnPid :: pid() StreamRef :: reference() Status :: 100..199 Headers :: [{binary(), binary()}] Informational response. +This message informs the relevant process that the server sent an informational response to the original request. +Informational responses are only intermediate responses and provide no guarantees as to what the final response will be. An informational response always precedes the response to the original request.</description> </item> <item> @@ -6615,9 +6969,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_push/</guid> <description>Name gun_push - Server-initiated push - Description {gun_push, ConnPid, StreamRef, NewStreamRef, Method, URI, Headers} ConnPid :: pid() StreamRef :: reference() NewStreamRef :: reference() Method :: binary() URI :: binary() Headers :: [{binary(), binary()}] Server-initiated push. - This message informs the relevant process that the server is pushing a resource related to the effective target URI of the original request. - A server-initiated push message always precedes the response to the original request.</description> +Description {gun_push, ConnPid, StreamRef, NewStreamRef, Method, URI, Headers} ConnPid :: pid() StreamRef :: reference() NewStreamRef :: reference() Method :: binary() URI :: binary() Headers :: [{binary(), binary()}] Server-initiated push. +This message informs the relevant process that the server is pushing a resource related to the effective target URI of the original request. +A server-initiated push message always precedes the response to the original request.</description> </item> <item> @@ -6627,9 +6981,11 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_response/</guid> <description>Name gun_response - Response - Description {gun_response, ConnPid, StreamRef, IsFin, Status, Headers} ConnPid :: pid() StreamRef :: reference() IsFin :: fin | nofin Status :: non_neg_integer() Headers :: [{binary(), binary()}] Response. - This message informs the relevant process that the server sent a response to the original request. - Elements ConnPid The pid of the Gun connection process. StreamRef Identifier of the stream for the original request.</description> +Description {gun_response, ConnPid, StreamRef, IsFin, Status, Headers} ConnPid :: pid() StreamRef :: reference() IsFin :: fin | nofin Status :: non_neg_integer() Headers :: [{binary(), binary()}] Response. +This message informs the relevant process that the server sent a response to the original request. +Elements ConnPid The pid of the Gun connection process. + StreamRef Identifier of the stream for the original request. + IsFin Whether this message terminates the response.</description> </item> <item> @@ -6639,10 +6995,12 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_trailers/</guid> <description>Name gun_trailers - Response trailers - Description {gun_trailers, ConnPid, StreamRef, Headers} ConnPid :: pid() StreamRef :: reference() Headers :: [{binary(), binary()}] Response trailers. - This message informs the relevant process that the server sent response trailers for the response to the original request. - A trailers message terminates the response. - Elements ConnPid The pid of the Gun connection process. StreamRef Identifier of the stream for the original request.</description> +Description {gun_trailers, ConnPid, StreamRef, Headers} ConnPid :: pid() StreamRef :: reference() Headers :: [{binary(), binary()}] Response trailers. +This message informs the relevant process that the server sent response trailers for the response to the original request. +A trailers message terminates the response. +Elements ConnPid The pid of the Gun connection process. + StreamRef Identifier of the stream for the original request. + Headers Trailing headers sent after the response body.</description> </item> <item> @@ -6652,9 +7010,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_up/</guid> <description>Name gun_up - The connection is up - Description {gun_up, ConnPid, Protocol} ConnPid :: pid() Protocol :: http | http2 The connection is up. - This message informs the owner process that the connection or reconnection completed. - Gun will now start processing the messages it received while waiting for the connection to be up. If this is a reconnection, then this may not be desirable for all requests.</description> +Description {gun_up, ConnPid, Protocol} ConnPid :: pid() Protocol :: http | http2 The connection is up. +This message informs the owner process that the connection or reconnection completed. +Gun will now start processing the messages it received while waiting for the connection to be up. If this is a reconnection, then this may not be desirable for all requests. Those requests should be cancelled when the connection goes down, and any subsequent messages ignored.</description> </item> <item> @@ -6664,9 +7022,9 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_upgrade/</guid> <description>Name gun_upgrade - Successful protocol upgrade - Description {gun_upgrade, ConnPid, StreamRef, Protocols, Headers} ConnPid :: pid() StreamRef :: reference() Protocols :: [&lt;&lt;"websocket"&gt;&gt;] Headers :: [{binary(), binary()}] Successful protocol upgrade. - This message informs the relevant process that the server accepted to upgrade to one or more protocols given in the original request. - The exact semantics of this message depend on the original protocol. HTTP/1.1 upgrades apply to the entire connection.</description> +Description {gun_upgrade, ConnPid, StreamRef, Protocols, Headers} ConnPid :: pid() StreamRef :: reference() Protocols :: [&lt;&lt;"websocket"&gt;&gt;] Headers :: [{binary(), binary()}] Successful protocol upgrade. +This message informs the relevant process that the server accepted to upgrade to one or more protocols given in the original request. +The exact semantics of this message depend on the original protocol. HTTP/1.1 upgrades apply to the entire connection. HTTP/2 uses a different mechanism which allows switching specific streams to a different protocol.</description> </item> <item> @@ -6676,10 +7034,10 @@ <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_ws/</guid> <description>Name gun_ws - Websocket frame - Description {gun_ws, ConnPid, StreamRef, Frame} ConnPid :: pid() StreamRef :: reference() Frame :: close | {text | binary | close, binary()} | {close, non_neg_integer(), binary()} Websocket frame. - This message informs the relevant process that the server sent the enclosed frame. - This message can only be sent on streams that were upgraded to the Websocket protocol. - Elements ConnPid The pid of the Gun connection process.</description> +Description {gun_ws, ConnPid, StreamRef, Frame} ConnPid :: pid() StreamRef :: reference() Frame :: close | {text | binary | close, binary()} | {close, non_neg_integer(), binary()} Websocket frame. +This message informs the relevant process that the server sent the enclosed frame. +This message can only be sent on streams that were upgraded to the Websocket protocol. +Elements ConnPid The pid of the Gun connection process.</description> </item> <item> @@ -6689,9 +7047,10 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch/</guid> <description>Name ranch - socket acceptor pool - Description The ranch module provides functions for starting and manipulating Ranch listeners. - Types max_conns() = non_neg_integer() | infinity Maximum number of connections allowed on this listener. - This is a soft limit. The actual number of connections might be slightly above the limit due to concurrency when accepting new connections. Some connections may also be removed from this count explicitly by the user code.</description> +Description The ranch module provides functions for starting and manipulating Ranch listeners. +Types max_conns() = non_neg_integer() | infinity Maximum number of connections allowed on this listener. +This is a soft limit. The actual number of connections might be slightly above the limit due to concurrency when accepting new connections. Some connections may also be removed from this count explicitly by the user code. +opt() opt() = {ack_timeout, timeout()} | {connection_type, worker | supervisor} | {max_connections, max_conns()} | {shutdown, timeout() | brutal_kill} | {socket, any()} Ranch-specific transport options.</description> </item> <item> @@ -6701,9 +7060,10 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch/</guid> <description>Name ranch - socket acceptor pool - Description The ranch module provides functions for starting and manipulating Ranch listeners. - Types max_conns() = non_neg_integer() | infinity Maximum number of connections allowed on this listener. - This is a soft limit. The actual number of connections might be slightly above the limit due to concurrency when accepting new connections. Some connections may also be removed from this count explicitly by the user code.</description> +Description The ranch module provides functions for starting and manipulating Ranch listeners. +Types max_conns() = non_neg_integer() | infinity Maximum number of connections allowed on this listener. +This is a soft limit. The actual number of connections might be slightly above the limit due to concurrency when accepting new connections. Some connections may also be removed from this count explicitly by the user code. +opt() opt() = {ack_timeout, timeout()} | {connection_type, worker | supervisor} | {max_connections, max_conns()} | {shutdown, timeout() | brutal_kill} | {socket, any()} Ranch-specific transport options.</description> </item> <item> @@ -6713,9 +7073,23 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/manual/ranch/</guid> <description>Name ranch - socket acceptor pool - Description The ranch module provides functions for starting and manipulating Ranch listeners. - Types max_conns() = non_neg_integer() | infinity Maximum number of connections allowed on this listener. - This is a soft limit. The actual number of connections might be slightly above the limit due to concurrency when accepting new connections. Some connections may also be removed from this count explicitly by the user code.</description> +Description The ranch module provides functions for starting and manipulating Ranch listeners. +Types max_conns() = non_neg_integer() | infinity Maximum number of connections allowed on this listener. +This is a soft limit. The actual number of connections might be slightly above the limit due to concurrency when accepting new connections. Some connections may also be removed from this count explicitly by the user code. +opt() opt() = {ack_timeout, timeout()} | {connection_type, worker | supervisor} | {max_connections, max_conns()} | {num_acceptors, pos_integer()} | {shutdown, timeout() | brutal_kill} | {socket, any()} Ranch-specific transport options.</description> + </item> + + <item> + <title>ranch(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch/</guid> + <description>Name ranch - socket acceptor pool +Description The ranch module provides functions for starting and manipulating Ranch listeners. +Types max_conns() = non_neg_integer() | infinity Maximum number of connections allowed on this listener. +This is a soft limit. The actual number of connections might be slightly above the limit due to concurrency when accepting new connections. Some connections may also be removed from this count explicitly by the user code. +opt() opt() = {ack_timeout, timeout()} | {connection_type, worker | supervisor} | {max_connections, max_conns()} | {num_acceptors, pos_integer()} | {shutdown, timeout() | brutal_kill} | {socket, any()} Ranch-specific transport options.</description> </item> <item> @@ -6725,10 +7099,11 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch_app/</guid> <description>Name ranch - Socket acceptor pool for TCP protocols. - Dependencies The ranch application has no particular dependency required to start. - It has optional dependencies that are only required when listening for SSL connections. The dependencies are crypto, asn1, public_key and ssl. They are started automatically if they weren&#8217;t before. - Environment The ranch application defines one application environment configuration parameter. - profile (false) When enabled, Ranch will start eprof profiling automatically.</description> +Dependencies The ranch application has no particular dependency required to start. +It has optional dependencies that are only required when listening for SSL connections. The dependencies are crypto, asn1, public_key and ssl. They are started automatically if they weren&apos;t before. +Environment The ranch application defines one application environment configuration parameter. +profile (false) When enabled, Ranch will start eprof profiling automatically. + You can use the ranch_app:profile_output/0 function to stop profiling and output the results to the files procs.</description> </item> <item> @@ -6738,9 +7113,10 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch_app/</guid> <description>Name ranch - Socket acceptor pool for TCP protocols. - Dependencies The ranch application depends on the ssl application to start. It is used for handling secure connections, when the transport is ranch_ssl. It can be disabled if SSL is not used. - Environment The ranch application defines one application environment configuration parameter. - profile (false) When enabled, Ranch will start eprof profiling automatically.</description> +Dependencies The ranch application depends on the ssl application to start. It is used for handling secure connections, when the transport is ranch_ssl. It can be disabled if SSL is not used. +Environment The ranch application defines one application environment configuration parameter. +profile (false) When enabled, Ranch will start eprof profiling automatically. + You can use the ranch_app:profile_output/0 function to stop profiling and output the results to the files procs.</description> </item> <item> @@ -6750,9 +7126,23 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_app/</guid> <description>Name ranch - Socket acceptor pool for TCP protocols. - Dependencies The ranch application depends on the ssl application to start. It is used for handling secure connections, when the transport is ranch_ssl. It can be disabled if SSL is not used. - Environment The ranch application defines one application environment configuration parameter. - profile (false) When enabled, Ranch will start eprof profiling automatically.</description> +Dependencies The ranch application depends on the ssl application to start. It is used for handling secure connections, when the transport is ranch_ssl. It can be disabled if SSL is not used. +Environment The ranch application defines one application environment configuration parameter. +profile (false) When enabled, Ranch will start eprof profiling automatically. + You can use the ranch_app:profile_output/0 function to stop profiling and output the results to the files procs.</description> + </item> + + <item> + <title>ranch(7)</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch_app/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch_app/</guid> + <description>Name ranch - Socket acceptor pool for TCP protocols. +Dependencies The ranch application depends on the ssl application to start. It is used for handling secure connections, when the transport is ranch_ssl. It can be disabled if SSL is not used. +Environment The ranch application defines one application environment configuration parameter. +profile (false) When enabled, Ranch will start eprof profiling automatically. + You can use the ranch_app:profile_output/0 function to stop profiling and output the results to the files procs.</description> </item> <item> @@ -6762,9 +7152,13 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch_protocol/</guid> <description>Name ranch_protocol - behaviour for protocol modules - Description The ranch_protocol behaviour defines the interface used by Ranch protocols. - Types None. - Callbacks start_link(Ref, Socket, Transport, ProtoOpts) &#8594; {ok, pid()} | {ok, pid(), pid()} Ref = ranch:ref() Listener name. Socket = any() Socket for this connection. Transport = module() Transport module for this socket.</description> +Description The ranch_protocol behaviour defines the interface used by Ranch protocols. +Types None. +Callbacks start_link(Ref, Socket, Transport, ProtoOpts) -&gt; {ok, pid()} | {ok, pid(), pid()} Ref = ranch:ref() Listener name. + Socket = any() Socket for this connection. + Transport = module() Transport module for this socket. + ProtoOpts = any() Protocol options. + Start a new connection process for the given socket.</description> </item> <item> @@ -6774,9 +7168,13 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch_protocol/</guid> <description>Name ranch_protocol - behaviour for protocol modules - Description The ranch_protocol behaviour defines the interface used by Ranch protocols. - Types None. - Callbacks start_link(Ref, Socket, Transport, ProtoOpts) &#8594; {ok, pid()} | {ok, pid(), pid()} Ref = ranch:ref() Listener name. Socket = any() Socket for this connection. Transport = module() Transport module for this socket.</description> +Description The ranch_protocol behaviour defines the interface used by Ranch protocols. +Types None. +Callbacks start_link(Ref, Socket, Transport, ProtoOpts) -&gt; {ok, pid()} | {ok, pid(), pid()} Ref = ranch:ref() Listener name. + Socket = any() Socket for this connection. + Transport = module() Transport module for this socket. + ProtoOpts = any() Protocol options. + Start a new connection process for the given socket.</description> </item> <item> @@ -6786,9 +7184,29 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_protocol/</guid> <description>Name ranch_protocol - behaviour for protocol modules - Description The ranch_protocol behaviour defines the interface used by Ranch protocols. - Types None. - Callbacks start_link(Ref, Socket, Transport, ProtoOpts) &#8594; {ok, pid()} | {ok, pid(), pid()} Ref = ranch:ref() Listener name. Socket = any() Socket for this connection. Transport = module() Transport module for this socket.</description> +Description The ranch_protocol behaviour defines the interface used by Ranch protocols. +Types None. +Callbacks start_link(Ref, Socket, Transport, ProtoOpts) -&gt; {ok, pid()} | {ok, pid(), pid()} Ref = ranch:ref() Listener name. + Socket = any() Socket for this connection. + Transport = module() Transport module for this socket. + ProtoOpts = any() Protocol options. + Start a new connection process for the given socket.</description> + </item> + + <item> + <title>ranch_protocol(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch_protocol/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch_protocol/</guid> + <description>Name ranch_protocol - behaviour for protocol modules +Description The ranch_protocol behaviour defines the interface used by Ranch protocols. +Types None. +Callbacks start_link(Ref, Socket, Transport, ProtoOpts) -&gt; {ok, pid()} | {ok, pid(), pid()} Ref = ranch:ref() Listener name. + Socket = any() Socket for this connection. + Transport = module() Transport module for this socket. + ProtoOpts = any() Protocol options. + Start a new connection process for the given socket.</description> </item> <item> @@ -6798,8 +7216,8 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch_ssl/</guid> <description>Name ranch_ssl - SSL transport module - Description The ranch_ssl module implements an SSL Ranch transport. - Types ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {cacertfile, string()} | {cacerts, [public_key:der_encoded()]} | {cert, public_key:der_encoded()} | {certfile, string()} | {ciphers, [ssl:erl_cipher_suite()] | string()} | {client_renegotiation, boolean()} | {crl_cache, {module(), {internal | any(), list()}}} | {crl_check, boolean() | peer | best_effort} | {depth, 0..255} | {dh, public_key:der_encoded()} | {dhfile, string()} | {fail_if_no_peer_cert, boolean()} | {hibernate_after, integer() | undefined} | {honor_cipher_order, boolean()} | {key, {'RSAPrivateKey' | 'DSAPrivateKey' | 'PrivateKeyInfo', public_key:der_encoded()}} | {keyfile, string()} | {log_alert, boolean()} | {next_protocols_advertised, [binary()]} | {partial_chain, fun(([public_key:der_encoded()]) -&gt; {trusted_ca, public_key:der_encoded()} | unknown_ca)} | {password, string()} | {psk_identity, string()} | {reuse_session, fun()} | {reuse_sessions, boolean()} | {secure_renegotiate, boolean()} | {sni_fun, fun()} | {sni_hosts, [{string(), ssl_opt()}]} | {user_lookup_fun, {fun(), any()}} | {verify, ssl:verify_type()} | {verify_fun, {fun(), any()}} | {versions, [atom()]}.</description> +Description The ranch_ssl module implements an SSL Ranch transport. +Types ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {cacertfile, string()} | {cacerts, [public_key:der_encoded()]} | {cert, public_key:der_encoded()} | {certfile, string()} | {ciphers, [ssl:erl_cipher_suite()] | string()} | {client_renegotiation, boolean()} | {crl_cache, {module(), {internal | any(), list()}}} | {crl_check, boolean() | peer | best_effort} | {depth, 0..255} | {dh, public_key:der_encoded()} | {dhfile, string()} | {fail_if_no_peer_cert, boolean()} | {hibernate_after, integer() | undefined} | {honor_cipher_order, boolean()} | {key, {'RSAPrivateKey' | 'DSAPrivateKey' | 'PrivateKeyInfo', public_key:der_encoded()}} | {keyfile, string()} | {log_alert, boolean()} | {next_protocols_advertised, [binary()]} | {partial_chain, fun(([public_key:der_encoded()]) -&gt; {trusted_ca, public_key:der_encoded()} | unknown_ca)} | {password, string()} | {psk_identity, string()} | {reuse_session, fun()} | {reuse_sessions, boolean()} | {secure_renegotiate, boolean()} | {sni_fun, fun()} | {sni_hosts, [{string(), ssl_opt()}]} | {user_lookup_fun, {fun(), any()}} | {verify, ssl:verify_type()} | {verify_fun, {fun(), any()}} | {versions, [atom()]}.</description> </item> <item> @@ -6809,8 +7227,8 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch_ssl/</guid> <description>Name ranch_ssl - SSL transport module - Description The ranch_ssl module implements an SSL Ranch transport. - Types ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {beast_mitigation, one_n_minus_one | zero_n | disabled} | {cacertfile, string()} | {cacerts, [public_key:der_encoded()]} | {cert, public_key:der_encoded()} | {certfile, string()} | {ciphers, [ssl:erl_cipher_suite()] | string()} | {client_renegotiation, boolean()} | {crl_cache, {module(), {internal | any(), list()}}} | {crl_check, boolean() | peer | best_effort} | {depth, 0.</description> +Description The ranch_ssl module implements an SSL Ranch transport. +Types ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {beast_mitigation, one_n_minus_one | zero_n | disabled} | {cacertfile, string()} | {cacerts, [public_key:der_encoded()]} | {cert, public_key:der_encoded()} | {certfile, string()} | {ciphers, [ssl:erl_cipher_suite()] | string()} | {client_renegotiation, boolean()} | {crl_cache, {module(), {internal | any(), list()}}} | {crl_check, boolean() | peer | best_effort} | {depth, 0..255} | {dh, public_key:der_encoded()} | {dhfile, string()} | {fail_if_no_peer_cert, boolean()} | {hibernate_after, integer() | undefined} | {honor_cipher_order, boolean()} | {key, {'RSAPrivateKey' | 'DSAPrivateKey' | 'PrivateKeyInfo', public_key:der_encoded()}} | {keyfile, string()} | {log_alert, boolean()} | {next_protocols_advertised, [binary()]} | {padding_check, boolean()} | {partial_chain, fun(([public_key:der_encoded()]) -&gt; {trusted_ca, public_key:der_encoded()} | unknown_ca)} | {password, string()} | {psk_identity, string()} | {reuse_session, fun()} | {reuse_sessions, boolean()} | {secure_renegotiate, boolean()} | {signature_algs, [{atom(), atom()}]} | {sni_fun, fun()} | {sni_hosts, [{string(), ssl_opt()}]} | {user_lookup_fun, {fun(), any()}} | {v2_hello_compatible, boolean()} | {verify, ssl:verify_type()} | {verify_fun, {fun(), any()}} | {versions, [atom()]}.</description> </item> <item> @@ -6820,8 +7238,19 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_ssl/</guid> <description>Name ranch_ssl - SSL transport module - Description The ranch_ssl module implements an SSL Ranch transport. - Types ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {beast_mitigation, one_n_minus_one | zero_n | disabled} | {cacertfile, string()} | {cacerts, [public_key:der_encoded()]} | {cert, public_key:der_encoded()} | {certfile, string()} | {ciphers, [ssl:erl_cipher_suite()] | string()} | {client_renegotiation, boolean()} | {crl_cache, {module(), {internal | any(), list()}}} | {crl_check, boolean() | peer | best_effort} | {depth, 0.</description> +Description The ranch_ssl module implements an SSL Ranch transport. +Types ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {beast_mitigation, one_n_minus_one | zero_n | disabled} | {cacertfile, string()} | {cacerts, [public_key:der_encoded()]} | {cert, public_key:der_encoded()} | {certfile, string()} | {ciphers, [ssl:erl_cipher_suite()] | string()} | {client_renegotiation, boolean()} | {crl_cache, {module(), {internal | any(), list()}}} | {crl_check, boolean() | peer | best_effort} | {depth, 0..255} | {dh, public_key:der_encoded()} | {dhfile, string()} | {fail_if_no_peer_cert, boolean()} | {hibernate_after, integer() | undefined} | {honor_cipher_order, boolean()} | {key, {'RSAPrivateKey' | 'DSAPrivateKey' | 'PrivateKeyInfo', public_key:der_encoded()}} | {keyfile, string()} | {log_alert, boolean()} | {next_protocols_advertised, [binary()]} | {padding_check, boolean()} | {partial_chain, fun(([public_key:der_encoded()]) -&gt; {trusted_ca, public_key:der_encoded()} | unknown_ca)} | {password, string()} | {psk_identity, string()} | {reuse_session, fun()} | {reuse_sessions, boolean()} | {secure_renegotiate, boolean()} | {signature_algs, [{atom(), atom()}]} | {sni_fun, fun()} | {sni_hosts, [{string(), ssl_opt()}]} | {user_lookup_fun, {fun(), any()}} | {v2_hello_compatible, boolean()} | {verify, ssl:verify_type()} | {verify_fun, {fun(), any()}} | {versions, [atom()]}.</description> + </item> + + <item> + <title>ranch_ssl(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch_ssl/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch_ssl/</guid> + <description>Name ranch_ssl - SSL transport module +Description The ranch_ssl module implements an SSL Ranch transport. +Types ssl_opt() ssl_opt() = {alpn_preferred_protocols, [binary()]} | {beast_mitigation, one_n_minus_one | zero_n | disabled} | {cacertfile, string()} | {cacerts, [public_key:der_encoded()]} | {cert, public_key:der_encoded()} | {certfile, string()} | {ciphers, [ssl:erl_cipher_suite()] | string()} | {client_renegotiation, boolean()} | {crl_cache, {module(), {internal | any(), list()}}} | {crl_check, boolean() | peer | best_effort} | {depth, 0..255} | {dh, public_key:der_encoded()} | {dhfile, string()} | {fail_if_no_peer_cert, boolean()} | {hibernate_after, integer() | undefined} | {honor_cipher_order, boolean()} | {key, {'RSAPrivateKey' | 'DSAPrivateKey' | 'PrivateKeyInfo', public_key:der_encoded()}} | {keyfile, string()} | {log_alert, boolean()} | {next_protocols_advertised, [binary()]} | {padding_check, boolean()} | {partial_chain, fun(([public_key:der_encoded()]) -&gt; {trusted_ca, public_key:der_encoded()} | unknown_ca)} | {password, string()} | {psk_identity, string()} | {reuse_session, fun()} | {reuse_sessions, boolean()} | {secure_renegotiate, boolean()} | {signature_algs, [{atom(), atom()}]} | {sni_fun, fun()} | {sni_hosts, [{string(), ssl_opt()}]} | {user_lookup_fun, {fun(), any()}} | {v2_hello_compatible, boolean()} | {verify, ssl:verify_type()} | {verify_fun, {fun(), any()}} | {versions, [atom()]}.</description> </item> <item> @@ -6831,9 +7260,9 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch_tcp/</guid> <description>Name ranch_tcp - TCP transport module - Description The ranch_tcp module implements a TCP Ranch transport. - Note that due to bugs in OTP up to at least R16B02, it is recommended to disable async threads when using the sendfile function of this transport, as it can make the threads stuck indefinitely. - Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | {delay_send, boolean()} | {dontroute, boolean()} | {exit_on_close, boolean()} | {fd, non_neg_integer()} | {high_msgq_watermark, non_neg_integer()} | {high_watermark, non_neg_integer()} | inet | inet6 | {ip, inet:ip_address()} | {keepalive, boolean()} | {linger, {boolean(), non_neg_integer()}} | {low_msgq_watermark, non_neg_integer()} | {low_watermark, non_neg_integer()} | {nodelay, boolean()} | {port, inet:port_number()} | {priority, integer()} | {raw, non_neg_integer(), non_neg_integer(), binary()} | {recbuf, non_neg_integer()} | {send_timeout, timeout()} | {send_timeout_close, boolean()} | {sndbuf, non_neg_integer()} | {tos, integer()} Listen options.</description> +Description The ranch_tcp module implements a TCP Ranch transport. +Note that due to bugs in OTP up to at least R16B02, it is recommended to disable async threads when using the sendfile function of this transport, as it can make the threads stuck indefinitely. +Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | {delay_send, boolean()} | {dontroute, boolean()} | {exit_on_close, boolean()} | {fd, non_neg_integer()} | {high_msgq_watermark, non_neg_integer()} | {high_watermark, non_neg_integer()} | inet | inet6 | {ip, inet:ip_address()} | {keepalive, boolean()} | {linger, {boolean(), non_neg_integer()}} | {low_msgq_watermark, non_neg_integer()} | {low_watermark, non_neg_integer()} | {nodelay, boolean()} | {port, inet:port_number()} | {priority, integer()} | {raw, non_neg_integer(), non_neg_integer(), binary()} | {recbuf, non_neg_integer()} | {send_timeout, timeout()} | {send_timeout_close, boolean()} | {sndbuf, non_neg_integer()} | {tos, integer()} Listen options.</description> </item> <item> @@ -6843,9 +7272,9 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch_tcp/</guid> <description>Name ranch_tcp - TCP transport module - Description The ranch_tcp module implements a TCP Ranch transport. - Note that due to bugs in OTP up to at least R16B02, it is recommended to disable async threads when using the sendfile function of this transport, as it can make the threads stuck indefinitely. - Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | {delay_send, boolean()} | {dontroute, boolean()} | {exit_on_close, boolean()} | {fd, non_neg_integer()} | {high_msgq_watermark, non_neg_integer()} | {high_watermark, non_neg_integer()} | inet | inet6 | {ip, inet:ip_address()} | {ipv6_v6only, boolean()} | {keepalive, boolean()} | {linger, {boolean(), non_neg_integer()}} | {low_msgq_watermark, non_neg_integer()} | {low_watermark, non_neg_integer()} | {nodelay, boolean()} | {port, inet:port_number()} | {priority, integer()} | {raw, non_neg_integer(), non_neg_integer(), binary()} | {recbuf, non_neg_integer()} | {send_timeout, timeout()} | {send_timeout_close, boolean()} | {sndbuf, non_neg_integer()} | {tos, integer()} Listen options.</description> +Description The ranch_tcp module implements a TCP Ranch transport. +Note that due to bugs in OTP up to at least R16B02, it is recommended to disable async threads when using the sendfile function of this transport, as it can make the threads stuck indefinitely. +Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | {delay_send, boolean()} | {dontroute, boolean()} | {exit_on_close, boolean()} | {fd, non_neg_integer()} | {high_msgq_watermark, non_neg_integer()} | {high_watermark, non_neg_integer()} | inet | inet6 | {ip, inet:ip_address()} | {ipv6_v6only, boolean()} | {keepalive, boolean()} | {linger, {boolean(), non_neg_integer()}} | {low_msgq_watermark, non_neg_integer()} | {low_watermark, non_neg_integer()} | {nodelay, boolean()} | {port, inet:port_number()} | {priority, integer()} | {raw, non_neg_integer(), non_neg_integer(), binary()} | {recbuf, non_neg_integer()} | {send_timeout, timeout()} | {send_timeout_close, boolean()} | {sndbuf, non_neg_integer()} | {tos, integer()} Listen options.</description> </item> <item> @@ -6855,9 +7284,21 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_tcp/</guid> <description>Name ranch_tcp - TCP transport module - Description The ranch_tcp module implements a TCP Ranch transport. - Note that due to bugs in OTP up to at least R16B02, it is recommended to disable async threads when using the sendfile function of this transport, as it can make the threads stuck indefinitely. - Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | {delay_send, boolean()} | {dontroute, boolean()} | {exit_on_close, boolean()} | {fd, non_neg_integer()} | {high_msgq_watermark, non_neg_integer()} | {high_watermark, non_neg_integer()} | inet | inet6 | {ip, inet:ip_address()} | {ipv6_v6only, boolean()} | {keepalive, boolean()} | {linger, {boolean(), non_neg_integer()}} | {low_msgq_watermark, non_neg_integer()} | {low_watermark, non_neg_integer()} | {nodelay, boolean()} | {port, inet:port_number()} | {priority, integer()} | {raw, non_neg_integer(), non_neg_integer(), binary()} | {recbuf, non_neg_integer()} | {send_timeout, timeout()} | {send_timeout_close, boolean()} | {sndbuf, non_neg_integer()} | {tos, integer()} Listen options.</description> +Description The ranch_tcp module implements a TCP Ranch transport. +Note that due to bugs in OTP up to at least R16B02, it is recommended to disable async threads when using the sendfile function of this transport, as it can make the threads stuck indefinitely. +Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | {delay_send, boolean()} | {dontroute, boolean()} | {exit_on_close, boolean()} | {fd, non_neg_integer()} | {high_msgq_watermark, non_neg_integer()} | {high_watermark, non_neg_integer()} | inet | inet6 | {ip, inet:ip_address()} | {ipv6_v6only, boolean()} | {keepalive, boolean()} | {linger, {boolean(), non_neg_integer()}} | {low_msgq_watermark, non_neg_integer()} | {low_watermark, non_neg_integer()} | {nodelay, boolean()} | {port, inet:port_number()} | {priority, integer()} | {raw, non_neg_integer(), non_neg_integer(), binary()} | {recbuf, non_neg_integer()} | {send_timeout, timeout()} | {send_timeout_close, boolean()} | {sndbuf, non_neg_integer()} | {tos, integer()} Listen options.</description> + </item> + + <item> + <title>ranch_tcp(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch_tcp/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch_tcp/</guid> + <description>Name ranch_tcp - TCP transport module +Description The ranch_tcp module implements a TCP Ranch transport. +Note that due to bugs in OTP up to at least R16B02, it is recommended to disable async threads when using the sendfile function of this transport, as it can make the threads stuck indefinitely. +Types opt() opt() = {backlog, non_neg_integer()} | {buffer, non_neg_integer()} | {delay_send, boolean()} | {dontroute, boolean()} | {exit_on_close, boolean()} | {fd, non_neg_integer()} | {high_msgq_watermark, non_neg_integer()} | {high_watermark, non_neg_integer()} | inet | inet6 | {ip, inet:ip_address()} | {ipv6_v6only, boolean()} | {keepalive, boolean()} | {linger, {boolean(), non_neg_integer()}} | {low_msgq_watermark, non_neg_integer()} | {low_watermark, non_neg_integer()} | {nodelay, boolean()} | {port, inet:port_number()} | {priority, integer()} | {raw, non_neg_integer(), non_neg_integer(), binary()} | {recbuf, non_neg_integer()} | {send_timeout, timeout()} | {send_timeout_close, boolean()} | {sndbuf, non_neg_integer()} | {tos, integer()} Listen options.</description> </item> <item> @@ -6867,10 +7308,12 @@ <guid>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch_transport/</guid> <description>Name ranch_transport - behaviour for transport modules - Description The ranch_transport behaviour defines the interface used by Ranch transports. - Types sendfile_opts() = [{chunk_size, non_neg_integer()}] Options used by the sendfile function and callbacks. - Allows configuring the chunk size, in bytes. Defaults to 8191 bytes. - Callbacks accept(LSocket, Timeout) &#8594; {ok, CSocket} | {error, closed | timeout | atom()} LSocket = CSocket = any() Listening socket.</description> +Description The ranch_transport behaviour defines the interface used by Ranch transports. +Types sendfile_opts() = [{chunk_size, non_neg_integer()}] Options used by the sendfile function and callbacks. +Allows configuring the chunk size, in bytes. Defaults to 8191 bytes. +Callbacks accept(LSocket, Timeout) -&gt; {ok, CSocket} | {error, closed | timeout | atom()} LSocket = CSocket = any() Listening socket. + Timeout = timeout() Accept timeout. + Accept a connection on the given listening socket.</description> </item> <item> @@ -6880,10 +7323,12 @@ <guid>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch_transport/</guid> <description>Name ranch_transport - behaviour for transport modules - Description The ranch_transport behaviour defines the interface used by Ranch transports. - Types sendfile_opts() = [{chunk_size, non_neg_integer()}] Options used by the sendfile function and callbacks. - Allows configuring the chunk size, in bytes. Defaults to 8191 bytes. - Callbacks accept(LSocket, Timeout) &#8594; {ok, CSocket} | {error, closed | timeout | atom()} LSocket = CSocket = any() Listening socket.</description> +Description The ranch_transport behaviour defines the interface used by Ranch transports. +Types sendfile_opts() = [{chunk_size, non_neg_integer()}] Options used by the sendfile function and callbacks. +Allows configuring the chunk size, in bytes. Defaults to 8191 bytes. +Callbacks accept(LSocket, Timeout) -&gt; {ok, CSocket} | {error, closed | timeout | atom()} LSocket = CSocket = any() Listening socket. + Timeout = timeout() Accept timeout. + Accept a connection on the given listening socket.</description> </item> <item> @@ -6893,10 +7338,27 @@ <guid>https://ninenines.eu/docs/en/ranch/1.4/manual/ranch_transport/</guid> <description>Name ranch_transport - behaviour for transport modules - Description The ranch_transport behaviour defines the interface used by Ranch transports. - Types sendfile_opts() = [{chunk_size, non_neg_integer()}] Options used by the sendfile function and callbacks. - Allows configuring the chunk size, in bytes. Defaults to 8191 bytes. - Callbacks accept(LSocket, Timeout) &#8594; {ok, CSocket} | {error, closed | timeout | atom()} LSocket = CSocket = any() Listening socket.</description> +Description The ranch_transport behaviour defines the interface used by Ranch transports. +Types sendfile_opts() = [{chunk_size, non_neg_integer()}] Options used by the sendfile function and callbacks. +Allows configuring the chunk size, in bytes. Defaults to 8191 bytes. +Callbacks accept(LSocket, Timeout) -&gt; {ok, CSocket} | {error, closed | timeout | atom()} LSocket = CSocket = any() Listening socket. + Timeout = timeout() Accept timeout. + Accept a connection on the given listening socket.</description> + </item> + + <item> + <title>ranch_transport(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch_transport/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/ranch/1.5/manual/ranch_transport/</guid> + <description>Name ranch_transport - behaviour for transport modules +Description The ranch_transport behaviour defines the interface used by Ranch transports. +Types sendfile_opts() = [{chunk_size, non_neg_integer()}] Options used by the sendfile function and callbacks. +Allows configuring the chunk size, in bytes. Defaults to 8191 bytes. +Callbacks accept(LSocket, Timeout) -&gt; {ok, CSocket} | {error, closed | timeout | atom()} LSocket = CSocket = any() Listening socket. + Timeout = timeout() Accept timeout. + Accept a connection on the given listening socket.</description> </item> </channel> |