summaryrefslogtreecommitdiffstats
path: root/docs/en/cowboy/2.0/guide/modern_web/index.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/en/cowboy/2.0/guide/modern_web/index.html')
-rw-r--r--docs/en/cowboy/2.0/guide/modern_web/index.html221
1 files changed, 113 insertions, 108 deletions
diff --git a/docs/en/cowboy/2.0/guide/modern_web/index.html b/docs/en/cowboy/2.0/guide/modern_web/index.html
index 62aef447..2bbf1072 100644
--- a/docs/en/cowboy/2.0/guide/modern_web/index.html
+++ b/docs/en/cowboy/2.0/guide/modern_web/index.html
@@ -7,7 +7,7 @@
<meta name="description" content="">
<meta name="author" content="Loïc Hoguin based on a design from (Soft10) Pol Cámara">
- <meta name="generator" content="Hugo 0.17" />
+ <meta name="generator" content="Hugo 0.26" />
<title>Nine Nines: The modern Web</title>
@@ -67,119 +67,124 @@
<h1 class="lined-header"><span>The modern Web</span></h1>
-<div class="paragraph"><p>Cowboy is a server for the modern Web. This chapter explains
-what it means and details all the standards involved.</p></div>
-<div class="paragraph"><p>Cowboy supports all the standards listed in this document.</p></div>
-<div class="sect1">
-<h2 id="_http_2">HTTP/2</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>HTTP/2 is the most efficient protocol for consuming Web
-services. It enables clients to keep a connection open
-for long periods of time; to send requests concurrently;
-to reduce the size of requests through HTTP headers
-compression; and more. The protocol is binary, greatly
-reducing the resources needed to parse it.</p></div>
-<div class="paragraph"><p>HTTP/2 also enables the server to push messages to the
-client. This can be used for various purposes, including
-the sending of related resources before the client requests
-them, in an effort to reduce latency. This can also be used
-to enable bidirectional communication.</p></div>
-<div class="paragraph"><p>Cowboy provides transparent support for HTTP/2. Clients
-that know it can use it; others fall back to HTTP/1.1
-automatically.</p></div>
-<div class="paragraph"><p>HTTP/2 is compatible with the HTTP/1.1 semantics.</p></div>
-<div class="paragraph"><p>HTTP/2 is defined by RFC 7540 and RFC 7541.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_http_1_1">HTTP/1.1</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>HTTP/1.1 is the previous version of the HTTP protocol.
-The protocol itself is text-based and suffers from numerous
-issues and limitations. In particular it is not possible
-to execute requests concurrently (though pipelining is
-sometimes possible), and it&#8217;s also sometimes difficult
-to detect that a client disconnected.</p></div>
-<div class="paragraph"><p>HTTP/1.1 does provide very good semantics for interacting
-with Web services. It defines the standard methods, headers
-and status codes used by HTTP/1.1 and HTTP/2 clients and
-servers.</p></div>
-<div class="paragraph"><p>HTTP/1.1 also defines compatibility with an older version
-of the protocol, HTTP/1.0, which was never really standardized
-across implementations.</p></div>
-<div class="paragraph"><p>The core of HTTP/1.1 is defined by RFC 7230, RFC 7231,
-RFC 7232, RFC 7233, RFC 7234 and RFC 7235. Numerous RFCs
-and other specifications exist defining additional HTTP
-methods, status codes, headers or semantics.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_websocket">Websocket</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Websocket is a protocol built on top of HTTP/1.1 that provides
-a two-ways communication channel between the client and the
-server. Communication is asynchronous and can occur concurrently.</p></div>
-<div class="paragraph"><p>It consists of a Javascript object allowing setting up a
-Websocket connection to the server, and a binary based
-protocol for sending data to the server or the client.</p></div>
-<div class="paragraph"><p>Websocket connections can transfer either UTF-8 encoded text
-data or binary data. The protocol also includes support for
-implementing a ping/pong mechanism, allowing the server and
-the client to have more confidence that the connection is still
-alive.</p></div>
-<div class="paragraph"><p>A Websocket connection can be used to transfer any kind of data,
-small or big, text or binary. Because of this Websocket is
-sometimes used for communication between systems.</p></div>
-<div class="paragraph"><p>Websocket messages have no semantics on their own. Websocket
-is closer to TCP in that aspect, and requires you to design
-and implement your own protocol on top of it; or adapt an
-existing protocol to Websocket.</p></div>
-<div class="paragraph"><p>The Websocket protocol is defined by RFC 6455.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_long_lived_requests">Long-lived requests</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>Cowboy provides an interface that can be used to support
-long-polling or to stream large amounts of data reliably,
-including using Server-Sent Events.</p></div>
-<div class="paragraph"><p>Long-polling is a mechanism in which the client performs
-a request which may not be immediately answered by the
-server. It allows clients to request resources that may
-not currently exist, but are expected to be created soon,
-and which will be returned as soon as they are.</p></div>
-<div class="paragraph"><p>Long-polling is essentially a hack, but it is widely used
-to overcome limitations on older clients and servers.</p></div>
-<div class="paragraph"><p>Server-Sent Events is a small protocol defined as a media
-type, <code>text/event-stream</code>, along with a new HTTP header,
-<code>Last-Event-ID</code>. It is defined in the EventSource W3C
-specification.</p></div>
-<div class="paragraph"><p>Cowboy provides an interface known as loop handlers that
-facilitates the implementation of long-polling or stream
-mechanisms. It works regardless of the underlying protocol.</p></div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_rest">REST</h2>
-<div class="sectionbody">
-<div class="paragraph"><p>REST, or REpresentational State Transfer, is a style of
-architecture for loosely connected distributed systems.
-It can easily be implemented on top of HTTP.</p></div>
-<div class="paragraph"><p>REST is essentially a set of constraints to be followed.
-Many of these constraints are purely architectural and
-solved by simply using HTTP. Some constraints must be
-explicitly followed by the developer.</p></div>
-<div class="paragraph"><p>Cowboy provides an interface known as REST handlers that
-simplifies the implementation of a REST API on top of
-the HTTP protocol.</p></div>
-</div>
-</div>
+<div class="paragraph"><p>Cowboy is a server for the modern Web. This chapter explains
+what it means and details all the standards involved.</p></div>
+<div class="paragraph"><p>Cowboy supports all the standards listed in this document.</p></div>
+<div class="sect1">
+<h2 id="_http_2">HTTP/2</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>HTTP/2 is the most efficient protocol for consuming Web
+services. It enables clients to keep a connection open
+for long periods of time; to send requests concurrently;
+to reduce the size of requests through HTTP headers
+compression; and more. The protocol is binary, greatly
+reducing the resources needed to parse it.</p></div>
+<div class="paragraph"><p>HTTP/2 also enables the server to push messages to the
+client. This can be used for various purposes, including
+the sending of related resources before the client requests
+them, in an effort to reduce latency. This can also be used
+to enable bidirectional communication.</p></div>
+<div class="paragraph"><p>Cowboy provides transparent support for HTTP/2. Clients
+that know it can use it; others fall back to HTTP/1.1
+automatically.</p></div>
+<div class="paragraph"><p>HTTP/2 is compatible with the HTTP/1.1 semantics.</p></div>
+<div class="paragraph"><p>HTTP/2 is defined by RFC 7540 and RFC 7541.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_http_1_1">HTTP/1.1</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>HTTP/1.1 is the previous version of the HTTP protocol.
+The protocol itself is text-based and suffers from numerous
+issues and limitations. In particular it is not possible
+to execute requests concurrently (though pipelining is
+sometimes possible), and it&#8217;s also sometimes difficult
+to detect that a client disconnected.</p></div>
+<div class="paragraph"><p>HTTP/1.1 does provide very good semantics for interacting
+with Web services. It defines the standard methods, headers
+and status codes used by HTTP/1.1 and HTTP/2 clients and
+servers.</p></div>
+<div class="paragraph"><p>HTTP/1.1 also defines compatibility with an older version
+of the protocol, HTTP/1.0, which was never really standardized
+across implementations.</p></div>
+<div class="paragraph"><p>The core of HTTP/1.1 is defined by RFC 7230, RFC 7231,
+RFC 7232, RFC 7233, RFC 7234 and RFC 7235. Numerous RFCs
+and other specifications exist defining additional HTTP
+methods, status codes, headers or semantics.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_websocket">Websocket</h2>
+<div class="sectionbody">
+<div class="paragraph"><p><a href="../ws_protocol">Websocket</a> is a protocol built on top of HTTP/1.1
+that provides a two-ways communication channel between the client and
+the server. Communication is asynchronous and can occur concurrently.</p></div>
+<div class="paragraph"><p>It consists of a Javascript object allowing setting up a
+Websocket connection to the server, and a binary based
+protocol for sending data to the server or the client.</p></div>
+<div class="paragraph"><p>Websocket connections can transfer either UTF-8 encoded text
+data or binary data. The protocol also includes support for
+implementing a ping/pong mechanism, allowing the server and
+the client to have more confidence that the connection is still
+alive.</p></div>
+<div class="paragraph"><p>A Websocket connection can be used to transfer any kind of data,
+small or big, text or binary. Because of this Websocket is
+sometimes used for communication between systems.</p></div>
+<div class="paragraph"><p>Websocket messages have no semantics on their own. Websocket
+is closer to TCP in that aspect, and requires you to design
+and implement your own protocol on top of it; or adapt an
+existing protocol to Websocket.</p></div>
+<div class="paragraph"><p>Cowboy provides an interface known as <a href="../ws_handlers">Websocket handlers</a>
+that gives complete control over a Websocket connection.</p></div>
+<div class="paragraph"><p>The Websocket protocol is defined by RFC 6455.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_long_lived_requests">Long-lived requests</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>Cowboy provides an interface that can be used to support
+long-polling or to stream large amounts of data reliably,
+including using Server-Sent Events.</p></div>
+<div class="paragraph"><p>Long-polling is a mechanism in which the client performs
+a request which may not be immediately answered by the
+server. It allows clients to request resources that may
+not currently exist, but are expected to be created soon,
+and which will be returned as soon as they are.</p></div>
+<div class="paragraph"><p>Long-polling is essentially a hack, but it is widely used
+to overcome limitations on older clients and servers.</p></div>
+<div class="paragraph"><p>Server-Sent Events is a small protocol defined as a media
+type, <code>text/event-stream</code>, along with a new HTTP header,
+<code>Last-Event-ID</code>. It is defined in the EventSource W3C
+specification.</p></div>
+<div class="paragraph"><p>Cowboy provides an interface known as <a href="../loop_handlers">loop handlers</a>
+that facilitates the implementation of long-polling or stream
+mechanisms. It works regardless of the underlying protocol.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_rest">REST</h2>
+<div class="sectionbody">
+<div class="paragraph"><p><a href="../rest_principles">REST, or REpresentational State Transfer</a>,
+is a style of architecture for loosely connected distributed
+systems. It can easily be implemented on top of HTTP.</p></div>
+<div class="paragraph"><p>REST is essentially a set of constraints to be followed.
+Many of these constraints are purely architectural and
+solved by simply using HTTP. Some constraints must be
+explicitly followed by the developer.</p></div>
+<div class="paragraph"><p>Cowboy provides an interface known as <a href="../rest_handlers">REST handlers</a>
+that simplifies the implementation of a REST API on top of
+the HTTP protocol.</p></div>
+</div>
+</div>
+
+
+
<nav style="margin:1em 0">