diff options
Diffstat (limited to 'index.xml')
| -rw-r--r-- | index.xml | 2885 |
1 files changed, 2045 insertions, 840 deletions
@@ -2,12 +2,841 @@ <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>Nine Nines</title> - <link>https://ninenines.eu/index.xml</link> + <link>https://ninenines.eu/</link> <description>Recent content on Nine Nines</description> <generator>Hugo -- gohugo.io</generator> <language>en-us</language> <lastBuildDate>Wed, 23 Aug 2017 18:00:00 +0100</lastBuildDate> - <atom:link href="https://ninenines.eu/index.xml" rel="self" type="application/rss+xml" /> + + <atom:link href="https://ninenines.eu/index.xml" rel="self" type="application/rss+xml" /> + + + <item> + <title>Installation</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/installation/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Introduction</title> + <link>https://ninenines.eu/docs/en/gun/1.0/guide/introduction/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/gun/1.0/guide/introduction/</guid> + <description>Gun is an Erlang HTTP client with support for HTTP/1.1, HTTP/2 and Websocket. + 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. + Gun is developed for Erlang 18+. + Gun may be compiled on earlier Erlang versions with small source code modifications but there is no guarantee that it will work as intended.</description> + </item> + + <item> + <title>Introduction</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/guide/introduction/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Introduction</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/guide/introduction/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>The modern Web</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/modern_web/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Erlang and the Web</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/erlang_web/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Getting started</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/getting_started/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Listeners</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/guide/listeners/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Listeners</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/guide/listeners/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Starting and stopping</title> + <link>https://ninenines.eu/docs/en/gun/1.0/guide/start/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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 Before Gun can be used it needs to be in Erlang&#8217;s ERL_LIBS path variable. If you use erlang.mk or a similar build tool, you only need to specify Gun as a dependency to your application and the tool will take care of downloading Gun and setting up paths. + With erlang.mk this is done by adding gun to the DEPS variable in your Makefile.</description> + </item> + + <item> + <title>Supported protocols</title> + <link>https://ninenines.eu/docs/en/gun/1.0/guide/protocols/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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 each respective methods. Gun also provides a gun:data/4 function for streaming the request body. + Gun will send a gun_response message for every response received, followed by zero or more gun_data messages for the response body.</description> + </item> + + <item> + <title>Introduction</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/introduction/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Transports</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/guide/transports/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Transports</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/guide/transports/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Overview</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/overview/</link> + <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> + </item> + + <item> + <title>Connection</title> + <link>https://ninenines.eu/docs/en/gun/1.0/guide/connect/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Protocols</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/guide/protocols/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Protocols</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/guide/protocols/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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/5.</description> + </item> + + <item> + <title>Getting started</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/getting_started/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Updating Erlang.mk</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/updating/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>HTTP</title> + <link>https://ninenines.eu/docs/en/gun/1.0/guide/http/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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(s) 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> + <title>Embedded mode</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/guide/embedded/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Embedded mode</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/guide/embedded/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Limitations</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/limitations/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Flow diagram</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/flow_diagram/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Websocket</title> + <link>https://ninenines.eu/docs/en/gun/1.0/guide/websocket/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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. + @todo recovering from connection failure reconnecting to Websocket etc. + 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.</description> + </item> + + <item> + <title>Writing parsers</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/guide/parsers/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Writing parsers</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/guide/parsers/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Building</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/app/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Listeners</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/listeners/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>SSL client authentication</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/guide/ssl_auth/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>SSL client authentication</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/guide/ssl_auth/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Packages and dependencies</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/deps/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Routing</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/routing/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>NIFs and port drivers</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/ports/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Internals</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/guide/internals/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Internals</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/guide/internals/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Constraints</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/constraints/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Releases</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/releases/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Self-extracting releases</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/sfx/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Handlers</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/handlers/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Escripts</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/escripts/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Loop handlers</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/loop_handlers/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>OTP version management</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/kerl/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Static files</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/static_files/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Compatibility with other build tools</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/compat/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>AsciiDoc documentation</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/asciidoc/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>The Req object</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/req/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Reading the request body</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/req_body/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>EDoc comments</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/edoc/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Erlang shell</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/shell/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Sending a response</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/resp/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>EUnit</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/eunit/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Using cookies</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/cookies/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Common Test</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/common_test/</link> + <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> + </item> + + <item> + <title>Multipart requests</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/multipart/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Code coverage</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/coverage/</link> + <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> + </item> + + <item> + <title>REST principles</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/rest_principles/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Continuous integration</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/ci/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>REST handlers</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/rest_handlers/</link> + <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> + </item> + + <item> + <title>Dialyzer</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/dialyzer/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Xref</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/xref/</link> + <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> + </item> + + <item> + <title>REST flowcharts</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/rest_flowcharts/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>External plugins</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/external_plugins/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Designing a resource handler</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/resource_design/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>List of plugins</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/external_plugins_list/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>The Websocket protocol</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/ws_protocol/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Why Erlang.mk</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/why/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Websocket handlers</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/ws_handlers/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Short history</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/history/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Streams</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/streams/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Contributing</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/contributing/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Middlewares</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/middlewares/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Migrating from Cowboy 1.0 to 2.0</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/migrating_from_1.0/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>HTTP and other specifications</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/specs/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> <item> <title>Cowboy 2.0 release candidate 2</title> @@ -15,42 +844,10 @@ <pubDate>Wed, 23 Aug 2017 18:00:00 +0100</pubDate> <guid>https://ninenines.eu/articles/cowboy-2.0.0-rc.2/</guid> - <description><div class="paragraph"><p>Cowboy <code>2.0.0-rc.2</code> has been released!</p></div>
-<div class="paragraph"><p>This is the new recommended version of Cowboy.
-Its API should not change before release. While
-you probably should not use it in production yet,
-many do successfully. Use at your own risk.</p></div>
-<div class="paragraph"><p>This new version contains fixes for the following
-issues:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-HTTP/2 server push was using the wrong header
- compression context.
-</p>
-</li>
-<li>
-<p>
-HTTP/2 flow control could end up queueing data
- in the wrong order when resuming the sending of
- data.
-</p>
-</li>
-<li>
-<p>
-The <code>shutdown</code> timeout was not implemented
- and request processes could be killed too quickly.
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>What else is new in Cowboy 2.0? Check the
-<a href="https://ninenines.eu/articles/cowboy-2.0.0-rc.1">rc.1 announcement</a>.</p></div>
-<div class="paragraph"><p>Please test this new release candidate and provide
-feedback! The best place to provide feedback is via
-tickets. Do not hesitate to open a ticket or bring
-an existing ticket to my attention to get it resolved
-before 2.0.</p></div>
-</description> + <description>Cowboy 2.0.0-rc.2 has been released! + This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk. + This new version contains fixes for the following issues: + HTTP/2 server push was using the wrong header compression context. HTTP/2 flow control could end up queueing data in the wrong order when resuming the sending of data.</description> </item> <item> @@ -59,63 +856,9 @@ before 2.0.</p></div> <pubDate>Mon, 24 Jul 2017 18:00:00 +0100</pubDate> <guid>https://ninenines.eu/articles/cowboy-2.0.0-rc.1/</guid> - <description><div class="paragraph"><p>Cowboy <code>2.0.0-rc.1</code> has been released!</p></div>
-<div class="paragraph"><p>This is the new recommended version of Cowboy.
-Its API should not change before release. While
-you probably should not use it in production yet,
-many do successfully. Use at your own risk.</p></div>
-<div class="paragraph"><p>The plan is to have a new RC version every couple
-weeks until the summer ends or later if there are
-still blocking issues open. Only issues that can&#8217;t
-be fixed without making breaking changes to the
-interface may block the release.</p></div>
-<div class="paragraph"><p>Numerous changes were made since Cowboy 1.0. The
-one most people care about is probably HTTP/2, but
-it&#8217;s most likely not the only one worthwhile. The
-full list of changes (excluding types) can be found
-in the user guide chapter
-<a href="https://ninenines.eu/docs/en/cowboy/2.0/guide/migrating_from_1.0/">Migrating from Cowboy 1.0 to 2.0</a>.</p></div>
-<div class="paragraph"><p>As this is not the full release just yet, please pay
-extra attention to details and report anything
-suspicious you find.</p></div>
-<div class="paragraph"><p>There are still some tests failing. Most of those are
-related to standards that are not being followed perfectly
-just yet. Some of those will probably not be fixed before
-Cowboy 2.0 is released. They are edge cases and should not
-prevent interoperability.</p></div>
-<div class="paragraph"><p>The manual received a lot of love. It now has one page per
-function with a detailed description, arguments list, return
-value, changelog and examples. It also links to the other
-relevant manual pages: <a href="https://ninenines.eu/docs/en/cowboy/2.0/manual/">https://ninenines.eu/docs/en/cowboy/2.0/manual/</a></p></div>
-<div class="paragraph"><p>Cowboy is now tested and supported with Erlang/OTP 19.0 or above
-on Arch Linux, FreeBSD, OSX, Ubuntu and Windows 7. Contact me
-if you can provide permanent access to another platform for the
-purposes of testing.</p></div>
-<div class="paragraph"><p>Cowboy is now available from four locations:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-<a href="https://git.ninenines.eu/cowboy.git">https://git.ninenines.eu/cowboy.git</a>
-</p>
-</li>
-<li>
-<p>
-<a href="https://github.com/ninenines/cowboy.git">https://github.com/ninenines/cowboy.git</a>
-</p>
-</li>
-<li>
-<p>
-<a href="https://bitbucket.org/ninenines/cowboy.git">https://bitbucket.org/ninenines/cowboy.git</a>
-</p>
-</li>
-<li>
-<p>
-<a href="https://gitlab.com/ninenines/cowboy.git">https://gitlab.com/ninenines/cowboy.git</a>
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>They are updated at the same time so there is no real difference.</p></div>
-</description> + <description>Cowboy 2.0.0-rc.1 has been released! + This is the new recommended version of Cowboy. Its API should not change before release. While you probably should not use it in production yet, many do successfully. Use at your own risk. + The plan is to have a new RC version every couple weeks until the summer ends or later if there are still blocking issues open. Only issues that can&#8217;t be fixed without making breaking changes to the interface may block the release.</description> </item> <item> @@ -124,140 +867,8 @@ purposes of testing.</p></div> <pubDate>Sun, 26 Mar 2017 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/articles/the-elephant-in-the-room/</guid> - <description><div class="paragraph"><p>Have you ever tried telling someone why they should use
-Erlang? You boast the smaller code size, the auto healing
-mechanisms, the distribution and they seem really excited.
-They wonder why they never heard about Erlang before. And
-then you show them what the code looks like. All excitement
-goes away. The smiles disappear. Their face starts
-becoming really serious.</p></div>
-<div class="paragraph"><p>You lost them. You know you lost them. They comment on the
-syntax, or perhaps you do, already admitting defeat. It&#8217;s
-unlike anything they have ever used before. And they will
-most likely end up not using it.</p></div>
-<div class="paragraph"><p>What about people who already know what the syntax looks
-like? As soon as you mention Erlang, the topic of the syntax
-comes in. It&#8217;s like nothing else matters.</p></div>
-<div class="paragraph"><p>Perhaps the topic of syntax didn&#8217;t come up. But they&#8217;re
-still not going to try Erlang because of it.</p></div>
-<div class="paragraph"><p>You&#8217;re probably not having these kinds of interactions at
-Erlang conferences. This doesn&#8217;t happen with people who are
-already somewhat interested in, or need, the features that
-Erlang provides. With them the syntax is at worst a minor
-inconvenience.</p></div>
-<div class="paragraph"><p>This happens because most developers are familiar with
-syntaxes that look nothing like Erlang. To be clear, I
-include language features and other concepts like objects
-as part of "syntax" here. Familiarity is a very important
-factor to drive adoption.</p></div>
-<div class="paragraph"><p>You can see an example of that in the Elixir world, where
-the majority of people come from Ruby or already knew and
-liked Ruby. The 2016 survey tells us that 59% of Elixir
-developers were using Ruby primarily before. That&#8217;s in
-large part because of the syntax. They will deny it of
-course and find other reasons. And yet, we don&#8217;t see such
-a strong adoption of Erlang from Ruby developers, before
-or after Elixir appeared.</p></div>
-<div class="paragraph"><p>Side note: have you ever wondered why the Elixir community
-is, I quote, much friendlier than the Ruby community?
-Despite having much of the same people?</p></div>
-<div class="paragraph"><p>Before we continue, let me be clear. I love the Erlang
-syntax. It is simple and explicit. It is powerful, especially
-when dealing with binary data. It has very few quirks.
-It has little to no ambiguity. It&#8217;s great. Except for
-persuading people to use it.</p></div>
-<div class="paragraph"><p>Over the years I have been writing Erlang, I have seen
-very few people point out that the syntax slows down
-adoption. We have no problem with it, so why would others?
-At the same time, people coming to Erlang come to solve
-a real problem they&#8217;re having, so the syntax is fairly
-secondary. Even if they hate it at first, they know they
-can solve their problems despite the syntax.</p></div>
-<div class="paragraph"><p>You don&#8217;t build a popular product or language by solving
-people&#8217;s problems though. In general you end up solving
-some problems and creating new problems. No, you build
-a popular product by <strong>convincing people to use it</strong>. And
-you make them stay with your product by making them
-<strong>commit</strong> to using it.</p></div>
-<div class="paragraph"><p>Take MongoDB for example. It didn&#8217;t become popular by
-working, or even by being practical. It wasn&#8217;t performing
-its primary function and was losing people&#8217;s data. That
-didn&#8217;t stop it from becoming popular. Smart people would
-knowingly use a database that was losing data. Think about
-that for a minute.</p></div>
-<div class="paragraph"><p>MongoDB of course had a huge marketing machine, and they
-focused on that. They helped organize many meetups all
-over the world, complete with various swag items given
-for free, including a small handbook about MongoDB. All
-people had to do was show up.</p></div>
-<div class="paragraph"><p>They didn&#8217;t go tell people to look at all the weaknesses
-their product had. They focused on the strengths. On
-what would convince people to try it. They would go
-to meetups, discuss with others, commit to try it (or
-try it at meetups directly), and by doing so sell MongoDB
-to themselves.</p></div>
-<div class="paragraph"><p>How do we get people to meetups though? That&#8217;d be the
-first step: you need to <strong>catch their attention</strong>.
-I believe MongoDB did this using benchmark results.
-Ironic isn&#8217;t it? MongoDB gets fast benchmark results
-because they lose data, and this gets everyone to buy
-into the product.</p></div>
-<div class="paragraph"><p>The key points to remember about this are:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-catch people&#8217;s attention
-</p>
-</li>
-<li>
-<p>
-show your product&#8217;s strengths
-</p>
-</li>
-<li>
-<p>
-make people take a commitment
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>Once they commit to something, you win. Everyone will not
-end up ultimately using your product of course, but it&#8217;s
-at the very least become a consideration. It&#8217;s on their
-mind. Their resolve will be stronger when they ultimately
-try it and inevitably run into issues.</p></div>
-<div class="paragraph"><p>Erlang&#8217;s syntax is a weakness. Almost nobody looks at the
-Erlang syntax and falls in love with it at first sight.
-No, it takes time to learn it and understand how good it
-is. You need to sell Erlang to people without showing
-the Erlang syntax. If you do show it, then you need to
-hide the parts that feel alien. Function calls are OK.
-Recursion, not so much. Maps are OK. Records, not.</p></div>
-<div class="paragraph"><p>Avoiding code is not always possible when you try
-to sell it, especially to developers. You can however
-prepare them to accept the alien syntax by admitting
-that the syntax is not perfect before you show it.
-You can do this while praising it at the same time.
-For example, "the syntax is a little out there, but
-it matches the concepts perfectly, it will all make
-sense when you start learning".</p></div>
-<div class="paragraph"><p>This might not be the best introduction. Someone will
-need to A/B test it to find the one that gives the
-best results. But that should give you ideas.</p></div>
-<div class="paragraph"><p>When something terrible happens, mentioning that this
-isn&#8217;t the end of the world <strong>before</strong> you tell others what
-happened will soften their reaction. When someone
-breaks your favorite item and cries over it calling
-themselves stupid, it&#8217;s harder to get mad at them,
-compared to the same event with no emotional reaction.</p></div>
-<div class="paragraph"><p>Our behavior is largely dependent on what&#8217;s at the
-top of our mind, so it&#8217;s up to you to take advantage
-of this to make your case in the best conditions.</p></div>
-<div class="paragraph"><p>Next time you try to make someone use Erlang, remember
-that you should aim for getting a spoken commitment
-out of them, if possible before you show the syntax.
-If that&#8217;s not possible, then prepare them to accept
-the flaws or the weirdness before they see them.</p></div>
-</description> + <description>Have you ever tried telling someone why they should use Erlang? You boast the smaller code size, the auto healing mechanisms, the distribution and they seem really excited. They wonder why they never heard about Erlang before. And then you show them what the code looks like. All excitement goes away. The smiles disappear. Their face starts becoming really serious. + You lost them. You know you lost them. They comment on the syntax, or perhaps you do, already admitting defeat.</description> </item> <item> @@ -266,119 +877,8 @@ the flaws or the weirdness before they see them.</p></div> <pubDate>Sun, 22 Jan 2017 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/articles/dont-let-it-crash/</guid> - <description><div class="paragraph"><p>We have a specific mindset when writing Erlang
-programs. We focus on the normal execution of the
-program and don&#8217;t handle most of the errors that may
-occur. We sometimes call this normal execution the
-<em>happy path</em>.</p></div>
-<div class="paragraph"><p>The general pattern behind writing only for the
-<em>happy path</em>, letting the VM catch errors (writing
-them to a log for future consumption) and then
-having a supervisor restart the processes that
-failed from a clean state, has a name. We call it
-<em>let it crash</em>; and it drives many of our design
-decisions.</p></div>
-<div class="paragraph"><p>It&#8217;s a really great way to program and the results
-are fantastic compared to most other programming
-languages. And yet, <em>let it crash</em> barely convinced
-anyone that they should use Erlang. Why would that
-be?</p></div>
-<div class="paragraph"><p>You may already know that Cowboy is capable of
-handling at least 2 million Websocket connections
-on a single server. This is in large part thanks
-to the capabilities of the VM. Still, 2 million
-is good, much better than most other servers can
-do.</p></div>
-<div class="paragraph"><p>Cowboy is not just a Websocket server; it&#8217;s also
-an HTTP and HTTP/2 server, and it handles many
-related features like long polling or the parsing
-of most request headers.</p></div>
-<div class="paragraph"><p>Can you guess how large the Cowboy codebase is,
-without looking at the source?</p></div>
-<div class="paragraph"><p>Do make sure you have a clear answer in your mind
-before you go check.</p></div>
-<div class="paragraph"><p>Good, you are back. Now what were the results? If
-I am correct, you overestimated the size of Cowboy.
-Cowboy is in fact about five thousand lines of code.
-You probably thought it was at least ten thousand.
-About eighty percent of readers will have
-overestimated the size of Cowboy. And you did only
-because I mentioned it can handle millions of
-Websocket connections.</p></div>
-<div class="paragraph"><p>Numerous studies show this effect. Just mentioning
-the large number already prepared your mind to think
-in that direction. Repeating the number made you
-focus even more on it. Then the question asked for
-a number, which ended up larger than the reality.</p></div>
-<div class="paragraph"><p>The same effect can be applied to negotiation for
-example. You generally want to start by giving your
-offer (and not let the other party initiate) and
-you want to give a really large number first. You
-can also prepare your customer by mentioning an even
-larger number in the previous discussion.</p></div>
-<div class="paragraph"><p>And it&#8217;s not just numbers either. An experiment
-showed that just by looking at an image of clouds,
-customers of a pillow store were buying pillows
-more comfortable (and more expensive) than those
-who didn&#8217;t see that image.</p></div>
-<div class="paragraph"><p>This is the power of associations. It is covered in
-much larger detail in the books
-<a href="https://www.amazon.com/Influence-Psychology-Persuasion-Robert-Cialdini/dp/006124189X">Influence</a>
-and
-<a href="https://www.amazon.com/Pre-Suasion-Revolutionary-Way-Influence-Persuade/dp/1501109790">Pre-suasion</a>.
-I highly recommend reading those and applying what
-you learn to your daily life. I&#8217;m definitely not
-a professional psychologist so take this post with
-a grain of salt.</p></div>
-<div class="paragraph"><p>When selling Erlang, whether we are selling it to
-a customer or trying to convince a developer friend
-to start using it, we often talk about how Erlang
-<em>lets you sleep at night</em>, that it is auto healing
-and always gets fantastic uptimes.</p></div>
-<div class="paragraph"><p>And then we talk about <em>let it crash</em>.</p></div>
-<div class="paragraph"><p>And we describe what it means.</p></div>
-<div class="paragraph"><p>We might as well just say that Erlang crashes a lot
-and then take the door. It would have the same effect.
-It doesn&#8217;t even stop at programs crashing. You know
-what else crashes? Cars, planes, trains. Often with
-disastrous consequences. Is that really the message
-we want to convey?</p></div>
-<div class="paragraph"><p>They even <a href="https://img.youtube.com/vi/oEUBW2lCkIk/0.jpg">printed it on a t-shirt</a>!
-Keep calm and let it crash. It&#8217;s the kind of t-shirt
-you probably shouldn&#8217;t wear in an airport, and for good
-reasons. A few people did, then realized what they were
-wearing and were not too smug about it.</p></div>
-<div class="paragraph"><p>And yet this is how we sell Erlang.</p></div>
-<div class="paragraph"><p>A better way would be to focus on the positives, of
-course, but also to make sure that those positives
-are phrased in a way that prevents bad associations
-to be formed in people&#8217;s minds.</p></div>
-<div class="paragraph"><p>Instead of <em>let it crash</em>, you can say that Erlang
-has <em>auto healing mechanisms</em>. Healing is a good
-thing and accurately describes what happens in the
-system.</p></div>
-<div class="paragraph"><p>Should you need to go into more details, you will
-probably want to avoid <em>recover from crashes</em> and
-instead say <em>recover from exceptions</em>. Exceptions
-are a pretty neutral word and, should you explain
-what you mean by that, you can talk about exceptions
-that occur for reasons unrelated to Erlang, like
-hardware failure or network instability.</p></div>
-<div class="paragraph"><p>The trick is to always use positive words and
-phrases to describe Erlang, and to use external
-factors to explain how Erlang deals with failures.
-Never mention the failures internal to Erlang
-systems unless you are asked specifically, in
-which case you can say that the auto healing
-applies to all exceptions.</p></div>
-<div class="paragraph"><p>The <em>let it crash</em> philosophy is great when
-learning Erlang or when writing fault-tolerant
-systems. But it&#8217;s not going to convince anyone
-to use it unless they were already looking for
-it.</p></div>
-<div class="paragraph"><p>Do you like this post? Tell me on Twitter. I might
-make more.</p></div>
-</description> + <description>We have a specific mindset when writing Erlang programs. We focus on the normal execution of the program and don&#8217;t handle most of the errors that may occur. We sometimes call this normal execution the happy path. + The general pattern behind writing only for the happy path, letting the VM catch errors (writing them to a log for future consumption) and then having a supervisor restart the processes that failed from a clean state, has a name.</description> </item> <item> @@ -387,117 +887,10 @@ make more.</p></div> <pubDate>Tue, 03 Jan 2017 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/articles/cowboy-2.0.0-pre.4/</guid> - <description><div class="paragraph"><p>Cowboy <code>2.0.0-pre.4</code> has been released!</p></div>
-<div class="paragraph"><p>This is the new recommended version of Cowboy.
-While I would not recommend putting it in production
-just yet, I do recommend you start writing new
-applications with this Cowboy version.</p></div>
-<div class="paragraph"><p>The most significant changes in the pre-release are:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-A new architecture: there now is one process per
- connection and one process per request. This was
- done because HTTP/2 allows running requests concurrently.
-</p>
-</li>
-<li>
-<p>
-Stream handlers. Every request, response and data goes
- through stream handlers. They are meant to replace hooks
- and more. They will be documented in a future pre-release.
- Check <code>cowboy_stream</code> and <code>cowboy_stream_h</code> if interested.
-</p>
-</li>
-<li>
-<p>
-Numerous changes to the <code>cowboy_req</code> interface. This
- is very close to final. Check the manual for what changed.
-</p>
-</li>
-<li>
-<p>
-The Req object is no longer passed in Websocket callbacks.
-</p>
-</li>
-<li>
-<p>
-It is now possible to send frames directly from <code>websocket_init/1</code>.
-</p>
-</li>
-<li>
-<p>
-SPDY support was removed, now that we have HTTP/2.
-</p>
-</li>
-<li>
-<p>
-Update Ranch to 1.3. We still depend on Cowlib master
- for the time being.
-</p>
-</li>
-<li>
-<p>
-A much improved manual.
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>The manual received a lot of love. It now has one page per
-function with a detailed description, arguments list, return
-value, changelog and examples. It also links to the other
-relevant manual pages: <a href="https://ninenines.eu/docs/en/cowboy/2.0/manual/">https://ninenines.eu/docs/en/cowboy/2.0/manual/</a></p></div>
-<div class="paragraph"><p>I am quite proud of the manual right now. While more
-improvements can be made, what we have now is way better
-than before. Feedback for further improvements is welcome!</p></div>
-<div class="paragraph"><p>This is a significant step toward Cowboy 2.0. Almost all
-the breaking changes are in. A few more pre-releases are
-planned and will be released on a weekly basis (with exceptions).</p></div>
-<div class="paragraph"><p>Cowboy is now tested and supported with Erlang/OTP 18.0 or above
-on Arch Linux, FreeBSD, OSX, Ubuntu and Windows 7. Contact me
-if you can provide permanent access to another platform for the
-purposes of testing.</p></div>
-<div class="paragraph"><p>Cowboy is now available from four locations:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-<a href="https://git.ninenines.eu/cowboy.git">https://git.ninenines.eu/cowboy.git</a>
-</p>
-</li>
-<li>
-<p>
-<a href="https://github.com/ninenines/cowboy.git">https://github.com/ninenines/cowboy.git</a>
-</p>
-</li>
-<li>
-<p>
-<a href="https://bitbucket.org/ninenines/cowboy.git">https://bitbucket.org/ninenines/cowboy.git</a>
-</p>
-</li>
-<li>
-<p>
-<a href="https://gitlab.com/ninenines/cowboy.git">https://gitlab.com/ninenines/cowboy.git</a>
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>They are updated at the same time so there is no real difference.</p></div>
-<div class="paragraph"><p>Cowboy 2.0 will be released once all the breaking changes
-are completed and the temporarily removed features are
-added back.</p></div>
-<div class="paragraph"><p>Thanks for your patience. I know it took a long time.</p></div>
-<hr/>
-<div class="paragraph"><p>Half-price on all donations because I need a new hat:</p></div>
-<form action="https://www.paypal.com/cgi-bin/webscr" method="post" style="display:inline">
-<input type="hidden" name="cmd" value="_donations">
-<input type="hidden" name="business" value="[email protected]">
-<input type="hidden" name="lc" value="FR">
-<input type="hidden" name="item_name" value="Loic Hoguin">
-<input type="hidden" name="item_number" value="99s">
-<input type="hidden" name="currency_code" value="EUR">
-<input type="hidden" name="bn" value="PP-DonationsBF:btn_donate_LG.gif:NonHosted">
-<input type="image" src="https://www.paypalobjects.com/en_US/i/btn/btn_donate_LG.gif" border="0" name="submit" alt="PayPal - The safer, easier way to pay online!">
-<img alt="" border="0" src="https://www.paypalobjects.com/fr_FR/i/scr/pixel.gif" width="1" height="1">
-</form>
-</description> + <description>Cowboy 2.0.0-pre.4 has been released! + This is the new recommended version of Cowboy. While I would not recommend putting it in production just yet, I do recommend you start writing new applications with this Cowboy version. + The most significant changes in the pre-release are: + A new architecture: there now is one process per connection and one process per request. This was done because HTTP/2 allows running requests concurrently.</description> </item> <item> @@ -506,89 +899,9 @@ added back.</p></div> <pubDate>Mon, 28 Nov 2016 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/articles/ranch-1.3/</guid> - <description><div class="paragraph"><p>Ranch <code>1.3.0</code> has been released!</p></div>
-<div class="paragraph"><p>This release fixes a number of long standing issues and adds
-a small number of features:</p></div>
-<div class="paragraph"><p>The <code>ssl</code> application has been added to the list of dependencies.
-If you don&#8217;t need it, you can remove it automatically when fetching
-Ranch or when building the release. If you do need it, you will no
-longer have issues shutting down a node because of Ranch.</p></div>
-<div class="paragraph"><p>The <code>ranch:info/0</code> and <code>ranch:procs/2</code> can be used to retrieve
-information about Ranch&#8217;s state. Use it for diagnostic and
-discovery purposes.</p></div>
-<div class="paragraph"><p>SSL listeners can now be configured without a certificate, for setups
-that make use of the SNI extension.</p></div>
-<div class="paragraph"><p>Transport options are now a blacklist, meaning all unknown options
-will be accepted. However Dialyzer will warn if said option is not
-defined in Ranch&#8217;s type specifications. Please send a patch when that
-happens!</p></div>
-<div class="paragraph"><p>Various bugs have been fixed, including the bug where the
-number of active connections could become negative. Common
-errors at listener startup should be easier to read (for
-example when the port is already in use).</p></div>
-<div class="paragraph"><p>See the <a href="https://git.ninenines.eu/ranch.git/plain/CHANGELOG.asciidoc">CHANGELOG</a>
-for more details.</p></div>
-<div class="paragraph"><p>Ranch is now tested and supported with Erlang/OTP R16B or above
-on Arch Linux, FreeBSD, OSX, Ubuntu and Windows 7. Contact me
-if you can provide permanent access to another platform for the
-purposes of testing.</p></div>
-<div class="paragraph"><p>Ranch is now available from four locations:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-<a href="https://git.ninenines.eu/ranch.git">https://git.ninenines.eu/ranch.git</a>
-</p>
-</li>
-<li>
-<p>
-<a href="https://github.com/ninenines/ranch.git">https://github.com/ninenines/ranch.git</a>
-</p>
-</li>
-<li>
-<p>
-<a href="https://bitbucket.org/ninenines/ranch.git">https://bitbucket.org/ninenines/ranch.git</a>
-</p>
-</li>
-<li>
-<p>
-<a href="https://gitlab.com/ninenines/ranch.git">https://gitlab.com/ninenines/ranch.git</a>
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>They are updated at the same time so there is no real difference.</p></div>
-<div class="paragraph"><p>The most recent Ranch commit is now always signed. You can import the
-<a href="https://pgp.mit.edu/pks/lookup?op=vindex&amp;fingerprint=on&amp;exact=on&amp;search=0xF19F189CECC7439699CEDD7A6EF7A77066CCCC8A">signing key for Loïc Hoguin</a> with:</p></div>
-<div class="listingblock">
-<div class="content"><!-- Generator: GNU source-highlight 3.1.8
-by Lorenzo Bettini
-http://www.lorenzobettini.it
-http://www.gnu.org/software/src-highlite -->
-<pre><tt>$ gpg --keyserver hkp<span style="color: #990000">:</span>//keys<span style="color: #990000">.</span>gnupg<span style="color: #990000">.</span>net --recv-key 66CCCC8A</tt></pre></div></div>
-<div class="paragraph"><p>The primary key fingerprint is <code>F19F 189C ECC7 4396 99CE DD7A 6EF7 A770 66CC CC8A</code>.</p></div>
-<div class="paragraph"><p>When verifying signatures in git, the following should appear:</p></div>
-<div class="listingblock">
-<div class="content"><!-- Generator: GNU source-highlight 3.1.8
-by Lorenzo Bettini
-http://www.lorenzobettini.it
-http://www.gnu.org/software/src-highlite -->
-<pre><tt>gpg<span style="color: #990000">:</span> Signature made Sat <span style="color: #993399">26</span> Nov <span style="color: #993399">2016</span> <span style="color: #993399">12</span><span style="color: #990000">:</span><span style="color: #993399">58</span><span style="color: #990000">:</span><span style="color: #993399">35</span> PM CET
-gpg<span style="color: #990000">:</span> using RSA key 71366FF21851DF03
-gpg<span style="color: #990000">:</span> Good signature from <span style="color: #FF0000">"Loïc Hoguin &lt;[email protected]&gt;"</span> <span style="color: #990000">[</span>unknown<span style="color: #990000">]</span>
-gpg<span style="color: #990000">:</span> WARNING<span style="color: #990000">:</span> This key is not certified with a trusted signature<span style="color: #990000">!</span>
-gpg<span style="color: #990000">:</span> There is no indication that the signature belongs to the owner<span style="color: #990000">.</span>
-Primary key fingerprint<span style="color: #990000">:</span> F19F 189C ECC7 <span style="color: #993399">4396</span> 99CE DD7A 6EF7 A770 66CC CC8A
- Subkey fingerprint<span style="color: #990000">:</span> FEDA <span style="color: #993399">6E41</span> B390 F745 A385 5CDC <span style="color: #993399">7136</span> 6FF2 <span style="color: #993399">1851</span> DF03</tt></pre></div></div>
-<div class="paragraph"><p>You can safely ignore the warning if you don&#8217;t know what it
-means, as long as everything else is correct.</p></div>
-<div class="paragraph"><p>Mirrors and signature verification will soon be implemented
-directly in Erlang.mk. In the meantime, you will need to
-set them up manually.</p></div>
-<div class="paragraph"><p>Most of this work was done to fix issues in RabbitMQ. Paid
-customers get priority; contact me if you have some issues
-that need fixing sooner rather than later.</p></div>
-<div class="paragraph"><p>Expect future releases to be announced in this space.</p></div>
-<div class="paragraph"><p>Thanks for reading!</p></div>
-</description> + <description>Ranch 1.3.0 has been released! + This release fixes a number of long standing issues and adds a small number of features: + The ssl application has been added to the list of dependencies. If you don&#8217;t need it, you can remove it automatically when fetching Ranch or when building the release. If you do need it, you will no longer have issues shutting down a node because of Ranch.</description> </item> <item> @@ -597,17 +910,10 @@ that need fixing sooner rather than later.</p></div> <pubDate>Mon, 29 Aug 2016 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/articles/ml-archives/</guid> - <description><div class="paragraph"><p>The <a href="https://ninenines.eu/archives/extend">old mailing list archives</a> have been
-added to the site, mainly for referencing purposes.</p></div>
-<div class="paragraph"><p>The mailing list has been shut down and all personal information
-has been deleted.</p></div>
-<div class="paragraph"><p>If you need help with a project, consider either opening a ticket
-on that project&#8217;s issues tracker or going through the community
-channels (erlang-questions, #ninenines or #erlang on Freenode).</p></div>
-<div class="paragraph"><p>Prefer tickets; often when people have issues it highlights an
-underlying problem in the project or its documentation.</p></div>
-<div class="paragraph"><p>Thanks.</p></div>
-</description> + <description>The old mailing list archives have been added to the site, mainly for referencing purposes. + The mailing list has been shut down and all personal information has been deleted. + If you need help with a project, consider either opening a ticket on that project&#8217;s issues tracker or going through the community channels (erlang-questions, #ninenines or #erlang on Freenode). + Prefer tickets; often when people have issues it highlights an underlying problem in the project or its documentation.</description> </item> <item> @@ -616,64 +922,9 @@ underlying problem in the project or its documentation.</p></div> <pubDate>Sat, 02 Apr 2016 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/articles/website-update/</guid> - <description><div class="paragraph"><p>Last week-end I updated the Nine Nines website.</p></div>
-<div class="paragraph"><p>I switched to <a href="http://gohugo.io/">Hugo</a>. The site is
-now built from <a href="http://asciidoc.org/">Asciidoc</a>
-documents. You probably saw me switch to Asciidoc
-for documentation this past year. This is the
-natural conclusion to that story. The great thing
-is that with a little bit of Makefile magic I can
-just copy the documentation files into Hugo and
-poof, they appear on the website.</p></div>
-<div class="paragraph"><p>I am very happy with that new setup. I can now
-post my thoughts again. Woo! Expect regular posts
-from now on. I will try to replace my long series
-of tweets with posts.</p></div>
-<div class="paragraph"><p>The sections have been rearranged. There used to
-be a separate training section; now
-<a href="https://ninenines.eu/services">all my services</a> are described in
-one page. I have also clarified my areas of
-expertise. There used to be confusion in the past,
-so now it should be clearer that I am not a
-distributed systems expert.</p></div>
-<div class="paragraph"><p>On that note, if you are looking for my
-services right now, I&#8217;m not available. I&#8217;ll have
-to work 7 days a week for a while. Try again in a
-couple months. More on that in a future post.</p></div>
-<div class="paragraph"><p>The <a href="https://ninenines.eu/docs">documentation</a> becomes a first class
-citizen. Bullet and Cowlib don&#8217;t have proper
-documentation&#8230; yet. I have started working on the
-Cowlib documentation, and Bullet shouldn&#8217;t take too
-long. All these projects will be documented when
-Cowboy gets to 2.0, and will all be supported
-equally. Note that the Cowboy 1.0 documentation
-still has the old website templates and links.
-Don&#8217;t worry about it.</p></div>
-<div class="paragraph"><p>The mailing lists link has been removed. I did
-announce a few months back that mailing lists were
-going to go. They&#8217;re still up right now, but not
-for long. I am planning to put the archives
-read-only, link to them from a future post and
-be done with it. If you have a question, open a
-ticket on Github. Then I can just decide to leave
-the ticket open if I want to do improvements based
-on your feedback.</p></div>
-<div class="paragraph"><p>I have replaced most of the "we" by "I". I am
-a one-man company right now. Have been for a while.
-Doesn&#8217;t make sense to keep a facade. I want to be
-close to users, not put a barrier between us.</p></div>
-<div class="paragraph"><p>The RSS changed. The old link doesn&#8217;t work anymore.
-The new link is at <a href="https://ninenines.eu/index.xml">/index.xml</a>,
-or <a href="https://ninenines.eu/articles/index.xml">/articles/index.xml</a>
-if you only care about my posts. I guess that&#8217;s the
-one most people want.</p></div>
-<div class="paragraph"><p>I still have some tweaks to do, but it will take a
-while. My long term plan is to remove Bootstrap, use
-vanilla CSS and as little JS as possible. The reason
-for that is that it&#8217;s cheaper than upgrading libraries
-every few years. Life is too short to spend it
-upgrading JS libraries.</p></div>
-</description> + <description>Last week-end I updated the Nine Nines website. + I switched to Hugo. The site is now built from Asciidoc documents. You probably saw me switch to Asciidoc for documentation this past year. This is the natural conclusion to that story. The great thing is that with a little bit of Makefile magic I can just copy the documentation files into Hugo and poof, they appear on the website. + I am very happy with that new setup.</description> </item> <item> @@ -682,20 +933,10 @@ upgrading JS libraries.</p></div> <pubDate>Wed, 02 Sep 2015 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/articles/erlanger-playbook-september-2015-update/</guid> - <description><div class="paragraph"><p>An update to The Erlanger Playbook is now available!</p></div>
-<div class="paragraph"><p>The Erlanger Playbook is a book about software development using
-Erlang. It currently covers all areas from the conception, design,
-the writing of code, documentation and tests.</p></div>
-<div class="paragraph"><p>The book is still a work in progress. Future topics will include
-refactoring, debugging and tracing, benchmarking, releases, community
-management (for open source projects).</p></div>
-<div class="paragraph"><p>This update fixes a number of things and adds two chapters: IOlists
-and Erlang building blocks.</p></div>
-<div class="paragraph"><p>Learn more about <a href="https://ninenines.eu/articles/erlanger-playbook">The Erlanger Playbook</a>!</p></div>
-<div class="paragraph"><p>This is a self-published ebook. The base price is 50€. All proceeds
-will be used to allow me to work on open source full time.</p></div>
-<div class="paragraph"><p>Thank you for helping me helping you help us all!</p></div>
-</description> + <description>An update to The Erlanger Playbook is now available! + The Erlanger Playbook is a book about software development using Erlang. It currently covers all areas from the conception, design, the writing of code, documentation and tests. + The book is still a work in progress. Future topics will include refactoring, debugging and tracing, benchmarking, releases, community management (for open source projects). + This update fixes a number of things and adds two chapters: IOlists and Erlang building blocks.</description> </item> <item> @@ -704,108 +945,11 @@ will be used to allow me to work on open source full time.</p></div> <pubDate>Wed, 01 Jul 2015 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/services/</guid> - <description><div class="paragraph"><p>If you are interested by any of these opportunities,
-<a href="mailto:[email protected]">send me an email</a>.</p></div>
-<div class="sect1">
-<h2 id="_consulting">Consulting</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>You can get me, Loïc Hoguin, author of Cowboy, to help you
-solve a problem or work on a particular project.</p></div>
-<div class="paragraph"><p>My area of expertise is Erlang; HTTP, Websocket and REST APIs;
-design and implementation of protocols; and messaging systems.</p></div>
-<div class="paragraph"><p>I can also be helpful with testing or code reviews.</p></div>
-<div class="paragraph"><p>I offer both hourly and daily rates:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-200€ hourly rate (remote)
-</p>
-</li>
-<li>
-<p>
-1000€ daily rate (remote and on-site)
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>For remote consulting, the work can be done by phone, email,
-IRC, GitHub and/or any other platform for collaborative work.</p></div>
-<div class="paragraph"><p>For on-site consulting, the travel expenses and
-accomodations are to be paid by the customer. I will also
-ask for a higher rate if forced to stay on-site for more
-than a week.</p></div>
-<div class="paragraph"><p>Note that my expertise does not cover all areas where
-Erlang is used. My help will be limited in the areas of
-distributed databases, or large distributed systems.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_sponsoring">Sponsoring</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>You can sponsor one of my projects.</p></div>
-<div class="paragraph"><p>Sponsoring gives you:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-a direct, private line of communication
-</p>
-</li>
-<li>
-<p>
-the power to make me maintain older versions of my projects
- (as long as they are sponsoring)
-</p>
-</li>
-<li>
-<p>
-priority when adding features or fixing bugs
-</p>
-</li>
-<li>
-<p>
-advertisement space on this website and in the README file
- of the project of your choice
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>Sponsors may choose to benefit from any of these perks.</p></div>
-<div class="paragraph"><p>In exchange sponsors must contribute financially. A minimum
-of 200€ per month is required. Sponsors may give as much as
-they want. Payment can be monthly or one-time. Invoices are
-of course provided.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_erlang_beginner_training">Erlang beginner training</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>I would be happy to introduce more people to Erlang. I have
-a 1-day Erlang training readily available for consumption.
-The goal of this training is to teach the basics of Erlang
-systems and programming. It&#8217;s a kind of "Getting started"
-for Erlang.</p></div>
-<div class="paragraph"><p>You can review the <a href="https://ninenines.eu/talks/thinking-in-erlang/thinking-in-erlang.html">training slides</a>.</p></div>
-<div class="paragraph"><p>This training is meant to be given to a large number of
-people interested in Erlang, as part of a public event,
-where anyone interested can come.</p></div>
-<div class="paragraph"><p>Another important aspect of this training is that it is
-meant to be affordable. We want the most people to learn
-Erlang as possible.</p></div>
-<div class="paragraph"><p>If you have room, think you can gather 20+ people and
-are interested in sponsoring a training session, then
-we should talk.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_custom_training">Custom training</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>I can also provide custom training, tailored to your level
-and your needs. It can take the form of a class, Q&amp;A or a
-code review/writing session. I need to know your expectations
-to prepare an appropriate training.</p></div>
-<div class="paragraph"><p>Custom training rates are the same as consulting rates and
-the same restrictions apply.</p></div>
-</div>
-</div>
-</description> + <description>If you are interested by any of these opportunities, send me an email. + Consulting You can get me, Loïc Hoguin, author of Cowboy, to help you solve a problem or work on a particular project. + My area of expertise is Erlang; HTTP, Websocket and REST APIs; design and implementation of protocols; and messaging systems. + I can also be helpful with testing or code reviews. + I offer both hourly and daily rates:</description> </item> <item> @@ -814,13 +958,9 @@ the same restrictions apply.</p></div> <pubDate>Wed, 01 Jul 2015 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/docs/</guid> - <description><div class="sect2">
-<h3 id="_contribute">Contribute</h3>
-<div class="paragraph"><p>Do you have examples, tutorials, videos about one or more
-of my projects? I would happily include them on this page.</p></div>
-<div class="paragraph"><p><a href="mailto:[email protected]">Send me an email with the details</a>.</p></div>
-</div>
-</description> + <description>Contribute Do you have examples, tutorials, videos about one or more of my projects? I would happily include them on this page. + Send me an email with the details. + </description> </item> <item> @@ -829,23 +969,8 @@ of my projects? I would happily include them on this page.</p></div> <pubDate>Wed, 01 Jul 2015 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/donate/</guid> - <description><div class="sect2">
-<h3 id="_like_my_work_donate">Like my work? Donate!</h3>
-<div class="paragraph"><p>Donate to Loïc Hoguin because his work on Cowboy
-and Erlang.mk is fantastic:</p></div>
-<form action="https://www.paypal.com/cgi-bin/webscr" method="post" style="display:inline">
-<input type="hidden" name="cmd" value="_donations">
-<input type="hidden" name="business" value="[email protected]">
-<input type="hidden" name="lc" value="FR">
-<input type="hidden" name="item_name" value="Loic Hoguin">
-<input type="hidden" name="item_number" value="99s">
-<input type="hidden" name="currency_code" value="EUR">
-<input type="hidden" name="bn" value="PP-DonationsBF:btn_donate_LG.gif:NonHosted">
-<input type="image" src="https://www.paypalobjects.com/en_US/i/btn/btn_donate_LG.gif" border="0" name="submit" alt="PayPal - The safer, easier way to pay online!">
-<img alt="" border="0" src="https://www.paypalobjects.com/fr_FR/i/scr/pixel.gif" width="1" height="1">
-</form>
-</div>
-</description> + <description>Like my work? Donate! Donate to Loïc Hoguin because his work on Cowboy and Erlang.mk is fantastic: + </description> </item> <item> @@ -854,15 +979,9 @@ and Erlang.mk is fantastic:</p></div> <pubDate>Wed, 01 Jul 2015 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/talks/</guid> - <description><div class="sect2">
-<h3 id="_talk_requests">Talk requests</h3>
-<div class="paragraph"><p>Organizing a conference and in need of a speaker for a talk
-about Erlang and the Web? Need an introduction to Erlang/OTP
-for your company? Looking for a cool subject for a user group
-meeting?</p></div>
-<div class="paragraph"><p><a href="mailto:[email protected]">Send me an email with the details</a>.</p></div>
-</div>
-</description> + <description>Talk requests Organizing a conference and in need of a speaker for a talk about Erlang and the Web? Need an introduction to Erlang/OTP for your company? Looking for a cool subject for a user group meeting? + Send me an email with the details. + </description> </item> <item> @@ -871,10 +990,9 @@ meeting?</p></div> <pubDate>Wed, 01 Jul 2015 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/slogan/</guid> - <description><div class="paragraph"><p>Feeling generous? Love reading?<br />
-<a href="https://salt.bountysource.com/teams/ninenines">Crowdfund my salary</a>
-or buy <a href="https://ninenines.eu/articles/erlanger-playbook">The Erlanger Playbook</a></p></div>
-</description> + <description>Feeling generous? Love reading? +Crowdfund my salary or buy The Erlanger Playbook + </description> </item> <item> @@ -883,88 +1001,1175 @@ or buy <a href="https://ninenines.eu/articles/erlanger-playbook">T <pubDate>Thu, 18 Jun 2015 00:00:00 +0100</pubDate> <guid>https://ninenines.eu/articles/erlanger-playbook/</guid> - <description><div class="paragraph"><p>I am proud to announce the pre-release of The Erlanger Playbook.</p></div>
-<div class="paragraph"><p>The Erlanger Playbook is a book about software development using
-Erlang. It currently covers all areas from the conception, design,
-the writing of code, documentation and tests.</p></div>
-<div class="paragraph"><p>The book is still a work in progress. Future topics will include
-refactoring, debugging and tracing, benchmarking, releases, community
-management (for open source projects).</p></div>
-<div class="paragraph"><p>The following sections are currently available:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-About this book; Changelog; Future additions
-</p>
-</li>
-<li>
-<p>
-<em>Erlang:</em> Building blocks; Patterns
-</p>
-</li>
-<li>
-<p>
-<em>Workflow:</em> Think; Write; Stay productive
-</p>
-</li>
-<li>
-<p>
-<em>Documentation:</em> On documentation; Tutorials; User guide; Manual; README files
-</p>
-</li>
-<li>
-<p>
-<em>Design:</em> RESTful APIs; Lessons learned
-</p>
-</li>
-<li>
-<p>
-<em>Code:</em> Starting a project; Version control; Project structure; Code style; Best practices; Special processes; IOLists; The process dictionary
-</p>
-</li>
-<li>
-<p>
-<em>Tests:</em> On testing; Success typing analysis; Manual testing; Unit testing; Functional testing
-</p>
-</li>
-<li>
-<p>
-<em>Selling Erlang:</em> On persuasion; Don&#8217;t let it crash
-</p>
-</li>
-</ul></div>
-<div class="paragraph"><p>Read a preview: <a href="https://ninenines.eu/res/erlanger-preview.pdf">Special processes</a></p></div>
-<div class="paragraph"><p>The book is currently 180 pages long. The final version
-of the book is planned to be between 200 and 250 pages.
-A print version of the book will be considered once the final
-version gets released. The printed book is <strong>not</strong> included
-in the price.</p></div>
-<div class="paragraph"><p>This is a self-published book. The base price is 50€. All proceeds
-will be used to allow me to work on open source full time.</p></div>
-<form action="https://www.paypal.com/cgi-bin/webscr" method="post" target="_top">
-<input type="hidden" name="cmd" value="_s-xclick">
-<input type="hidden" name="hosted_button_id" value="9M44HJCGX3GVN">
-<input type="image" src="https://www.paypalobjects.com/en_US/i/btn/btn_buynowCC_LG.gif" border="0" name="submit" alt="PayPal - The safer, easier way to pay online!">
-<img alt="" border="0" src="https://www.paypalobjects.com/fr_FR/i/scr/pixel.gif" width="1" height="1">
-</form>
-<div class="paragraph"><p>You are more than welcome to pay extra by using this second button.
-It allows you to set the price you want. Make sure to set it to at least
-50€ to receive the book.</p></div>
-<form action="https://www.paypal.com/cgi-bin/webscr" method="post" target="_top">
-<input type="hidden" name="cmd" value="_s-xclick">
-<input type="hidden" name="hosted_button_id" value="BBW9TR9LBK8C2">
-<input type="image" src="https://www.paypalobjects.com/en_US/i/btn/btn_buynowCC_LG.gif" border="0" name="submit" alt="PayPal - The safer, easier way to pay online!">
-<img alt="" border="0" src="https://www.paypalobjects.com/fr_FR/i/scr/pixel.gif" width="1" height="1">
-</form>
-<div class="paragraph"><p>Make sure to provide a valid email address.</p></div>
-<div class="paragraph"><p>There will be a <strong>delay</strong> between payment and sending of the book.
-This process is currently manual.</p></div>
-<div class="paragraph"><p>As the book is a pre-release, feedback is more than welcome. You can
-send your comments to erlanger@ this website.</p></div>
-<div class="paragraph"><p>The plan is to add content regularly until I run out of things to say.
-You will receive updates to the book for free as soon as they are available.</p></div>
-<div class="paragraph"><p>Huge thanks for your interest in buying this book!</p></div>
-</description> + <description>I am proud to announce the pre-release of The Erlanger Playbook. + The Erlanger Playbook is a book about software development using Erlang. It currently covers all areas from the conception, design, the writing of code, documentation and tests. + The book is still a work in progress. Future topics will include refactoring, debugging and tracing, benchmarking, releases, community management (for open source projects). + The following sections are currently available:</description> + </item> + + <item> + <title>Validating UTF-8 binaries with Erlang</title> + <link>https://ninenines.eu/articles/erlang-validate-utf8/</link> + <pubDate>Fri, 06 Mar 2015 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/erlang-validate-utf8/</guid> + <description>Yesterday I pushed Websocket permessage-deflate to Cowboy master. I also pushed a change in the way the code validates UTF-8 data (required for text and close frames as per the spec). + When looking into why the permessage-deflate tests in autobahntestsuite were taking such a long time, I found that autobahn is using an adaptation of the algorithm named Flexible and Economical UTF-8 Decoder. This is the C99 implementation: + // Copyright (c) 2008-2009 Bjoern Hoehrmann &lt;bjoern@hoehrmann.</description> + </item> + + <item> + <title>On open source</title> + <link>https://ninenines.eu/articles/on-open-source/</link> + <pubDate>Fri, 05 Sep 2014 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/on-open-source/</guid> + <description>Last week I read a great article on contributing to open source by Alvaro Videla. He makes many great points and I am in agreement with most of it. This made me want to properly explain my point of view with regard to open source and contributions. Unlike most open source evangelism articles I will not talk about ideals or any of that crap, but rather my personal feelings and experience.</description> + </item> + + <item> + <title>The story so far</title> + <link>https://ninenines.eu/articles/the-story-so-far/</link> + <pubDate>Sat, 23 Aug 2014 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/the-story-so-far/</guid> + <description>As I am away from home with little to do (some call this a vacation) I wanted to reflect a little on the story so far, or how I arrived to Erlang and got to where I am now. The raw personal experience. It&#8217;ll be an article that&#8217;s more about social aspect, communities and marketing a project than technical considerations. As a period piece, it will also allow me to reflect on the evolution of Erlang in recent years.</description> + </item> + + <item> + <title>Cowboy 2.0 and query strings</title> + <link>https://ninenines.eu/articles/cowboy2-qs/</link> + <pubDate>Wed, 20 Aug 2014 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/cowboy2-qs/</guid> + <description>Now that Cowboy 1.0 is out, I can spend some of my time thinking about Cowboy 2.0 that will be released soon after Erlang/OTP 18.0. This entry discusses the proposed changes to query string handling in Cowboy. + Cowboy 2.0 will respond to user wishes by simplifying the interface of the cowboy_req module. Users want two things: less juggling with the Req variable, and more maps. Maps is the only dynamic key/value data structure in Erlang that we can match directly to extract values, allowing users to greatly simplify their code as they don&#8217;t need to call functions to do everything anymore.</description> + </item> + + <item> + <title>January 2014 status</title> + <link>https://ninenines.eu/articles/january-2014-status/</link> + <pubDate>Tue, 07 Jan 2014 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/january-2014-status/</guid> + <description>I will now be regularly writing posts about project status, plans and hopes for the future. + Before that though, there&#8217;s one important news to share. + Until a year ago all development was financed through consulting and development services. This worked alright but too much time was spent doing things that didn&#8217;t benefit the open source projects. And that didn&#8217;t make me happy at all. Because I like being happy I stopped that for the most part and spent the year figuring things out, experimenting and discussing with people about it.</description> + </item> + + <item> + <title>Farwest got funded!</title> + <link>https://ninenines.eu/articles/farwest-funded/</link> + <pubDate>Thu, 27 Jun 2013 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/farwest-funded/</guid> + <description>This was a triumph! I&#8217;m making a note here: HUGE SUCCESS!! + It&#8217;s hard to overstate my satisfaction. Thanks to everyone who made this possible. + If you have backed this fundraiser, and haven&#8217;t provided your personal details yet, please do so quickly so that your rewards can be sent! + I am hoping that we will be able to make good use of all that money. The details of the expenses will be published regularly on the 2013 Fundraiser wiki page, giving you full disclosure as to how your money is used.</description> + </item> + + <item> + <title>Build Erlang releases with Erlang.mk and Relx</title> + <link>https://ninenines.eu/articles/erlang.mk-and-relx/</link> + <pubDate>Tue, 28 May 2013 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/erlang.mk-and-relx/</guid> + <description>Building OTP releases has always been a difficult task. Tools like Reltool or Rebar have made this simpler, but it&#8217;s no panacea. This article will show you an alternative and hopefully much simpler solution. + There is two steps to building a release. First you need to build the various OTP applications you want to include in the release. Once done, you need to create the release itself, by including the Erlang runtime system alongside the applications, a boot script to start the node and all its applications, and some configuration files.</description> + </item> + + <item> + <title>Xerl: intermediate module</title> + <link>https://ninenines.eu/articles/xerl-0.5-intermediate-module/</link> + <pubDate>Mon, 25 Mar 2013 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/xerl-0.5-intermediate-module/</guid> + <description>Today we will start the work on the intermediate module that will be used to run the code for the expressions found in our file&#8217;s body, replacing our interpreter. + This is what we want to have when all the work is done: + xerl -&gt; tokens -&gt; AST -&gt; intermediate -&gt; cerl Today we will perform this work only on the atomic integer expression however, so we will not build any module at the end.</description> + </item> + + <item> + <title>Xerl: expression separator</title> + <link>https://ninenines.eu/articles/xerl-0.4-expression-separator/</link> + <pubDate>Fri, 01 Mar 2013 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/xerl-0.4-expression-separator/</guid> + <description>As promised we are adding an expression separator this time. This will be short and easy. + In the tokenizer we only need to add a line recognizing the comma as a valid token. + , : {token, {',', TokenLine}}. Then we need to change the following lines in the parser: + exprs -&gt; expr : ['$1']. exprs -&gt; expr exprs : ['$1' | '$2']. And add a comma between the expressions on the second line:</description> + </item> + + <item> + <title>Erlang Scalability</title> + <link>https://ninenines.eu/articles/erlang-scalability/</link> + <pubDate>Mon, 18 Feb 2013 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/erlang-scalability/</guid> + <description>I would like to share some experience and theories on Erlang scalability. + This will be in the form of a series of hints, which may or may not be accompanied with explanations as to why things are this way, or how they improve or reduce the scalability of a system. I will try to do my best to avoid giving falsehoods, even if that means a few things won&#8217;t be explained.</description> + </item> + + <item> + <title>Xerl: atomic expressions</title> + <link>https://ninenines.eu/articles/xerl-0.3-atomic-expressions/</link> + <pubDate>Mon, 18 Feb 2013 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/xerl-0.3-atomic-expressions/</guid> + <description>We will be adding atomic integer expressions to our language. These look as follow in Erlang: + 42. And the result of this expression is of course 42. + We will be running this expression at compile time, since we don&#8217;t have the means to run code at runtime yet. This will of course result in no module being compiled, but that&#8217;s OK, it will allow us to discuss a few important things we&#8217;ll have to plan for later on.</description> + </item> + + <item> + <title>Xerl: two modules</title> + <link>https://ninenines.eu/articles/xerl-0.2-two-modules/</link> + <pubDate>Sun, 03 Feb 2013 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/xerl-0.2-two-modules/</guid> + <description>Everything is an expression. + This sentence carries profound meaning. We will invoke it many times over the course of these articles. + If everything is an expression, then the language shouldn&#8217;t have any problem with me defining two modules in the same source file. + mod first_module begin end mod second_module begin end Likewise, it shouldn&#8217;t have any problem with me defining a module inside another module. + mod out_module begin mod in_module begin end end Of course, in the context of the Erlang VM, these two snippets are equivalent; there is nothing preventing you from calling the in_module module from any other module.</description> + </item> + + <item> + <title>Xerl: empty modules</title> + <link>https://ninenines.eu/articles/xerl-0.1-empty-modules/</link> + <pubDate>Wed, 30 Jan 2013 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/xerl-0.1-empty-modules/</guid> + <description>Let&#8217;s build a programming language. I call it Xerl: eXtended ERLang. It&#8217;ll be an occasion for us to learn a few things, especially me. + Unlike in Erlang, in this language, everything is an expression. This means that modules and functions are expression, and indeed that you can have more than one module per file. + We are just starting, so let&#8217;s no go ahead of ourselves here. We&#8217;ll begin with writing the code allowing us to compile an empty module.</description> + </item> + + <item> + <title>Build an FTP Server with Ranch in 30 Minutes</title> + <link>https://ninenines.eu/articles/ranch-ftp/</link> + <pubDate>Wed, 14 Nov 2012 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/ranch-ftp/</guid> + <description>Last week I was speaking at the London Erlang Factory Lite where I presented a live demonstration of building an FTP server using Ranch. As there was no slide, you should use this article as a reference instead. + The goal of this article is to showcase how to use Ranch for writing a network protocol implementation, how Ranch gets out of the way to let you write the code that matters, and the common techniques used when writing servers.</description> + </item> + + <item> + <title>Erlang Tic Tac Toe</title> + <link>https://ninenines.eu/articles/tictactoe/</link> + <pubDate>Wed, 17 Oct 2012 00:00:00 +0100</pubDate> + + <guid>https://ninenines.eu/articles/tictactoe/</guid> + <description>Everyone knows Tic Tac Toe, right? + Players choose either to be the Xs or the Os, then place their symbol on a 3x3 board one after another, trying to create a line of 3 of them. + Writing an algorithm to check for victory sounds easy, right? It&#8217;s easily tested, considering there&#8217;s only 8 possible winning rows (3 horizontal, 3 vertical and 2 diagonal). + In Erlang though, you probably wouldn&#8217;t want an algorithm.</description> + </item> + + <item> + <title>Cowboy Function Reference</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Cowboy User Guide</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/guide/</link> + <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> + </item> + + <item> + <title>Erlang.mk User Guide</title> + <link>https://ninenines.eu/docs/en/erlang.mk/1/guide/</link> + <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 Tests Erlang shell EUnit Common Test Code coverage Continuous integration Dialyzer Xref Third-party plugins External plugins List of plugins About Erlang.</description> + </item> + + <item> + <title>Gun Function Reference</title> + <link>https://ninenines.eu/docs/en/gun/1.0/manual/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/gun/1.0/manual/</guid> + <description> gun(7) gun(3) </description> + </item> + + <item> + <title>Gun User Guide</title> + <link>https://ninenines.eu/docs/en/gun/1.0/guide/</link> + <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> + </item> + + <item> + <title>HTTP status codes(7)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/http_status_codes/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>Ranch Function Reference</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/manual/</link> + <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> + </item> + + <item> + <title>Ranch Function Reference</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/manual/</link> + <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> + </item> + + <item> + <title>Ranch User Guide</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/guide/</link> + <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> + </item> + + <item> + <title>Ranch User Guide</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/guide/</link> + <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> + </item> + + <item> + <title>cowboy(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy(7)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_app/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy:set_env(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy.set_env/</link> + <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> + </item> + + <item> + <title>cowboy:start_clear(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy.start_clear/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy:start_tls(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy.start_tls/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy:stop_listener(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy.stop_listener/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_constraints(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_constraints/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_constraints:int(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_constraints.int/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_constraints:nonempty(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_constraints.nonempty/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_handler(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_handler/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_handler:terminate(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_handler.terminate/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_http(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_http/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_http2(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_http2/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_loop(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_loop/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_middleware(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_middleware/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:binding(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.binding/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:bindings(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.bindings/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:body_length(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.body_length/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:delete_resp_header(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.delete_resp_header/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:has_body(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.has_body/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:has_resp_body(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_body/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:has_resp_header(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.has_resp_header/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:header(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.header/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:headers(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.headers/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:host(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.host/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:host_info(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.host_info/</link> + <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> + </item> + + <item> + <title>cowboy_req:match_cookies(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.match_cookies/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:match_qs(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.match_qs/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:method(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.method/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:parse_cookies(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.parse_cookies/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:parse_header(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.parse_header/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:parse_qs(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.parse_qs/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:path(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.path/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:path_info(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.path_info/</link> + <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> + </item> + + <item> + <title>cowboy_req:peer(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.peer/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:port(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.port/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:push(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.push/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:qs(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.qs/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:read_body(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.read_body/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:read_part(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.read_part/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:read_part_body(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.read_part_body/</link> + <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> + </item> + + <item> + <title>cowboy_req:read_urlencoded_body(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.read_urlencoded_body/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:reply(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.reply/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:resp_header(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.resp_header/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:resp_headers(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.resp_headers/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:scheme(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.scheme/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:set_resp_body(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_body/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:set_resp_cookie(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_cookie/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:set_resp_header(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_header/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:set_resp_headers(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.set_resp_headers/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:stream_body(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.stream_body/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:stream_reply(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.stream_reply/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:uri(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.uri/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_req:version(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_req.version/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_rest(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_rest/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_router(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_router/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_router:compile(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_router.compile/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_static(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_static/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_stream(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_stream/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>cowboy_websocket(3)</title> + <link>https://ninenines.eu/docs/en/cowboy/2.0/manual/cowboy_websocket/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>gun(3)</title> + <link>https://ninenines.eu/docs/en/gun/1.0/manual/gun/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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. + Types opts() = map() Configuration for the connection. + The following keys are defined: + connect_timeout &#8658; timeout() Connection timeout. Defaults to infinity. http_opts &#8658; http_opts() Options specific to the HTTP protocol.</description> + </item> + + <item> + <title>gun(7)</title> + <link>https://ninenines.eu/docs/en/gun/1.0/manual/gun_app/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <guid>https://ninenines.eu/docs/en/gun/1.0/manual/gun_app/</guid> + <description>Name gun - Erlang HTTP client with support for HTTP/1.1, HTTP/2 and Websocket. + Dependencies The gun application uses the Erlang applications ranch for abstracting TCP and TLS over a common interface, and the ssl application for TLS support, required for HTTPS and secure HTTP/2 support. In addition, Gun requires the crypto application (a dependency of ssl) for Websocket. + These dependencies must be started for the gun application to work.</description> + </item> + + <item> + <title>ranch(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>ranch(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>ranch(7)</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch_app/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>ranch(7)</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch_app/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>ranch_protocol(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch_protocol/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>ranch_protocol(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch_protocol/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>ranch_ssl(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch_ssl/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>ranch_ssl(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch_ssl/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>ranch_tcp(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch_tcp/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>ranch_tcp(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch_tcp/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>ranch_transport(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.2/manual/ranch_transport/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> + </item> + + <item> + <title>ranch_transport(3)</title> + <link>https://ninenines.eu/docs/en/ranch/1.3/manual/ranch_transport/</link> + <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> + + <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> </item> </channel> |