1 files changed, 55 insertions, 19 deletions
diff --git a/docs/en/cowboy/2.0/guide/streams/index.html b/docs/en/cowboy/2.0/guide/streams/index.html
index a73d9928..4641b9b1 100644
--- a/docs/en/cowboy/2.0/guide/streams/index.html
+++ b/docs/en/cowboy/2.0/guide/streams/index.html
@@ -67,25 +67,61 @@
 
 <h1 class="lined-header"><span>Streams</span></h1>
 
-<div class="paragraph"><p>Placeholder chapter.</p></div>
-<div class="paragraph"><p>Streams are a new feature in Cowboy 2.0 that requires
-a little more tweaking before they can be generally
-useful. This chapter will be made available in a future
-pre-release.</p></div>
-<div class="paragraph"><p>Streams are meant to replace hooks. The relevant chapters
-for Cowboy 1.0 were:</p></div>
-<div class="ulist"><ul>
-<li>
-<p>
-<a href="../hooks">Hooks</a>
-</p>
-</li>
-<li>
-<p>
-<a href="../broken_clients">Dealing with broken clients</a>
-</p>
-</li>
-</ul></div>
+<div class="paragraph"><p>A stream is the set of messages that form an HTTP
+request/response pair.</p></div>
+<div class="paragraph"><p>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.</p></div>
+<div class="paragraph"><p>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.</p></div>
+<div class="sect1">
+<h2 id="_stream_handlers">Stream handlers</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>Stream handlers must implement five different callbacks.
+Four of them are directly related; one is special.</p></div>
+<div class="paragraph"><p>All callbacks receives the stream ID as first argument.</p></div>
+<div class="paragraph"><p>Most of them can return a list of commands to be executed
+by Cowboy. When callbacks are chained, it is possible to
+intercept and modify these commands. This can be useful
+for modifying responses for example.</p></div>
+<div class="paragraph"><p>The <code>init/3</code> callback is invoked when a new request
+comes in. It receives the Req object and the protocol options
+for this listener.</p></div>
+<div class="paragraph"><p>The <code>data/4</code> callback is invoked when data from the request
+body is received. It receives both this data and a flag
+indicating whether more is to be expected.</p></div>
+<div class="paragraph"><p>The <code>info/3</code> callback is invoked when an Erlang message is
+received for this stream. They will typically be messages
+sent by the request process.</p></div>
+<div class="paragraph"><p>Finally the <code>terminate/3</code> callback is invoked with the
+terminate reason for the stream. The return value is ignored.
+Note that as with all terminate callbacks in Erlang, there
+is no strong guarantee that it will be called.</p></div>
+<div class="paragraph"><p>The special callback <code>early_error/5</code> is called when an error
+occurs before the request headers were fully received and
+Cowboy is sending a response. It receives the partial Req
+object, the error reason, the protocol options and the response
+Cowboy will send. This response must be returned, possibly
+modified.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_built_in_handlers">Built-in handlers</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>Cowboy comes with two handlers.</p></div>
+<div class="paragraph"><p><code>cowboy_stream_h</code> is the default stream handler.
+It is the core of much of the functionality of Cowboy.
+All chains of stream handlers should call it last.</p></div>
+<div class="paragraph"><p><code>cowboy_compress_h</code> will automatically compress
+responses when possible. It is not enabled by default.
+It is a good example for writing your own handlers
+that will modify responses.</p></div>
+</div>
+</div>