Rebuild using Asciideck

1 files changed, 27 insertions, 104 deletions

diff --git a/docs/en/cowboy/2.4/guide/modern_web/index.html b/docs/en/cowboy/2.4/guide/modern_web/index.html
index 0a335686..00328997 100644
--- a/docs/en/cowboy/2.4/guide/modern_web/index.html
+++ b/docs/en/cowboy/2.4/guide/modern_web/index.html
@@ -62,115 +62,38 @@
 
 <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">
+<p>Cowboy is a server for the modern Web. This chapter explains what it means and details all the standards involved.</p>
+<p>Cowboy supports all the standards listed in this document.</p>
 <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">
+<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>
+<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>
+<p>Cowboy provides transparent support for HTTP/2. Clients that know it can use it; others fall back to HTTP/1.1 automatically.</p>
+<p>HTTP/2 is compatible with the HTTP/1.1 semantics.</p>
+<p>HTTP/2 is defined by RFC 7540 and RFC 7541.</p>
 <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">
+<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&apos;s also sometimes difficult to detect that a client disconnected.</p>
+<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>
+<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>
+<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>
 <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">
+<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>
+<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>
+<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>
+<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>
+<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>
+<p>Cowboy provides an interface known as <a href="../ws_handlers">Websocket handlers</a> that gives complete control over a Websocket connection.</p>
+<p>The Websocket protocol is defined by RFC 6455.</p>
 <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">
+<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>
+<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>
+<p>Long-polling is essentially a hack, but it is widely used to overcome limitations on older clients and servers.</p>
+<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>
+<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>
 <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>
+<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>
+<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>
+<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>
+