diff options
Diffstat (limited to 'docs/en/cowboy/2.3/guide')
30 files changed, 2086 insertions, 5299 deletions
diff --git a/docs/en/cowboy/2.3/guide/constraints/index.html b/docs/en/cowboy/2.3/guide/constraints/index.html index 029dcc19..7907e2b5 100644 --- a/docs/en/cowboy/2.3/guide/constraints/index.html +++ b/docs/en/cowboy/2.3/guide/constraints/index.html @@ -62,141 +62,86 @@ <h1 class="lined-header"><span>Constraints</span></h1> -<div class="paragraph"><p>Constraints are validation and conversion functions applied -to user input.</p></div> -<div class="paragraph"><p>They are used in various places in Cowboy, including the -router and the <code>cowboy_req</code> match functions.</p></div> -<div class="sect1"> +<p>Constraints are validation and conversion functions applied to user input.</p> +<p>They are used in various places in Cowboy, including the router and the <code>cowboy_req</code> match functions.</p> <h2 id="_syntax">Syntax</h2> -<div class="sectionbody"> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>A field can take the form of an atom <code>field</code>, a tuple with -constraints <code>{field, Constraints}</code> or a tuple with constraints -and a default value <code>{field, Constraints, Default}</code>. -The <code>field</code> form indicates the field is mandatory.</p></div> -<div class="paragraph"><p>Note that when used with the router, only the second form -makes sense, as it does not use the default and the field -is always defined.</p></div> -<div class="paragraph"><p>Constraints for each field are provided as an ordered list -of atoms or funs to apply. Built-in constraints are provided -as atoms, while custom constraints are provided as funs.</p></div> -<div class="paragraph"><p>When multiple constraints are provided, they are applied in -the order given. If the value has been modified by a constraint -then the next one receives the new value.</p></div> -<div class="paragraph"><p>For example, the following constraints will first validate -and convert the field <code>my_value</code> to an integer, and then -check that the integer is positive:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>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.</p> +<p>A field can take the form of an atom <code>field</code>, a tuple with constraints <code>{field, Constraints}</code> or a tuple with constraints and a default value <code>{field, Constraints, Default}</code>. The <code>field</code> form indicates the field is mandatory.</p> +<p>Note that when used with the router, only the second form makes sense, as it does not use the default and the field is always defined.</p> +<p>Constraints for each field are provided as an ordered list of atoms or funs to apply. Built-in constraints are provided as atoms, while custom constraints are provided as funs.</p> +<p>When multiple constraints are provided, they are applied in the order given. If the value has been modified by a constraint then the next one receives the new value.</p> +<p>For example, the following constraints will first validate and convert the field <code>my_value</code> to an integer, and then check that the integer is positive:</p> +<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><span style="color: #009900">PositiveFun</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #0000FF">fun</span></span> - (<span style="color: #990000">_</span>, <span style="color: #009900">V</span>) <span style="font-weight: bold"><span style="color: #0000FF">when</span></span> <span style="color: #009900">V</span> <span style="color: #990000">></span> <span style="color: #993399">0</span> <span style="color: #990000">-></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">V</span>}; - (<span style="color: #990000">_</span>, <span style="color: #990000">_</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">error</span>, <span style="color: #FF6600">not_positive</span>} -<span style="font-weight: bold"><span style="color: #0000FF">end</span></span>, -{<span style="color: #FF6600">my_value</span>, [<span style="color: #FF6600">int</span>, <span style="color: #009900">PositiveFun</span>]}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>We ignore the first fun argument in this snippet. We shouldn’t. -We will simply learn what it is later in this chapter.</p></div> -<div class="paragraph"><p>When there’s only one constraint, it can be provided directly -without wrapping it into a list:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PositiveFun</font> <font color="#990000">=</font> <b><font color="#0000FF">fun</font></b> + (<font color="#990000">_</font>, <font color="#009900">V</font>) <b><font color="#0000FF">when</font></b> <font color="#009900">V</font> <font color="#990000">></font> <font color="#993399">0</font> <font color="#990000">-></font> + {<font color="#FF6600">ok</font>, <font color="#009900">V</font>}; + (<font color="#990000">_</font>, <font color="#990000">_</font>) <font color="#990000">-></font> + {<font color="#FF6600">error</font>, <font color="#FF6600">not_positive</font>} +<b><font color="#0000FF">end</font></b>, +{<font color="#FF6600">my_value</font>, [<font color="#FF6600">int</font>, <font color="#009900">PositiveFun</font>]}<font color="#990000">.</font></tt></pre> +</div></div> +<p>We ignore the first fun argument in this snippet. We shouldn't. We will simply learn what it is later in this chapter.</p> +<p>When there's only one constraint, it can be provided directly without wrapping it into a list:</p> +<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>{<span style="color: #FF6600">my_value</span>, <span style="color: #FF6600">int</span>}</tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt>{<font color="#FF6600">my_value</font>, <font color="#FF6600">int</font>}</tt></pre> +</div></div> <h2 id="_built_in_constraints">Built-in constraints</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Built-in constraints are specified as an atom:</p></div> -<div class="tableblock"> -<table rules="all" -width="100%" -frame="border" -cellspacing="0" cellpadding="4"> -<col width="50%" /> -<col width="50%" /> -<thead> -<tr> -<th align="left" valign="top"> Constraint </th> -<th align="left" valign="top"> Description</th> -</tr> -</thead> -<tbody> -<tr> -<td align="left" valign="top"><p class="table">int</p></td> -<td align="left" valign="top"><p class="table">Converts binary value to integer.</p></td> +<p>Built-in constraints are specified as an atom:</p> +<table rules="all" width="100%" frame="border" + cellspacing="0" cellpadding="4"> +<thead><tr><th>Constraint</th> +<th>Description</th> +</tr></thead><tbody><tr><td>int</td> +<td>Converts binary value to integer.</td> </tr> -<tr> -<td align="left" valign="top"><p class="table">nonempty</p></td> -<td align="left" valign="top"><p class="table">Ensures the binary value is non-empty.</p></td> +<tr><td>nonempty</td> +<td>Ensures the binary value is non-empty.</td> </tr> -</tbody> -</table> -</div> -</div> -</div> -<div class="sect1"> +</tbody></table> <h2 id="_custom_constraints">Custom constraints</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Custom constraints are specified as a fun. This fun takes -two arguments. The first argument indicates the operation -to be performed, and the second is the value. What the -value is and what must be returned depends on the operation.</p></div> -<div class="paragraph"><p>Cowboy currently defines three operations. The operation -used for validating and converting user input is the <code>forward</code> -operation.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Custom constraints are specified as a fun. This fun takes two arguments. The first argument indicates the operation to be performed, and the second is the value. What the value is and what must be returned depends on the operation.</p> +<p>Cowboy currently defines three operations. The operation used for validating and converting user input is the <code>forward</code> operation.</p> +<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><span style="font-weight: bold"><span style="color: #000000">int</span></span>(<span style="color: #FF6600">forward</span>, <span style="color: #009900">Value</span>) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #0000FF">try</span></span> - {<span style="color: #FF6600">ok</span>, <span style="font-weight: bold"><span style="color: #000000">binary_to_integer</span></span>(<span style="color: #009900">Value</span>)} - <span style="font-weight: bold"><span style="color: #0000FF">catch</span></span> <span style="color: #990000">_:_</span> <span style="color: #990000">-></span> - {<span style="color: #FF6600">error</span>, <span style="color: #FF6600">not_an_integer</span>} - <span style="font-weight: bold"><span style="color: #0000FF">end</span></span>;</tt></pre></div></div> -<div class="paragraph"><p>The value must be returned even if it is not converted -by the constraint.</p></div> -<div class="paragraph"><p>The <code>reverse</code> operation does the opposite: it -takes a converted value and changes it back to what the -user input would have been.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">int</font></b>(<font color="#FF6600">forward</font>, <font color="#009900">Value</font>) <font color="#990000">-></font> + <b><font color="#0000FF">try</font></b> + {<font color="#FF6600">ok</font>, <b><font color="#000000">binary_to_integer</font></b>(<font color="#009900">Value</font>)} + <b><font color="#0000FF">catch</font></b> <font color="#990000">_:_</font> <font color="#990000">-></font> + {<font color="#FF6600">error</font>, <font color="#FF6600">not_an_integer</font>} + <b><font color="#0000FF">end</font></b>;</tt></pre> +</div></div> +<p>The value must be returned even if it is not converted by the constraint.</p> +<p>The <code>reverse</code> operation does the opposite: it takes a converted value and changes it back to what the user input would have been.</p> +<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><span style="font-weight: bold"><span style="color: #000000">int</span></span>(<span style="color: #FF6600">reverse</span>, <span style="color: #009900">Value</span>) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #0000FF">try</span></span> - {<span style="color: #FF6600">ok</span>, <span style="font-weight: bold"><span style="color: #000000">integer_to_binary</span></span>(<span style="color: #009900">Value</span>)} - <span style="font-weight: bold"><span style="color: #0000FF">catch</span></span> <span style="color: #990000">_:_</span> <span style="color: #990000">-></span> - {<span style="color: #FF6600">error</span>, <span style="color: #FF6600">not_an_integer</span>} - <span style="font-weight: bold"><span style="color: #0000FF">end</span></span>;</tt></pre></div></div> -<div class="paragraph"><p>Finally, the <code>format_error</code> operation takes an error -returned by any other operation and returns a formatted -human-readable error message.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">int</font></b>(<font color="#FF6600">reverse</font>, <font color="#009900">Value</font>) <font color="#990000">-></font> + <b><font color="#0000FF">try</font></b> + {<font color="#FF6600">ok</font>, <b><font color="#000000">integer_to_binary</font></b>(<font color="#009900">Value</font>)} + <b><font color="#0000FF">catch</font></b> <font color="#990000">_:_</font> <font color="#990000">-></font> + {<font color="#FF6600">error</font>, <font color="#FF6600">not_an_integer</font>} + <b><font color="#0000FF">end</font></b>;</tt></pre> +</div></div> +<p>Finally, the <code>format_error</code> operation takes an error returned by any other operation and returns a formatted human-readable error message.</p> +<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><span style="font-weight: bold"><span style="color: #000000">int</span></span>(<span style="color: #FF6600">format_error</span>, {<span style="color: #FF6600">not_an_integer</span>, <span style="color: #009900">Value</span>}) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #000000">io_lib:format</span></span>(<span style="color: #FF0000">"The value ~p is not an integer."</span>, [<span style="color: #009900">Value</span>])<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Notice that for this case you get both the error and -the value that was given to the constraint that produced -this error.</p></div> -<div class="paragraph"><p>Cowboy will not catch exceptions coming from constraint -functions. They should be written to not emit any exceptions.</p></div> -</div> -</div> +<pre><tt><b><font color="#000000">int</font></b>(<font color="#FF6600">format_error</font>, {<font color="#FF6600">not_an_integer</font>, <font color="#009900">Value</font>}) <font color="#990000">-></font> + <b><font color="#000000">io_lib:format</font></b>(<font color="#FF0000">"The value ~p is not an integer."</font>, [<font color="#009900">Value</font>])<font color="#990000">.</font></tt></pre> +</div></div> +<p>Notice that for this case you get both the error and the value that was given to the constraint that produced this error.</p> +<p>Cowboy will not catch exceptions coming from constraint functions. They should be written to not emit any exceptions.</p> + diff --git a/docs/en/cowboy/2.3/guide/cookies/index.html b/docs/en/cowboy/2.3/guide/cookies/index.html index 2f4c28f8..8d1e67bb 100644 --- a/docs/en/cowboy/2.3/guide/cookies/index.html +++ b/docs/en/cowboy/2.3/guide/cookies/index.html @@ -62,144 +62,103 @@ <h1 class="lined-header"><span>Using cookies</span></h1> -<div class="paragraph"><p>Cookies are a mechanism allowing applications to maintain -state on top of the stateless HTTP protocol.</p></div> -<div class="paragraph"><p>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).</p></div> -<div class="paragraph"><p>Cookie names are de facto case sensitive.</p></div> -<div class="paragraph"><p>Cookies are stored client-side and sent with every subsequent -request that matches the domain and path for which they were -stored, until they expire. This can create a non-negligible -cost.</p></div> -<div class="paragraph"><p>Cookies should not be considered secure. They are stored on -the user’s computer in plain text, and can be read by any -program. They can also be read by proxies when using clear -connections. Always validate the value before using it, -and never store any sensitive information inside it.</p></div> -<div class="paragraph"><p>Cookies set by the server are only available in requests -following the client reception of the response containing -them.</p></div> -<div class="paragraph"><p>Cookies may be sent repeatedly. This is often useful to -update the expiration time and avoid losing a cookie.</p></div> -<div class="sect1"> +<p>Cookies are a mechanism allowing applications to maintain state on top of the stateless HTTP protocol.</p> +<p>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).</p> +<p>Cookie names are de facto case sensitive.</p> +<p>Cookies are stored client-side and sent with every subsequent request that matches the domain and path for which they were stored, until they expire. This can create a non-negligible cost.</p> +<p>Cookies should not be considered secure. They are stored on the user's computer in plain text, and can be read by any program. They can also be read by proxies when using clear connections. Always validate the value before using it, and never store any sensitive information inside it.</p> +<p>Cookies set by the server are only available in requests following the client reception of the response containing them.</p> +<p>Cookies may be sent repeatedly. This is often useful to update the expiration time and avoid losing a cookie.</p> <h2 id="_setting_cookies">Setting cookies</h2> -<div class="sectionbody"> -<div class="paragraph"><p>By default cookies are defined for the duration of the session:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>By default cookies are defined for the duration of the session:</p> +<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><span style="color: #009900">SessionID</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">generate_session_id</span></span>(), -<span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:set_resp_cookie</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"sessionid"</span><span style="color: #990000">>></span>, <span style="color: #009900">SessionID</span>, <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>They can also be set for a duration in seconds:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">SessionID</font> <font color="#990000">=</font> <b><font color="#000000">generate_session_id</font></b>(), +<font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:set_resp_cookie</font></b>(<font color="#990000"><<</font><font color="#FF0000">"sessionid"</font><font color="#990000">>></font>, <font color="#009900">SessionID</font>, <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>They can also be set for a duration in seconds:</p> +<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><span style="color: #009900">SessionID</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">generate_session_id</span></span>(), -<span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:set_resp_cookie</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"sessionid"</span><span style="color: #990000">>></span>, <span style="color: #009900">SessionID</span>, <span style="color: #009900">Req0</span>, - #{<span style="color: #0000FF">max_age</span> <span style="color: #990000">=></span> <span style="color: #993399">3600</span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>To delete cookies, set <code>max_age</code> to 0:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">SessionID</font> <font color="#990000">=</font> <b><font color="#000000">generate_session_id</font></b>(), +<font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:set_resp_cookie</font></b>(<font color="#990000"><<</font><font color="#FF0000">"sessionid"</font><font color="#990000">>></font>, <font color="#009900">SessionID</font>, <font color="#009900">Req0</font>, + #{<font color="#0000FF">max_age</font> <font color="#990000">=></font> <font color="#993399">3600</font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>To delete cookies, set <code>max_age</code> to 0:</p> +<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><span style="color: #009900">SessionID</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">generate_session_id</span></span>(), -<span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:set_resp_cookie</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"sessionid"</span><span style="color: #990000">>></span>, <span style="color: #009900">SessionID</span>, <span style="color: #009900">Req0</span>, - #{<span style="color: #0000FF">max_age</span> <span style="color: #990000">=></span> <span style="color: #993399">0</span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>To restrict cookies to a specific domain and path, the options -of the same name can be used:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">SessionID</font> <font color="#990000">=</font> <b><font color="#000000">generate_session_id</font></b>(), +<font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:set_resp_cookie</font></b>(<font color="#990000"><<</font><font color="#FF0000">"sessionid"</font><font color="#990000">>></font>, <font color="#009900">SessionID</font>, <font color="#009900">Req0</font>, + #{<font color="#0000FF">max_age</font> <font color="#990000">=></font> <font color="#993399">0</font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>To restrict cookies to a specific domain and path, the options of the same name can be used:</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:set_resp_cookie</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"inaccount"</span><span style="color: #990000">>></span>, <span style="color: #990000"><<</span><span style="color: #FF0000">"1"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req0</span>, - #{<span style="color: #0000FF">domain</span> <span style="color: #990000">=></span> <span style="color: #FF0000">"my.example.org"</span>, <span style="color: #0000FF">path</span> <span style="color: #990000">=></span> <span style="color: #FF0000">"/account"</span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Cookies will be sent with requests to this domain and all -its subdomains, and to resources on this path or deeper -in the path hierarchy.</p></div> -<div class="paragraph"><p>To restrict cookies to secure channels (typically resources -available over HTTPS):</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:set_resp_cookie</font></b>(<font color="#990000"><<</font><font color="#FF0000">"inaccount"</font><font color="#990000">>></font>, <font color="#990000"><<</font><font color="#FF0000">"1"</font><font color="#990000">>></font>, <font color="#009900">Req0</font>, + #{<font color="#0000FF">domain</font> <font color="#990000">=></font> <font color="#FF0000">"my.example.org"</font>, <font color="#0000FF">path</font> <font color="#990000">=></font> <font color="#FF0000">"/account"</font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>Cookies will be sent with requests to this domain and all its subdomains, and to resources on this path or deeper in the path hierarchy.</p> +<p>To restrict cookies to secure channels (typically resources available over HTTPS):</p> +<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><span style="color: #009900">SessionID</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">generate_session_id</span></span>(), -<span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:set_resp_cookie</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"sessionid"</span><span style="color: #990000">>></span>, <span style="color: #009900">SessionID</span>, <span style="color: #009900">Req0</span>, - #{<span style="color: #0000FF">secure</span> <span style="color: #990000">=></span> <span style="color: #000080">true</span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>To prevent client-side scripts from accessing a cookie:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">SessionID</font> <font color="#990000">=</font> <b><font color="#000000">generate_session_id</font></b>(), +<font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:set_resp_cookie</font></b>(<font color="#990000"><<</font><font color="#FF0000">"sessionid"</font><font color="#990000">>></font>, <font color="#009900">SessionID</font>, <font color="#009900">Req0</font>, + #{<font color="#0000FF">secure</font> <font color="#990000">=></font> <font color="#000080">true</font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>To prevent client-side scripts from accessing a cookie:</p> +<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><span style="color: #009900">SessionID</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">generate_session_id</span></span>(), -<span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:set_resp_cookie</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"sessionid"</span><span style="color: #990000">>></span>, <span style="color: #009900">SessionID</span>, <span style="color: #009900">Req0</span>, - #{<span style="color: #0000FF">http_only</span> <span style="color: #990000">=></span> <span style="color: #000080">true</span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Cookies may also be set client-side, for example using -Javascript.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">SessionID</font> <font color="#990000">=</font> <b><font color="#000000">generate_session_id</font></b>(), +<font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:set_resp_cookie</font></b>(<font color="#990000"><<</font><font color="#FF0000">"sessionid"</font><font color="#990000">>></font>, <font color="#009900">SessionID</font>, <font color="#009900">Req0</font>, + #{<font color="#0000FF">http_only</font> <font color="#990000">=></font> <font color="#000080">true</font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>Cookies may also be set client-side, for example using Javascript.</p> <h2 id="_reading_cookies">Reading cookies</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The client only ever sends back the cookie name and value. -All other options that can be set are never sent back.</p></div> -<div class="paragraph"><p>Cowboy provides two functions for reading cookies. Both -involve parsing the cookie header(s) and so should not -be called repeatedly.</p></div> -<div class="paragraph"><p>You can get all cookies as a key/value list:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The client only ever sends back the cookie name and value. All other options that can be set are never sent back.</p> +<p>Cowboy provides two functions for reading cookies. Both involve parsing the cookie header(s) and so should not be called repeatedly.</p> +<p>You can get all cookies as a key/value list:</p> +<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><span style="color: #009900">Cookies</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:parse_cookies</span></span>(<span style="color: #009900">Req</span>), -{<span style="color: #990000">_</span>, <span style="color: #009900">Lang</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">lists:keyfind</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"lang"</span><span style="color: #990000">>></span>, <span style="color: #993399">1</span>, <span style="color: #009900">Cookies</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Or you can perform a match against cookies and retrieve -only the ones you need, while at the same time doing -any required post processing using <a href="../constraints">constraints</a>. -This function returns a map:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Cookies</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:parse_cookies</font></b>(<font color="#009900">Req</font>), +{<font color="#990000">_</font>, <font color="#009900">Lang</font>} <font color="#990000">=</font> <b><font color="#000000">lists:keyfind</font></b>(<font color="#990000"><<</font><font color="#FF0000">"lang"</font><font color="#990000">>></font>, <font color="#993399">1</font>, <font color="#009900">Cookies</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Or you can perform a match against cookies and retrieve only the ones you need, while at the same time doing any required post processing using <a href="../constraints">constraints</a>. This function returns a map:</p> +<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>#{<span style="color: #FF6600">id</span> <span style="color: #990000">:=</span> <span style="color: #009900">ID</span>, <span style="color: #FF6600">lang</span> <span style="color: #990000">:=</span> <span style="color: #009900">Lang</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:match_cookies</span></span>([<span style="color: #FF6600">id</span>, <span style="color: #FF6600">lang</span>], <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>You can use constraints to validate the values while matching -them. The following snippet will crash if the <code>id</code> cookie is -not an integer number or if the <code>lang</code> cookie is empty. Additionally -the <code>id</code> cookie value will be converted to an integer term:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>#{<font color="#FF6600">id</font> <font color="#990000">:=</font> <font color="#009900">ID</font>, <font color="#FF6600">lang</font> <font color="#990000">:=</font> <font color="#009900">Lang</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:match_cookies</font></b>([<font color="#FF6600">id</font>, <font color="#FF6600">lang</font>], <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>You can use constraints to validate the values while matching them. The following snippet will crash if the <code>id</code> cookie is not an integer number or if the <code>lang</code> cookie is empty. Additionally the <code>id</code> cookie value will be converted to an integer term:</p> +<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><span style="color: #009900">CookiesMap</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:match_cookies</span></span>([{<span style="color: #FF6600">id</span>, <span style="color: #FF6600">int</span>}, {<span style="color: #FF6600">lang</span>, <span style="color: #FF6600">nonempty</span>}], <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Note that if two cookies share the same name, then the map value -will be a list of the two cookie values.</p></div> -<div class="paragraph"><p>A default value can be provided. The default will be used -if the <code>lang</code> cookie is not found. It will not be used if -the cookie is found but has an empty value:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">CookiesMap</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:match_cookies</font></b>([{<font color="#FF6600">id</font>, <font color="#FF6600">int</font>}, {<font color="#FF6600">lang</font>, <font color="#FF6600">nonempty</font>}], <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Note that if two cookies share the same name, then the map value will be a list of the two cookie values.</p> +<p>A default value can be provided. The default will be used if the <code>lang</code> cookie is not found. It will not be used if the cookie is found but has an empty value:</p> +<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>#{<span style="color: #FF6600">lang</span> <span style="color: #990000">:=</span> <span style="color: #009900">Lang</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:match_cookies</span></span>([{<span style="color: #FF6600">lang</span>, [], <span style="color: #990000"><<</span><span style="color: #FF0000">"en-US"</span><span style="color: #990000">>></span>}], <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>If no default is provided and the value is missing, an -exception is thrown.</p></div> -</div> -</div> +<pre><tt>#{<font color="#FF6600">lang</font> <font color="#990000">:=</font> <font color="#009900">Lang</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:match_cookies</font></b>([{<font color="#FF6600">lang</font>, [], <font color="#990000"><<</font><font color="#FF0000">"en-US"</font><font color="#990000">>></font>}], <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>If no default is provided and the value is missing, an exception is thrown.</p> + diff --git a/docs/en/cowboy/2.3/guide/erlang_web/index.html b/docs/en/cowboy/2.3/guide/erlang_web/index.html index 97bc07d2..76a54644 100644 --- a/docs/en/cowboy/2.3/guide/erlang_web/index.html +++ b/docs/en/cowboy/2.3/guide/erlang_web/index.html @@ -62,194 +62,52 @@ <h1 class="lined-header"><span>Erlang and the Web</span></h1> -<div class="paragraph"><p>Erlang is the ideal platform for writing Web applications. -Its features are a perfect match for the requirements of -modern Web applications.</p></div> -<div class="sect1"> +<p>Erlang is the ideal platform for writing Web applications. Its features are a perfect match for the requirements of modern Web applications.</p> <h2 id="_the_web_is_concurrent">The Web is concurrent</h2> -<div class="sectionbody"> -<div class="paragraph"><p>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. This isn’t much.</p></div> -<div class="paragraph"><p>But think about it. You are not the only one accessing -the server at the same time. There can be hundreds, if -not thousands, if not millions of connections to the -same server at the same time.</p></div> -<div class="paragraph"><p>Even today a lot of systems used in production haven’t -solved the C10K problem (ten thousand concurrent connections). -And the ones who did are trying hard to get to the next -step, C100K, and are pretty far from it.</p></div> -<div class="paragraph"><p>Erlang meanwhile has no problem handling millions of -connections. At the time of writing there are application -servers written in Erlang that can handle more than two -million connections on a single server in a real production -application, with spare memory and CPU!</p></div> -<div class="paragraph"><p>The Web is concurrent, and Erlang is a language designed -for concurrency, so it is a perfect match.</p></div> -<div class="paragraph"><p>Of course, various platforms need to scale beyond a few -million connections. This is where Erlang’s built-in -distribution mechanisms come in. If one server isn’t -enough, add more! Erlang allows you to use the same code -for talking to local processes or to processes in other -parts of your cluster, which means you can scale very -quickly if the need arises.</p></div> -<div class="paragraph"><p>The Web has large userbases, and the Erlang platform was -designed to work in a distributed setting, so it is a -perfect match.</p></div> -<div class="paragraph"><p>Or is it? Surely you can find solutions to handle that many -concurrent connections with your favorite language… But all -these solutions will break down in the next few years. Why? -Firstly because servers don’t get any more powerful, they -instead get a lot more cores and memory. This is only useful -if your application can use them properly, and Erlang is -light-years away from anything else in that area. Secondly, -today your computer and your phone are online, tomorrow your -watch, goggles, bike, car, fridge and tons of other devices -will also connect to various applications on the Internet.</p></div> -<div class="paragraph"><p>Only Erlang is prepared to deal with what’s coming.</p></div> -</div> -</div> -<div class="sect1"> +<p>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. This isn't much.</p> +<p>But think about it. You are not the only one accessing the server at the same time. There can be hundreds, if not thousands, if not millions of connections to the same server at the same time.</p> +<p>Even today a lot of systems used in production haven't solved the C10K problem (ten thousand concurrent connections). And the ones who did are trying hard to get to the next step, C100K, and are pretty far from it.</p> +<p>Erlang meanwhile has no problem handling millions of connections. At the time of writing there are application servers written in Erlang that can handle more than two million connections on a single server in a real production application, with spare memory and CPU!</p> +<p>The Web is concurrent, and Erlang is a language designed for concurrency, so it is a perfect match.</p> +<p>Of course, various platforms need to scale beyond a few million connections. This is where Erlang's built-in distribution mechanisms come in. If one server isn't enough, add more! Erlang allows you to use the same code for talking to local processes or to processes in other parts of your cluster, which means you can scale very quickly if the need arises.</p> +<p>The Web has large userbases, and the Erlang platform was designed to work in a distributed setting, so it is a perfect match.</p> +<p>Or is it? Surely you can find solutions to handle that many concurrent connections with your favorite language... But all these solutions will break down in the next few years. Why? Firstly because servers don't get any more powerful, they instead get a lot more cores and memory. This is only useful if your application can use them properly, and Erlang is light-years away from anything else in that area. Secondly, today your computer and your phone are online, tomorrow your watch, goggles, bike, car, fridge and tons of other devices will also connect to various applications on the Internet.</p> +<p>Only Erlang is prepared to deal with what's coming.</p> <h2 id="_the_web_is_soft_real_time">The Web is soft real time</h2> -<div class="sectionbody"> -<div class="paragraph"><p>What does soft real time mean, you ask? It means we want the -operations done as quickly as possible, and in the case of -web applications, it means we want the data propagated fast.</p></div> -<div class="paragraph"><p>In comparison, hard real time has a similar meaning, but also -has a hard time constraint, for example an operation needs to -be done in under N milliseconds otherwise the system fails -entirely.</p></div> -<div class="paragraph"><p>Users aren’t that needy yet, they just want to get access -to their content in a reasonable delay, and they want the -actions they make to register at most a few seconds after -they submitted them, otherwise they’ll start worrying about -whether it successfully went through.</p></div> -<div class="paragraph"><p>The Web is soft real time because taking longer to perform an -operation would be seen as bad quality of service.</p></div> -<div class="paragraph"><p>Erlang is a soft real time system. It will always run -processes fairly, a little at a time, switching to another -process after a while and preventing a single process to -steal resources from all others. This means that Erlang -can guarantee stable low latency of operations.</p></div> -<div class="paragraph"><p>Erlang provides the guarantees that the soft real time Web -requires.</p></div> -</div> -</div> -<div class="sect1"> +<p>What does soft real time mean, you ask? It means we want the operations done as quickly as possible, and in the case of web applications, it means we want the data propagated fast.</p> +<p>In comparison, hard real time has a similar meaning, but also has a hard time constraint, for example an operation needs to be done in under N milliseconds otherwise the system fails entirely.</p> +<p>Users aren't that needy yet, they just want to get access to their content in a reasonable delay, and they want the actions they make to register at most a few seconds after they submitted them, otherwise they'll start worrying about whether it successfully went through.</p> +<p>The Web is soft real time because taking longer to perform an operation would be seen as bad quality of service.</p> +<p>Erlang is a soft real time system. It will always run processes fairly, a little at a time, switching to another process after a while and preventing a single process to steal resources from all others. This means that Erlang can guarantee stable low latency of operations.</p> +<p>Erlang provides the guarantees that the soft real time Web requires.</p> <h2 id="_the_web_is_asynchronous">The Web is asynchronous</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Long ago, the Web was synchronous because HTTP was synchronous. -You fired a request, and then waited for a response. Not anymore. -It all began when XmlHttpRequest started being used. It allowed -the client to perform asynchronous calls to the server.</p></div> -<div class="paragraph"><p>Then Websocket appeared and allowed both the server and the client -to send data to the other endpoint completely asynchronously. The -data is contained within frames and no response is necessary.</p></div> -<div class="paragraph"><p>Erlang processes work the same. They send each other data contained -within messages and then continue running without needing a response. -They tend to spend most of their time inactive, waiting for a new -message, and the Erlang VM happily activate them when one is received.</p></div> -<div class="paragraph"><p>It is therefore quite easy to imagine Erlang being good at receiving -Websocket frames, which may come in at unpredictable times, pass the -data to the responsible processes which are always ready waiting for -new messages, and perform the operations required by only activating -the required parts of the system.</p></div> -<div class="paragraph"><p>The more recent Web technologies, like Websocket of course, but also -HTTP/2.0, are all fully asynchronous protocols. The concept -of requests and responses is retained of course, but anything could -be sent in between, by both the client or the browser, and the -responses could also be received in a completely different order.</p></div> -<div class="paragraph"><p>Erlang is by nature asynchronous and really good at it thanks to the -great engineering that has been done in the VM over the years. It’s -only natural that it’s so good at dealing with the asynchronous Web.</p></div> -</div> -</div> -<div class="sect1"> +<p>Long ago, the Web was synchronous because HTTP was synchronous. You fired a request, and then waited for a response. Not anymore. It all began when XmlHttpRequest started being used. It allowed the client to perform asynchronous calls to the server.</p> +<p>Then Websocket appeared and allowed both the server and the client to send data to the other endpoint completely asynchronously. The data is contained within frames and no response is necessary.</p> +<p>Erlang processes work the same. They send each other data contained within messages and then continue running without needing a response. They tend to spend most of their time inactive, waiting for a new message, and the Erlang VM happily activate them when one is received.</p> +<p>It is therefore quite easy to imagine Erlang being good at receiving Websocket frames, which may come in at unpredictable times, pass the data to the responsible processes which are always ready waiting for new messages, and perform the operations required by only activating the required parts of the system.</p> +<p>The more recent Web technologies, like Websocket of course, but also HTTP/2.0, are all fully asynchronous protocols. The concept of requests and responses is retained of course, but anything could be sent in between, by both the client or the browser, and the responses could also be received in a completely different order.</p> +<p>Erlang is by nature asynchronous and really good at it thanks to the great engineering that has been done in the VM over the years. It's only natural that it's so good at dealing with the asynchronous Web.</p> <h2 id="_the_web_is_omnipresent">The Web is omnipresent</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The Web has taken a very important part of our lives. We’re -connected at all times, when we’re on our phone, using our computer, -passing time using a tablet while in the bathroom… And this -isn’t going to slow down, every single device at home or on us -will be connected.</p></div> -<div class="paragraph"><p>All these devices are always connected. And with the number of -alternatives to give you access to the content you seek, users -tend to not stick around when problems arise. Users today want -their applications to be always available and if it’s having -too many issues they just move on.</p></div> -<div class="paragraph"><p>Despite this, when developers choose a product to use for building -web applications, their only concern seems to be "Is it fast?", -and they look around for synthetic benchmarks showing which one -is the fastest at sending "Hello world" with only a handful -concurrent connections. Web benchmarks haven’t been representative -of reality in a long time, and are drifting further away as -time goes on.</p></div> -<div class="paragraph"><p>What developers should really ask themselves is "Can I service -all my users with no interruption?" and they’d find that they have -two choices. They can either hope for the best, or they can use -Erlang.</p></div> -<div class="paragraph"><p>Erlang is built for fault tolerance. When writing code in any other -language, you have to check all the return values and act accordingly -to avoid any unforeseen issues. If you’re lucky, you won’t miss -anything important. When writing Erlang code, you can just check -the success condition and ignore all errors. If an error happens, -the Erlang process crashes and is then restarted by a special -process called a supervisor.</p></div> -<div class="paragraph"><p>Erlang developers thus have no need to fear unhandled -errors, and can focus on handling only the errors that should -give some feedback to the user and let the system take care of -the rest. This also has the advantage of allowing them to write -a lot less code, and let them sleep at night.</p></div> -<div class="paragraph"><p>Erlang’s fault tolerance oriented design is the first piece of -what makes it the best choice for the omnipresent, always available -Web.</p></div> -<div class="paragraph"><p>The second piece is Erlang’s built-in distribution. Distribution -is a key part of building a fault tolerant system, because it -allows you to handle bigger failures, like a whole server going -down, or even a data center entirely.</p></div> -<div class="paragraph"><p>Fault tolerance and distribution are important today, and will be -vital in the future of the Web. Erlang is ready.</p></div> -</div> -</div> -<div class="sect1"> +<p>The Web has taken a very important part of our lives. We're connected at all times, when we're on our phone, using our computer, passing time using a tablet while in the bathroom... And this isn't going to slow down, every single device at home or on us will be connected.</p> +<p>All these devices are always connected. And with the number of alternatives to give you access to the content you seek, users tend to not stick around when problems arise. Users today want their applications to be always available and if it's having too many issues they just move on.</p> +<p>Despite this, when developers choose a product to use for building web applications, their only concern seems to be "Is it fast?", and they look around for synthetic benchmarks showing which one is the fastest at sending "Hello world" with only a handful concurrent connections. Web benchmarks haven't been representative of reality in a long time, and are drifting further away as time goes on.</p> +<p>What developers should really ask themselves is "Can I service all my users with no interruption?" and they'd find that they have two choices. They can either hope for the best, or they can use Erlang.</p> +<p>Erlang is built for fault tolerance. When writing code in any other language, you have to check all the return values and act accordingly to avoid any unforeseen issues. If you're lucky, you won't miss anything important. When writing Erlang code, you can just check the success condition and ignore all errors. If an error happens, the Erlang process crashes and is then restarted by a special process called a supervisor.</p> +<p>Erlang developers thus have no need to fear unhandled errors, and can focus on handling only the errors that should give some feedback to the user and let the system take care of the rest. This also has the advantage of allowing them to write a lot less code, and let them sleep at night.</p> +<p>Erlang's fault tolerance oriented design is the first piece of what makes it the best choice for the omnipresent, always available Web.</p> +<p>The second piece is Erlang's built-in distribution. Distribution is a key part of building a fault tolerant system, because it allows you to handle bigger failures, like a whole server going down, or even a data center entirely.</p> +<p>Fault tolerance and distribution are important today, and will be vital in the future of the Web. Erlang is ready.</p> <h2 id="_learn_erlang">Learn Erlang</h2> -<div class="sectionbody"> -<div class="paragraph"><p>If you are new to Erlang, you may want to grab a book or -two to get started. Those are my recommendations as the -author of Cowboy.</p></div> -<div class="sect3"> +<p>If you are new to Erlang, you may want to grab a book or two to get started. Those are my recommendations as the author of Cowboy.</p> <h4 id="_the_erlanger_playbook">The Erlanger Playbook</h4> -<div class="paragraph"><p>The Erlanger Playbook is an ebook I am currently writing, -which covers a number of different topics from code to -documentation to testing Erlang applications. It also has -an Erlang section where it covers directly the building -blocks and patterns, rather than details like the syntax.</p></div> -<div class="paragraph"><p>You can most likely read it as a complete beginner, but -you will need a companion book to make the most of it. -Buy it from the <a href="https://ninenines.eu">Nine Nines website</a>.</p></div> -</div> -<div class="sect3"> +<p>The Erlanger Playbook is an ebook I am currently writing, which covers a number of different topics from code to documentation to testing Erlang applications. It also has an Erlang section where it covers directly the building blocks and patterns, rather than details like the syntax.</p> +<p>You can most likely read it as a complete beginner, but you will need a companion book to make the most of it. Buy it from the <a href="https://ninenines.eu">Nine Nines website</a>.</p> <h4 id="_programming_erlang">Programming Erlang</h4> -<div class="paragraph"><p>This book is from one of the creator of Erlang, Joe -Armstrong. It provides a very good explanation of what -Erlang is and why it is so. It serves as a very good -introduction to the language and platform.</p></div> -<div class="paragraph"><p>The book is <a href="http://pragprog.com/book/jaerlang2/programming-erlang">Programming Erlang</a>, -and it also features a chapter on Cowboy.</p></div> -</div> -<div class="sect3"> +<p>This book is from one of the creator of Erlang, Joe Armstrong. It provides a very good explanation of what Erlang is and why it is so. It serves as a very good introduction to the language and platform.</p> +<p>The book is <a href="http://pragprog.com/book/jaerlang2/programming-erlang">Programming Erlang</a>, and it also features a chapter on Cowboy.</p> <h4 id="_learn_you_some_erlang_for_great_good">Learn You Some Erlang for Great Good!</h4> -<div class="paragraph"><p><a href="http://learnyousomeerlang.com">LYSE</a> is a much more complete -book covering many aspects of Erlang, while also providing -stories and humor. Be warned: it’s pretty verbose. It comes -with a free online version and a more refined paper and -ebook version.</p></div> -</div> -</div> -</div> +<p><a href="http://learnyousomeerlang.com">LYSE</a> is a much more complete book covering many aspects of Erlang, while also providing stories and humor. Be warned: it's pretty verbose. It comes with a free online version and a more refined paper and ebook version.</p> + diff --git a/docs/en/cowboy/2.3/guide/flow_diagram/index.html b/docs/en/cowboy/2.3/guide/flow_diagram/index.html index 05bc677a..d675a2f5 100644 --- a/docs/en/cowboy/2.3/guide/flow_diagram/index.html +++ b/docs/en/cowboy/2.3/guide/flow_diagram/index.html @@ -62,113 +62,30 @@ <h1 class="lined-header"><span>Flow diagram</span></h1> -<div class="paragraph"><p>Cowboy is a lightweight HTTP server with support for HTTP/1.1, -HTTP/2 and Websocket.</p></div> -<div class="paragraph"><p>It is built on top of Ranch. Please see the Ranch guide for more -information about how the network connections are handled.</p></div> -<div class="sect1"> +<p>Cowboy is a lightweight HTTP server with support for HTTP/1.1, HTTP/2 and Websocket.</p> +<p>It is built on top of Ranch. Please see the Ranch guide for more information about how the network connections are handled.</p> <h2 id="_overview">Overview</h2> -<div class="sectionbody"> -<div class="imageblock"> -<div class="content"> -<img src="../http_req_resp.png" alt="HTTP request/response flowchart" /> -</div> -</div> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>After Ranch accepts a new connection, whether it is an -HTTP/1.1 or HTTP/2 connection, Cowboy starts receiving -requests and handling them.</p></div> -<div class="paragraph"><p>In HTTP/1.1 all requests come sequentially. In HTTP/2 -the requests may arrive and be processed concurrently.</p></div> -<div class="paragraph"><p>When a request comes in, Cowboy creates a stream, which -is a set of request/response and all the events associated -with them. The protocol code in Cowboy defers the handling -of these streams to stream handler modules. When you -configure Cowboy you may define one or more module that -will receive all events associated with a stream, including -the request, response, bodies, Erlang messages and more.</p></div> -<div class="paragraph"><p>By default Cowboy comes configured with a stream handler -called <code>cowboy_stream_h</code>. This stream handler will create -a new process for every request coming in, and then -communicate with this process to read the body or send -a response back. The request process executes middlewares -which, by default, including the router and then the -execution of handlers. Like stream handlers, middlewares -may also be customized.</p></div> -<div class="paragraph"><p>A response may be sent at almost any point in this -diagram. If the response must be sent before the stream -is initialized (because an error occurred early, for -example) then stream handlers receive a special event -indicating this error.</p></div> -</div> -</div> -<div class="sect1"> +<img src="../http_req_resp.png" alt="HTTP request/response flowchart"/><p>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.</p> +<p>After Ranch accepts a new connection, whether it is an HTTP/1.1 or HTTP/2 connection, Cowboy starts receiving requests and handling them.</p> +<p>In HTTP/1.1 all requests come sequentially. In HTTP/2 the requests may arrive and be processed concurrently.</p> +<p>When a request comes in, Cowboy creates a stream, which is a set of request/response and all the events associated with them. The protocol code in Cowboy defers the handling of these streams to stream handler modules. When you configure Cowboy you may define one or more module that will receive all events associated with a stream, including the request, response, bodies, Erlang messages and more.</p> +<p>By default Cowboy comes configured with a stream handler called <code>cowboy_stream_h</code>. This stream handler will create a new process for every request coming in, and then communicate with this process to read the body or send a response back. The request process executes middlewares which, by default, including the router and then the execution of handlers. Like stream handlers, middlewares may also be customized.</p> +<p>A response may be sent at almost any point in this diagram. If the response must be sent before the stream is initialized (because an error occurred early, for example) then stream handlers receive a special event indicating this error.</p> <h2 id="_protocol_specific_headers">Protocol-specific headers</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy takes care of protocol-specific headers and prevents -you from sending them manually. For HTTP/1.1 this includes -the <code>transfer-encoding</code> and <code>connection</code> headers. For HTTP/2 -this includes the colon headers like <code>:status</code>.</p></div> -<div class="paragraph"><p>Cowboy will also remove protocol-specific headers from -requests before passing them to stream handlers. Cowboy -tries to hide the implementation details of all protocols -as well as possible.</p></div> -</div> -</div> -<div class="sect1"> +<p>Cowboy takes care of protocol-specific headers and prevents you from sending them manually. For HTTP/1.1 this includes the <code>transfer-encoding</code> and <code>connection</code> headers. For HTTP/2 this includes the colon headers like <code>:status</code>.</p> +<p>Cowboy will also remove protocol-specific headers from requests before passing them to stream handlers. Cowboy tries to hide the implementation details of all protocols as well as possible.</p> <h2 id="_number_of_processes_per_connection">Number of processes per connection</h2> -<div class="sectionbody"> -<div class="paragraph"><p>By default, Cowboy will use one process per connection, -plus one process per set of request/response (called a -stream, internally).</p></div> -<div class="paragraph"><p>The reason it creates a new process for every request is due -to the requirements of HTTP/2 where requests are executed -concurrently and independently from the connection. The -frames from the different requests end up interleaved on -the single TCP connection.</p></div> -<div class="paragraph"><p>The request processes are never reused. There is therefore -no need to perform any cleanup after the response has been -sent. The process will terminate and Erlang/OTP will reclaim -all memory at once.</p></div> -<div class="paragraph"><p>Cowboy ultimately does not require more than one process -per connection. It is possible to interact with the connection -directly from a stream handler, a low level interface to Cowboy. -They are executed from within the connection process, and can -handle the incoming requests and send responses. This is however -not recommended in normal circumstances, as a stream handler -taking too long to execute could have a negative impact on -concurrent requests or the state of the connection itself.</p></div> -</div> -</div> -<div class="sect1"> +<p>By default, Cowboy will use one process per connection, plus one process per set of request/response (called a stream, internally).</p> +<p>The reason it creates a new process for every request is due to the requirements of HTTP/2 where requests are executed concurrently and independently from the connection. The frames from the different requests end up interleaved on the single TCP connection.</p> +<p>The request processes are never reused. There is therefore no need to perform any cleanup after the response has been sent. The process will terminate and Erlang/OTP will reclaim all memory at once.</p> +<p>Cowboy ultimately does not require more than one process per connection. It is possible to interact with the connection directly from a stream handler, a low level interface to Cowboy. They are executed from within the connection process, and can handle the incoming requests and send responses. This is however not recommended in normal circumstances, as a stream handler taking too long to execute could have a negative impact on concurrent requests or the state of the connection itself.</p> <h2 id="_date_header">Date header</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Because querying for the current date and time can be expensive, -Cowboy generates one <em>Date</em> header value every second, shares it -to all other processes, which then simply copy it in the response. -This allows compliance with HTTP/1.1 with no actual performance loss.</p></div> -</div> -</div> -<div class="sect1"> +<p>Because querying for the current date and time can be expensive, Cowboy generates one <em>Date</em> header value every second, shares it to all other processes, which then simply copy it in the response. This allows compliance with HTTP/1.1 with no actual performance loss.</p> <h2 id="_binaries">Binaries</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy makes extensive use of binaries.</p></div> -<div class="paragraph"><p>Binaries are more efficient than lists for representing -strings because they take less memory space. Processing -performance can vary depending on the operation. Binaries -are known for generally getting a great boost if the code -is compiled natively. Please see the HiPE documentation -for more details.</p></div> -<div class="paragraph"><p>Binaries may end up being shared between processes. This -can lead to some large memory usage when one process keeps -the binary data around forever without freeing it. If you -see some weird memory usage in your application, this might -be the cause.</p></div> -</div> -</div> +<p>Cowboy makes extensive use of binaries.</p> +<p>Binaries are more efficient than lists for representing strings because they take less memory space. Processing performance can vary depending on the operation. Binaries are known for generally getting a great boost if the code is compiled natively. Please see the HiPE documentation for more details.</p> +<p>Binaries may end up being shared between processes. This can lead to some large memory usage when one process keeps the binary data around forever without freeing it. If you see some weird memory usage in your application, this might be the cause.</p> + diff --git a/docs/en/cowboy/2.3/guide/getting_started/index.html b/docs/en/cowboy/2.3/guide/getting_started/index.html index b06cbf46..d214b33a 100644 --- a/docs/en/cowboy/2.3/guide/getting_started/index.html +++ b/docs/en/cowboy/2.3/guide/getting_started/index.html @@ -62,161 +62,104 @@ <h1 class="lined-header"><span>Getting started</span></h1> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>This chapter walks you through all the steps of setting up -Cowboy, writing your first application and generating your first -release. At the end of this chapter you should know everything -you need to push your first Cowboy application to production.</p></div> -<div class="sect1"> +<p>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.</p> +<p>This chapter walks you through all the steps of setting up Cowboy, writing your first application and generating your first release. At the end of this chapter you should know everything you need to push your first Cowboy application to production.</p> <h2 id="_prerequisites">Prerequisites</h2> -<div class="sectionbody"> -<div class="paragraph"><p>We are going to use the <a href="https://github.com/ninenines/erlang.mk">Erlang.mk</a> -build system. If you are using Windows, please check the -<a href="http://erlang.mk/guide/installation.html">Installation instructions</a> -to get your environment setup before you continue.</p></div> -</div> -</div> -<div class="sect1"> +<p>We are going to use the <a href="https://github.com/ninenines/erlang.mk">Erlang.mk</a> build system. If you are using Windows, please check the <a href="http://erlang.mk/guide/installation.html">Installation instructions</a> to get your environment setup before you continue.</p> <h2 id="_bootstrap">Bootstrap</h2> -<div class="sectionbody"> -<div class="paragraph"><p>First, let’s create the directory for our application.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>First, let's create the directory for our application.</p> +<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>$ mkdir hello_erlang -$ cd hello_erlang</tt></pre></div></div> -<div class="paragraph"><p>Then we need to download Erlang.mk. Either use the following -command or download it manually.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +$ cd hello_erlang</tt></pre> +</div></div> +<p>Then we need to download Erlang.mk. Either use the following command or download it manually.</p> +<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>$ wget https<span style="color: #990000">:</span>//erlang<span style="color: #990000">.</span>mk/erlang<span style="color: #990000">.</span>mk</tt></pre></div></div> -<div class="paragraph"><p>We can now bootstrap our application. Since we are going to generate -a release, we will also bootstrap it at the same time.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>$ wget https<font color="#990000">:</font>//erlang<font color="#990000">.</font>mk/erlang<font color="#990000">.</font>mk</tt></pre> +</div></div> +<p>We can now bootstrap our application. Since we are going to generate a release, we will also bootstrap it at the same time.</p> +<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>$ make -f erlang<span style="color: #990000">.</span>mk bootstrap bootstrap-rel</tt></pre></div></div> -<div class="paragraph"><p>This creates a Makefile, a base application, and the release files -necessary for creating the release. We can already build and start -this release.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>$ make -f erlang<font color="#990000">.</font>mk bootstrap bootstrap-rel</tt></pre> +</div></div> +<p>This creates a Makefile, a base application, and the release files necessary for creating the release. We can already build and start this release.</p> +<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>$ make run -<span style="color: #990000">...</span> -<span style="color: #990000">(</span>hello_erlang@<span style="color: #993399">127.0</span><span style="color: #990000">.</span><span style="color: #993399">0.1</span><span style="color: #990000">)</span><span style="color: #993399">1</span><span style="color: #990000">></span></tt></pre></div></div> -<div class="paragraph"><p>Entering the command <code>i().</code> will show the running processes, including -one called <code>hello_erlang_sup</code>. This is the supervisor for our -application.</p></div> -<div class="paragraph"><p>The release currently does nothing. In the rest of this chapter we -will add Cowboy as a dependency and write a simple "Hello world!" -handler.</p></div> -</div> -</div> -<div class="sect1"> +<font color="#990000">...</font> +<font color="#990000">(</font>hello_erlang@<font color="#993399">127.0</font><font color="#990000">.</font><font color="#993399">0.1</font><font color="#990000">)</font><font color="#993399">1</font><font color="#990000">></font></tt></pre> +</div></div> +<p>Entering the command <code>i().</code> will show the running processes, including one called <code>hello_erlang_sup</code>. This is the supervisor for our application.</p> +<p>The release currently does nothing. In the rest of this chapter we will add Cowboy as a dependency and write a simple "Hello world!" handler.</p> <h2 id="_cowboy_setup">Cowboy setup</h2> -<div class="sectionbody"> -<div class="paragraph"><p>We will modify the <em>Makefile</em> to tell the build system it needs to -fetch and compile Cowboy:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>We will modify the <em>Makefile</em> to tell the build system it needs to fetch and compile Cowboy:</p> +<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><span style="color: #009900">PROJECT =</span> hello_erlang +<pre><tt><font color="#009900">PROJECT =</font> hello_erlang -<span style="color: #009900">DEPS =</span> cowboy -<span style="color: #009900">dep_cowboy_commit =</span> 2.3.0 +<font color="#009900">DEPS =</font> cowboy +<font color="#009900">dep_cowboy_commit =</font> 2.3.0 -<span style="color: #009900">DEP_PLUGINS =</span> cowboy +<font color="#009900">DEP_PLUGINS =</font> cowboy -include erlang.mk</tt></pre></div></div> -<div class="paragraph"><p>We also tell the build system to load the plugins Cowboy provides. -These include predefined templates that we will use soon.</p></div> -<div class="paragraph"><p>If you do <code>make run</code> now, Cowboy will be included in the release -and started automatically. This is not enough however, as Cowboy -doesn’t do anything by default. We still need to tell Cowboy to -listen for connections.</p></div> -</div> -</div> -<div class="sect1"> +include erlang.mk</tt></pre> +</div></div> +<p>We also tell the build system to load the plugins Cowboy provides. These include predefined templates that we will use soon.</p> +<p>If you do <code>make run</code> now, Cowboy will be included in the release and started automatically. This is not enough however, as Cowboy doesn't do anything by default. We still need to tell Cowboy to listen for connections.</p> <h2 id="_listening_for_connections">Listening for connections</h2> -<div class="sectionbody"> -<div class="paragraph"><p>First we define the routes that Cowboy will use to map requests -to handler modules, and then we start the listener. This is best -done at application startup.</p></div> -<div class="paragraph"><p>Open the <em>src/hello_erlang_app.erl</em> file and add the necessary -code to the <code>start/2</code> function to make it look like this:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>First we define the routes that Cowboy will use to map requests to handler modules, and then we start the listener. This is best done at application startup.</p> +<p>Open the <em>src/hello_erlang_app.erl</em> file and add the necessary code to the <code>start/2</code> function to make it look like this:</p> +<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><span style="font-weight: bold"><span style="color: #000000">start</span></span>(<span style="color: #009900">_Type</span>, <span style="color: #009900">_Args</span>) <span style="color: #990000">-></span> - <span style="color: #009900">Dispatch</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_router:compile</span></span>([ - {<span style="color: #FF6600">'_'</span>, [{<span style="color: #FF0000">"/"</span>, <span style="color: #FF6600">hello_handler</span>, []}]} +<pre><tt><b><font color="#000000">start</font></b>(<font color="#009900">_Type</font>, <font color="#009900">_Args</font>) <font color="#990000">-></font> + <font color="#009900">Dispatch</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_router:compile</font></b>([ + {<font color="#FF6600">'_'</font>, [{<font color="#FF0000">"/"</font>, <font color="#FF6600">hello_handler</font>, []}]} ]), - {<span style="color: #FF6600">ok</span>, <span style="color: #990000">_</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy:start_clear</span></span>(<span style="color: #FF6600">my_http_listener</span>, - [{<span style="color: #FF6600">port</span>, <span style="color: #993399">8080</span>}], - #{<span style="color: #0000FF">env</span> <span style="color: #990000">=></span> #{<span style="color: #0000FF">dispatch</span> <span style="color: #990000">=></span> <span style="color: #009900">Dispatch</span>}} + {<font color="#FF6600">ok</font>, <font color="#990000">_</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy:start_clear</font></b>(<font color="#FF6600">my_http_listener</font>, + [{<font color="#FF6600">port</font>, <font color="#993399">8080</font>}], + #{<font color="#0000FF">env</font> <font color="#990000">=></font> #{<font color="#0000FF">dispatch</font> <font color="#990000">=></font> <font color="#009900">Dispatch</font>}} ), - <span style="font-weight: bold"><span style="color: #000000">hello_erlang_sup:start_link</span></span>()<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Routes are explained in details in the <a href="../routing">Routing</a> -chapter. For this tutorial we map the path <code>/</code> to the handler -module <code>hello_handler</code>. This module doesn’t exist yet.</p></div> -<div class="paragraph"><p>Build and start the release, then open <a href="http://localhost:8080">http://localhost:8080</a> -in your browser. You will get a 500 error because the module is missing. -Any other URL, like <a href="http://localhost:8080/test">http://localhost:8080/test</a>, will result in a -404 error.</p></div> -</div> -</div> -<div class="sect1"> + <b><font color="#000000">hello_erlang_sup:start_link</font></b>()<font color="#990000">.</font></tt></pre> +</div></div> +<p>Routes are explained in details in the <a href="../routing">Routing</a> chapter. For this tutorial we map the path <code>/</code> to the handler module <code>hello_handler</code>. This module doesn't exist yet.</p> +<p>Build and start the release, then open <a href="http://localhost:8080">http://localhost:8080</a> in your browser. You will get a 500 error because the module is missing. Any other URL, like <a href="http://localhost:8080/test">http://localhost:8080/test</a>, will result in a 404 error.</p> <h2 id="_handling_requests">Handling requests</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy features different kinds of handlers, including REST -and Websocket handlers. For this tutorial we will use a plain -HTTP handler.</p></div> -<div class="paragraph"><p>Generate a handler from a template:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy features different kinds of handlers, including REST and Websocket handlers. For this tutorial we will use a plain HTTP handler.</p> +<p>Generate a handler from a template:</p> +<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>$ make new <span style="color: #009900">t</span><span style="color: #990000">=</span>cowboy<span style="color: #990000">.</span>http <span style="color: #009900">n</span><span style="color: #990000">=</span>hello_handler</tt></pre></div></div> -<div class="paragraph"><p>Then, open the <em>src/hello_handler.erl</em> file and modify -the <code>init/2</code> function like this to send a reply.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>$ make new <font color="#009900">t</font><font color="#990000">=</font>cowboy<font color="#990000">.</font>http <font color="#009900">n</font><font color="#990000">=</font>hello_handler</tt></pre> +</div></div> +<p>Then, open the <em>src/hello_handler.erl</em> file and modify the <code>init/2</code> function like this to send a reply.</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req0</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - <span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">200</span>, - #{<span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"text/plain"</span><span style="color: #990000">>></span>}, - <span style="color: #990000"><<</span><span style="color: #FF0000">"Hello Erlang!"</span><span style="color: #990000">>></span>, - <span style="color: #009900">Req0</span>), - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>What the above code does is send a 200 OK reply, with the -Content-type header set to <code>text/plain</code> and the response -body set to <code>Hello Erlang!</code>.</p></div> -<div class="paragraph"><p>If you run the release and open <a href="http://localhost:8080">http://localhost:8080</a> -in your browser, you should get a nice <code>Hello Erlang!</code> displayed!</p></div> -</div> -</div> +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req0</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + <font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">200</font>, + #{<font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"text/plain"</font><font color="#990000">>></font>}, + <font color="#990000"><<</font><font color="#FF0000">"Hello Erlang!"</font><font color="#990000">>></font>, + <font color="#009900">Req0</font>), + {<font color="#FF6600">ok</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>What the above code does is send a 200 OK reply, with the Content-type header set to <code>text/plain</code> and the response body set to <code>Hello Erlang!</code>.</p> +<p>If you run the release and open <a href="http://localhost:8080">http://localhost:8080</a> in your browser, you should get a nice <code>Hello Erlang!</code> displayed!</p> + diff --git a/docs/en/cowboy/2.3/guide/handlers/index.html b/docs/en/cowboy/2.3/guide/handlers/index.html index e8567d8e..61d83e67 100644 --- a/docs/en/cowboy/2.3/guide/handlers/index.html +++ b/docs/en/cowboy/2.3/guide/handlers/index.html @@ -62,91 +62,57 @@ <h1 class="lined-header"><span>Handlers</span></h1> -<div class="paragraph"><p>Handlers are Erlang modules that handle HTTP requests.</p></div> -<div class="sect1"> +<p>Handlers are Erlang modules that handle HTTP requests.</p> <h2 id="_plain_http_handlers">Plain HTTP handlers</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The most basic handler in Cowboy implements the mandatory -<code>init/2</code> callback, manipulates the request, optionally -sends a response and then returns.</p></div> -<div class="paragraph"><p>This callback receives the <a href="../req">Req object</a> and the initial -state defined in the <a href="../routing">router configuration</a>.</p></div> -<div class="paragraph"><p>A handler that does nothing would look like this:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The most basic handler in Cowboy implements the mandatory <code>init/2</code> callback, manipulates the request, optionally sends a response and then returns.</p> +<p>This callback receives the <a href="../req">Req object</a> and the initial state defined in the <a href="../routing">router configuration</a>.</p> +<p>A handler that does nothing would look like this:</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Despite sending no reply, a <code>204 No Content</code> response will be -sent to the client, as Cowboy makes sure that a response is -sent for every request.</p></div> -<div class="paragraph"><p>We need to use the Req object to reply.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">ok</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>Despite sending no reply, a <code>204 No Content</code> response will be sent to the client, as Cowboy makes sure that a response is sent for every request.</p> +<p>We need to use the Req object to reply.</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req0</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - <span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">200</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"text/plain"</span><span style="color: #990000">>></span> - }, <span style="color: #990000"><<</span><span style="color: #FF0000">"Hello World!"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req0</span>), - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Cowboy will immediately send a response when <code>cowboy:reply/4</code> -is called.</p></div> -<div class="paragraph"><p>We then return a 3-tuple. <code>ok</code> means that the handler ran -successfully. We also give the modified Req back to Cowboy.</p></div> -<div class="paragraph"><p>The last value of the tuple is a state that will be used -in every subsequent callbacks to this handler. Plain HTTP -handlers only have one additional callback, the optional -and rarely used <code>terminate/3</code>.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req0</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + <font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">200</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"text/plain"</font><font color="#990000">>></font> + }, <font color="#990000"><<</font><font color="#FF0000">"Hello World!"</font><font color="#990000">>></font>, <font color="#009900">Req0</font>), + {<font color="#FF6600">ok</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>Cowboy will immediately send a response when <code>cowboy:reply/4</code> is called.</p> +<p>We then return a 3-tuple. <code>ok</code> means that the handler ran successfully. We also give the modified Req back to Cowboy.</p> +<p>The last value of the tuple is a state that will be used in every subsequent callbacks to this handler. Plain HTTP handlers only have one additional callback, the optional and rarely used <code>terminate/3</code>.</p> <h2 id="_other_handlers">Other handlers</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The <code>init/2</code> callback can also be used to inform Cowboy -that this is a different kind of handler and that Cowboy -should switch to it. To do this you simply need to return -the module name of the handler type you want to switch to.</p></div> -<div class="paragraph"><p>Cowboy comes with three handler types you can switch to: -<a href="../rest_handlers">cowboy_rest</a>, <a href="#ws_handlers">cowboy_websocket</a> -and <a href="../loop_handlers">cowboy_loop</a>. In addition to those you -can define your own handler types.</p></div> -<div class="paragraph"><p>Switching is simple. Instead of returning <code>ok</code>, you simply -return the name of the handler type you want to use. The -following snippet switches to a Websocket handler:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The <code>init/2</code> callback can also be used to inform Cowboy that this is a different kind of handler and that Cowboy should switch to it. To do this you simply need to return the module name of the handler type you want to switch to.</p> +<p>Cowboy comes with three handler types you can switch to: <a href="../rest_handlers">cowboy_rest</a>, <a href="../ws_handlers">cowboy_websocket</a> and <a href="../loop_handlers">cowboy_loop</a>. In addition to those you can define your own handler types.</p> +<p>Switching is simple. Instead of returning <code>ok</code>, you simply return the name of the handler type you want to use. The following snippet switches to a Websocket handler:</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">cowboy_websocket</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">cowboy_websocket</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_cleaning_up">Cleaning up</h2> -<div class="sectionbody"> -<div class="paragraph"><p>All handler types provide the optional <code>terminate/3</code> callback.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>All handler types provide the optional <code>terminate/3</code> callback.</p> +<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><span style="font-weight: bold"><span style="color: #000000">terminate</span></span>(<span style="color: #009900">_Reason</span>, <span style="color: #009900">_Req</span>, <span style="color: #009900">_State</span>) <span style="color: #990000">-></span> - <span style="color: #FF6600">ok</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>This callback is strictly reserved for any required cleanup. -You cannot send a response from this function. There is no -other return value.</p></div> -<div class="paragraph"><p>This callback is optional because it is rarely necessary. -Cleanup should be done in separate processes directly (by -monitoring the handler process to detect when it exits).</p></div> -<div class="paragraph"><p>Cowboy does not reuse processes for different requests. The -process will terminate soon after this call returns.</p></div> -</div> -</div> +<pre><tt><b><font color="#000000">terminate</font></b>(<font color="#009900">_Reason</font>, <font color="#009900">_Req</font>, <font color="#009900">_State</font>) <font color="#990000">-></font> + <font color="#FF6600">ok</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>This callback is strictly reserved for any required cleanup. You cannot send a response from this function. There is no other return value.</p> +<p>This callback is optional because it is rarely necessary. Cleanup should be done in separate processes directly (by monitoring the handler process to detect when it exits).</p> +<p>Cowboy does not reuse processes for different requests. The process will terminate soon after this call returns.</p> + diff --git a/docs/en/cowboy/2.3/guide/index.html b/docs/en/cowboy/2.3/guide/index.html index 88267686..2aede748 100644 --- a/docs/en/cowboy/2.3/guide/index.html +++ b/docs/en/cowboy/2.3/guide/index.html @@ -62,214 +62,85 @@ <h1 class="lined-header"><span>Cowboy User Guide</span></h1> -<div class="sect1"> +<!-- REST: where should i handle bindings? init, probably. qs? in media type functions--> +<!-- REST: explain how a module per media type is good; module may be shared between client/server--> <h2 id="_rationale">Rationale</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="modern_web/">The modern Web</a> -</p> +<ul><li><a href="modern_web/">The modern Web</a> </li> -<li> -<p> -<a href="erlang_web/">Erlang and the Web</a> -</p> +<li><a href="erlang_web/">Erlang and the Web</a> </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_introduction">Introduction</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="introduction/">Introduction</a> -</p> +<ul><li><a href="introduction/">Introduction</a> </li> -<li> -<p> -<a href="getting_started/">Getting started</a> -</p> +<li><a href="getting_started/">Getting started</a> </li> -<li> -<p> -<a href="flow_diagram/">Flow diagram</a> -</p> +<li><a href="flow_diagram/">Flow diagram</a> </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_configuration">Configuration</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="listeners/">Listeners</a> -</p> +<ul><li><a href="listeners/">Listeners</a> </li> -<li> -<p> -<a href="routing/">Routing</a> -</p> +<li><a href="routing/">Routing</a> </li> -<li> -<p> -<a href="constraints/">Constraints</a> -</p> +<li><a href="constraints/">Constraints</a> </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_handlers">Handlers</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="handlers/">Handlers</a> -</p> +<ul><li><a href="handlers/">Handlers</a> </li> -<li> -<p> -<a href="loop_handlers/">Loop handlers</a> -</p> +<li><a href="loop_handlers/">Loop handlers</a> </li> -<li> -<p> -<a href="static_files/">Static files</a> -</p> +<li><a href="static_files/">Static files</a> </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_request_and_response">Request and response</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="req/">Request details</a> -</p> +<ul><li><a href="req/">Request details</a> </li> -<li> -<p> -<a href="req_body/">Reading the request body</a> -</p> +<li><a href="req_body/">Reading the request body</a> </li> -<li> -<p> -<a href="resp/">Sending a response</a> -</p> +<li><a href="resp/">Sending a response</a> </li> -<li> -<p> -<a href="cookies/">Using cookies</a> -</p> +<li><a href="cookies/">Using cookies</a> </li> -<li> -<p> -<a href="multipart/">Multipart</a> -</p> +<li><a href="multipart/">Multipart</a> </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_rest">REST</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="rest_principles/">REST principles</a> -</p> +<ul><li><a href="rest_principles/">REST principles</a> </li> -<li> -<p> -<a href="rest_handlers/">Handling REST requests</a> -</p> +<li><a href="rest_handlers/">Handling REST requests</a> </li> -<li> -<p> -<a href="rest_flowcharts/">REST flowcharts</a> -</p> +<li><a href="rest_flowcharts/">REST flowcharts</a> </li> -<li> -<p> -<a href="resource_design/">Designing a resource handler</a> -</p> +<li><a href="resource_design/">Designing a resource handler</a> </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_websocket">Websocket</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="ws_protocol/">The Websocket protocol</a> -</p> +<ul><li><a href="ws_protocol/">The Websocket protocol</a> </li> -<li> -<p> -<a href="ws_handlers/">Websocket handlers</a> -</p> +<li><a href="ws_handlers/">Websocket handlers</a> </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_advanced">Advanced</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="streams/">Streams</a> -</p> +<ul><li><a href="streams/">Streams</a> </li> -<li> -<p> -<a href="middlewares/">Middlewares</a> -</p> +<li><a href="middlewares/">Middlewares</a> </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_additional_information">Additional information</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="migrating_from_2.2/">Migrating from Cowboy 2.2 to 2.3</a> -</p> +<ul><li><a href="migrating_from_2.2/">Migrating from Cowboy 2.2 to 2.3</a> </li> -<li> -<p> -<a href="migrating_from_2.1/">Migrating from Cowboy 2.1 to 2.2</a> -</p> +<li><a href="migrating_from_2.1/">Migrating from Cowboy 2.1 to 2.2</a> </li> -<li> -<p> -<a href="migrating_from_2.0/">Migrating from Cowboy 2.0 to 2.1</a> -</p> +<li><a href="migrating_from_2.0/">Migrating from Cowboy 2.0 to 2.1</a> </li> -<li> -<p> -<a href="migrating_from_1.0/">Migrating from Cowboy 1.0 to 2.0</a> -</p> +<li><a href="migrating_from_1.0/">Migrating from Cowboy 1.0 to 2.0</a> </li> -<li> -<p> -<a href="specs/">HTTP and other specifications</a> -</p> +<li><a href="specs/">HTTP and other specifications</a> </li> -</ul></div> -</div> -</div> +</ul> + diff --git a/docs/en/cowboy/2.3/guide/introduction/index.html b/docs/en/cowboy/2.3/guide/introduction/index.html index eaeaf485..3a0db4b4 100644 --- a/docs/en/cowboy/2.3/guide/introduction/index.html +++ b/docs/en/cowboy/2.3/guide/introduction/index.html @@ -62,79 +62,40 @@ <h1 class="lined-header"><span>Introduction</span></h1> -<div class="paragraph"><p>Cowboy is a small, fast and modern HTTP server for Erlang/OTP.</p></div> -<div class="paragraph"><p>Cowboy aims to provide a complete <a href="../modern_web">modern Web stack</a>. -This includes HTTP/1.1, HTTP/2, Websocket, Server-Sent Events and -Webmachine-based REST.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>Cowboy is clean Erlang code. It includes hundreds of tests and its code -is fully compliant with the Dialyzer. It is also well documented and -features a Function Reference, a User Guide and numerous Tutorials.</p></div> -<div class="sect1"> +<p>Cowboy is a small, fast and modern HTTP server for Erlang/OTP.</p> +<p>Cowboy aims to provide a complete <a href="../modern_web">modern Web stack</a>. This includes HTTP/1.1, HTTP/2, Websocket, Server-Sent Events and Webmachine-based REST.</p> +<p>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.</p> +<p>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.</p> +<p>Cowboy is clean Erlang code. It includes hundreds of tests and its code is fully compliant with the Dialyzer. It is also well documented and features a Function Reference, a User Guide and numerous Tutorials.</p> <h2 id="_prerequisites">Prerequisites</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Beginner Erlang knowledge is recommended for reading this guide.</p></div> -<div class="paragraph"><p>Knowledge of the HTTP protocol is recommended but not required, as it -will be detailed throughout the guide.</p></div> -</div> -</div> -<div class="sect1"> +<p>Beginner Erlang knowledge is recommended for reading this guide.</p> +<p>Knowledge of the HTTP protocol is recommended but not required, as it will be detailed throughout the guide.</p> <h2 id="_supported_platforms">Supported platforms</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy is tested and supported on Linux, FreeBSD, Windows and OSX.</p></div> -<div class="paragraph"><p>Cowboy has been reported to work on other platforms, but we make no -guarantee that the experience will be safe and smooth. You are advised -to perform the necessary testing and security audits prior to deploying -on other platforms.</p></div> -<div class="paragraph"><p>Cowboy is developed for Erlang/OTP 19.0 and newer.</p></div> -</div> -</div> -<div class="sect1"> +<p>Cowboy is tested and supported on Linux, FreeBSD, Windows and OSX.</p> +<p>Cowboy has been reported to work on other platforms, but we make no guarantee that the experience will be safe and smooth. You are advised to perform the necessary testing and security audits prior to deploying on other platforms.</p> +<p>Cowboy is developed for Erlang/OTP 19.0 and newer.</p> <h2 id="_license">License</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy uses the ISC License.</p></div> -<div class="listingblock"> -<div class="content"> -<pre><code>Copyright (c) 2011-2017, Loïc Hoguin <[email protected]> +<p>Cowboy uses the ISC License.</p> +<div class="listingblock"><div class="content"><pre>Copyright (c) 2011-2017, Loïc Hoguin <[email protected]> Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. -THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF -OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.</code></pre> -</div></div> -</div> -</div> -<div class="sect1"> +OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.</pre></div></div> <h2 id="_versioning">Versioning</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy uses <a href="http://semver.org/">Semantic Versioning 2.0.0</a>.</p></div> -</div> -</div> -<div class="sect1"> +<p>Cowboy uses <a href="http://semver.org/">Semantic Versioning 2.0.0</a>.</p> <h2 id="_conventions">Conventions</h2> -<div class="sectionbody"> -<div class="paragraph"><p>In the HTTP protocol, the method name is case sensitive. All standard -method names are uppercase.</p></div> -<div class="paragraph"><p>Header names are case insensitive. When using HTTP/1.1, Cowboy converts -all the request header names to lowercase. HTTP/2 requires clients to -send them as lowercase. Any other header name is expected to be provided -lowercased, including when querying information about the request or -when sending responses.</p></div> -<div class="paragraph"><p>The same applies to any other case insensitive value.</p></div> -</div> -</div> +<p>In the HTTP protocol, the method name is case sensitive. All standard method names are uppercase.</p> +<p>Header names are case insensitive. When using HTTP/1.1, Cowboy converts all the request header names to lowercase. HTTP/2 requires clients to send them as lowercase. Any other header name is expected to be provided lowercased, including when querying information about the request or when sending responses.</p> +<p>The same applies to any other case insensitive value.</p> + diff --git a/docs/en/cowboy/2.3/guide/listeners/index.html b/docs/en/cowboy/2.3/guide/listeners/index.html index 0990f98c..743c25fb 100644 --- a/docs/en/cowboy/2.3/guide/listeners/index.html +++ b/docs/en/cowboy/2.3/guide/listeners/index.html @@ -62,109 +62,61 @@ <h1 class="lined-header"><span>Listeners</span></h1> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>This chapter is specific to Cowboy. Please refer to the -<a href="https://ninenines.eu/docs/en/ranch/1.3/guide/listeners/">Ranch User Guide</a> -for more information about listeners.</p></div> -<div class="paragraph"><p>Cowboy provides two types of listeners: one listening for -clear TCP connections, and one listening for secure TLS -connections. Both of them support the HTTP/1.1 and HTTP/2 -protocols.</p></div> -<div class="sect1"> +<p>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.</p> +<p>This chapter is specific to Cowboy. Please refer to the <a href="https://ninenines.eu/docs/en/ranch/1.3/guide/listeners/">Ranch User Guide</a> for more information about listeners.</p> +<p>Cowboy provides two types of listeners: one listening for clear TCP connections, and one listening for secure TLS connections. Both of them support the HTTP/1.1 and HTTP/2 protocols.</p> <h2 id="_clear_tcp_listener">Clear TCP listener</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The clear TCP listener will accept connections on the -given port. A typical HTTP server would listen on port 80. -Port 80 requires special permissions on most platforms -however so a common alternative is port 8080.</p></div> -<div class="paragraph"><p>The following snippet starts listening for connections -on port 8080:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The clear TCP listener will accept connections on the given port. A typical HTTP server would listen on port 80. Port 80 requires special permissions on most platforms however so a common alternative is port 8080.</p> +<p>The following snippet starts listening for connections on port 8080:</p> +<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><span style="font-weight: bold"><span style="color: #000000">start</span></span>(<span style="color: #009900">_Type</span>, <span style="color: #009900">_Args</span>) <span style="color: #990000">-></span> - <span style="color: #009900">Dispatch</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_router:compile</span></span>([ - {<span style="color: #FF6600">'_'</span>, [{<span style="color: #FF0000">"/"</span>, <span style="color: #FF6600">hello_handler</span>, []}]} +<pre><tt><b><font color="#000000">start</font></b>(<font color="#009900">_Type</font>, <font color="#009900">_Args</font>) <font color="#990000">-></font> + <font color="#009900">Dispatch</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_router:compile</font></b>([ + {<font color="#FF6600">'_'</font>, [{<font color="#FF0000">"/"</font>, <font color="#FF6600">hello_handler</font>, []}]} ]), - {<span style="color: #FF6600">ok</span>, <span style="color: #990000">_</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy:start_clear</span></span>(<span style="color: #FF6600">my_http_listener</span>, - [{<span style="color: #FF6600">port</span>, <span style="color: #993399">8080</span>}], - #{<span style="color: #0000FF">env</span> <span style="color: #990000">=></span> #{<span style="color: #0000FF">dispatch</span> <span style="color: #990000">=></span> <span style="color: #009900">Dispatch</span>}} + {<font color="#FF6600">ok</font>, <font color="#990000">_</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy:start_clear</font></b>(<font color="#FF6600">my_http_listener</font>, + [{<font color="#FF6600">port</font>, <font color="#993399">8080</font>}], + #{<font color="#0000FF">env</font> <font color="#990000">=></font> #{<font color="#0000FF">dispatch</font> <font color="#990000">=></font> <font color="#009900">Dispatch</font>}} ), - <span style="font-weight: bold"><span style="color: #000000">hello_erlang_sup:start_link</span></span>()<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>The <a href="../getting_started">Getting Started</a> chapter uses a -clear TCP listener.</p></div> -<div class="paragraph"><p>Clients connecting to Cowboy on the clear listener port are -expected to use either HTTP/1.1 or HTTP/2.</p></div> -<div class="paragraph"><p>Cowboy supports both methods of initiating a clear -HTTP/2 connection: through the Upgrade mechanism -(<a href="https://tools.ietf.org/html/rfc7540#section-3.2">RFC 7540 3.2</a>) -or by sending the preface directly -(<a href="https://tools.ietf.org/html/rfc7540#section-3.4">RFC 7540 3.4</a>).</p></div> -<div class="paragraph"><p>Compatibility with HTTP/1.0 is provided by Cowboy’s HTTP/1.1 -implementation.</p></div> -</div> -</div> -<div class="sect1"> + <b><font color="#000000">hello_erlang_sup:start_link</font></b>()<font color="#990000">.</font></tt></pre> +</div></div> +<p>The <a href="../getting_started">Getting Started</a> chapter uses a clear TCP listener.</p> +<p>Clients connecting to Cowboy on the clear listener port are expected to use either HTTP/1.1 or HTTP/2.</p> +<p>Cowboy supports both methods of initiating a clear HTTP/2 connection: through the Upgrade mechanism (<a href="https://tools.ietf.org/html/rfc7540#section-3.2">RFC 7540 3.2</a>) or by sending the preface directly (<a href="https://tools.ietf.org/html/rfc7540#section-3.4">RFC 7540 3.4</a>).</p> +<p>Compatibility with HTTP/1.0 is provided by Cowboy's HTTP/1.1 implementation.</p> <h2 id="_secure_tls_listener">Secure TLS listener</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The secure TLS listener will accept connections on the -given port. A typical HTTPS server would listen on port 443. -Port 443 requires special permissions on most platforms -however so a common alternative is port 8443.</p></div> -<div class="paragraph"><p>The function provided by Cowboy will ensure that the TLS -options given are following the HTTP/2 RFC with regards -to security. For example some TLS extensions or ciphers -may be disabled. This also applies to HTTP/1.1 connections -on this listener. If this is not desirable, Ranch can be -used directly to setup a custom listener.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The secure TLS listener will accept connections on the given port. A typical HTTPS server would listen on port 443. Port 443 requires special permissions on most platforms however so a common alternative is port 8443.</p> +<!-- @todo Make a complete list of restrictions.--> +<p>The function provided by Cowboy will ensure that the TLS options given are following the HTTP/2 RFC with regards to security. For example some TLS extensions or ciphers may be disabled. This also applies to HTTP/1.1 connections on this listener. If this is not desirable, Ranch can be used directly to setup a custom listener.</p> +<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><span style="font-weight: bold"><span style="color: #000000">start</span></span>(<span style="color: #009900">_Type</span>, <span style="color: #009900">_Args</span>) <span style="color: #990000">-></span> - <span style="color: #009900">Dispatch</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_router:compile</span></span>([ - {<span style="color: #FF6600">'_'</span>, [{<span style="color: #FF0000">"/"</span>, <span style="color: #FF6600">hello_handler</span>, []}]} +<pre><tt><b><font color="#000000">start</font></b>(<font color="#009900">_Type</font>, <font color="#009900">_Args</font>) <font color="#990000">-></font> + <font color="#009900">Dispatch</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_router:compile</font></b>([ + {<font color="#FF6600">'_'</font>, [{<font color="#FF0000">"/"</font>, <font color="#FF6600">hello_handler</font>, []}]} ]), - {<span style="color: #FF6600">ok</span>, <span style="color: #990000">_</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy:start_tls</span></span>(<span style="color: #FF6600">my_http_listener</span>, + {<font color="#FF6600">ok</font>, <font color="#990000">_</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy:start_tls</font></b>(<font color="#FF6600">my_http_listener</font>, [ - {<span style="color: #FF6600">port</span>, <span style="color: #993399">8443</span>}, - {<span style="color: #FF6600">certfile</span>, <span style="color: #FF0000">"/path/to/certfile"</span>}, - {<span style="color: #FF6600">keyfile</span>, <span style="color: #FF0000">"/path/to/keyfile"</span>} + {<font color="#FF6600">port</font>, <font color="#993399">8443</font>}, + {<font color="#FF6600">certfile</font>, <font color="#FF0000">"/path/to/certfile"</font>}, + {<font color="#FF6600">keyfile</font>, <font color="#FF0000">"/path/to/keyfile"</font>} ], - #{<span style="color: #0000FF">env</span> <span style="color: #990000">=></span> #{<span style="color: #0000FF">dispatch</span> <span style="color: #990000">=></span> <span style="color: #009900">Dispatch</span>}} + #{<font color="#0000FF">env</font> <font color="#990000">=></font> #{<font color="#0000FF">dispatch</font> <font color="#990000">=></font> <font color="#009900">Dispatch</font>}} ), - <span style="font-weight: bold"><span style="color: #000000">hello_erlang_sup:start_link</span></span>()<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Clients connecting to Cowboy on the secure listener are -expected to use the ALPN TLS extension to indicate what -protocols they understand. Cowboy always prefers HTTP/2 -over HTTP/1.1 when both are supported. When neither are -supported by the client, or when the ALPN extension was -missing, Cowboy expects HTTP/1.1 to be used.</p></div> -<div class="paragraph"><p>Cowboy also advertises HTTP/2 support through the older -NPN TLS extension for compatibility. Note however that -this support will likely not be enabled by default when -Cowboy 2.0 gets released.</p></div> -<div class="paragraph"><p>Compatibility with HTTP/1.0 is provided by Cowboy’s HTTP/1.1 -implementation.</p></div> -</div> -</div> -<div class="sect1"> + <b><font color="#000000">hello_erlang_sup:start_link</font></b>()<font color="#990000">.</font></tt></pre> +</div></div> +<p>Clients connecting to Cowboy on the secure listener are expected to use the ALPN TLS extension to indicate what protocols they understand. Cowboy always prefers HTTP/2 over HTTP/1.1 when both are supported. When neither are supported by the client, or when the ALPN extension was missing, Cowboy expects HTTP/1.1 to be used.</p> +<p>Cowboy also advertises HTTP/2 support through the older NPN TLS extension for compatibility. Note however that this support will likely not be enabled by default when Cowboy 2.0 gets released.</p> +<p>Compatibility with HTTP/1.0 is provided by Cowboy's HTTP/1.1 implementation.</p> <h2 id="_protocol_configuration">Protocol configuration</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The HTTP/1.1 and HTTP/2 protocols share the same semantics; -only their framing differs. The first is a text protocol and -the second a binary protocol.</p></div> -<div class="paragraph"><p>Cowboy doesn’t separate the configuration for HTTP/1.1 and -HTTP/2. Everything goes into the same map. Many options are -shared.</p></div> -</div> -</div> +<p>The HTTP/1.1 and HTTP/2 protocols share the same semantics; only their framing differs. The first is a text protocol and the second a binary protocol.</p> +<p>Cowboy doesn't separate the configuration for HTTP/1.1 and HTTP/2. Everything goes into the same map. Many options are shared.</p> +<!-- @todo Describe good to know options for both protocols?--> +<!-- Maybe do that in separate chapters?--> + diff --git a/docs/en/cowboy/2.3/guide/loop_handlers/index.html b/docs/en/cowboy/2.3/guide/loop_handlers/index.html index 57c5be92..637a54e1 100644 --- a/docs/en/cowboy/2.3/guide/loop_handlers/index.html +++ b/docs/en/cowboy/2.3/guide/loop_handlers/index.html @@ -62,131 +62,72 @@ <h1 class="lined-header"><span>Loop handlers</span></h1> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>Loop handlers can also be used for requests where a response is -partially available and you need to stream the response body -while the connection is open. The most known example of such -practice is server-sent events.</p></div> -<div class="paragraph"><p>While the same can be accomplished using plain HTTP handlers, -it is recommended to use loop handlers because they are well-tested -and allow using built-in features like hibernation and timeouts.</p></div> -<div class="paragraph"><p>Loop handlers essentially wait for one or more Erlang messages -and feed these messages to the <code>info/3</code> callback. It also features -the <code>init/2</code> and <code>terminate/3</code> callbacks which work the same as -for plain HTTP handlers.</p></div> -<div class="sect1"> +<p>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.</p> +<p>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.</p> +<p>Loop handlers can also be used for requests where a response is partially available and you need to stream the response body while the connection is open. The most known example of such practice is server-sent events.</p> +<p>While the same can be accomplished using plain HTTP handlers, it is recommended to use loop handlers because they are well-tested and allow using built-in features like hibernation and timeouts.</p> +<p>Loop handlers essentially wait for one or more Erlang messages and feed these messages to the <code>info/3</code> callback. It also features the <code>init/2</code> and <code>terminate/3</code> callbacks which work the same as for plain HTTP handlers.</p> <h2 id="_initialization">Initialization</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The <code>init/2</code> function must return a <code>cowboy_loop</code> tuple to enable -loop handler behavior. This tuple may optionally contain -a timeout value and/or the atom <code>hibernate</code> to make the -process enter hibernation until a message is received.</p></div> -<div class="paragraph"><p>This snippet enables the loop handler:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The <code>init/2</code> function must return a <code>cowboy_loop</code> tuple to enable loop handler behavior. This tuple may optionally contain a timeout value and/or the atom <code>hibernate</code> to make the process enter hibernation until a message is received.</p> +<p>This snippet enables the loop handler:</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">cowboy_loop</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>This also makes the process hibernate:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">cowboy_loop</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>This also makes the process hibernate:</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">cowboy_loop</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>, <span style="color: #FF6600">hibernate</span>}<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">cowboy_loop</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>, <font color="#FF6600">hibernate</font>}<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_receive_loop">Receive loop</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Once initialized, Cowboy will wait for messages to arrive -in the process' mailbox. When a message arrives, Cowboy -calls the <code>info/3</code> function with the message, the Req object -and the handler’s state.</p></div> -<div class="paragraph"><p>The following snippet sends a reply when it receives a -<code>reply</code> message from another process, or waits for another -message otherwise.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Once initialized, Cowboy will wait for messages to arrive in the process' mailbox. When a message arrives, Cowboy calls the <code>info/3</code> function with the message, the Req object and the handler's state.</p> +<p>The following snippet sends a reply when it receives a <code>reply</code> message from another process, or waits for another message otherwise.</p> +<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><span style="font-weight: bold"><span style="color: #000000">info</span></span>({<span style="color: #FF6600">reply</span>, <span style="color: #009900">Body</span>}, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">200</span>, #{}, <span style="color: #009900">Body</span>, <span style="color: #009900">Req</span>), - {<span style="color: #FF6600">stop</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}; -<span style="font-weight: bold"><span style="color: #000000">info</span></span>(<span style="color: #009900">_Msg</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>, <span style="color: #FF6600">hibernate</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Do note that the <code>reply</code> tuple here may be any message -and is simply an example.</p></div> -<div class="paragraph"><p>This callback may perform any necessary operation including -sending all or parts of a reply, and will subsequently -return a tuple indicating if more messages are to be expected.</p></div> -<div class="paragraph"><p>The callback may also choose to do nothing at all and just -skip the message received.</p></div> -<div class="paragraph"><p>If a reply is sent, then the <code>stop</code> tuple should be returned. -This will instruct Cowboy to end the request.</p></div> -<div class="paragraph"><p>Otherwise an <code>ok</code> tuple should be returned.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">info</font></b>({<font color="#FF6600">reply</font>, <font color="#009900">Body</font>}, <font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">200</font>, #{}, <font color="#009900">Body</font>, <font color="#009900">Req</font>), + {<font color="#FF6600">stop</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}; +<b><font color="#000000">info</font></b>(<font color="#009900">_Msg</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">ok</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>, <font color="#FF6600">hibernate</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>Do note that the <code>reply</code> tuple here may be any message and is simply an example.</p> +<p>This callback may perform any necessary operation including sending all or parts of a reply, and will subsequently return a tuple indicating if more messages are to be expected.</p> +<p>The callback may also choose to do nothing at all and just skip the message received.</p> +<p>If a reply is sent, then the <code>stop</code> tuple should be returned. This will instruct Cowboy to end the request.</p> +<p>Otherwise an <code>ok</code> tuple should be returned.</p> <h2 id="_streaming_loop">Streaming loop</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Another common case well suited for loop handlers is -streaming data received in the form of Erlang messages. -This can be done by initiating a chunked reply in the -<code>init/2</code> callback and then using <code>cowboy_req:chunk/2</code> -every time a message is received.</p></div> -<div class="paragraph"><p>The following snippet does exactly that. As you can see -a chunk is sent every time an <code>event</code> message is received, -and the loop is stopped by sending an <code>eof</code> message.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Another common case well suited for loop handlers is streaming data received in the form of Erlang messages. This can be done by initiating a chunked reply in the <code>init/2</code> callback and then using <code>cowboy_req:chunk/2</code> every time a message is received.</p> +<p>The following snippet does exactly that. As you can see a chunk is sent every time an <code>event</code> message is received, and the loop is stopped by sending an <code>eof</code> message.</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - <span style="color: #009900">Req2</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_reply</span></span>(<span style="color: #993399">200</span>, <span style="color: #009900">Req</span>), - {<span style="color: #FF6600">cowboy_loop</span>, <span style="color: #009900">Req2</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span> - -<span style="font-weight: bold"><span style="color: #000000">info</span></span>(<span style="color: #FF6600">eof</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">stop</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}; -<span style="font-weight: bold"><span style="color: #000000">info</span></span>({<span style="color: #FF6600">event</span>, <span style="color: #009900">Data</span>}, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_body</span></span>(<span style="color: #009900">Data</span>, <span style="color: #FF6600">nofin</span>, <span style="color: #009900">Req</span>), - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}; -<span style="font-weight: bold"><span style="color: #000000">info</span></span>(<span style="color: #009900">_Msg</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + <font color="#009900">Req2</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:stream_reply</font></b>(<font color="#993399">200</font>, <font color="#009900">Req</font>), + {<font color="#FF6600">cowboy_loop</font>, <font color="#009900">Req2</font>, <font color="#009900">State</font>}<font color="#990000">.</font> + +<b><font color="#000000">info</font></b>(<font color="#FF6600">eof</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">stop</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}; +<b><font color="#000000">info</font></b>({<font color="#FF6600">event</font>, <font color="#009900">Data</font>}, <font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + <b><font color="#000000">cowboy_req:stream_body</font></b>(<font color="#009900">Data</font>, <font color="#FF6600">nofin</font>, <font color="#009900">Req</font>), + {<font color="#FF6600">ok</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}; +<b><font color="#000000">info</font></b>(<font color="#009900">_Msg</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">ok</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_cleaning_up">Cleaning up</h2> -<div class="sectionbody"> -<div class="paragraph"><p>It is recommended that you set the connection header to -<code>close</code> when replying, as this process may be reused for -a subsequent request.</p></div> -<div class="paragraph"><p>Please refer to the <a href="../handlers">Handlers chapter</a> -for general instructions about cleaning up.</p></div> -</div> -</div> -<div class="sect1"> +<p>It is recommended that you set the connection header to <code>close</code> when replying, as this process may be reused for a subsequent request.</p> +<p>Please refer to the <a href="../handlers">Handlers chapter</a> for general instructions about cleaning up.</p> <h2 id="_hibernate">Hibernate</h2> -<div class="sectionbody"> -<div class="paragraph"><p>To save memory, you may hibernate the process in between -messages received. This is done by returning the atom -<code>hibernate</code> as part of the <code>loop</code> tuple callbacks normally -return. Just add the atom at the end and Cowboy will hibernate -accordingly.</p></div> -</div> -</div> +<p>To save memory, you may hibernate the process in between messages received. This is done by returning the atom <code>hibernate</code> as part of the <code>loop</code> tuple callbacks normally return. Just add the atom at the end and Cowboy will hibernate accordingly.</p> + diff --git a/docs/en/cowboy/2.3/guide/middlewares/index.html b/docs/en/cowboy/2.3/guide/middlewares/index.html index a02ce678..6dbf8869 100644 --- a/docs/en/cowboy/2.3/guide/middlewares/index.html +++ b/docs/en/cowboy/2.3/guide/middlewares/index.html @@ -62,92 +62,38 @@ <h1 class="lined-header"><span>Middlewares</span></h1> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>Cowboy will execute all middlewares in the given order, unless one -of them decides to stop processing.</p></div> -<div class="sect1"> +<p>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.</p> +<p>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.</p> +<p>Cowboy will execute all middlewares in the given order, unless one of them decides to stop processing.</p> <h2 id="_usage">Usage</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Middlewares only need to implement a single callback: <code>execute/2</code>. -It is defined in the <code>cowboy_middleware</code> behavior.</p></div> -<div class="paragraph"><p>This callback has two arguments. The first is the <code>Req</code> object. -The second is the environment.</p></div> -<div class="paragraph"><p>Middlewares can return one of three different values:</p></div> -<div class="ulist"><ul> -<li> -<p> -<code>{ok, Req, Env}</code> to continue the request processing -</p> +<p>Middlewares only need to implement a single callback: <code>execute/2</code>. It is defined in the <code>cowboy_middleware</code> behavior.</p> +<p>This callback has two arguments. The first is the <code>Req</code> object. The second is the environment.</p> +<p>Middlewares can return one of three different values:</p> +<ul><li><code>{ok, Req, Env}</code> to continue the request processing </li> -<li> -<p> -<code>{suspend, Module, Function, Args}</code> to hibernate -</p> +<li><code>{suspend, Module, Function, Args}</code> to hibernate </li> -<li> -<p> -<code>{stop, Req}</code> to stop processing and move on to the next request -</p> +<li><code>{stop, Req}</code> to stop processing and move on to the next request </li> -</ul></div> -<div class="paragraph"><p>Of note is that when hibernating, processing will resume on the given -MFA, discarding all previous stacktrace. Make sure you keep the <code>Req</code> -and <code>Env</code> in the arguments of this MFA for later use.</p></div> -<div class="paragraph"><p>If an error happens during middleware processing, Cowboy will not try -to send an error back to the socket, the process will just crash. It -is up to the middleware to make sure that a reply is sent if something -goes wrong.</p></div> -</div> -</div> -<div class="sect1"> +</ul> +<p>Of note is that when hibernating, processing will resume on the given MFA, discarding all previous stacktrace. Make sure you keep the <code>Req</code> and <code>Env</code> in the arguments of this MFA for later use.</p> +<p>If an error happens during middleware processing, Cowboy will not try to send an error back to the socket, the process will just crash. It is up to the middleware to make sure that a reply is sent if something goes wrong.</p> <h2 id="_configuration">Configuration</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The middleware environment is defined as the <code>env</code> protocol option. -In the previous chapters we saw it briefly when we needed to pass -the routing information. It is a list of tuples with the first -element being an atom and the second any Erlang term.</p></div> -<div class="paragraph"><p>Two values in the environment are reserved:</p></div> -<div class="ulist"><ul> -<li> -<p> -<code>listener</code> contains the name of the listener -</p> +<p>The middleware environment is defined as the <code>env</code> protocol option. In the previous chapters we saw it briefly when we needed to pass the routing information. It is a list of tuples with the first element being an atom and the second any Erlang term.</p> +<p>Two values in the environment are reserved:</p> +<ul><li><code>listener</code> contains the name of the listener </li> -<li> -<p> -<code>result</code> contains the result of the processing -</p> +<li><code>result</code> contains the result of the processing </li> -</ul></div> -<div class="paragraph"><p>The <code>listener</code> value is always defined. The <code>result</code> value can be -set by any middleware. If set to anything other than <code>ok</code>, Cowboy -will not process any subsequent requests on this connection.</p></div> -<div class="paragraph"><p>The middlewares that come with Cowboy may define or require other -environment values to perform.</p></div> -<div class="paragraph"><p>You can update the environment by calling the <code>cowboy:set_env/3</code> -convenience function, adding or replacing a value in the environment.</p></div> -</div> -</div> -<div class="sect1"> +</ul> +<p>The <code>listener</code> value is always defined. The <code>result</code> value can be set by any middleware. If set to anything other than <code>ok</code>, Cowboy will not process any subsequent requests on this connection.</p> +<p>The middlewares that come with Cowboy may define or require other environment values to perform.</p> +<p>You can update the environment by calling the <code>cowboy:set_env/3</code> convenience function, adding or replacing a value in the environment.</p> <h2 id="_routing_middleware">Routing middleware</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The routing middleware requires the <code>dispatch</code> value. If routing -succeeds, it will put the handler name and options in the <code>handler</code> -and <code>handler_opts</code> values of the environment, respectively.</p></div> -</div> -</div> -<div class="sect1"> +<p>The routing middleware requires the <code>dispatch</code> value. If routing succeeds, it will put the handler name and options in the <code>handler</code> and <code>handler_opts</code> values of the environment, respectively.</p> <h2 id="_handler_middleware">Handler middleware</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The handler middleware requires the <code>handler</code> and <code>handler_opts</code> -values. It puts the result of the request handling into <code>result</code>.</p></div> -</div> -</div> +<p>The handler middleware requires the <code>handler</code> and <code>handler_opts</code> values. It puts the result of the request handling into <code>result</code>.</p> + diff --git a/docs/en/cowboy/2.3/guide/migrating_from_1.0/index.html b/docs/en/cowboy/2.3/guide/migrating_from_1.0/index.html index c284d717..b8a30584 100644 --- a/docs/en/cowboy/2.3/guide/migrating_from_1.0/index.html +++ b/docs/en/cowboy/2.3/guide/migrating_from_1.0/index.html @@ -62,388 +62,120 @@ <h1 class="lined-header"><span>Migrating from Cowboy 1.0 to 2.0</span></h1> -<div class="paragraph"><p>A lot has changed between Cowboy 1.0 and 2.0. The <code>cowboy_req</code> -interface in particular has seen a massive revamp. Hooks are -gone, their functionality can now be achieved via stream -handlers.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="sect1"> +<p>A lot has changed between Cowboy 1.0 and 2.0. The <code>cowboy_req</code> interface in particular has seen a massive revamp. Hooks are gone, their functionality can now be achieved via stream handlers.</p> +<p>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.</p> <h2 id="_compatibility">Compatibility</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Compatibility with Erlang/OTP R16, 17 and 18 has been dropped. -Erlang/OTP 19.0 or above is required. It is non-trivial to -make Cowboy 2.0 work with older Erlang/OTP versions.</p></div> -<div class="paragraph"><p>Cowboy 2.0 is not compatible with Cowlib versions older than -2.0. It should be compatible with Ranch 1.0 or above, however -it has not been tested with Ranch versions older than 1.4.</p></div> -<div class="paragraph"><p>Cowboy 2.0 is tested on Arch Linux, Ubuntu, FreeBSD, Windows -and OSX. It is tested with every point release (latest patch -release) and also with HiPE on the most recent release.</p></div> -<div class="paragraph"><p>Cowboy 2.0 now comes with Erlang.mk templates.</p></div> -</div> -</div> -<div class="sect1"> +<p>Compatibility with Erlang/OTP R16, 17 and 18 has been dropped. Erlang/OTP 19.0 or above is required. It is non-trivial to make Cowboy 2.0 work with older Erlang/OTP versions.</p> +<p>Cowboy 2.0 is not compatible with Cowlib versions older than 2.0. It should be compatible with Ranch 1.0 or above, however it has not been tested with Ranch versions older than 1.4.</p> +<p>Cowboy 2.0 is tested on Arch Linux, Ubuntu, FreeBSD, Windows and OSX. It is tested with every point release (latest patch release) and also with HiPE on the most recent release.</p> +<p>Cowboy 2.0 now comes with Erlang.mk templates.</p> <h2 id="_features_added">Features added</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -The HTTP/2 protocol is now supported. -</p> -</li> -<li> -<p> -Cowboy no longer uses only one process per connection. - It now uses one process per connection plus one process - per request by default. This is necessary for HTTP/2. - There might be a slight drop in performance for HTTP/1.1 - connections due to this change. -</p> -</li> -<li> -<p> -Cowboy internals have largely been reworked in order to - support HTTP/2. This opened the way to stream handlers, - which are a chain of modules that are called whenever - something happens relating to a request/response. -</p> -</li> -<li> -<p> -The <code>cowboy_stream_h</code> stream handler has been added. - It provides most of Cowboy’s default behavior. -</p> -</li> -<li> -<p> -The <code>cowboy_compress_h</code> stream handler has been added. - It compresses responses when possible. It’s worth noting - that it compresses in more cases than Cowboy 1.0 ever did. -</p> -</li> -<li> -<p> -Because of the many changes in the internals of Cowboy, - many options have been added or modified. Of note is that - the Websocket options are now given per handler rather - than for the entire listener. -</p> -</li> -<li> -<p> -Websocket permessage-deflate compression is now supported - via the <code>compress</code> option. -</p> -</li> -<li> -<p> -Static file handlers will now correctly find files found - in <em>.ez</em> archives. -</p> -</li> -<li> -<p> -Constraints have been generalized and are now used not only - in the router but also in some <code>cowboy_req</code> functions. Their - interface has also been modified to allow for reverse - operations and formatting of errors. -</p> -</li> -</ul></div> -</div> -</div> -<div class="sect1"> +<ul><li>The HTTP/2 protocol is now supported. +</li> +<li>Cowboy no longer uses only one process per connection. It now uses one process per connection plus one process per request by default. This is necessary for HTTP/2. There might be a slight drop in performance for HTTP/1.1 connections due to this change. +</li> +<li>Cowboy internals have largely been reworked in order to support HTTP/2. This opened the way to stream handlers, which are a chain of modules that are called whenever something happens relating to a request/response. +</li> +<li>The <code>cowboy_stream_h</code> stream handler has been added. It provides most of Cowboy's default behavior. +</li> +<li>The <code>cowboy_compress_h</code> stream handler has been added. It compresses responses when possible. It's worth noting that it compresses in more cases than Cowboy 1.0 ever did. +</li> +<li>Because of the many changes in the internals of Cowboy, many options have been added or modified. Of note is that the Websocket options are now given per handler rather than for the entire listener. +</li> +<li>Websocket permessage-deflate compression is now supported via the <code>compress</code> option. +</li> +<li>Static file handlers will now correctly find files found in <em>.ez</em> archives. +</li> +<li>Constraints have been generalized and are now used not only in the router but also in some <code>cowboy_req</code> functions. Their interface has also been modified to allow for reverse operations and formatting of errors. +</li> +</ul> <h2 id="_features_removed">Features removed</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -SPDY support has been removed. Use HTTP/2 instead. -</p> -</li> -<li> -<p> -Hooks have been removed. Use <a href="../streams">stream handlers</a> instead. -</p> -</li> -<li> -<p> -The undocumented <code>waiting_stream</code> hack has been removed. - It allowed disabling chunked transfer-encoding for HTTP/1.1. - It has no equivalent in Cowboy 2.0. Open a ticket if necessary. -</p> -</li> -<li> -<p> -Sub protocols still exist, but their interface has largely changed - and they are no longer documented for the time being. -</p> -</li> -</ul></div> -</div> -</div> -<div class="sect1"> +<ul><li>SPDY support has been removed. Use HTTP/2 instead. +</li> +<li>Hooks have been removed. Use <a href="../streams">stream handlers</a> instead. +</li> +<li>The undocumented <code>waiting_stream</code> hack has been removed. It allowed disabling chunked transfer-encoding for HTTP/1.1. It has no equivalent in Cowboy 2.0. Open a ticket if necessary. +</li> +<li>Sub protocols still exist, but their interface has largely changed and they are no longer documented for the time being. +</li> +</ul> <h2 id="_changed_behaviors">Changed behaviors</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -The handler behaviors have been renamed and are now <code>cowboy_handler</code>, - <code>cowboy_loop</code>, <code>cowboy_rest</code> and <code>cowboy_websocket</code>. -</p> -</li> -<li> -<p> -Plain HTTP, loop, REST and Websocket handlers have had their - init and terminate callbacks unified. They now all use the - <code>init/2</code> and <code>terminate/3</code> callbacks. The latter is now optional. - The terminate reason has now been documented for all handlers. -</p> -</li> -<li> -<p> -The tuple returned to switch to a different handler type has - changed. It now takes the form <code>{Module, Req, State}</code> or - <code>{Module, Req, State, Opts}</code>, where <code>Opts</code> is a map of options - to configure the handler. The timeout and hibernate options - must now be specified using this map, where applicable. -</p> -</li> -<li> -<p> -All behaviors that used to accept <code>halt</code> or <code>shutdown</code> tuples - as a return value no longer do so. The return value is now - a <code>stop</code> tuple, consistent across Cowboy. -</p> -</li> -<li> -<p> -Middlewares can no longer return an <code>error</code> tuple. They have - to send the response and return a <code>stop</code> tuple instead. -</p> -</li> -<li> -<p> -The <code>known_content_type</code> REST handler callback has been removed - as it was found unnecessary. -</p> -</li> -<li> -<p> -Websocket handlers have both the normal <code>init/2</code> and - an optional <code>websocket_init/1</code> function. The reason for - that exception is that the <code>websocket_*</code> callbacks execute - in a separate process from the <code>init/2</code> callback, and it - was therefore not obvious how timers or monitors should - be setup properly. They are effectively initializing the - handler before and after the HTTP/1.1 upgrade. -</p> -</li> -<li> -<p> -Websocket handlers can now send frames directly from - <code>websocket_init/1</code>. The frames will be sent immediately - after the handshake. -</p> -</li> -<li> -<p> -Websocket handler callbacks no longer receive the Req - argument. The <code>init/2</code> callback still receives it and - can be used to extract relevant information. The <code>terminate/3</code> - callback, if implemented, may still receive the Req - (see next bullet point). -</p> -</li> -<li> -<p> -Websocket handlers have a new <code>req_filter</code> option that - can be used to customize how much information should be - discarded from the Req object after the handshake. Note - that the Req object is only available in <code>terminate/3</code> - past that point. -</p> -</li> -<li> -<p> -Websocket handlers have their timeout default changed - from infinity to 60 seconds. -</p> -</li> -</ul></div> -</div> -</div> -<div class="sect1"> +<ul><li>The handler behaviors have been renamed and are now <code>cowboy_handler</code>, <code>cowboy_loop</code>, <code>cowboy_rest</code> and <code>cowboy_websocket</code>. +</li> +<li>Plain HTTP, loop, REST and Websocket handlers have had their init and terminate callbacks unified. They now all use the <code>init/2</code> and <code>terminate/3</code> callbacks. The latter is now optional. The terminate reason has now been documented for all handlers. +</li> +<li>The tuple returned to switch to a different handler type has changed. It now takes the form <code>{Module, Req, State}</code> or <code>{Module, Req, State, Opts}</code>, where <code>Opts</code> is a map of options to configure the handler. The timeout and hibernate options must now be specified using this map, where applicable. +</li> +<li>All behaviors that used to accept <code>halt</code> or <code>shutdown</code> tuples as a return value no longer do so. The return value is now a <code>stop</code> tuple, consistent across Cowboy. +</li> +<li>Middlewares can no longer return an <code>error</code> tuple. They have to send the response and return a <code>stop</code> tuple instead. +</li> +<li>The <code>known_content_type</code> REST handler callback has been removed as it was found unnecessary. +</li> +<li>Websocket handlers have both the normal <code>init/2</code> and an optional <code>websocket_init/1</code> function. The reason for that exception is that the <code>websocket_*</code> callbacks execute in a separate process from the <code>init/2</code> callback, and it was therefore not obvious how timers or monitors should be setup properly. They are effectively initializing the handler before and after the HTTP/1.1 upgrade. +</li> +<li>Websocket handlers can now send frames directly from <code>websocket_init/1</code>. The frames will be sent immediately after the handshake. +</li> +<li>Websocket handler callbacks no longer receive the Req argument. The <code>init/2</code> callback still receives it and can be used to extract relevant information. The <code>terminate/3</code> callback, if implemented, may still receive the Req (see next bullet point). +</li> +<li>Websocket handlers have a new <code>req_filter</code> option that can be used to customize how much information should be discarded from the Req object after the handshake. Note that the Req object is only available in <code>terminate/3</code> past that point. +</li> +<li>Websocket handlers have their timeout default changed from infinity to 60 seconds. +</li> +</ul> <h2 id="_new_functions">New functions</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -The <code>cowboy_req:scheme/1</code> function has been added. -</p> -</li> -<li> -<p> -The <code>cowboy_req:uri/1,2</code> function has been added, replacing the - less powerful functions <code>cowboy_req:url/1</code> and <code>cowboy_req:host_url/1</code>. -</p> -</li> -<li> -<p> -The functions <code>cowboy_req:match_qs/2</code> and <code>cowboy_req:match_cookies/2</code> - allow matching query string and cookies against constraints. -</p> -</li> -<li> -<p> -The function <code>cowboy_req:set_resp_cookie/3</code> has been added to - complement <code>cowboy_req:set_resp_cookie/4</code>. -</p> -</li> -<li> -<p> -The functions <code>cowboy_req:resp_header/2,3</code> and <code>cowboy_req:resp_headers/1</code> - have been added. They can be used to retrieve response headers - that were previously set. -</p> -</li> -<li> -<p> -The function <code>cowboy_req:set_resp_headers/2</code> has been added. It - allows setting many response headers at once. -</p> -</li> -<li> -<p> -The functions <code>cowboy_req:push/3,4</code> can be used to push resources - for protocols that support it (by default only HTTP/2). -</p> -</li> -</ul></div> -</div> -</div> -<div class="sect1"> +<ul><li>The <code>cowboy_req:scheme/1</code> function has been added. +</li> +<li>The <code>cowboy_req:uri/1,2</code> function has been added, replacing the less powerful functions <code>cowboy_req:url/1</code> and <code>cowboy_req:host_url/1</code>. +</li> +<li>The functions <code>cowboy_req:match_qs/2</code> and <code>cowboy_req:match_cookies/2</code> allow matching query string and cookies against constraints. +</li> +<li>The function <code>cowboy_req:set_resp_cookie/3</code> has been added to complement <code>cowboy_req:set_resp_cookie/4</code>. +</li> +<li>The functions <code>cowboy_req:resp_header/2,3</code> and <code>cowboy_req:resp_headers/1</code> have been added. They can be used to retrieve response headers that were previously set. +</li> +<li>The function <code>cowboy_req:set_resp_headers/2</code> has been added. It allows setting many response headers at once. +</li> +<li>The functions <code>cowboy_req:push/3,4</code> can be used to push resources for protocols that support it (by default only HTTP/2). +</li> +</ul> <h2 id="_changed_functions">Changed functions</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -The <code>cowboy:start_http/4</code> function was renamed to <code>cowboy:start_clear/3</code>. -</p> -</li> -<li> -<p> -The <code>cowboy:start_https/4</code> function was renamed to <code>cowboy:start_tls/3</code>. -</p> -</li> -<li> -<p> -Most, if not all, functions in the <code>cowboy_req</code> module have been modified. - Please consult the changelog of each individual functions. The changes - are mainly about simplifying and clarifying the interface. The Req is no - longer returned when not necessary, maps are used wherever possible, - and some functions have been renamed. -</p> -</li> -<li> -<p> -The position of the <code>Opts</code> argument for <code>cowboy_req:set_resp_cookie/4</code> - has changed to improve consistency. It is now the last argument. -</p> -</li> -</ul></div> -</div> -</div> -<div class="sect1"> +<ul><li>The <code>cowboy:start_http/4</code> function was renamed to <code>cowboy:start_clear/3</code>. +</li> +<li>The <code>cowboy:start_https/4</code> function was renamed to <code>cowboy:start_tls/3</code>. +</li> +<li>Most, if not all, functions in the <code>cowboy_req</code> module have been modified. Please consult the changelog of each individual functions. The changes are mainly about simplifying and clarifying the interface. The Req is no longer returned when not necessary, maps are used wherever possible, and some functions have been renamed. +</li> +<li>The position of the <code>Opts</code> argument for <code>cowboy_req:set_resp_cookie/4</code> has changed to improve consistency. It is now the last argument. +</li> +</ul> <h2 id="_removed_functions">Removed functions</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -The functions <code>cowboy_req:url/1</code> and <code>cowboy_req:host_url/1</code> have been - removed in favor of the new function <code>cowboy_req:uri/1,2</code>. -</p> -</li> -<li> -<p> -The functions <code>cowboy_req:meta/2,3</code> and <code>cowboy_req:set_meta/3</code> have - been removed. The Req object is now a public map, therefore they became - unnecessary. -</p> -</li> -<li> -<p> -The functions <code>cowboy_req:set_resp_body_fun/2,3</code> have been removed. - For sending files, the function <code>cowboy_req:set_resp_body/2</code> can now - take a sendfile tuple. -</p> -</li> -<li> -<p> -Remove many undocumented functions from <code>cowboy_req</code>, including the - functions <code>cowboy_req:get/2</code> and <code>cowboy_req:set/3</code>. -</p> -</li> -</ul></div> -</div> -</div> -<div class="sect1"> +<ul><li>The functions <code>cowboy_req:url/1</code> and <code>cowboy_req:host_url/1</code> have been removed in favor of the new function <code>cowboy_req:uri/1,2</code>. +</li> +<li>The functions <code>cowboy_req:meta/2,3</code> and <code>cowboy_req:set_meta/3</code> have been removed. The Req object is now a public map, therefore they became unnecessary. +</li> +<li>The functions <code>cowboy_req:set_resp_body_fun/2,3</code> have been removed. For sending files, the function <code>cowboy_req:set_resp_body/2</code> can now take a sendfile tuple. +</li> +<li>Remove many undocumented functions from <code>cowboy_req</code>, including the functions <code>cowboy_req:get/2</code> and <code>cowboy_req:set/3</code>. +</li> +</ul> <h2 id="_other_changes">Other changes</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -The correct percent-decoding algorithm is now used for path elements - during routing. It will no longer decode <code>+</code> characters. -</p> -</li> -<li> -<p> -The router will now properly handle path segments <code>.</code> and <code>..</code>. -</p> -</li> -<li> -<p> -Routing behavior has changed for URIs containing latin1 characters. - They are no longer allowed. URIs are expected to be in UTF-8 once - they are percent-decoded. -</p> -</li> -<li> -<p> -Clients that send multiple headers of the same name - will have the values of those headers concatenated into a - comma-separated list. This is of special importance in the - case of the content-type header, as previously only the - first value was used in the <code>content_types_accepted/2</code> step - in REST handlers. -</p> -</li> -<li> -<p> -Etag comparison in REST handlers has been fixed. Some requests may - now fail when they succeeded in the past. -</p> -</li> -<li> -<p> -The <code>If-*-Since</code> headers are now ignored in REST handlers if - the corresponding <code>If*-Match</code> header exist. The former is - largely a backward compatible header and this shouldn’t create - any issue. The new behavior follows the current RFCs more closely. -</p> -</li> -<li> -<p> -The static file handler has been improved to handle more special - characters on systems that accept them. -</p> -</li> -</ul></div> -</div> -</div> +<ul><li>The correct percent-decoding algorithm is now used for path elements during routing. It will no longer decode <code>+</code> characters. +</li> +<li>The router will now properly handle path segments <code>.</code> and <code>..</code>. +</li> +<li>Routing behavior has changed for URIs containing latin1 characters. They are no longer allowed. URIs are expected to be in UTF-8 once they are percent-decoded. +</li> +<li>Clients that send multiple headers of the same name will have the values of those headers concatenated into a comma-separated list. This is of special importance in the case of the content-type header, as previously only the first value was used in the <code>content_types_accepted/2</code> step in REST handlers. +</li> +<li>Etag comparison in REST handlers has been fixed. Some requests may now fail when they succeeded in the past. +</li> +<li>The <code>If-*-Since</code> headers are now ignored in REST handlers if the corresponding <code>If*-Match</code> header exist. The former is largely a backward compatible header and this shouldn't create any issue. The new behavior follows the current RFCs more closely. +</li> +<li>The static file handler has been improved to handle more special characters on systems that accept them. +</li> +</ul> + diff --git a/docs/en/cowboy/2.3/guide/migrating_from_2.0/index.html b/docs/en/cowboy/2.3/guide/migrating_from_2.0/index.html index d547b8c6..fa7978d1 100644 --- a/docs/en/cowboy/2.3/guide/migrating_from_2.0/index.html +++ b/docs/en/cowboy/2.3/guide/migrating_from_2.0/index.html @@ -62,188 +62,55 @@ <h1 class="lined-header"><span>Migrating from Cowboy 2.0 to 2.1</span></h1> -<div class="paragraph"><p>Cowboy 2.1 focused on adding features that were temporarily -removed in Cowboy 2.0. A number of bugs found in the 2.0 -release were also fixed.</p></div> -<div class="sect1"> +<p>Cowboy 2.1 focused on adding features that were temporarily removed in Cowboy 2.0. A number of bugs found in the 2.0 release were also fixed.</p> <h2 id="_features_added">Features added</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -It is now possible to obtain the client TLS certificate - and the local IP/port for the connection from the Req object. -</p> +<ul><li>It is now possible to obtain the client TLS certificate and the local IP/port for the connection from the Req object. </li> -<li> -<p> -Informational responses (1XX responses) can now be sent. - They must be sent before initiating the final response. -</p> +<li>Informational responses (1XX responses) can now be sent. They must be sent before initiating the final response. </li> -<li> -<p> -The <code>expect: 100-continue</code> header is now handled - automatically. The 100 response will be sent on the - first <code>cowboy_req:read_body/2,3,4</code> call. This only applies - when using the default <code>cowboy_stream_h</code> stream handler. -</p> +<li>The <code>expect: 100-continue</code> header is now handled automatically. The 100 response will be sent on the first <code>cowboy_req:read_body/2,3,4</code> call. This only applies when using the default <code>cowboy_stream_h</code> stream handler. </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_experimental_features_added">Experimental features added</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Experimental features are previews of features that will be -added in a future release. They are not documented and their -interface may change at any time. You are welcome to try them -and provide feedback.</p></div> -<div class="ulist"><ul> -<li> -<p> -The <code>cowboy_metrics_h</code> stream handler can be used to - extract metrics out of Cowboy. It must be used first in - the list of stream handlers, and will record all events - related to requests, responses and spawned processes. - When the stream terminates it will pass this information - to a user-defined callback. -</p> +<p>Experimental features are previews of features that will be added in a future release. They are not documented and their interface may change at any time. You are welcome to try them and provide feedback.</p> +<ul><li>The <code>cowboy_metrics_h</code> stream handler can be used to extract metrics out of Cowboy. It must be used first in the list of stream handlers, and will record all events related to requests, responses and spawned processes. When the stream terminates it will pass this information to a user-defined callback. </li> -<li> -<p> -The <code>cowboy_tracer_h</code> stream handler can be used to setup - automatic tracing of specific requests. You can conditionally - enable tracing based on a function, header, path or any other - element from the request and the trace will apply to the - entire connection and any processes created by it. This is - meant to be used for debugging both in tests and production. -</p> +<li>The <code>cowboy_tracer_h</code> stream handler can be used to setup automatic tracing of specific requests. You can conditionally enable tracing based on a function, header, path or any other element from the request and the trace will apply to the entire connection and any processes created by it. This is meant to be used for debugging both in tests and production. </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_changed_behaviors">Changed behaviors</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -The <code>cowboy_rest</code> handler now implements a mechanism for - switching to a different type of handler from any callback - where <code>stop</code> is also allowed. Switch by returning - <code>{switch_handler, Module}</code> or <code>{switch_handler, Module, Opts}</code>. - This is especially useful for switching to <code>cowboy_loop</code> - for streaming the request or response body. -</p> +<ul><li>The <code>cowboy_rest</code> handler now implements a mechanism for switching to a different type of handler from any callback where <code>stop</code> is also allowed. Switch by returning <code>{switch_handler, Module}</code> or <code>{switch_handler, Module, Opts}</code>. This is especially useful for switching to <code>cowboy_loop</code> for streaming the request or response body. </li> -<li> -<p> -REST callbacks that do not allow <code>stop</code> as a return value - are now explicitly listed in the documentation. -</p> +<li>REST callbacks that do not allow <code>stop</code> as a return value are now explicitly listed in the documentation. </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_new_functions">New functions</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -The function <code>cowboy_req:sock/1</code> returns the IP/port - of the local socket. -</p> +<ul><li>The function <code>cowboy_req:sock/1</code> returns the IP/port of the local socket. </li> -<li> -<p> -The function <code>cowboy_req:cert/1</code> returns the client - TLS certificate or <code>undefined</code> if it isn’t available. -</p> +<li>The function <code>cowboy_req:cert/1</code> returns the client TLS certificate or <code>undefined</code> if it isn't available. </li> -<li> -<p> -The function <code>cowboy_req:inform/2,3</code> sends an - informational response. -</p> +<li>The function <code>cowboy_req:inform/2,3</code> sends an informational response. </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_bugs_fixed">Bugs fixed</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -Ensure HTTP/2 connections are not closed prematurely - when the user code does not read the request body. -</p> +<ul><li>Ensure HTTP/2 connections are not closed prematurely when the user code does not read the request body. </li> -<li> -<p> -Ensure HTTP/1.1 streams are not terminated too early. - Their behavior is now consistent with the HTTP/2 code - where the stream handler is only terminated when the - <code>stop</code> command is returned. -</p> +<li>Ensure HTTP/1.1 streams are not terminated too early. Their behavior is now consistent with the HTTP/2 code where the stream handler is only terminated when the <code>stop</code> command is returned. </li> -<li> -<p> -Sending zero-sized data from stream handlers or from - <code>cowboy_req:stream_body/3</code> could lead to issues with - HTTP/1.1. This has been fixed. -</p> +<li>Sending zero-sized data from stream handlers or from <code>cowboy_req:stream_body/3</code> could lead to issues with HTTP/1.1. This has been fixed. </li> -<li> -<p> -The final chunk sent by Cowboy when it terminates a - chunked body after the handler process exits was not - passed through stream handlers, which could lead to - issues when <code>cowboy_compress_h</code> was being used. This - is now corrected. -</p> +<li>The final chunk sent by Cowboy when it terminates a chunked body after the handler process exits was not passed through stream handlers, which could lead to issues when <code>cowboy_compress_h</code> was being used. This is now corrected. </li> -<li> -<p> -The stream handler state was discarded in some cases - where Cowboy had to send a response or response data - automatically when ending a stream. This has now - been corrected. -</p> +<li>The stream handler state was discarded in some cases where Cowboy had to send a response or response data automatically when ending a stream. This has now been corrected. </li> -<li> -<p> -The stream handler callback <code>terminate/3</code> will now be - called when switching to another protocol using the - command <code>switch_protocol</code>. This doesn’t apply when - doing upgrades to HTTP/2 as those occur before the - stream is initialized. -</p> +<li>The stream handler callback <code>terminate/3</code> will now be called when switching to another protocol using the command <code>switch_protocol</code>. This doesn't apply when doing upgrades to HTTP/2 as those occur before the stream is initialized. </li> -<li> -<p> -Cowlib has been updated to 2.0.1 to fix an issue with - Websocket compression when using Erlang/OTP 20.1. Note - that at the time of writing all 20.1 versions (from - 20.1 to 20.1.4) have issues when compression is enabled. - It is expected to work properly from 20.1.5 onward. In - the meantime it is recommended to run the plain 20.1 - release and disable Websocket compression, or use a - release before 20.1. -</p> +<li>Cowlib has been updated to 2.0.1 to fix an issue with Websocket compression when using Erlang/OTP 20.1. Note that at the time of writing all 20.1 versions (from 20.1 to 20.1.4) have issues when compression is enabled. It is expected to work properly from 20.1.5 onward. In the meantime it is recommended to run the plain 20.1 release and disable Websocket compression, or use a release before 20.1. </li> -<li> -<p> -Cowboy will no longer crash when the <code>cowboy_clock</code> - process is not running. This can happen when Cowboy - is being restarted during upgrades, for example. -</p> +<li>Cowboy will no longer crash when the <code>cowboy_clock</code> process is not running. This can happen when Cowboy is being restarted during upgrades, for example. </li> -</ul></div> -</div> -</div> +</ul> + diff --git a/docs/en/cowboy/2.3/guide/migrating_from_2.1/index.html b/docs/en/cowboy/2.3/guide/migrating_from_2.1/index.html index 6d6fed21..364c295f 100644 --- a/docs/en/cowboy/2.3/guide/migrating_from_2.1/index.html +++ b/docs/en/cowboy/2.3/guide/migrating_from_2.1/index.html @@ -62,203 +62,66 @@ <h1 class="lined-header"><span>Migrating from Cowboy 2.1 to 2.2</span></h1> -<div class="paragraph"><p>Cowboy 2.2 focused on adding features required for writing -gRPC servers and on completing test suites for the core -HTTP RFCs, fixing many bugs along the way.</p></div> -<div class="sect1"> +<p>Cowboy 2.2 focused on adding features required for writing gRPC servers and on completing test suites for the core HTTP RFCs, fixing many bugs along the way.</p> <h2 id="_features_added">Features added</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -Add support for sending trailers at the end of response bodies. - Trailers are additional header fields that may be sent after the - body to add more information to the response. Their usage is - required in gRPC servers. They are optional and may be discarded - in other scenarios (for example if the request goes through an - HTTP/1.0 proxy, as HTTP/1.0 does not support trailers). -</p> +<ul><li>Add support for sending trailers at the end of response bodies. Trailers are additional header fields that may be sent after the body to add more information to the response. Their usage is required in gRPC servers. They are optional and may be discarded in other scenarios (for example if the request goes through an HTTP/1.0 proxy, as HTTP/1.0 does not support trailers). </li> -<li> -<p> -The <code>max_skip_body_length</code> option was added to <code>cowboy_http</code>. - It controls how much of a request body Cowboy is willing to skip - when the handler did not touch it. If the remaining body size is - too large Cowboy instead closes the connection. It defaults to 1MB. -</p> +<li>The <code>max_skip_body_length</code> option was added to <code>cowboy_http</code>. It controls how much of a request body Cowboy is willing to skip when the handler did not touch it. If the remaining body size is too large Cowboy instead closes the connection. It defaults to 1MB. </li> -<li> -<p> -The CONNECT and TRACE methods are now rejected as they are - currently not implemented and must be handled differently than - other methods. They will be implemented in a future release. -</p> +<li>The CONNECT and TRACE methods are now rejected as they are currently not implemented and must be handled differently than other methods. They will be implemented in a future release. </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_new_functions">New functions</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -The function <code>stream_trailers/2</code> has been added. It terminates - a stream and adds trailer fields at the end of the response. A - corresponding stream handler command <code>{trailers, Trailers}</code> - has also been added. -</p> +<ul><li>The function <code>stream_trailers/2</code> has been added. It terminates a stream and adds trailer fields at the end of the response. A corresponding stream handler command <code>{trailers, Trailers}</code> has also been added. </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_bugs_fixed">Bugs fixed</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -Test suites for the core HTTP RFCs RFC7230, RFC7231 and RFC7540 - have been completed. Many of the bugs listed here were fixed as - a result of this work. -</p> +<ul><li>Test suites for the core HTTP RFCs RFC7230, RFC7231 and RFC7540 have been completed. Many of the bugs listed here were fixed as a result of this work. </li> -<li> -<p> -Many HTTP/2 edge cases when clients are misbehaving have been - corrected. This includes many cases where the request is malformed - (for example when a pseudo-header is present twice). -</p> +<li>Many HTTP/2 edge cases when clients are misbehaving have been corrected. This includes many cases where the request is malformed (for example when a pseudo-header is present twice). </li> -<li> -<p> -When the HTTP/2 SETTINGS_INITIAL_WINDOW_SIZE value changes, - Cowboy now properly updates the flow control windows. -</p> +<li>When the HTTP/2 SETTINGS_INITIAL_WINDOW_SIZE value changes, Cowboy now properly updates the flow control windows. </li> -<li> -<p> -HTTP/2 could mistakenly log stray messages that actually were - expected. This is no longer the case. -</p> +<li>HTTP/2 could mistakenly log stray messages that actually were expected. This is no longer the case. </li> -<li> -<p> -We no longer send a GOAWAY frame when the HTTP/2 preface is invalid. -</p> +<li>We no longer send a GOAWAY frame when the HTTP/2 preface is invalid. </li> -<li> -<p> -Some values in the Req object of pushed requests were in the - wrong type. They are now the expected binary instead of iolist. -</p> +<li>Some values in the Req object of pushed requests were in the wrong type. They are now the expected binary instead of iolist. </li> -<li> -<p> -A response body was sometimes sent in response to HEAD requests - when using HTTP/2. The body is now ignored. -</p> +<li>A response body was sometimes sent in response to HEAD requests when using HTTP/2. The body is now ignored. </li> -<li> -<p> -The <code>max_headers</code> option for <code>cowboy_http</code> was not always respected - depending on the contents of the buffer. The limit is now strict. -</p> +<li>The <code>max_headers</code> option for <code>cowboy_http</code> was not always respected depending on the contents of the buffer. The limit is now strict. </li> -<li> -<p> -When an early error occurred on the HTTP/1.1 request line, the - partial Req given to stream handlers was missing the <code>ref</code> and - <code>peer</code> information. This has been corrected. -</p> +<li>When an early error occurred on the HTTP/1.1 request line, the partial Req given to stream handlers was missing the <code>ref</code> and <code>peer</code> information. This has been corrected. </li> -<li> -<p> -Absolute URIs with a userinfo component, or without an authority - component, are now properly rejected for HTTP/1.0 and HTTP/1.1. -</p> +<li>Absolute URIs with a userinfo component, or without an authority component, are now properly rejected for HTTP/1.0 and HTTP/1.1. </li> -<li> -<p> -Whitespace is no longer allowed in header lines before the colon. -</p> +<li>Whitespace is no longer allowed in header lines before the colon. </li> -<li> -<p> -408 responses to HTTP/1.1 requests now properly include a - connection: close header indicating that we are going to - close the connection. This header will also be sent for - other early errors resulting in the closing of the connection. -</p> +<li>408 responses to HTTP/1.1 requests now properly include a connection: close header indicating that we are going to close the connection. This header will also be sent for other early errors resulting in the closing of the connection. </li> -<li> -<p> -When both the transfer-encoding and content-length headers are - sent in an HTTP/1.1 request, the transfer-encoding now takes - precedence over the content-length header and the latter is - removed from the Req object. -</p> +<li>When both the transfer-encoding and content-length headers are sent in an HTTP/1.1 request, the transfer-encoding now takes precedence over the content-length header and the latter is removed from the Req object. </li> -<li> -<p> -A 400 response is now returned when the transfer-encoding - header is invalid or contains any transfer-coding other - than chunked. -</p> +<li>A 400 response is now returned when the transfer-encoding header is invalid or contains any transfer-coding other than chunked. </li> -<li> -<p> -Invalid chunk sizes are now rejected immediately. -</p> +<li>Invalid chunk sizes are now rejected immediately. </li> -<li> -<p> -Chunk extensions are now limited to 129 characters. They are - not used in practice and are still ignored by Cowboy. The limit - is not configurable. -</p> +<li>Chunk extensions are now limited to 129 characters. They are not used in practice and are still ignored by Cowboy. The limit is not configurable. </li> -<li> -<p> -The final chunk was mistakenly sent in responses to HEAD - requests. This is now corrected. -</p> +<li>The final chunk was mistakenly sent in responses to HEAD requests. This is now corrected. </li> -<li> -<p> -<code>OPTIONS *</code> requests were broken in Cowboy 2.0. They are now - working again. Both the routing and <code>cowboy_req:uri/1,2</code> have - been corrected. -</p> +<li><code>OPTIONS *</code> requests were broken in Cowboy 2.0. They are now working again. Both the routing and <code>cowboy_req:uri/1,2</code> have been corrected. </li> -<li> -<p> -204 responses no longer include a content-length header. -</p> +<li>204 responses no longer include a content-length header. </li> -<li> -<p> -A packet could be lost when switching to Websocket or any - other protocol via the <code>switch_protocol</code> command. This is - now fixed. -</p> +<li>A packet could be lost when switching to Websocket or any other protocol via the <code>switch_protocol</code> command. This is now fixed. </li> -<li> -<p> -A 426 response will now be sent when a handler requires - the client to upgrade to Websocket and the request did not - include the required headers. -</p> +<li>A 426 response will now be sent when a handler requires the client to upgrade to Websocket and the request did not include the required headers. </li> -<li> -<p> -Both experimental stream handlers <code>cowboy_metrics_h</code> and - <code>cowboy_tracer_h</code> received a number of fixes and improvements. -</p> +<li>Both experimental stream handlers <code>cowboy_metrics_h</code> and <code>cowboy_tracer_h</code> received a number of fixes and improvements. </li> -</ul></div> -</div> -</div> +</ul> + diff --git a/docs/en/cowboy/2.3/guide/migrating_from_2.2/index.html b/docs/en/cowboy/2.3/guide/migrating_from_2.2/index.html index ced40d21..95aea629 100644 --- a/docs/en/cowboy/2.3/guide/migrating_from_2.2/index.html +++ b/docs/en/cowboy/2.3/guide/migrating_from_2.2/index.html @@ -62,108 +62,38 @@ <h1 class="lined-header"><span>Migrating from Cowboy 2.2 to 2.3</span></h1> -<div class="paragraph"><p>Cowboy 2.3 focused on making the Cowboy processes behave -properly according to OTP principles. This version is a -very good milestone toward that goal and most of everything -should now work. Release upgrades and a few details will -be improved in future versions.</p></div> -<div class="sect1"> +<p>Cowboy 2.3 focused on making the Cowboy processes behave properly according to OTP principles. This version is a very good milestone toward that goal and most of everything should now work. Release upgrades and a few details will be improved in future versions.</p> <h2 id="_features_added">Features added</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -Add support for all functions from the module <code>sys</code>. Note - that Cowboy currently does not implement the <code>sys</code> debugging - mechanisms as tracing is recommended instead. -</p> +<ul><li>Add support for all functions from the module <code>sys</code>. Note that Cowboy currently does not implement the <code>sys</code> debugging mechanisms as tracing is recommended instead. </li> -<li> -<p> -Add a <code>max_frame_size</code> option for Websocket handlers - to close the connection when the client attempts to - send a frame that’s too large. It currently defaults - to <code>infinity</code> to avoid breaking existing code but will - be changed in a future version. -</p> +<li>Add a <code>max_frame_size</code> option for Websocket handlers to close the connection when the client attempts to send a frame that's too large. It currently defaults to <code>infinity</code> to avoid breaking existing code but will be changed in a future version. </li> -<li> -<p> -Update Cowlib to 2.2.1. -</p> +<li>Update Cowlib to 2.2.1. </li> -<li> -<p> -Add support for the 308 status code and a test suite - for RFC7538 where it is defined. -</p> +<li>Add support for the 308 status code and a test suite for RFC7538 where it is defined. </li> -</ul></div> -</div> -</div> -<div class="sect1"> +</ul> <h2 id="_bugs_fixed">Bugs fixed</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -Ensure timeout options accept the value <code>infinity</code> as - documented. -</p> +<ul><li>Ensure timeout options accept the value <code>infinity</code> as documented. </li> -<li> -<p> -Properly reject HTTP/2 requests with an invalid content-length - header instead of simply crashing. -</p> +<li>Properly reject HTTP/2 requests with an invalid content-length header instead of simply crashing. </li> -<li> -<p> -When switching from HTTP/1.1 to Websocket or user protocols - all the messages in the mailbox were flushed. Only messages - specific to <code>cowboy_http</code> should now be flushed. -</p> +<li>When switching from HTTP/1.1 to Websocket or user protocols all the messages in the mailbox were flushed. Only messages specific to <code>cowboy_http</code> should now be flushed. </li> -<li> -<p> -Parsing of the x-forwarded-for header has been corrected. - It now supports IPv6 addresses both with and without port. -</p> +<li>Parsing of the x-forwarded-for header has been corrected. It now supports IPv6 addresses both with and without port. </li> -<li> -<p> -Websocket subprotocol tokens are now parsed in a case - insensitive manner, according to the spec. -</p> +<li>Websocket subprotocol tokens are now parsed in a case insensitive manner, according to the spec. </li> -<li> -<p> -Cookies without values are now allowed. For example <code>Cookie: foo</code>. -</p> +<li>Cookies without values are now allowed. For example <code>Cookie: foo</code>. </li> -<li> -<p> -Colons are now allowed within path segments in routes provided - to <code>cowboy_router:compile/1</code> as long as they are not the first - character of the path segment. -</p> +<li>Colons are now allowed within path segments in routes provided to <code>cowboy_router:compile/1</code> as long as they are not the first character of the path segment. </li> -<li> -<p> -The <code>cowboy_req:delete_resp_header/2</code> function will no longer - crash when no response header was set before calling it. -</p> +<li>The <code>cowboy_req:delete_resp_header/2</code> function will no longer crash when no response header was set before calling it. </li> -<li> -<p> -A miscount of the output HTTP/2 flow control window has been - fixed. It prevented sending the response body fully to some - clients. The issue only affected response bodies sent as iolists. -</p> +<li>A miscount of the output HTTP/2 flow control window has been fixed. It prevented sending the response body fully to some clients. The issue only affected response bodies sent as iolists. </li> -</ul></div> -</div> -</div> +</ul> + diff --git a/docs/en/cowboy/2.3/guide/modern_web/index.html b/docs/en/cowboy/2.3/guide/modern_web/index.html index 4b1a8406..2f9cc837 100644 --- a/docs/en/cowboy/2.3/guide/modern_web/index.html +++ b/docs/en/cowboy/2.3/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’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'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> + diff --git a/docs/en/cowboy/2.3/guide/multipart/index.html b/docs/en/cowboy/2.3/guide/multipart/index.html index 17224160..2f5559f5 100644 --- a/docs/en/cowboy/2.3/guide/multipart/index.html +++ b/docs/en/cowboy/2.3/guide/multipart/index.html @@ -62,169 +62,107 @@ <h1 class="lined-header"><span>Multipart requests</span></h1> -<div class="paragraph"><p>Multipart originates from MIME, an Internet standard that -extends the format of emails.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>In the context of HTTP, multipart is most often used -with the <code>multipart/form-data</code> media type. It is what -browsers use to upload files through HTML forms.</p></div> -<div class="paragraph"><p>The <code>multipart/byteranges</code> is also common. It is the -media type used to send arbitrary bytes from a resource, -enabling clients to resume downloads.</p></div> -<div class="sect1"> +<p>Multipart originates from MIME, an Internet standard that extends the format of emails.</p> +<p>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.</p> +<p>In the context of HTTP, multipart is most often used with the <code>multipart/form-data</code> media type. It is what browsers use to upload files through HTML forms.</p> +<p>The <code>multipart/byteranges</code> is also common. It is the media type used to send arbitrary bytes from a resource, enabling clients to resume downloads.</p> <h2 id="_form_data">Form-data</h2> -<div class="sectionbody"> -<div class="paragraph"><p>In the normal case, when a form is submitted, the -browser will use the <code>application/x-www-form-urlencoded</code> -content-type. This type is just a list of keys and -values and is therefore not fit for uploading files.</p></div> -<div class="paragraph"><p>That’s where the <code>multipart/form-data</code> content-type -comes in. When the form is configured to use this -content-type, the browser will create a multipart -message where each part corresponds to a field on -the form. For files, it also adds some metadata in -the part headers, like the file name.</p></div> -<div class="paragraph"><p>A form with a text input, a file input and a select -choice box will result in a multipart message with -three parts, one for each field.</p></div> -<div class="paragraph"><p>The browser does its best to determine the media type -of the files it sends this way, but you should not -rely on it for determining the contents of the file. -Proper investigation of the contents is recommended.</p></div> -</div> -</div> -<div class="sect1"> +<p>In the normal case, when a form is submitted, the browser will use the <code>application/x-www-form-urlencoded</code> content-type. This type is just a list of keys and values and is therefore not fit for uploading files.</p> +<p>That's where the <code>multipart/form-data</code> content-type comes in. When the form is configured to use this content-type, the browser will create a multipart message where each part corresponds to a field on the form. For files, it also adds some metadata in the part headers, like the file name.</p> +<p>A form with a text input, a file input and a select choice box will result in a multipart message with three parts, one for each field.</p> +<p>The browser does its best to determine the media type of the files it sends this way, but you should not rely on it for determining the contents of the file. Proper investigation of the contents is recommended.</p> <h2 id="_checking_for_multipart_messages">Checking for multipart messages</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The content-type header indicates the presence of -a multipart message:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The content-type header indicates the presence of a multipart message:</p> +<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>{<span style="color: #990000"><<</span><span style="color: #FF0000">"multipart"</span><span style="color: #990000">>></span>, <span style="color: #990000"><<</span><span style="color: #FF0000">"form-data"</span><span style="color: #990000">>></span>, <span style="color: #990000">_</span>} - <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:parse_header</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt>{<font color="#990000"><<</font><font color="#FF0000">"multipart"</font><font color="#990000">>></font>, <font color="#990000"><<</font><font color="#FF0000">"form-data"</font><font color="#990000">>></font>, <font color="#990000">_</font>} + <font color="#990000">=</font> <b><font color="#000000">cowboy_req:parse_header</font></b>(<font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font>, <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_reading_a_multipart_message">Reading a multipart message</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy provides two sets of functions for reading -request bodies as multipart messages.</p></div> -<div class="paragraph"><p>The <code>cowboy_req:read_part/1,2</code> functions return the -next part’s headers, if any.</p></div> -<div class="paragraph"><p>The <code>cowboy_req:read_part_body/1,2</code> functions return -the current part’s body. For large bodies you may -need to call the function multiple times.</p></div> -<div class="paragraph"><p>To read a multipart message you need to iterate over -all its parts:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy provides two sets of functions for reading request bodies as multipart messages.</p> +<p>The <code>cowboy_req:read_part/1,2</code> functions return the next part's headers, if any.</p> +<p>The <code>cowboy_req:read_part_body/1,2</code> functions return the current part's body. For large bodies you may need to call the function multiple times.</p> +<p>To read a multipart message you need to iterate over all its parts:</p> +<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><span style="font-weight: bold"><span style="color: #000000">multipart</span></span>(<span style="color: #009900">Req0</span>) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #0000FF">case</span></span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_part</span></span>(<span style="color: #009900">Req0</span>) <span style="font-weight: bold"><span style="color: #0000FF">of</span></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">_Headers</span>, <span style="color: #009900">Req1</span>} <span style="color: #990000">-></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">_Body</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_part_body</span></span>(<span style="color: #009900">Req1</span>), - <span style="font-weight: bold"><span style="color: #000000">multipart</span></span>(<span style="color: #009900">Req</span>); - {<span style="color: #FF6600">done</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">-></span> - <span style="color: #009900">Req</span> - <span style="font-weight: bold"><span style="color: #0000FF">end</span></span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>When part bodies are too large, Cowboy will return -a <code>more</code> tuple, and allow you to loop until the part -body has been fully read.</p></div> -<div class="paragraph"><p>The function <code>cow_multipart:form_data/1</code> can be used -to quickly obtain information about a part from a -<code>multipart/form-data</code> message. The function returns -a <code>data</code> or a <code>file</code> tuple depending on whether this -is a normal field or a file being uploaded.</p></div> -<div class="paragraph"><p>The following snippet will use this function and -use different strategies depending on whether the -part is a file:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">multipart</font></b>(<font color="#009900">Req0</font>) <font color="#990000">-></font> + <b><font color="#0000FF">case</font></b> <b><font color="#000000">cowboy_req:read_part</font></b>(<font color="#009900">Req0</font>) <b><font color="#0000FF">of</font></b> + {<font color="#FF6600">ok</font>, <font color="#009900">_Headers</font>, <font color="#009900">Req1</font>} <font color="#990000">-></font> + {<font color="#FF6600">ok</font>, <font color="#009900">_Body</font>, <font color="#009900">Req</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:read_part_body</font></b>(<font color="#009900">Req1</font>), + <b><font color="#000000">multipart</font></b>(<font color="#009900">Req</font>); + {<font color="#FF6600">done</font>, <font color="#009900">Req</font>} <font color="#990000">-></font> + <font color="#009900">Req</font> + <b><font color="#0000FF">end</font></b><font color="#990000">.</font></tt></pre> +</div></div> +<p>When part bodies are too large, Cowboy will return a <code>more</code> tuple, and allow you to loop until the part body has been fully read.</p> +<p>The function <code>cow_multipart:form_data/1</code> can be used to quickly obtain information about a part from a <code>multipart/form-data</code> message. The function returns a <code>data</code> or a <code>file</code> tuple depending on whether this is a normal field or a file being uploaded.</p> +<p>The following snippet will use this function and use different strategies depending on whether the part is a file:</p> +<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><span style="font-weight: bold"><span style="color: #000000">multipart</span></span>(<span style="color: #009900">Req0</span>) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #0000FF">case</span></span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_part</span></span>(<span style="color: #009900">Req0</span>) <span style="font-weight: bold"><span style="color: #0000FF">of</span></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">Headers</span>, <span style="color: #009900">Req1</span>} <span style="color: #990000">-></span> - <span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #0000FF">case</span></span> <span style="font-weight: bold"><span style="color: #000000">cow_multipart:form_data</span></span>(<span style="color: #009900">Headers</span>) <span style="font-weight: bold"><span style="color: #0000FF">of</span></span> - {<span style="color: #FF6600">data</span>, <span style="color: #009900">_FieldName</span>} <span style="color: #990000">-></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">_Body</span>, <span style="color: #009900">Req2</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_part_body</span></span>(<span style="color: #009900">Req1</span>), - <span style="color: #009900">Req2</span>; - {<span style="color: #FF6600">file</span>, <span style="color: #009900">_FieldName</span>, <span style="color: #009900">_Filename</span>, <span style="color: #009900">_CType</span>} <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #000000">stream_file</span></span>(<span style="color: #009900">Req1</span>) - <span style="font-weight: bold"><span style="color: #0000FF">end</span></span>, - <span style="font-weight: bold"><span style="color: #000000">multipart</span></span>(<span style="color: #009900">Req</span>); - {<span style="color: #FF6600">done</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">-></span> - <span style="color: #009900">Req</span> - <span style="font-weight: bold"><span style="color: #0000FF">end</span></span><span style="color: #990000">.</span> - -<span style="font-weight: bold"><span style="color: #000000">stream_file</span></span>(<span style="color: #009900">Req0</span>) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #0000FF">case</span></span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_part_body</span></span>(<span style="color: #009900">Req0</span>) <span style="font-weight: bold"><span style="color: #0000FF">of</span></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">_LastBodyChunk</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">-></span> - <span style="color: #009900">Req</span>; - {<span style="color: #FF6600">more</span>, <span style="color: #009900">_BodyChunk</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #000000">stream_file</span></span>(<span style="color: #009900">Req</span>) - <span style="font-weight: bold"><span style="color: #0000FF">end</span></span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Both the part header and body reading functions can take -options that will be given to the request body reading -functions. By default, <code>cowboy_req:read_part/1</code> reads -up to 64KB for up to 5 seconds. <code>cowboy_req:read_part_body/1</code> -has the same defaults as <code>cowboy_req:read_body/1</code>.</p></div> -<div class="paragraph"><p>To change the defaults for part headers:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">multipart</font></b>(<font color="#009900">Req0</font>) <font color="#990000">-></font> + <b><font color="#0000FF">case</font></b> <b><font color="#000000">cowboy_req:read_part</font></b>(<font color="#009900">Req0</font>) <b><font color="#0000FF">of</font></b> + {<font color="#FF6600">ok</font>, <font color="#009900">Headers</font>, <font color="#009900">Req1</font>} <font color="#990000">-></font> + <font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#0000FF">case</font></b> <b><font color="#000000">cow_multipart:form_data</font></b>(<font color="#009900">Headers</font>) <b><font color="#0000FF">of</font></b> + {<font color="#FF6600">data</font>, <font color="#009900">_FieldName</font>} <font color="#990000">-></font> + {<font color="#FF6600">ok</font>, <font color="#009900">_Body</font>, <font color="#009900">Req2</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:read_part_body</font></b>(<font color="#009900">Req1</font>), + <font color="#009900">Req2</font>; + {<font color="#FF6600">file</font>, <font color="#009900">_FieldName</font>, <font color="#009900">_Filename</font>, <font color="#009900">_CType</font>} <font color="#990000">-></font> + <b><font color="#000000">stream_file</font></b>(<font color="#009900">Req1</font>) + <b><font color="#0000FF">end</font></b>, + <b><font color="#000000">multipart</font></b>(<font color="#009900">Req</font>); + {<font color="#FF6600">done</font>, <font color="#009900">Req</font>} <font color="#990000">-></font> + <font color="#009900">Req</font> + <b><font color="#0000FF">end</font></b><font color="#990000">.</font> + +<b><font color="#000000">stream_file</font></b>(<font color="#009900">Req0</font>) <font color="#990000">-></font> + <b><font color="#0000FF">case</font></b> <b><font color="#000000">cowboy_req:read_part_body</font></b>(<font color="#009900">Req0</font>) <b><font color="#0000FF">of</font></b> + {<font color="#FF6600">ok</font>, <font color="#009900">_LastBodyChunk</font>, <font color="#009900">Req</font>} <font color="#990000">-></font> + <font color="#009900">Req</font>; + {<font color="#FF6600">more</font>, <font color="#009900">_BodyChunk</font>, <font color="#009900">Req</font>} <font color="#990000">-></font> + <b><font color="#000000">stream_file</font></b>(<font color="#009900">Req</font>) + <b><font color="#0000FF">end</font></b><font color="#990000">.</font></tt></pre> +</div></div> +<p>Both the part header and body reading functions can take options that will be given to the request body reading functions. By default, <code>cowboy_req:read_part/1</code> reads up to 64KB for up to 5 seconds. <code>cowboy_req:read_part_body/1</code> has the same defaults as <code>cowboy_req:read_body/1</code>.</p> +<p>To change the defaults for part headers:</p> +<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><span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_part</span></span>(<span style="color: #009900">Req</span>, #{<span style="font-weight: bold"><span style="color: #000080">length</span></span> <span style="color: #990000">=></span> <span style="color: #993399">128000</span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>And for part bodies:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">cowboy_req:read_part</font></b>(<font color="#009900">Req</font>, #{<b><font color="#000080">length</font></b> <font color="#990000">=></font> <font color="#993399">128000</font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>And for part bodies:</p> +<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><span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_part_body</span></span>(<span style="color: #009900">Req</span>, #{<span style="font-weight: bold"><span style="color: #000080">length</span></span> <span style="color: #990000">=></span> <span style="color: #993399">1000000</span>, <span style="color: #0000FF">period</span> <span style="color: #990000">=></span> <span style="color: #993399">7000</span>})<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">cowboy_req:read_part_body</font></b>(<font color="#009900">Req</font>, #{<b><font color="#000080">length</font></b> <font color="#990000">=></font> <font color="#993399">1000000</font>, <font color="#0000FF">period</font> <font color="#990000">=></font> <font color="#993399">7000</font>})<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_skipping_unwanted_parts">Skipping unwanted parts</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Part bodies do not have to be read. Cowboy will automatically -skip it when you request the next part’s body.</p></div> -<div class="paragraph"><p>The following snippet reads all part headers and skips -all bodies:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Part bodies do not have to be read. Cowboy will automatically skip it when you request the next part's body.</p> +<p>The following snippet reads all part headers and skips all bodies:</p> +<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><span style="font-weight: bold"><span style="color: #000000">multipart</span></span>(<span style="color: #009900">Req0</span>) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #0000FF">case</span></span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_part</span></span>(<span style="color: #009900">Req0</span>) <span style="font-weight: bold"><span style="color: #0000FF">of</span></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">_Headers</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #000000">multipart</span></span>(<span style="color: #009900">Req</span>); - {<span style="color: #FF6600">done</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">-></span> - <span style="color: #009900">Req</span> - <span style="font-weight: bold"><span style="color: #0000FF">end</span></span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Similarly, if you start reading the body and it ends up -being too big, you can simply continue with the next part. -Cowboy will automatically skip what remains.</p></div> -<div class="paragraph"><p>While Cowboy can skip part bodies automatically, the read -rate is not configurable. Depending on your application -you may want to skip manually, in particular if you observe -poor performance while skipping.</p></div> -<div class="paragraph"><p>You do not have to read all parts either. You can stop -reading as soon as you find the data you need.</p></div> -</div> -</div> +<pre><tt><b><font color="#000000">multipart</font></b>(<font color="#009900">Req0</font>) <font color="#990000">-></font> + <b><font color="#0000FF">case</font></b> <b><font color="#000000">cowboy_req:read_part</font></b>(<font color="#009900">Req0</font>) <b><font color="#0000FF">of</font></b> + {<font color="#FF6600">ok</font>, <font color="#009900">_Headers</font>, <font color="#009900">Req</font>} <font color="#990000">-></font> + <b><font color="#000000">multipart</font></b>(<font color="#009900">Req</font>); + {<font color="#FF6600">done</font>, <font color="#009900">Req</font>} <font color="#990000">-></font> + <font color="#009900">Req</font> + <b><font color="#0000FF">end</font></b><font color="#990000">.</font></tt></pre> +</div></div> +<p>Similarly, if you start reading the body and it ends up being too big, you can simply continue with the next part. Cowboy will automatically skip what remains.</p> +<p>While Cowboy can skip part bodies automatically, the read rate is not configurable. Depending on your application you may want to skip manually, in particular if you observe poor performance while skipping.</p> +<p>You do not have to read all parts either. You can stop reading as soon as you find the data you need.</p> +<!-- @todo Cover the building of multipart messages.--> + diff --git a/docs/en/cowboy/2.3/guide/req/index.html b/docs/en/cowboy/2.3/guide/req/index.html index 9d44a310..b709f063 100644 --- a/docs/en/cowboy/2.3/guide/req/index.html +++ b/docs/en/cowboy/2.3/guide/req/index.html @@ -62,407 +62,283 @@ <h1 class="lined-header"><span>The Req object</span></h1> -<div class="paragraph"><p>The Req object is a variable used for obtaining information -about a request, read its body or send a response.</p></div> -<div class="paragraph"><p>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 <code>cowboy_req</code> module.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="sect1"> +<p>The Req object is a variable used for obtaining information about a request, read its body or send a response.</p> +<p>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 <code>cowboy_req</code> module.</p> +<p>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.</p> <h2 id="_direct_access">Direct access</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The Req map contains a number of fields which are documented -and can be accessed directly. They are the fields that have -a direct mapping to HTTP: the request <code>method</code>; the HTTP -<code>version</code> used; the effective URI components <code>scheme</code>, -<code>host</code>, <code>port</code>, <code>path</code> and <code>qs</code>; the request <code>headers</code>; -and the connection <code>peer</code> address and port.</p></div> -<div class="paragraph"><p>Note that the <code>version</code> field can be used to determine -whether a connection is using HTTP/2.</p></div> -<div class="paragraph"><p>To access a field, you can simply match in the function -head. The following example sends a simple "Hello world!" -response when the <code>method</code> is GET, and a 405 error -otherwise.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The Req map contains a number of fields which are documented and can be accessed directly. They are the fields that have a direct mapping to HTTP: the request <code>method</code>; the HTTP <code>version</code> used; the effective URI components <code>scheme</code>, <code>host</code>, <code>port</code>, <code>path</code> and <code>qs</code>; the request <code>headers</code>; and the connection <code>peer</code> address and port.</p> +<p>Note that the <code>version</code> field can be used to determine whether a connection is using HTTP/2.</p> +<p>To access a field, you can simply match in the function head. The following example sends a simple "Hello world!" response when the <code>method</code> is GET, and a 405 error otherwise.</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req0</span><span style="color: #990000">=</span>#{<span style="color: #FF6600">method</span> <span style="color: #990000">:=</span> <span style="color: #990000"><<</span><span style="color: #FF0000">"GET"</span><span style="color: #990000">>></span>}, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - <span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">200</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"text/plain"</span><span style="color: #990000">>></span> - }, <span style="color: #990000"><<</span><span style="color: #FF0000">"Hello world!"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req0</span>), - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}; -<span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req0</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - <span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">405</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"allow"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"GET"</span><span style="color: #990000">>></span> - }, <span style="color: #009900">Req0</span>), - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Any other field is internal and should not be accessed. -They may change in future releases, including maintenance -releases, without notice.</p></div> -<div class="paragraph"><p>Modifying the Req object, while allowed, is not recommended -unless strictly necessary. If adding new fields, make sure -to namespace the field names so that no conflict can occur -with future Cowboy updates or third party projects.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req0</font><font color="#990000">=</font>#{<font color="#FF6600">method</font> <font color="#990000">:=</font> <font color="#990000"><<</font><font color="#FF0000">"GET"</font><font color="#990000">>></font>}, <font color="#009900">State</font>) <font color="#990000">-></font> + <font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">200</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"text/plain"</font><font color="#990000">>></font> + }, <font color="#990000"><<</font><font color="#FF0000">"Hello world!"</font><font color="#990000">>></font>, <font color="#009900">Req0</font>), + {<font color="#FF6600">ok</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}; +<b><font color="#000000">init</font></b>(<font color="#009900">Req0</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + <font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">405</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"allow"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"GET"</font><font color="#990000">>></font> + }, <font color="#009900">Req0</font>), + {<font color="#FF6600">ok</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>Any other field is internal and should not be accessed. They may change in future releases, including maintenance releases, without notice.</p> +<p>Modifying the Req object, while allowed, is not recommended unless strictly necessary. If adding new fields, make sure to namespace the field names so that no conflict can occur with future Cowboy updates or third party projects.</p> +<!-- @todo There are currently no tests for direct access.--> <h2 id="_introduction_to_the_cowboy_req_interface">Introduction to the cowboy_req interface</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Functions in the <code>cowboy_req</code> module provide access to -the request information but also various operations that -are common when dealing with HTTP requests.</p></div> -<div class="paragraph"><p>All the functions that begin with a verb indicate an action. -Other functions simply return the corresponding value -(sometimes that value does need to be built, but the -cost of the operation is equivalent to retrieving a value).</p></div> -<div class="paragraph"><p>Some of the <code>cowboy_req</code> functions return an updated Req -object. They are the read, reply, set and delete functions. -While ignoring the returned Req will not cause incorrect -behavior for some of them, it is highly recommended to -always keep and use the last returned Req object. The -manual for <code>cowboy_req</code> details these functions and what -modifications are done to the Req object.</p></div> -<div class="paragraph"><p>Some of the calls to <code>cowboy_req</code> have side effects. This -is the case of the read and reply functions. Cowboy reads -the request body or replies immediately when the function -is called.</p></div> -<div class="paragraph"><p>All functions will crash if something goes wrong. There -is usually no need to catch these errors, Cowboy will -send the appropriate 4xx or 5xx response depending on -where the crash occurred.</p></div> -</div> -</div> -<div class="sect1"> +<!-- @todo Link to cowboy_req manual--> +<p>Functions in the <code>cowboy_req</code> module provide access to the request information but also various operations that are common when dealing with HTTP requests.</p> +<p>All the functions that begin with a verb indicate an action. Other functions simply return the corresponding value (sometimes that value does need to be built, but the cost of the operation is equivalent to retrieving a value).</p> +<p>Some of the <code>cowboy_req</code> functions return an updated Req object. They are the read, reply, set and delete functions. While ignoring the returned Req will not cause incorrect behavior for some of them, it is highly recommended to always keep and use the last returned Req object. The manual for <code>cowboy_req</code> details these functions and what modifications are done to the Req object.</p> +<p>Some of the calls to <code>cowboy_req</code> have side effects. This is the case of the read and reply functions. Cowboy reads the request body or replies immediately when the function is called.</p> +<p>All functions will crash if something goes wrong. There is usually no need to catch these errors, Cowboy will send the appropriate 4xx or 5xx response depending on where the crash occurred.</p> <h2 id="_request_method">Request method</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The request method can be retrieved directly:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The request method can be retrieved directly:</p> +<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>#{<span style="color: #FF6600">method</span> <span style="color: #990000">:=</span> <span style="color: #009900">Method</span>} <span style="color: #990000">=</span> <span style="color: #009900">Req</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Or using a function:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>#{<font color="#FF6600">method</font> <font color="#990000">:=</font> <font color="#009900">Method</font>} <font color="#990000">=</font> <font color="#009900">Req</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>Or using a function:</p> +<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><span style="color: #009900">Method</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:method</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>The method is a case sensitive binary string. Standard -methods include GET, HEAD, OPTIONS, PATCH, POST, PUT -or DELETE.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">Method</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:method</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>The method is a case sensitive binary string. Standard methods include GET, HEAD, OPTIONS, PATCH, POST, PUT or DELETE.</p> <h2 id="_http_version">HTTP version</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The HTTP version is informational. It does not indicate that -the client implements the protocol well or fully.</p></div> -<div class="paragraph"><p>There is typically no need to change behavior based on the -HTTP version: Cowboy already does it for you.</p></div> -<div class="paragraph"><p>It can be useful in some cases, though. For example, one may -want to redirect HTTP/1.1 clients to use Websocket, while HTTP/2 -clients keep using HTTP/2.</p></div> -<div class="paragraph"><p>The HTTP version can be retrieved directly:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The HTTP version is informational. It does not indicate that the client implements the protocol well or fully.</p> +<p>There is typically no need to change behavior based on the HTTP version: Cowboy already does it for you.</p> +<p>It can be useful in some cases, though. For example, one may want to redirect HTTP/1.1 clients to use Websocket, while HTTP/2 clients keep using HTTP/2.</p> +<p>The HTTP version can be retrieved directly:</p> +<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>#{<span style="color: #FF6600">version</span> <span style="color: #990000">:=</span> <span style="color: #009900">Version</span>} <span style="color: #990000">=</span> <span style="color: #009900">Req</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Or using a function:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>#{<font color="#FF6600">version</font> <font color="#990000">:=</font> <font color="#009900">Version</font>} <font color="#990000">=</font> <font color="#009900">Req</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>Or using a function:</p> +<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><span style="color: #009900">Version</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:version</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Cowboy defines the <code>'HTTP/1.0'</code>, <code>'HTTP/1.1'</code> and <code>'HTTP/2'</code> -versions. Custom protocols can define their own values as -atoms.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">Version</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:version</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Cowboy defines the <code>'HTTP/1.0'</code>, <code>'HTTP/1.1'</code> and <code>'HTTP/2'</code> versions. Custom protocols can define their own values as atoms.</p> <h2 id="_effective_request_uri">Effective request URI</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The scheme, host, port, path and query string components -of the effective request URI can all be retrieved directly:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The scheme, host, port, path and query string components of the effective request URI can all be retrieved directly:</p> +<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>#{ - <span style="color: #FF6600">scheme</span> <span style="color: #990000">:=</span> <span style="color: #009900">Scheme</span>, - <span style="color: #FF6600">host</span> <span style="color: #990000">:=</span> <span style="color: #009900">Host</span>, - <span style="color: #FF6600">port</span> <span style="color: #990000">:=</span> <span style="color: #009900">Port</span>, - <span style="color: #FF6600">path</span> <span style="color: #990000">:=</span> <span style="color: #009900">Path</span>, - <span style="color: #FF6600">qs</span> <span style="color: #990000">:=</span> <span style="color: #009900">Qs</span> -} <span style="color: #990000">=</span> <span style="color: #009900">Req</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Or using the related functions:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight + <font color="#FF6600">scheme</font> <font color="#990000">:=</font> <font color="#009900">Scheme</font>, + <font color="#FF6600">host</font> <font color="#990000">:=</font> <font color="#009900">Host</font>, + <font color="#FF6600">port</font> <font color="#990000">:=</font> <font color="#009900">Port</font>, + <font color="#FF6600">path</font> <font color="#990000">:=</font> <font color="#009900">Path</font>, + <font color="#FF6600">qs</font> <font color="#990000">:=</font> <font color="#009900">Qs</font> +} <font color="#990000">=</font> <font color="#009900">Req</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>Or using the related functions:</p> +<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><span style="color: #009900">Scheme</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:scheme</span></span>(<span style="color: #009900">Req</span>), -<span style="color: #009900">Host</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:host</span></span>(<span style="color: #009900">Req</span>), -<span style="color: #009900">Port</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:port</span></span>(<span style="color: #009900">Req</span>), -<span style="color: #009900">Path</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:path</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span> -<span style="color: #009900">Qs</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:qs</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>The scheme and host are lowercased case insensitive binary -strings. The port is an integer representing the port number. -The path and query string are case sensitive binary strings.</p></div> -<div class="paragraph"><p>Cowboy defines only the <code><<"http">></code> and <code><<"https">></code> schemes. -They are chosen so that the scheme will only be <code><<"https">></code> -for requests on secure HTTP/1.1 or HTTP/2 connections.</p></div> -<div class="paragraph"><p>The effective request URI itself can be reconstructed with -the <code>cowboy_req:uri/1,2</code> function. By default, an absolute -URI is returned:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Scheme</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:scheme</font></b>(<font color="#009900">Req</font>), +<font color="#009900">Host</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:host</font></b>(<font color="#009900">Req</font>), +<font color="#009900">Port</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:port</font></b>(<font color="#009900">Req</font>), +<font color="#009900">Path</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:path</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font> +<font color="#009900">Qs</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:qs</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>The scheme and host are lowercased case insensitive binary strings. The port is an integer representing the port number. The path and query string are case sensitive binary strings.</p> +<p>Cowboy defines only the <code><<"http">></code> and <code><<"https">></code> schemes. They are chosen so that the scheme will only be <code><<"https">></code> for requests on secure HTTP/1.1 or HTTP/2 connections.</p> +<!-- @todo Is that tested well?--> +<p>The effective request URI itself can be reconstructed with the <code>cowboy_req:uri/1,2</code> function. By default, an absolute URI is returned:</p> +<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><span style="font-style: italic"><span style="color: #9A1900">%% </span></span><span style="text-decoration: underline"><span style="color: #0000FF">scheme://host</span></span><span style="font-style: italic"><span style="color: #9A1900">[:port]/path[?qs]</span></span> -<span style="color: #009900">URI</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:uri</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Options are available to either disable or replace some -or all of the components. Various URIs or URI formats can -be generated this way, including the origin form:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><i><font color="#9A1900">%% </font></i><u><font color="#0000FF">scheme://host</font></u><i><font color="#9A1900">[:port]/path[?qs]</font></i> +<font color="#009900">URI</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:uri</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Options are available to either disable or replace some or all of the components. Various URIs or URI formats can be generated this way, including the origin form:</p> +<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><span style="font-style: italic"><span style="color: #9A1900">%% /path[?qs]</span></span> -<span style="color: #009900">URI</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:uri</span></span>(<span style="color: #009900">Req</span>, #{<span style="color: #0000FF">host</span> <span style="color: #990000">=></span> <span style="color: #000080">undefined</span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>The protocol relative form:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><i><font color="#9A1900">%% /path[?qs]</font></i> +<font color="#009900">URI</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:uri</font></b>(<font color="#009900">Req</font>, #{<font color="#0000FF">host</font> <font color="#990000">=></font> <font color="#000080">undefined</font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>The protocol relative form:</p> +<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><span style="font-style: italic"><span style="color: #9A1900">%% //host[:port]/path[?qs]</span></span> -<span style="color: #009900">URI</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:uri</span></span>(<span style="color: #009900">Req</span>, #{<span style="color: #0000FF">scheme</span> <span style="color: #990000">=></span> <span style="color: #000080">undefined</span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>The absolute URI without a query string:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><i><font color="#9A1900">%% //host[:port]/path[?qs]</font></i> +<font color="#009900">URI</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:uri</font></b>(<font color="#009900">Req</font>, #{<font color="#0000FF">scheme</font> <font color="#990000">=></font> <font color="#000080">undefined</font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>The absolute URI without a query string:</p> +<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><span style="color: #009900">URI</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:uri</span></span>(<span style="color: #009900">Req</span>, #{<span style="color: #0000FF">qs</span> <span style="color: #990000">=></span> <span style="color: #000080">undefined</span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>A different host:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">URI</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:uri</font></b>(<font color="#009900">Req</font>, #{<font color="#0000FF">qs</font> <font color="#990000">=></font> <font color="#000080">undefined</font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>A different host:</p> +<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><span style="color: #009900">URI</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:uri</span></span>(<span style="color: #009900">Req</span>, #{<span style="color: #0000FF">host</span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"example.org"</span><span style="color: #990000">>></span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>And any other combination.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">URI</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:uri</font></b>(<font color="#009900">Req</font>, #{<font color="#0000FF">host</font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"example.org"</font><font color="#990000">>></font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>And any other combination.</p> <h2 id="_bindings">Bindings</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Bindings are the host and path components that you chose -to extract when defining the routes of your application. -They are only available after the routing.</p></div> -<div class="paragraph"><p>Cowboy provides functions to retrieve one or all bindings.</p></div> -<div class="paragraph"><p>To retrieve a single value:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Bindings are the host and path components that you chose to extract when defining the routes of your application. They are only available after the routing.</p> +<p>Cowboy provides functions to retrieve one or all bindings.</p> +<p>To retrieve a single value:</p> +<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><span style="color: #009900">Value</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:binding</span></span>(<span style="color: #FF6600">userid</span>, <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>When attempting to retrieve a value that was not bound, -<code>undefined</code> will be returned. A different default value -can be provided:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Value</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:binding</font></b>(<font color="#FF6600">userid</font>, <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>When attempting to retrieve a value that was not bound, <code>undefined</code> will be returned. A different default value can be provided:</p> +<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><span style="color: #009900">Value</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:binding</span></span>(<span style="color: #FF6600">userid</span>, <span style="color: #009900">Req</span>, <span style="color: #993399">42</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>To retrieve everything that was bound:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Value</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:binding</font></b>(<font color="#FF6600">userid</font>, <font color="#009900">Req</font>, <font color="#993399">42</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>To retrieve everything that was bound:</p> +<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><span style="color: #009900">Bindings</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:bindings</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>They are returned as a map, with keys being atoms.</p></div> -<div class="paragraph"><p>The Cowboy router also allows you to capture many host -or path segments at once using the <code>...</code> qualifier.</p></div> -<div class="paragraph"><p>To retrieve the segments captured from the host name:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Bindings</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:bindings</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>They are returned as a map, with keys being atoms.</p> +<p>The Cowboy router also allows you to capture many host or path segments at once using the <code>...</code> qualifier.</p> +<p>To retrieve the segments captured from the host name:</p> +<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><span style="color: #009900">HostInfo</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:host_info</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>And the path segments:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">HostInfo</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:host_info</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>And the path segments:</p> +<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><span style="color: #009900">PathInfo</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:path_info</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Cowboy will return <code>undefined</code> if <code>...</code> was not used -in the route.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">PathInfo</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:path_info</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Cowboy will return <code>undefined</code> if <code>...</code> was not used in the route.</p> <h2 id="_query_parameters">Query parameters</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy provides two functions to access query parameters. -You can use the first to get the entire list of parameters.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy provides two functions to access query parameters. You can use the first to get the entire list of parameters.</p> +<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><span style="color: #009900">QsVals</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:parse_qs</span></span>(<span style="color: #009900">Req</span>), -{<span style="color: #990000">_</span>, <span style="color: #009900">Lang</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">lists:keyfind</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"lang"</span><span style="color: #990000">>></span>, <span style="color: #993399">1</span>, <span style="color: #009900">QsVals</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Cowboy will only parse the query string, and not do any -transformation. This function may therefore return duplicates, -or parameter names without an associated value. The order of -the list returned is undefined.</p></div> -<div class="paragraph"><p>When a query string is <code>key=1&key=2</code>, the list returned will -contain two parameters of name <code>key</code>.</p></div> -<div class="paragraph"><p>The same is true when trying to use the PHP-style suffix <code>[]</code>. -When a query string is <code>key[]=1&key[]=2</code>, the list returned will -contain two parameters of name <code>key[]</code>.</p></div> -<div class="paragraph"><p>When a query string is simply <code>key</code>, Cowboy will return the -list <code>[{<<"key">>, true}]</code>, using <code>true</code> to indicate that the -parameter <code>key</code> was defined, but with no value.</p></div> -<div class="paragraph"><p>The second function Cowboy provides allows you to match out -only the parameters you are interested in, and at the same -time do any post processing you require using <a href="../constraints">constraints</a>. -This function returns a map.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">QsVals</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:parse_qs</font></b>(<font color="#009900">Req</font>), +{<font color="#990000">_</font>, <font color="#009900">Lang</font>} <font color="#990000">=</font> <b><font color="#000000">lists:keyfind</font></b>(<font color="#990000"><<</font><font color="#FF0000">"lang"</font><font color="#990000">>></font>, <font color="#993399">1</font>, <font color="#009900">QsVals</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Cowboy will only parse the query string, and not do any transformation. This function may therefore return duplicates, or parameter names without an associated value. The order of the list returned is undefined.</p> +<p>When a query string is <code>key=1&key=2</code>, the list returned will contain two parameters of name <code>key</code>.</p> +<p>The same is true when trying to use the PHP-style suffix <code>[]</code>. When a query string is <code>key[]=1&key[]=2</code>, the list returned will contain two parameters of name <code>key[]</code>.</p> +<p>When a query string is simply <code>key</code>, Cowboy will return the list <code>[{<<"key">>, true}]</code>, using <code>true</code> to indicate that the parameter <code>key</code> was defined, but with no value.</p> +<p>The second function Cowboy provides allows you to match out only the parameters you are interested in, and at the same time do any post processing you require using <a href="../constraints">constraints</a>. This function returns a map.</p> +<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>#{<span style="color: #FF6600">id</span> <span style="color: #990000">:=</span> <span style="color: #009900">ID</span>, <span style="color: #FF6600">lang</span> <span style="color: #990000">:=</span> <span style="color: #009900">Lang</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:match_qs</span></span>([<span style="color: #FF6600">id</span>, <span style="color: #FF6600">lang</span>], <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Constraints can be applied automatically. The following -snippet will crash when the <code>id</code> parameter is not an integer, -or when the <code>lang</code> parameter is empty. At the same time, the -value for <code>id</code> will be converted to an integer term:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>#{<font color="#FF6600">id</font> <font color="#990000">:=</font> <font color="#009900">ID</font>, <font color="#FF6600">lang</font> <font color="#990000">:=</font> <font color="#009900">Lang</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:match_qs</font></b>([<font color="#FF6600">id</font>, <font color="#FF6600">lang</font>], <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Constraints can be applied automatically. The following snippet will crash when the <code>id</code> parameter is not an integer, or when the <code>lang</code> parameter is empty. At the same time, the value for <code>id</code> will be converted to an integer term:</p> +<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><span style="color: #009900">QsMap</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:match_qs</span></span>([{<span style="color: #FF6600">id</span>, <span style="color: #FF6600">int</span>}, {<span style="color: #FF6600">lang</span>, <span style="color: #FF6600">nonempty</span>}], <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>A default value may also be provided. The default will be used -if the <code>lang</code> key is not found. It will not be used if -the key is found but has an empty value.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">QsMap</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:match_qs</font></b>([{<font color="#FF6600">id</font>, <font color="#FF6600">int</font>}, {<font color="#FF6600">lang</font>, <font color="#FF6600">nonempty</font>}], <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>A default value may also be provided. The default will be used if the <code>lang</code> key is not found. It will not be used if the key is found but has an empty value.</p> +<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>#{<span style="color: #FF6600">lang</span> <span style="color: #990000">:=</span> <span style="color: #009900">Lang</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:match_qs</span></span>([{<span style="color: #FF6600">lang</span>, [], <span style="color: #990000"><<</span><span style="color: #FF0000">"en-US"</span><span style="color: #990000">>></span>}], <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>If no default is provided and the value is missing, the -query string is deemed invalid and the process will crash.</p></div> -<div class="paragraph"><p>When the query string is <code>key=1&key=2</code>, the value for <code>key</code> -will be the list <code>[1, 2]</code>. Parameter names do not need to -include the PHP-style suffix. Constraints may be used to -ensure that only one value was passed through.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt>#{<font color="#FF6600">lang</font> <font color="#990000">:=</font> <font color="#009900">Lang</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:match_qs</font></b>([{<font color="#FF6600">lang</font>, [], <font color="#990000"><<</font><font color="#FF0000">"en-US"</font><font color="#990000">>></font>}], <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>If no default is provided and the value is missing, the query string is deemed invalid and the process will crash.</p> +<p>When the query string is <code>key=1&key=2</code>, the value for <code>key</code> will be the list <code>[1, 2]</code>. Parameter names do not need to include the PHP-style suffix. Constraints may be used to ensure that only one value was passed through.</p> <h2 id="_headers">Headers</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Header values can be retrieved either as a binary string -or parsed into a more meaningful representation.</p></div> -<div class="paragraph"><p>The get the raw value:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Header values can be retrieved either as a binary string or parsed into a more meaningful representation.</p> +<p>The get the raw value:</p> +<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><span style="color: #009900">HeaderVal</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:header</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Cowboy expects all header names to be provided as lowercase -binary strings. This is true for both requests and responses, -regardless of the underlying protocol.</p></div> -<div class="paragraph"><p>When the header is missing from the request, <code>undefined</code> -will be returned. A different default can be provided:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">HeaderVal</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:header</font></b>(<font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font>, <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Cowboy expects all header names to be provided as lowercase binary strings. This is true for both requests and responses, regardless of the underlying protocol.</p> +<p>When the header is missing from the request, <code>undefined</code> will be returned. A different default can be provided:</p> +<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><span style="color: #009900">HeaderVal</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:header</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req</span>, <span style="color: #990000"><<</span><span style="color: #FF0000">"text/plain"</span><span style="color: #990000">>></span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>All headers can be retrieved at once, either directly:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">HeaderVal</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:header</font></b>(<font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font>, <font color="#009900">Req</font>, <font color="#990000"><<</font><font color="#FF0000">"text/plain"</font><font color="#990000">>></font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>All headers can be retrieved at once, either directly:</p> +<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>#{<span style="color: #FF6600">headers</span> <span style="color: #990000">:=</span> <span style="color: #009900">AllHeaders</span>} <span style="color: #990000">=</span> <span style="color: #009900">Req</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Or using a function:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>#{<font color="#FF6600">headers</font> <font color="#990000">:=</font> <font color="#009900">AllHeaders</font>} <font color="#990000">=</font> <font color="#009900">Req</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>Or using a function:</p> +<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><span style="color: #009900">AllHeaders</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:headers</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Cowboy provides equivalent functions to parse individual -headers. There is no function to parse all headers at once.</p></div> -<div class="paragraph"><p>To parse a specific header:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">AllHeaders</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:headers</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Cowboy provides equivalent functions to parse individual headers. There is no function to parse all headers at once.</p> +<p>To parse a specific header:</p> +<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><span style="color: #009900">ParsedVal</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:parse_header</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>An exception will be thrown if it doesn’t know how to parse the -given header, or if the value is invalid. The list of known headers -and default values can be found in the manual.</p></div> -<div class="paragraph"><p>When the header is missing, <code>undefined</code> is returned. You can -change the default value. Note that it should be the parsed value -directly:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">ParsedVal</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:parse_header</font></b>(<font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font>, <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>An exception will be thrown if it doesn't know how to parse the given header, or if the value is invalid. The list of known headers and default values can be found in the manual.</p> +<p>When the header is missing, <code>undefined</code> is returned. You can change the default value. Note that it should be the parsed value directly:</p> +<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><span style="color: #009900">ParsedVal</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:parse_header</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req</span>, - {<span style="color: #990000"><<</span><span style="color: #FF0000">"text"</span><span style="color: #990000">>></span>, <span style="color: #990000"><<</span><span style="color: #FF0000">"plain"</span><span style="color: #990000">>></span>, []})<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">ParsedVal</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:parse_header</font></b>(<font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font>, <font color="#009900">Req</font>, + {<font color="#990000"><<</font><font color="#FF0000">"text"</font><font color="#990000">>></font>, <font color="#990000"><<</font><font color="#FF0000">"plain"</font><font color="#990000">>></font>, []})<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_peer">Peer</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The peer address and port number for the connection can be -retrieved either directly or using a function.</p></div> -<div class="paragraph"><p>To retrieve the peer directly:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The peer address and port number for the connection can be retrieved either directly or using a function.</p> +<p>To retrieve the peer directly:</p> +<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>#{<span style="color: #FF6600">peer</span> <span style="color: #990000">:=</span> {<span style="color: #009900">IP</span>, <span style="color: #009900">Port</span>}} <span style="color: #990000">=</span> <span style="color: #009900">Req</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>And using a function:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>#{<font color="#FF6600">peer</font> <font color="#990000">:=</font> {<font color="#009900">IP</font>, <font color="#009900">Port</font>}} <font color="#990000">=</font> <font color="#009900">Req</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>And using a function:</p> +<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>{<span style="color: #009900">IP</span>, <span style="color: #009900">Port</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:peer</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Note that the peer corresponds to the remote end of the -connection to the server, which may or may not be the -client itself. It may also be a proxy or a gateway.</p></div> -</div> -</div> +<pre><tt>{<font color="#009900">IP</font>, <font color="#009900">Port</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:peer</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Note that the peer corresponds to the remote end of the connection to the server, which may or may not be the client itself. It may also be a proxy or a gateway.</p> + diff --git a/docs/en/cowboy/2.3/guide/req_body/index.html b/docs/en/cowboy/2.3/guide/req_body/index.html index 7db337da..a127f6f2 100644 --- a/docs/en/cowboy/2.3/guide/req_body/index.html +++ b/docs/en/cowboy/2.3/guide/req_body/index.html @@ -62,144 +62,93 @@ <h1 class="lined-header"><span>Reading the request body</span></h1> -<div class="paragraph"><p>The request body can be read using the Req object.</p></div> -<div class="paragraph"><p>Cowboy will not attempt to read the body until requested. -You need to call the body reading functions in order to -retrieve it.</p></div> -<div class="paragraph"><p>Cowboy will not cache the body, it is therefore only -possible to read it once.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>Cowboy provides functions for reading the body raw, -and read and parse form urlencoded or <a href="../multipart">multipart bodies</a>. -The latter is covered in its own chapter.</p></div> -<div class="sect1"> +<p>The request body can be read using the Req object.</p> +<p>Cowboy will not attempt to read the body until requested. You need to call the body reading functions in order to retrieve it.</p> +<p>Cowboy will not cache the body, it is therefore only possible to read it once.</p> +<p>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.</p> +<p>Cowboy provides functions for reading the body raw, and read and parse form urlencoded or <a href="../multipart">multipart bodies</a>. The latter is covered in its own chapter.</p> <h2 id="_request_body_presence">Request body presence</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Not all requests come with a body. You can check for -the presence of a request body with this function:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Not all requests come with a body. You can check for the presence of a request body with this function:</p> +<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><span style="font-weight: bold"><span style="color: #000000">cowboy_req:has_body</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>It returns <code>true</code> if there is a body; <code>false</code> otherwise.</p></div> -<div class="paragraph"><p>In practice, this function is rarely used. When the -method is <code>POST</code>, <code>PUT</code> or <code>PATCH</code>, the request body -is often required by the application, which should -just attempt to read it directly.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">cowboy_req:has_body</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>It returns <code>true</code> if there is a body; <code>false</code> otherwise.</p> +<p>In practice, this function is rarely used. When the method is <code>POST</code>, <code>PUT</code> or <code>PATCH</code>, the request body is often required by the application, which should just attempt to read it directly.</p> <h2 id="_request_body_length">Request body length</h2> -<div class="sectionbody"> -<div class="paragraph"><p>You can obtain the length of the body:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>You can obtain the length of the body:</p> +<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><span style="color: #009900">Length</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:body_length</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Note that the length may not be known in advance. In -that case <code>undefined</code> will be returned. This can happen -with HTTP/1.1’s chunked transfer-encoding, or HTTP/2 -when no content-length was provided.</p></div> -<div class="paragraph"><p>Cowboy will update the body length in the Req object -once the body has been read completely. A length will -always be returned when attempting to call this function -after reading the body completely.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">Length</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:body_length</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Note that the length may not be known in advance. In that case <code>undefined</code> will be returned. This can happen with HTTP/1.1's chunked transfer-encoding, or HTTP/2 when no content-length was provided.</p> +<p>Cowboy will update the body length in the Req object once the body has been read completely. A length will always be returned when attempting to call this function after reading the body completely.</p> <h2 id="_reading_the_body">Reading the body</h2> -<div class="sectionbody"> -<div class="paragraph"><p>You can read the entire body with one function call:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>You can read the entire body with one function call:</p> +<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>{<span style="color: #FF6600">ok</span>, <span style="color: #009900">Data</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_body</span></span>(<span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Cowboy returns an <code>ok</code> tuple when the body has been -read fully.</p></div> -<div class="paragraph"><p>By default, Cowboy will attempt to read up to 8MB -of data, for up to 15 seconds. The call will return -once Cowboy has read at least 8MB of data, or at -the end of the 15 seconds period.</p></div> -<div class="paragraph"><p>These values can be customized. For example, to read -only up to 1MB for up to 5 seconds:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>{<font color="#FF6600">ok</font>, <font color="#009900">Data</font>, <font color="#009900">Req</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:read_body</font></b>(<font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Cowboy returns an <code>ok</code> tuple when the body has been read fully.</p> +<p>By default, Cowboy will attempt to read up to 8MB of data, for up to 15 seconds. The call will return once Cowboy has read at least 8MB of data, or at the end of the 15 seconds period.</p> +<p>These values can be customized. For example, to read only up to 1MB for up to 5 seconds:</p> +<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>{<span style="color: #FF6600">ok</span>, <span style="color: #009900">Data</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_body</span></span>(<span style="color: #009900">Req0</span>, - #{<span style="font-weight: bold"><span style="color: #000080">length</span></span> <span style="color: #990000">=></span> <span style="color: #993399">1000000</span>, <span style="color: #0000FF">period</span> <span style="color: #990000">=></span> <span style="color: #993399">5000</span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>You may also disable the length limit:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>{<font color="#FF6600">ok</font>, <font color="#009900">Data</font>, <font color="#009900">Req</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:read_body</font></b>(<font color="#009900">Req0</font>, + #{<b><font color="#000080">length</font></b> <font color="#990000">=></font> <font color="#993399">1000000</font>, <font color="#0000FF">period</font> <font color="#990000">=></font> <font color="#993399">5000</font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>You may also disable the length limit:</p> +<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>{<span style="color: #FF6600">ok</span>, <span style="color: #009900">Data</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_body</span></span>(<span style="color: #009900">Req0</span>, #{<span style="font-weight: bold"><span style="color: #000080">length</span></span> <span style="color: #990000">=></span> <span style="color: #FF6600">infinity</span>})<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>This makes the function wait 15 seconds and return with -whatever arrived during that period. This is not -recommended for public facing applications.</p></div> -<div class="paragraph"><p>These two options can effectively be used to control -the rate of transmission of the request body.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt>{<font color="#FF6600">ok</font>, <font color="#009900">Data</font>, <font color="#009900">Req</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:read_body</font></b>(<font color="#009900">Req0</font>, #{<b><font color="#000080">length</font></b> <font color="#990000">=></font> <font color="#FF6600">infinity</font>})<font color="#990000">.</font></tt></pre> +</div></div> +<p>This makes the function wait 15 seconds and return with whatever arrived during that period. This is not recommended for public facing applications.</p> +<p>These two options can effectively be used to control the rate of transmission of the request body.</p> <h2 id="_streaming_the_body">Streaming the body</h2> -<div class="sectionbody"> -<div class="paragraph"><p>When the body is too large, the first call will return -a <code>more</code> tuple instead of <code>ok</code>. You can call the -function again to read more of the body, reading -it one chunk at a time.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>When the body is too large, the first call will return a <code>more</code> tuple instead of <code>ok</code>. You can call the function again to read more of the body, reading it one chunk at a time.</p> +<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><span style="font-weight: bold"><span style="color: #000000">read_body_to_console</span></span>(<span style="color: #009900">Req0</span>) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #0000FF">case</span></span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_body</span></span>(<span style="color: #009900">Req0</span>) <span style="font-weight: bold"><span style="color: #0000FF">of</span></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">Data</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #000000">io:format</span></span>(<span style="color: #FF0000">"~s"</span>, [<span style="color: #009900">Data</span>]), - <span style="color: #009900">Req</span>; - {<span style="color: #FF6600">more</span>, <span style="color: #009900">Data</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #000000">io:format</span></span>(<span style="color: #FF0000">"~s"</span>, [<span style="color: #009900">Data</span>]), - <span style="font-weight: bold"><span style="color: #000000">read_body_to_console</span></span>(<span style="color: #009900">Req</span>) - <span style="font-weight: bold"><span style="color: #0000FF">end</span></span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>The <code>length</code> and <code>period</code> options can also be used. -They need to be passed for every call.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">read_body_to_console</font></b>(<font color="#009900">Req0</font>) <font color="#990000">-></font> + <b><font color="#0000FF">case</font></b> <b><font color="#000000">cowboy_req:read_body</font></b>(<font color="#009900">Req0</font>) <b><font color="#0000FF">of</font></b> + {<font color="#FF6600">ok</font>, <font color="#009900">Data</font>, <font color="#009900">Req</font>} <font color="#990000">-></font> + <b><font color="#000000">io:format</font></b>(<font color="#FF0000">"~s"</font>, [<font color="#009900">Data</font>]), + <font color="#009900">Req</font>; + {<font color="#FF6600">more</font>, <font color="#009900">Data</font>, <font color="#009900">Req</font>} <font color="#990000">-></font> + <b><font color="#000000">io:format</font></b>(<font color="#FF0000">"~s"</font>, [<font color="#009900">Data</font>]), + <b><font color="#000000">read_body_to_console</font></b>(<font color="#009900">Req</font>) + <b><font color="#0000FF">end</font></b><font color="#990000">.</font></tt></pre> +</div></div> +<p>The <code>length</code> and <code>period</code> options can also be used. They need to be passed for every call.</p> <h2 id="_reading_a_form_urlencoded_body">Reading a form urlencoded body</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy provides a convenient function for reading and -parsing bodies sent as application/x-www-form-urlencoded.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy provides a convenient function for reading and parsing bodies sent as application/x-www-form-urlencoded.</p> +<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>{<span style="color: #FF6600">ok</span>, <span style="color: #009900">KeyValues</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_urlencoded_body</span></span>(<span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>This function returns a list of key/values, exactly like -the function <code>cowboy_req:parse_qs/1</code>.</p></div> -<div class="paragraph"><p>The defaults for this function are different. Cowboy will -read for up to 64KB and up to 5 seconds. They can be modified:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>{<font color="#FF6600">ok</font>, <font color="#009900">KeyValues</font>, <font color="#009900">Req</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:read_urlencoded_body</font></b>(<font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>This function returns a list of key/values, exactly like the function <code>cowboy_req:parse_qs/1</code>.</p> +<p>The defaults for this function are different. Cowboy will read for up to 64KB and up to 5 seconds. They can be modified:</p> +<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>{<span style="color: #FF6600">ok</span>, <span style="color: #009900">KeyValues</span>, <span style="color: #009900">Req</span>} <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:read_urlencoded_body</span></span>(<span style="color: #009900">Req0</span>, - #{<span style="font-weight: bold"><span style="color: #000080">length</span></span> <span style="color: #990000">=></span> <span style="color: #993399">4096</span>, <span style="color: #0000FF">period</span> <span style="color: #990000">=></span> <span style="color: #993399">3000</span>})<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> +<pre><tt>{<font color="#FF6600">ok</font>, <font color="#009900">KeyValues</font>, <font color="#009900">Req</font>} <font color="#990000">=</font> <b><font color="#000000">cowboy_req:read_urlencoded_body</font></b>(<font color="#009900">Req0</font>, + #{<b><font color="#000080">length</font></b> <font color="#990000">=></font> <font color="#993399">4096</font>, <font color="#0000FF">period</font> <font color="#990000">=></font> <font color="#993399">3000</font>})<font color="#990000">.</font></tt></pre> +</div></div> + diff --git a/docs/en/cowboy/2.3/guide/resource_design/index.html b/docs/en/cowboy/2.3/guide/resource_design/index.html index be567d98..699ebc56 100644 --- a/docs/en/cowboy/2.3/guide/resource_design/index.html +++ b/docs/en/cowboy/2.3/guide/resource_design/index.html @@ -62,213 +62,66 @@ <h1 class="lined-header"><span>Designing a resource handler</span></h1> -<div class="paragraph"><p>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.</p></div> -<div class="sect1"> +<p>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.</p> <h2 id="_the_service">The service</h2> -<div class="sectionbody"> -<div class="paragraph"><p>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. Implement the -<code>service_available</code> callback.</p></div> -<div class="paragraph"><p>What HTTP methods does the service implement? Do we need -more than the standard OPTIONS, HEAD, GET, PUT, POST, -PATCH and DELETE? Are we not using one of those at all? -Implement the <code>known_methods</code> callback.</p></div> -</div> -</div> -<div class="sect1"> +<p>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. Implement the <code>service_available</code> callback.</p> +<p>What HTTP methods does the service implement? Do we need more than the standard OPTIONS, HEAD, GET, PUT, POST, PATCH and DELETE? Are we not using one of those at all? Implement the <code>known_methods</code> callback.</p> <h2 id="_type_of_resource_handler">Type of resource handler</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Am I writing a handler for a collection of resources, -or for a single resource?</p></div> -<div class="paragraph"><p>The semantics for each of these are quite different. -You should not mix collection and single resource in -the same handler.</p></div> -</div> -</div> -<div class="sect1"> +<p>Am I writing a handler for a collection of resources, or for a single resource?</p> +<p>The semantics for each of these are quite different. You should not mix collection and single resource in the same handler.</p> <h2 id="_collection_handler">Collection handler</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Skip this section if you are not doing a collection.</p></div> -<div class="paragraph"><p>Is the collection hardcoded or dynamic? For example, -if you use the route <code>/users</code> for the collection of -users then the collection is hardcoded; if you use -<code>/forums/:category</code> for the collection of threads -then it isn’t. When the collection is hardcoded you -can safely assume the resource always exists.</p></div> -<div class="paragraph"><p>What methods should I implement?</p></div> -<div class="paragraph"><p>OPTIONS is used to get some information about the -collection. It is recommended to allow it even if you -do not implement it, as Cowboy has a default -implementation built-in.</p></div> -<div class="paragraph"><p>HEAD and GET are used to retrieve the collection. -If you allow GET, also allow HEAD as there’s no extra -work required to make it work.</p></div> -<div class="paragraph"><p>POST is used to create a new resource inside the -collection. Creating a resource by using POST on -the collection is useful when resources may be -created before knowing their URI, usually because -parts of it are generated dynamically. A common -case is some kind of auto incremented integer -identifier.</p></div> -<div class="paragraph"><p>The next methods are more rarely allowed.</p></div> -<div class="paragraph"><p>PUT is used to create a new collection (when -the collection isn’t hardcoded), or replace -the entire collection.</p></div> -<div class="paragraph"><p>DELETE is used to delete the entire collection.</p></div> -<div class="paragraph"><p>PATCH is used to modify the collection using -instructions given in the request body. A PATCH -operation is atomic. The PATCH operation may -be used for such things as reordering; adding, -modifying or deleting parts of the collection.</p></div> -</div> -</div> -<div class="sect1"> +<p>Skip this section if you are not doing a collection.</p> +<p>Is the collection hardcoded or dynamic? For example, if you use the route <code>/users</code> for the collection of users then the collection is hardcoded; if you use <code>/forums/:category</code> for the collection of threads then it isn't. When the collection is hardcoded you can safely assume the resource always exists.</p> +<p>What methods should I implement?</p> +<p>OPTIONS is used to get some information about the collection. It is recommended to allow it even if you do not implement it, as Cowboy has a default implementation built-in.</p> +<p>HEAD and GET are used to retrieve the collection. If you allow GET, also allow HEAD as there's no extra work required to make it work.</p> +<p>POST is used to create a new resource inside the collection. Creating a resource by using POST on the collection is useful when resources may be created before knowing their URI, usually because parts of it are generated dynamically. A common case is some kind of auto incremented integer identifier.</p> +<p>The next methods are more rarely allowed.</p> +<p>PUT is used to create a new collection (when the collection isn't hardcoded), or replace the entire collection.</p> +<p>DELETE is used to delete the entire collection.</p> +<p>PATCH is used to modify the collection using instructions given in the request body. A PATCH operation is atomic. The PATCH operation may be used for such things as reordering; adding, modifying or deleting parts of the collection.</p> <h2 id="_single_resource_handler">Single resource handler</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Skip this section if you are doing a collection.</p></div> -<div class="paragraph"><p>What methods should I implement?</p></div> -<div class="paragraph"><p>OPTIONS is used to get some information about the -resource. It is recommended to allow it even if you -do not implement it, as Cowboy has a default -implementation built-in.</p></div> -<div class="paragraph"><p>HEAD and GET are used to retrieve the resource. -If you allow GET, also allow HEAD as there’s no extra -work required to make it work.</p></div> -<div class="paragraph"><p>POST is used to update the resource.</p></div> -<div class="paragraph"><p>PUT is used to create a new resource (when it doesn’t -already exist) or replace the resource.</p></div> -<div class="paragraph"><p>DELETE is used to delete the resource.</p></div> -<div class="paragraph"><p>PATCH is used to modify the resource using -instructions given in the request body. A PATCH -operation is atomic. The PATCH operation may -be used for adding, removing or modifying specific -values in the resource.</p></div> -</div> -</div> -<div class="sect1"> +<p>Skip this section if you are doing a collection.</p> +<p>What methods should I implement?</p> +<p>OPTIONS is used to get some information about the resource. It is recommended to allow it even if you do not implement it, as Cowboy has a default implementation built-in.</p> +<p>HEAD and GET are used to retrieve the resource. If you allow GET, also allow HEAD as there's no extra work required to make it work.</p> +<p>POST is used to update the resource.</p> +<p>PUT is used to create a new resource (when it doesn't already exist) or replace the resource.</p> +<p>DELETE is used to delete the resource.</p> +<p>PATCH is used to modify the resource using instructions given in the request body. A PATCH operation is atomic. The PATCH operation may be used for adding, removing or modifying specific values in the resource.</p> <h2 id="_the_resource">The resource</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Following the above discussion, implement the -<code>allowed_methods</code> callback.</p></div> -<div class="paragraph"><p>Does the resource always exist? If it may not, implement -the <code>resource_exists</code> callback.</p></div> -<div class="paragraph"><p>Do I need to authenticate the client before they can -access the resource? What authentication mechanisms -should I provide? This may include form-based, token-based -(in the URL or a cookie), HTTP basic, HTTP digest, -SSL certificate or any other form of authentication. -Implement the <code>is_authorized</code> callback.</p></div> -<div class="paragraph"><p>Do I need fine-grained access control? How do I determine -that they are authorized access? Handle that in your -<code>is_authorized</code> callback.</p></div> -<div class="paragraph"><p>Can access to a resource be forbidden regardless of access -being authorized? A simple example of that is censorship -of a resource. Implement the <code>forbidden</code> callback.</p></div> -<div class="paragraph"><p>Are there any constraints on the length of the resource URI? -For example, the URI may be used as a key in storage and may -have a limit in length. Implement <code>uri_too_long</code>.</p></div> -</div> -</div> -<div class="sect1"> +<p>Following the above discussion, implement the <code>allowed_methods</code> callback.</p> +<p>Does the resource always exist? If it may not, implement the <code>resource_exists</code> callback.</p> +<p>Do I need to authenticate the client before they can access the resource? What authentication mechanisms should I provide? This may include form-based, token-based (in the URL or a cookie), HTTP basic, HTTP digest, SSL certificate or any other form of authentication. Implement the <code>is_authorized</code> callback.</p> +<p>Do I need fine-grained access control? How do I determine that they are authorized access? Handle that in your <code>is_authorized</code> callback.</p> +<p>Can access to a resource be forbidden regardless of access being authorized? A simple example of that is censorship of a resource. Implement the <code>forbidden</code> callback.</p> +<p>Are there any constraints on the length of the resource URI? For example, the URI may be used as a key in storage and may have a limit in length. Implement <code>uri_too_long</code>.</p> <h2 id="_representations">Representations</h2> -<div class="sectionbody"> -<div class="paragraph"><p>What media types do I provide? If text based, what charsets -are provided? What languages do I provide?</p></div> -<div class="paragraph"><p>Implement the mandatory <code>content_types_provided</code>. Prefix -the callbacks with <code>to_</code> for clarity. For example, <code>to_html</code> -or <code>to_text</code>.</p></div> -<div class="paragraph"><p>Implement the <code>languages_provided</code> or <code>charsets_provided</code> -callbacks if applicable.</p></div> -<div class="paragraph"><p>Is there any other header that may make the representation -of the resource vary? Implement the <code>variances</code> callback.</p></div> -<div class="paragraph"><p>Depending on your choices for caching content, you may -want to implement one or more of the <code>generate_etag</code>, -<code>last_modified</code> and <code>expires</code> callbacks.</p></div> -<div class="paragraph"><p>Do I want the user or user agent to actively choose a -representation available? Send a list of available -representations in the response body and implement -the <code>multiple_choices</code> callback.</p></div> -</div> -</div> -<div class="sect1"> +<p>What media types do I provide? If text based, what charsets are provided? What languages do I provide?</p> +<p>Implement the mandatory <code>content_types_provided</code>. Prefix the callbacks with <code>to_</code> for clarity. For example, <code>to_html</code> or <code>to_text</code>.</p> +<p>Implement the <code>languages_provided</code> or <code>charsets_provided</code> callbacks if applicable.</p> +<p>Is there any other header that may make the representation of the resource vary? Implement the <code>variances</code> callback.</p> +<p>Depending on your choices for caching content, you may want to implement one or more of the <code>generate_etag</code>, <code>last_modified</code> and <code>expires</code> callbacks.</p> +<p>Do I want the user or user agent to actively choose a representation available? Send a list of available representations in the response body and implement the <code>multiple_choices</code> callback.</p> <h2 id="_redirections">Redirections</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Do I need to keep track of what resources were deleted? -For example, you may have a mechanism where moving a -resource leaves a redirect link to its new location. -Implement the <code>previously_existed</code> callback.</p></div> -<div class="paragraph"><p>Was the resource moved, and is the move temporary? If -it is explicitly temporary, for example due to maintenance, -implement the <code>moved_temporarily</code> callback. Otherwise, -implement the <code>moved_permanently</code> callback.</p></div> -</div> -</div> -<div class="sect1"> +<p>Do I need to keep track of what resources were deleted? For example, you may have a mechanism where moving a resource leaves a redirect link to its new location. Implement the <code>previously_existed</code> callback.</p> +<p>Was the resource moved, and is the move temporary? If it is explicitly temporary, for example due to maintenance, implement the <code>moved_temporarily</code> callback. Otherwise, implement the <code>moved_permanently</code> callback.</p> <h2 id="_the_request">The request</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Do you need to read the query string? Individual headers? -Implement <code>malformed_request</code> and do all the parsing and -validation in this function. Note that the body should not -be read at this point.</p></div> -<div class="paragraph"><p>May there be a request body? Will I know its size? -What’s the maximum size of the request body I’m willing -to accept? Implement <code>valid_entity_length</code>.</p></div> -<div class="paragraph"><p>Finally, take a look at the sections corresponding to the -methods you are implementing.</p></div> -</div> -</div> -<div class="sect1"> +<p>Do you need to read the query string? Individual headers? Implement <code>malformed_request</code> and do all the parsing and validation in this function. Note that the body should not be read at this point.</p> +<p>May there be a request body? Will I know its size? What's the maximum size of the request body I'm willing to accept? Implement <code>valid_entity_length</code>.</p> +<p>Finally, take a look at the sections corresponding to the methods you are implementing.</p> <h2 id="_options_method">OPTIONS method</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy by default will send back a list of allowed methods. -Do I need to add more information to the response? Implement -the <code>options</code> method.</p></div> -</div> -</div> -<div class="sect1"> +<p>Cowboy by default will send back a list of allowed methods. Do I need to add more information to the response? Implement the <code>options</code> method.</p> <h2 id="_get_and_head_methods">GET and HEAD methods</h2> -<div class="sectionbody"> -<div class="paragraph"><p>If you implement the methods GET and/or HEAD, you must -implement one <code>ProvideResource</code> callback for each -content-type returned by the <code>content_types_provided</code> -callback.</p></div> -</div> -</div> -<div class="sect1"> -<h2 id="_put_post_and_patch_methods">PUT, POST and PATCH methods</h2> -<div class="sectionbody"> -<div class="paragraph"><p>If you implement the methods PUT, POST and/or PATCH, -you must implement the <code>content_types_accepted</code> callback, -and one <code>AcceptCallback</code> callback for each content-type -it returns. Prefix the <code>AcceptCallback</code> callback names -with <code>from_</code> for clarity. For example, <code>from_html</code> or -<code>from_json</code>.</p></div> -<div class="paragraph"><p>Do we want to allow the POST method to create individual -resources directly through their URI (like PUT)? Implement -the <code>allow_missing_post</code> callback. It is recommended to -explicitly use PUT in these cases instead.</p></div> -<div class="paragraph"><p>May there be conflicts when using PUT to create or replace -a resource? Do we want to make sure that two updates around -the same time are not cancelling one another? Implement the -<code>is_conflict</code> callback.</p></div> -</div> -</div> -<div class="sect1"> +<p>If you implement the methods GET and/or HEAD, you must implement one <code>ProvideResource</code> callback for each content-type returned by the <code>content_types_provided</code> callback.</p> +<h2 id="_put__post_and_patch_methods">PUT, POST and PATCH methods</h2> +<p>If you implement the methods PUT, POST and/or PATCH, you must implement the <code>content_types_accepted</code> callback, and one <code>AcceptCallback</code> callback for each content-type it returns. Prefix the <code>AcceptCallback</code> callback names with <code>from_</code> for clarity. For example, <code>from_html</code> or <code>from_json</code>.</p> +<p>Do we want to allow the POST method to create individual resources directly through their URI (like PUT)? Implement the <code>allow_missing_post</code> callback. It is recommended to explicitly use PUT in these cases instead.</p> +<p>May there be conflicts when using PUT to create or replace a resource? Do we want to make sure that two updates around the same time are not cancelling one another? Implement the <code>is_conflict</code> callback.</p> <h2 id="_delete_methods">DELETE methods</h2> -<div class="sectionbody"> -<div class="paragraph"><p>If you implement the method DELETE, you must implement -the <code>delete_resource</code> callback.</p></div> -<div class="paragraph"><p>When <code>delete_resource</code> returns, is the resource completely -removed from the server, including from any caching service? -If not, and/or if the deletion is asynchronous and we have -no way of knowing it has been completed yet, implement the -<code>delete_completed</code> callback.</p></div> -</div> -</div> +<p>If you implement the method DELETE, you must implement the <code>delete_resource</code> callback.</p> +<p>When <code>delete_resource</code> returns, is the resource completely removed from the server, including from any caching service? If not, and/or if the deletion is asynchronous and we have no way of knowing it has been completed yet, implement the <code>delete_completed</code> callback.</p> + diff --git a/docs/en/cowboy/2.3/guide/resp/index.html b/docs/en/cowboy/2.3/guide/resp/index.html index bc1a04ea..2fb3f064 100644 --- a/docs/en/cowboy/2.3/guide/resp/index.html +++ b/docs/en/cowboy/2.3/guide/resp/index.html @@ -62,373 +62,249 @@ <h1 class="lined-header"><span>Sending a response</span></h1> -<div class="paragraph"><p>The response must be sent using the Req object.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>Cowboy also provides a simplified interface for sending -files. It can also send only specific parts of a file.</p></div> -<div class="paragraph"><p>While only one response is allowed for every request, -HTTP/2 introduced a mechanism that allows the server -to push additional resources related to the response. -This chapter also describes how this feature works in -Cowboy.</p></div> -<div class="sect1"> +<p>The response must be sent using the Req object.</p> +<p>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.</p> +<p>Cowboy also provides a simplified interface for sending files. It can also send only specific parts of a file.</p> +<p>While only one response is allowed for every request, HTTP/2 introduced a mechanism that allows the server to push additional resources related to the response. This chapter also describes how this feature works in Cowboy.</p> <h2 id="_reply">Reply</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy provides three functions for sending the entire reply, -depending on whether you need to set headers and body. In all -cases, Cowboy will add any headers required by the protocol -(for example the date header will always be sent).</p></div> -<div class="paragraph"><p>When you need to set only the status code, -use <code>cowboy_req:reply/2</code>:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy provides three functions for sending the entire reply, depending on whether you need to set headers and body. In all cases, Cowboy will add any headers required by the protocol (for example the date header will always be sent).</p> +<p>When you need to set only the status code, use <code>cowboy_req:reply/2</code>:</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">200</span>, <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>When you need to set response headers at the same time, -use <code>cowboy_req:reply/3</code>:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">200</font>, <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>When you need to set response headers at the same time, use <code>cowboy_req:reply/3</code>:</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">303</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"location"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"https://ninenines.eu"</span><span style="color: #990000">>></span> -}, <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Note that the header name must always be a lowercase -binary.</p></div> -<div class="paragraph"><p>When you also need to set the response body, -use <code>cowboy_req:reply/4</code>:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">303</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"location"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"https://ninenines.eu"</font><font color="#990000">>></font> +}, <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Note that the header name must always be a lowercase binary.</p> +<p>When you also need to set the response body, use <code>cowboy_req:reply/4</code>:</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">200</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"text/plain"</span><span style="color: #990000">>></span> -}, <span style="color: #FF0000">"Hello world!"</span>, <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>You should always set the content-type header when the -response has a body. There is however no need to set -the content-length header; Cowboy does it automatically.</p></div> -<div class="paragraph"><p>The response body and the header values must be either -a binary or an iolist. An iolist is a list containing -binaries, characters, strings or other iolists. This -allows you to build a response from different parts -without having to do any concatenation:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">200</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"text/plain"</font><font color="#990000">>></font> +}, <font color="#FF0000">"Hello world!"</font>, <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>You should always set the content-type header when the response has a body. There is however no need to set the content-length header; Cowboy does it automatically.</p> +<p>The response body and the header values must be either a binary or an iolist. An iolist is a list containing binaries, characters, strings or other iolists. This allows you to build a response from different parts without having to do any concatenation:</p> +<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><span style="color: #009900">Title</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"Hello world!"</span>, -<span style="color: #009900">Body</span> <span style="color: #990000">=</span> <span style="color: #990000"><<</span><span style="color: #FF0000">"Hats off!"</span><span style="color: #990000">>></span>, -<span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">200</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"text/html"</span><span style="color: #990000">>></span> -}, [<span style="color: #FF0000">"<html><head><title>"</span>, <span style="color: #009900">Title</span>, <span style="color: #FF0000">"</title></head>"</span>, - <span style="color: #FF0000">"<body><p>"</span>, <span style="color: #009900">Body</span>, <span style="color: #FF0000">"</p></body></html>"</span>], <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>This method of building responses is more efficient than -concatenating. Behind the scenes, each element of the list -is simply a pointer, and those pointers are used directly -when writing to the socket.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">Title</font> <font color="#990000">=</font> <font color="#FF0000">"Hello world!"</font>, +<font color="#009900">Body</font> <font color="#990000">=</font> <font color="#990000"><<</font><font color="#FF0000">"Hats off!"</font><font color="#990000">>></font>, +<font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">200</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"text/html"</font><font color="#990000">>></font> +}, [<font color="#FF0000">"<html><head><title>"</font>, <font color="#009900">Title</font>, <font color="#FF0000">"</title></head>"</font>, + <font color="#FF0000">"<body><p>"</font>, <font color="#009900">Body</font>, <font color="#FF0000">"</p></body></html>"</font>], <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>This method of building responses is more efficient than concatenating. Behind the scenes, each element of the list is simply a pointer, and those pointers are used directly when writing to the socket.</p> <h2 id="_stream_reply">Stream reply</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy provides two functions for initiating a response, -and an additional function for streaming the response body. -Cowboy will add any required headers to the response.</p></div> -<div class="paragraph"><p>When you need to set only the status code, -use <code>cowboy_req:stream_reply/2</code>:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy provides two functions for initiating a response, and an additional function for streaming the response body. Cowboy will add any required headers to the response.</p> +<!-- @todo For HTTP/1.1 Cowboy should probably not use chunked transfer-encoding if the content-length is set.--> +<p>When you need to set only the status code, use <code>cowboy_req:stream_reply/2</code>:</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_reply</span></span>(<span style="color: #993399">200</span>, <span style="color: #009900">Req0</span>), - -<span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_body</span></span>(<span style="color: #FF0000">"Hello..."</span>, <span style="color: #FF6600">nofin</span>, <span style="color: #009900">Req</span>), -<span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_body</span></span>(<span style="color: #FF0000">"chunked..."</span>, <span style="color: #FF6600">nofin</span>, <span style="color: #009900">Req</span>), -<span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_body</span></span>(<span style="color: #FF0000">"world!!"</span>, <span style="color: #FF6600">fin</span>, <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>The second argument to <code>cowboy_req:stream_body/3</code> indicates -whether this data terminates the body. Use <code>fin</code> for the -final flag, and <code>nofin</code> otherwise.</p></div> -<div class="paragraph"><p>This snippet does not set a content-type header. This is -not recommended. All responses with a body should have -a content-type. The header can be set beforehand, or -using the <code>cowboy_req:stream_reply/3</code>:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:stream_reply</font></b>(<font color="#993399">200</font>, <font color="#009900">Req0</font>), + +<b><font color="#000000">cowboy_req:stream_body</font></b>(<font color="#FF0000">"Hello..."</font>, <font color="#FF6600">nofin</font>, <font color="#009900">Req</font>), +<b><font color="#000000">cowboy_req:stream_body</font></b>(<font color="#FF0000">"chunked..."</font>, <font color="#FF6600">nofin</font>, <font color="#009900">Req</font>), +<b><font color="#000000">cowboy_req:stream_body</font></b>(<font color="#FF0000">"world!!"</font>, <font color="#FF6600">fin</font>, <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>The second argument to <code>cowboy_req:stream_body/3</code> indicates whether this data terminates the body. Use <code>fin</code> for the final flag, and <code>nofin</code> otherwise.</p> +<p>This snippet does not set a content-type header. This is not recommended. All responses with a body should have a content-type. The header can be set beforehand, or using the <code>cowboy_req:stream_reply/3</code>:</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_reply</span></span>(<span style="color: #993399">200</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"text/html"</span><span style="color: #990000">>></span> -}, <span style="color: #009900">Req0</span>), - -<span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_body</span></span>(<span style="color: #FF0000">"<html><head>Hello world!</head>"</span>, <span style="color: #FF6600">nofin</span>, <span style="color: #009900">Req</span>), -<span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_body</span></span>(<span style="color: #FF0000">"<body><p>Hats off!</p></body></html>"</span>, <span style="color: #FF6600">fin</span>, <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>HTTP provides a few different ways to stream response bodies. -Cowboy will select the most appropriate one based on the HTTP -version and the request and response headers.</p></div> -<div class="paragraph"><p>While not required by any means, it is recommended that you -set the content-length header in the response if you know it -in advance. This will ensure that the best response method -is selected and help clients understand when the response -is fully received.</p></div> -<div class="paragraph"><p>Cowboy also provides a function to send response trailers. -Response trailers are semantically equivalent to the headers -you send in the response, only they are sent at the end. -This is especially useful to attach information to the -response that could not be generated until the response -body was fully generated.</p></div> -<div class="paragraph"><p>Trailer fields must be listed in the trailer header. Any -field not listed might be dropped by the client or an intermediary.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:stream_reply</font></b>(<font color="#993399">200</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"text/html"</font><font color="#990000">>></font> +}, <font color="#009900">Req0</font>), + +<b><font color="#000000">cowboy_req:stream_body</font></b>(<font color="#FF0000">"<html><head>Hello world!</head>"</font>, <font color="#FF6600">nofin</font>, <font color="#009900">Req</font>), +<b><font color="#000000">cowboy_req:stream_body</font></b>(<font color="#FF0000">"<body><p>Hats off!</p></body></html>"</font>, <font color="#FF6600">fin</font>, <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>HTTP provides a few different ways to stream response bodies. Cowboy will select the most appropriate one based on the HTTP version and the request and response headers.</p> +<p>While not required by any means, it is recommended that you set the content-length header in the response if you know it in advance. This will ensure that the best response method is selected and help clients understand when the response is fully received.</p> +<p>Cowboy also provides a function to send response trailers. Response trailers are semantically equivalent to the headers you send in the response, only they are sent at the end. This is especially useful to attach information to the response that could not be generated until the response body was fully generated.</p> +<p>Trailer fields must be listed in the trailer header. Any field not listed might be dropped by the client or an intermediary.</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_reply</span></span>(<span style="color: #993399">200</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"text/html"</span><span style="color: #990000">>></span>, - <span style="color: #990000"><<</span><span style="color: #FF0000">"trailer"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"expires, content-md5"</span><span style="color: #990000">>></span> -}, <span style="color: #009900">Req0</span>), - -<span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_body</span></span>(<span style="color: #FF0000">"<html><head>Hello world!</head>"</span>, <span style="color: #FF6600">nofin</span>, <span style="color: #009900">Req</span>), -<span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_body</span></span>(<span style="color: #FF0000">"<body><p>Hats off!</p></body></html>"</span>, <span style="color: #FF6600">nofin</span>, <span style="color: #009900">Req</span>), - -<span style="font-weight: bold"><span style="color: #000000">cowboy_req:stream_trailers</span></span>(#{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"expires"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"Sun, 10 Dec 2017 19:13:47 GMT"</span><span style="color: #990000">>></span>, - <span style="color: #990000"><<</span><span style="color: #FF0000">"content-md5"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"c6081d20ff41a42ce17048ed1c0345e2"</span><span style="color: #990000">>></span> -}, <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>The stream ends with trailers. It is no longer possible to -send data after sending trailers. You cannot send trailers -after setting the <code>fin</code> flag when streaming the body.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:stream_reply</font></b>(<font color="#993399">200</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"text/html"</font><font color="#990000">>></font>, + <font color="#990000"><<</font><font color="#FF0000">"trailer"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"expires, content-md5"</font><font color="#990000">>></font> +}, <font color="#009900">Req0</font>), + +<b><font color="#000000">cowboy_req:stream_body</font></b>(<font color="#FF0000">"<html><head>Hello world!</head>"</font>, <font color="#FF6600">nofin</font>, <font color="#009900">Req</font>), +<b><font color="#000000">cowboy_req:stream_body</font></b>(<font color="#FF0000">"<body><p>Hats off!</p></body></html>"</font>, <font color="#FF6600">nofin</font>, <font color="#009900">Req</font>), + +<b><font color="#000000">cowboy_req:stream_trailers</font></b>(#{ + <font color="#990000"><<</font><font color="#FF0000">"expires"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"Sun, 10 Dec 2017 19:13:47 GMT"</font><font color="#990000">>></font>, + <font color="#990000"><<</font><font color="#FF0000">"content-md5"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"c6081d20ff41a42ce17048ed1c0345e2"</font><font color="#990000">>></font> +}, <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>The stream ends with trailers. It is no longer possible to send data after sending trailers. You cannot send trailers after setting the <code>fin</code> flag when streaming the body.</p> <h2 id="_preset_response_headers">Preset response headers</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy provides functions to set response headers without -immediately sending them. They are stored in the Req object -and sent as part of the response when a reply function is -called.</p></div> -<div class="paragraph"><p>To set response headers:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy provides functions to set response headers without immediately sending them. They are stored in the Req object and sent as part of the response when a reply function is called.</p> +<p>To set response headers:</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:set_resp_header</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"allow"</span><span style="color: #990000">>></span>, <span style="color: #FF0000">"GET"</span>, <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Header names must be a lowercase binary.</p></div> -<div class="paragraph"><p>Do not use this function for setting cookies. Refer to -the <a href="../cookies">Cookies</a> chapter for more information.</p></div> -<div class="paragraph"><p>To check if a response header has already been set:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:set_resp_header</font></b>(<font color="#990000"><<</font><font color="#FF0000">"allow"</font><font color="#990000">>></font>, <font color="#FF0000">"GET"</font>, <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Header names must be a lowercase binary.</p> +<p>Do not use this function for setting cookies. Refer to the <a href="../cookies">Cookies</a> chapter for more information.</p> +<p>To check if a response header has already been set:</p> +<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><span style="font-weight: bold"><span style="color: #000000">cowboy_req:has_resp_header</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"allow"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>It returns <code>true</code> if the header was set, <code>false</code> otherwise.</p></div> -<div class="paragraph"><p>To delete a response header that was set previously:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">cowboy_req:has_resp_header</font></b>(<font color="#990000"><<</font><font color="#FF0000">"allow"</font><font color="#990000">>></font>, <font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>It returns <code>true</code> if the header was set, <code>false</code> otherwise.</p> +<p>To delete a response header that was set previously:</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:delete_resp_header</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"allow"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:delete_resp_header</font></b>(<font color="#990000"><<</font><font color="#FF0000">"allow"</font><font color="#990000">>></font>, <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_overriding_headers">Overriding headers</h2> -<div class="sectionbody"> -<div class="paragraph"><p>As Cowboy provides different ways of setting response -headers and body, clashes may occur, so it’s important -to understand what happens when a header is set twice.</p></div> -<div class="paragraph"><p>Headers come from five different origins:</p></div> -<div class="ulist"><ul> -<li> -<p> -Protocol-specific headers (for example HTTP/1.1’s connection header) -</p> +<p>As Cowboy provides different ways of setting response headers and body, clashes may occur, so it's important to understand what happens when a header is set twice.</p> +<p>Headers come from five different origins:</p> +<ul><li>Protocol-specific headers (for example HTTP/1.1's connection header) </li> -<li> -<p> -Other required headers (for example the date header) -</p> +<li>Other required headers (for example the date header) </li> -<li> -<p> -Preset headers -</p> +<li>Preset headers </li> -<li> -<p> -Headers given to the reply function -</p> +<li>Headers given to the reply function </li> -<li> -<p> -Set-cookie headers -</p> +<li>Set-cookie headers </li> -</ul></div> -<div class="paragraph"><p>Cowboy does not allow overriding protocol-specific headers.</p></div> -<div class="paragraph"><p>Set-cookie headers will always be appended at the end of -the list of headers before sending the response.</p></div> -<div class="paragraph"><p>Headers given to the reply function will always override -preset headers and required headers. If a header is found -in two or three of these, then the one in the reply function -is picked and the others are dropped.</p></div> -<div class="paragraph"><p>Similarly, preset headers will always override required -headers.</p></div> -<div class="paragraph"><p>To illustrate, look at the following snippet. Cowboy by -default sends the server header with the value "Cowboy". -We can override it:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +</ul> +<p>Cowboy does not allow overriding protocol-specific headers.</p> +<p>Set-cookie headers will always be appended at the end of the list of headers before sending the response.</p> +<p>Headers given to the reply function will always override preset headers and required headers. If a header is found in two or three of these, then the one in the reply function is picked and the others are dropped.</p> +<p>Similarly, preset headers will always override required headers.</p> +<p>To illustrate, look at the following snippet. Cowboy by default sends the server header with the value "Cowboy". We can override it:</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">200</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"server"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"yaws"</span><span style="color: #990000">>></span> -}, <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">200</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"server"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"yaws"</font><font color="#990000">>></font> +}, <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_preset_response_body">Preset response body</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy provides functions to set the response body without -immediately sending it. It is stored in the Req object and -sent when the reply function is called.</p></div> -<div class="paragraph"><p>To set the response body:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy provides functions to set the response body without immediately sending it. It is stored in the Req object and sent when the reply function is called.</p> +<p>To set the response body:</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:set_resp_body</span></span>(<span style="color: #FF0000">"Hello world!"</span>, <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>To check if a response body has already been set:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:set_resp_body</font></b>(<font color="#FF0000">"Hello world!"</font>, <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<!-- @todo Yeah we probably should add that function that--> +<!-- also sets the content-type at the same time...--> +<p>To check if a response body has already been set:</p> +<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><span style="font-weight: bold"><span style="color: #000000">cowboy_req:has_resp_body</span></span>(<span style="color: #009900">Req</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>It returns <code>true</code> if the body was set and is non-empty, -<code>false</code> otherwise.</p></div> -<div class="paragraph"><p>The preset response body is only sent if the reply function -used is <code>cowboy_req:reply/2</code> or <code>cowboy_req:reply/3</code>.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">cowboy_req:has_resp_body</font></b>(<font color="#009900">Req</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>It returns <code>true</code> if the body was set and is non-empty, <code>false</code> otherwise.</p> +<!-- @todo We probably should also have a function that--> +<!-- properly removes the response body, including any--> +<!-- content-* headers.--> +<p>The preset response body is only sent if the reply function used is <code>cowboy_req:reply/2</code> or <code>cowboy_req:reply/3</code>.</p> <h2 id="_sending_files">Sending files</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy provides a shortcut for sending files. When -using <code>cowboy_req:reply/4</code>, or when presetting the -response header, you can give a <code>sendfile</code> tuple to -Cowboy:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy provides a shortcut for sending files. When using <code>cowboy_req:reply/4</code>, or when presetting the response header, you can give a <code>sendfile</code> tuple to Cowboy:</p> +<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>{<span style="color: #FF6600">sendfile</span>, <span style="color: #009900">Offset</span>, <span style="color: #009900">Length</span>, <span style="color: #009900">Filename</span>}</tt></pre></div></div> -<div class="paragraph"><p>Depending on the values for <code>Offset</code> or <code>Length</code>, the -entire file may be sent, or just a part of it.</p></div> -<div class="paragraph"><p>The length is required even for sending the entire file. -Cowboy sends it in the content-length header.</p></div> -<div class="paragraph"><p>To send a file while replying:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>{<font color="#FF6600">sendfile</font>, <font color="#009900">Offset</font>, <font color="#009900">Length</font>, <font color="#009900">Filename</font>}</tt></pre> +</div></div> +<p>Depending on the values for <code>Offset</code> or <code>Length</code>, the entire file may be sent, or just a part of it.</p> +<p>The length is required even for sending the entire file. Cowboy sends it in the content-length header.</p> +<p>To send a file while replying:</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">200</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #FF0000">"image/png"</span> -}, {<span style="color: #FF6600">sendfile</span>, <span style="color: #993399">0</span>, <span style="color: #993399">12345</span>, <span style="color: #FF0000">"path/to/logo.png"</span>}, <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">200</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#FF0000">"image/png"</font> +}, {<font color="#FF6600">sendfile</font>, <font color="#993399">0</font>, <font color="#993399">12345</font>, <font color="#FF0000">"path/to/logo.png"</font>}, <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<!-- @todo An example of presetting a file would be useful,--> +<!-- but let's wait for the function that can set the--> +<!-- content-type at the same time.--> +<!-- @todo What about streaming many files? For example--> +<!-- it should be possible to build a tar file on the fly--> +<!-- while still using sendfile. Another example could be--> +<!-- proper support for multipart byte ranges. Yet another--> +<!-- example would be automatic concatenation of CSS or JS--> +<!-- files.--> <h2 id="_informational_responses">Informational responses</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy allows you to send informational responses.</p></div> -<div class="paragraph"><p>Informational responses are responses that have a status -code between 100 and 199. Any number can be sent before -the proper response. Sending an informational response -does not change the behavior of the proper response, and -clients are expected to ignore any informational response -they do not understand.</p></div> -<div class="paragraph"><p>The following snippet sends a 103 informational response -with some headers that are expected to be in the final -response.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy allows you to send informational responses.</p> +<p>Informational responses are responses that have a status code between 100 and 199. Any number can be sent before the proper response. Sending an informational response does not change the behavior of the proper response, and clients are expected to ignore any informational response they do not understand.</p> +<p>The following snippet sends a 103 informational response with some headers that are expected to be in the final response.</p> +<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><span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:inform</span></span>(<span style="color: #993399">103</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"link"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"</style.css>; rel=preload; as=style, </script.js>; rel=preload; as=script"</span><span style="color: #990000">>></span> -}, <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:inform</font></b>(<font color="#993399">103</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"link"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"</style.css>; rel=preload; as=style, </script.js>; rel=preload; as=script"</font><font color="#990000">>></font> +}, <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_push">Push</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The HTTP/2 protocol introduced the ability to push resources -related to the one sent in the response. Cowboy provides two -functions for that purpose: <code>cowboy_req:push/3,4</code>.</p></div> -<div class="paragraph"><p>Push is only available for HTTP/2. Cowboy will automatically -ignore push requests if the protocol doesn’t support it.</p></div> -<div class="paragraph"><p>The push function must be called before any of the reply -functions. Doing otherwise will result in a crash.</p></div> -<div class="paragraph"><p>To push a resource, you need to provide the same information -as a client performing a request would. This includes the -HTTP method, the URI and any necessary request headers.</p></div> -<div class="paragraph"><p>Cowboy by default only requires you to give the path to -the resource and the request headers. The rest of the URI -is taken from the current request (excluding the query -string, set to empty) and the method is GET by default.</p></div> -<div class="paragraph"><p>The following snippet pushes a CSS file that is linked to -in the response:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The HTTP/2 protocol introduced the ability to push resources related to the one sent in the response. Cowboy provides two functions for that purpose: <code>cowboy_req:push/3,4</code>.</p> +<p>Push is only available for HTTP/2. Cowboy will automatically ignore push requests if the protocol doesn't support it.</p> +<p>The push function must be called before any of the reply functions. Doing otherwise will result in a crash.</p> +<p>To push a resource, you need to provide the same information as a client performing a request would. This includes the HTTP method, the URI and any necessary request headers.</p> +<p>Cowboy by default only requires you to give the path to the resource and the request headers. The rest of the URI is taken from the current request (excluding the query string, set to empty) and the method is GET by default.</p> +<p>The following snippet pushes a CSS file that is linked to in the response:</p> +<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><span style="font-weight: bold"><span style="color: #000000">cowboy_req:push</span></span>(<span style="color: #FF0000">"/static/style.css"</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"accept"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"text/css"</span><span style="color: #990000">>></span> -}, <span style="color: #009900">Req0</span>), -<span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">200</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"content-type"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"text/html"</span><span style="color: #990000">>></span> -}, [<span style="color: #FF0000">"<html><head><title>My web page</title>"</span>, - <span style="color: #FF0000">"<link rel='stylesheet' type='text/css' href='/static/style.css'>"</span>, - <span style="color: #FF0000">"<body><p>Welcome to Erlang!</p></body></html>"</span>], <span style="color: #009900">Req0</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>To override the method, scheme, host, port or query string, -simply pass in a fourth argument. The following snippet -uses a different host name:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">cowboy_req:push</font></b>(<font color="#FF0000">"/static/style.css"</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"accept"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"text/css"</font><font color="#990000">>></font> +}, <font color="#009900">Req0</font>), +<font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">200</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"content-type"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"text/html"</font><font color="#990000">>></font> +}, [<font color="#FF0000">"<html><head><title>My web page</title>"</font>, + <font color="#FF0000">"<link rel='stylesheet' type='text/css' href='/static/style.css'>"</font>, + <font color="#FF0000">"<body><p>Welcome to Erlang!</p></body></html>"</font>], <font color="#009900">Req0</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>To override the method, scheme, host, port or query string, simply pass in a fourth argument. The following snippet uses a different host name:</p> +<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><span style="font-weight: bold"><span style="color: #000000">cowboy_req:push</span></span>(<span style="color: #FF0000">"/static/style.css"</span>, #{ - <span style="color: #990000"><<</span><span style="color: #FF0000">"accept"</span><span style="color: #990000">>></span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"text/css"</span><span style="color: #990000">>></span> -}, #{<span style="color: #0000FF">host</span> <span style="color: #990000">=></span> <span style="color: #990000"><<</span><span style="color: #FF0000">"cdn.example.org"</span><span style="color: #990000">>></span>}, <span style="color: #009900">Req</span>),</tt></pre></div></div> -<div class="paragraph"><p>Pushed resources don’t have to be files. As long as the push -request is cacheable, safe and does not include a body, the -resource can be pushed.</p></div> -<div class="paragraph"><p>Under the hood, Cowboy handles pushed requests the same as -normal requests: a different process is created which will -ultimately send a response to the client.</p></div> -</div> -</div> +<pre><tt><b><font color="#000000">cowboy_req:push</font></b>(<font color="#FF0000">"/static/style.css"</font>, #{ + <font color="#990000"><<</font><font color="#FF0000">"accept"</font><font color="#990000">>></font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"text/css"</font><font color="#990000">>></font> +}, #{<font color="#0000FF">host</font> <font color="#990000">=></font> <font color="#990000"><<</font><font color="#FF0000">"cdn.example.org"</font><font color="#990000">>></font>}, <font color="#009900">Req</font>),</tt></pre> +</div></div> +<p>Pushed resources don't have to be files. As long as the push request is cacheable, safe and does not include a body, the resource can be pushed.</p> +<p>Under the hood, Cowboy handles pushed requests the same as normal requests: a different process is created which will ultimately send a response to the client.</p> + diff --git a/docs/en/cowboy/2.3/guide/rest_flowcharts/index.html b/docs/en/cowboy/2.3/guide/rest_flowcharts/index.html index 7951c237..698e74db 100644 --- a/docs/en/cowboy/2.3/guide/rest_flowcharts/index.html +++ b/docs/en/cowboy/2.3/guide/rest_flowcharts/index.html @@ -62,244 +62,64 @@ <h1 class="lined-header"><span>REST flowcharts</span></h1> -<div class="paragraph"><p>This chapter will explain the REST handler state machine through -a number of different diagrams.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>All paths start with the "Start" diagram, and all paths excluding -the OPTIONS path go through the "Content negotiation" diagram -and optionally the "Conditional requests" diagram if the resource -exists.</p></div> -<div class="paragraph"><p>The red squares refer to another diagram. The light green squares -indicate a response. Other squares may be either a callback or a -question answered by Cowboy itself. Green arrows tend to indicate -the default behavior if the callback is undefined.</p></div> -<div class="sect1"> +<p>This chapter will explain the REST handler state machine through a number of different diagrams.</p> +<p>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.</p> +<p>All paths start with the "Start" diagram, and all paths excluding the OPTIONS path go through the "Content negotiation" diagram and optionally the "Conditional requests" diagram if the resource exists.</p> +<p>The red squares refer to another diagram. The light green squares indicate a response. Other squares may be either a callback or a question answered by Cowboy itself. Green arrows tend to indicate the default behavior if the callback is undefined.</p> <h2 id="_start">Start</h2> -<div class="sectionbody"> -<div class="paragraph"><p>All requests start from here.</p></div> -<div class="imageblock"> -<div class="content"> -<img src="../rest_start.png" alt="REST starting flowchart" /> -</div> -</div> -<div class="paragraph"><p>A series of callbacks are called in succession to perform -a general checkup of the service, the request line and -request headers.</p></div> -<div class="paragraph"><p>The request body, if any, is not expected to have been -received for any of these steps. It is only processed -at the end of the "PUT, POST and PATCH methods" diagram, -when all conditions have been met.</p></div> -<div class="paragraph"><p>The <code>known_methods</code> and <code>allowed_methods</code> callbacks -return a list of methods. Cowboy then checks if the request -method is in the list, and stops otherwise.</p></div> -<div class="paragraph"><p>The <code>is_authorized</code> callback may be used to check that -access to the resource is authorized. Authentication -may also be performed as needed. When authorization is -denied, the return value from the callback must include -a challenge applicable to the requested resource, which -will be sent back to the client in the www-authenticate -header.</p></div> -<div class="paragraph"><p>This diagram is immediately followed by either the -"OPTIONS method" diagram when the request method is -OPTIONS, or the "Content negotiation" diagram otherwise.</p></div> -</div> -</div> -<div class="sect1"> +<p>All requests start from here.</p> +<img src="../rest_start.png" alt="REST starting flowchart"/><p>A series of callbacks are called in succession to perform a general checkup of the service, the request line and request headers.</p> +<p>The request body, if any, is not expected to have been received for any of these steps. It is only processed at the end of the "PUT, POST and PATCH methods" diagram, when all conditions have been met.</p> +<p>The <code>known_methods</code> and <code>allowed_methods</code> callbacks return a list of methods. Cowboy then checks if the request method is in the list, and stops otherwise.</p> +<p>The <code>is_authorized</code> callback may be used to check that access to the resource is authorized. Authentication may also be performed as needed. When authorization is denied, the return value from the callback must include a challenge applicable to the requested resource, which will be sent back to the client in the www-authenticate header.</p> +<p>This diagram is immediately followed by either the "OPTIONS method" diagram when the request method is OPTIONS, or the "Content negotiation" diagram otherwise.</p> <h2 id="_options_method">OPTIONS method</h2> -<div class="sectionbody"> -<div class="paragraph"><p>This diagram only applies to OPTIONS requests.</p></div> -<div class="imageblock"> -<div class="content"> -<img src="../rest_options.png" alt="REST OPTIONS method flowchart" /> -</div> -</div> -<div class="paragraph"><p>The <code>options</code> callback may be used to add information -about the resource, such as media types or languages -provided; allowed methods; any extra information. A -response body may also be set, although clients should -not be expected to read it.</p></div> -<div class="paragraph"><p>If the <code>options</code> callback is not defined, Cowboy will -send a response containing the list of allowed methods -by default.</p></div> -</div> -</div> -<div class="sect1"> +<p>This diagram only applies to OPTIONS requests.</p> +<img src="../rest_options.png" alt="REST OPTIONS method flowchart"/><p>The <code>options</code> callback may be used to add information about the resource, such as media types or languages provided; allowed methods; any extra information. A response body may also be set, although clients should not be expected to read it.</p> +<p>If the <code>options</code> callback is not defined, Cowboy will send a response containing the list of allowed methods by default.</p> <h2 id="_content_negotiation">Content negotiation</h2> -<div class="sectionbody"> -<div class="paragraph"><p>This diagram applies to all request methods other than -OPTIONS. It is executed right after the "Start" diagram -is completed.</p></div> -<div class="imageblock"> -<div class="content"> -<img src="../rest_conneg.png" alt="REST content negotiation flowchart" /> -</div> -</div> -<div class="paragraph"><p>The purpose of these steps is to determine an appropriate -representation to be sent back to the client.</p></div> -<div class="paragraph"><p>The request may contain any of the accept header; the -accept-language header; or the accept-charset header. -When present, Cowboy will parse the headers and then -call the corresponding callback to obtain the list -of provided content-type, language or charset for this -resource. It then automatically select the best match -based on the request.</p></div> -<div class="paragraph"><p>If a callback is not defined, Cowboy will select the -content-type, language or charset that the client -prefers.</p></div> -<div class="paragraph"><p>The <code>content_types_provided</code> also returns the name of -a callback for every content-type it accepts. This -callback will only be called at the end of the -"GET and HEAD methods" diagram, when all conditions -have been met.</p></div> -<div class="paragraph"><p>The selected content-type, language and charset are -saved as meta values in the Req object. You <strong>should</strong> -use the appropriate representation if you set a -response body manually (alongside an error code, -for example).</p></div> -<div class="paragraph"><p>This diagram is immediately followed by -the "GET and HEAD methods" diagram, -the "PUT, POST and PATCH methods" diagram, -or the "DELETE method" diagram, depending on the -method.</p></div> -</div> -</div> -<div class="sect1"> +<p>This diagram applies to all request methods other than OPTIONS. It is executed right after the "Start" diagram is completed.</p> +<img src="../rest_conneg.png" alt="REST content negotiation flowchart"/><p>The purpose of these steps is to determine an appropriate representation to be sent back to the client.</p> +<p>The request may contain any of the accept header; the accept-language header; or the accept-charset header. When present, Cowboy will parse the headers and then call the corresponding callback to obtain the list of provided content-type, language or charset for this resource. It then automatically select the best match based on the request.</p> +<p>If a callback is not defined, Cowboy will select the content-type, language or charset that the client prefers.</p> +<p>The <code>content_types_provided</code> also returns the name of a callback for every content-type it accepts. This callback will only be called at the end of the "GET and HEAD methods" diagram, when all conditions have been met.</p> +<p>The selected content-type, language and charset are saved as meta values in the Req object. You <strong>should</strong> use the appropriate representation if you set a response body manually (alongside an error code, for example).</p> +<p>This diagram is immediately followed by the "GET and HEAD methods" diagram, the "PUT, POST and PATCH methods" diagram, or the "DELETE method" diagram, depending on the method.</p> <h2 id="_get_and_head_methods">GET and HEAD methods</h2> -<div class="sectionbody"> -<div class="paragraph"><p>This diagram only applies to GET and HEAD requests.</p></div> -<div class="paragraph"><p>For a description of the <code>cond</code> step, please see -the "Conditional requests" diagram.</p></div> -<div class="imageblock"> -<div class="content"> -<img src="../rest_get_head.png" alt="REST GET/HEAD methods flowchart" /> -</div> -</div> -<div class="paragraph"><p>When the resource exists, and the conditional steps -succeed, the resource can be retrieved.</p></div> -<div class="paragraph"><p>Cowboy prepares the response by first retrieving -metadata about the representation, then by calling -the <code>ProvideResource</code> callback. This is the callback -you defined for each content-types you returned from -<code>content_types_provided</code>. This callback returns the body -that will be sent back to the client, or a fun if the -body must be streamed.</p></div> -<div class="paragraph"><p>When the resource does not exist, Cowboy will figure out -whether the resource existed previously, and if so whether -it was moved elsewhere in order to redirect the client to -the new URI.</p></div> -<div class="paragraph"><p>The <code>moved_permanently</code> and <code>moved_temporarily</code> callbacks -must return the new location of the resource if it was in -fact moved.</p></div> -</div> -</div> -<div class="sect1"> -<h2 id="_put_post_and_patch_methods">PUT, POST and PATCH methods</h2> -<div class="sectionbody"> -<div class="paragraph"><p>This diagram only applies to PUT, POST and PATCH requests.</p></div> -<div class="paragraph"><p>For a description of the <code>cond</code> step, please see -the "Conditional requests" diagram.</p></div> -<div class="imageblock"> -<div class="content"> -<img src="../rest_put_post_patch.png" alt="REST PUT/POST/PATCH methods flowchart" /> -</div> -</div> -<div class="paragraph"><p>When the resource exists, first the conditional steps -are executed. When that succeeds, and the method is PUT, -Cowboy will call the <code>is_conflict</code> callback. This function -can be used to prevent potential race conditions, by locking -the resource for example.</p></div> -<div class="paragraph"><p>Then all three methods reach the <code>content_types_accepted</code> -step that we will describe in a few paragraphs.</p></div> -<div class="paragraph"><p>When the resource does not exist, and the method is PUT, -Cowboy will check for conflicts and then move on to the -<code>content_types_accepted</code> step. For other methods, Cowboy -will figure out whether the resource existed previously, -and if so whether it was moved elsewhere. If the resource -is truly non-existent, the method is POST and the call -for <code>allow_missing_post</code> returns <code>true</code>, then Cowboy will -move on to the <code>content_types_accepted</code> step. Otherwise -the request processing ends there.</p></div> -<div class="paragraph"><p>The <code>moved_permanently</code> and <code>moved_temporarily</code> callbacks -must return the new location of the resource if it was in -fact moved.</p></div> -<div class="paragraph"><p>The <code>content_types_accepted</code> returns a list of -content-types it accepts, but also the name of a callback -for each of them. Cowboy will select the appropriate -callback for processing the request body and call it.</p></div> -<div class="paragraph"><p>This callback may return one of three different return -values.</p></div> -<div class="paragraph"><p>If an error occurred while processing the request body, -it must return <code>false</code> and Cowboy will send an -appropriate error response.</p></div> -<div class="paragraph"><p>If the method is POST, then you may return <code>true</code> with -an URI of where the resource has been created. This is -especially useful for writing handlers for collections.</p></div> -<div class="paragraph"><p>Otherwise, return <code>true</code> to indicate success. Cowboy -will select the appropriate response to be sent depending -on whether a resource has been created, rather than -modified, and on the availability of a location header -or a body in the response.</p></div> -</div> -</div> -<div class="sect1"> +<p>This diagram only applies to GET and HEAD requests.</p> +<p>For a description of the <code>cond</code> step, please see the "Conditional requests" diagram.</p> +<img src="../rest_get_head.png" alt="REST GET/HEAD methods flowchart"/><p>When the resource exists, and the conditional steps succeed, the resource can be retrieved.</p> +<p>Cowboy prepares the response by first retrieving metadata about the representation, then by calling the <code>ProvideResource</code> callback. This is the callback you defined for each content-types you returned from <code>content_types_provided</code>. This callback returns the body that will be sent back to the client, or a fun if the body must be streamed.</p> +<p>When the resource does not exist, Cowboy will figure out whether the resource existed previously, and if so whether it was moved elsewhere in order to redirect the client to the new URI.</p> +<p>The <code>moved_permanently</code> and <code>moved_temporarily</code> callbacks must return the new location of the resource if it was in fact moved.</p> +<h2 id="_put__post_and_patch_methods">PUT, POST and PATCH methods</h2> +<p>This diagram only applies to PUT, POST and PATCH requests.</p> +<p>For a description of the <code>cond</code> step, please see the "Conditional requests" diagram.</p> +<img src="../rest_put_post_patch.png" alt="REST PUT/POST/PATCH methods flowchart"/><p>When the resource exists, first the conditional steps are executed. When that succeeds, and the method is PUT, Cowboy will call the <code>is_conflict</code> callback. This function can be used to prevent potential race conditions, by locking the resource for example.</p> +<p>Then all three methods reach the <code>content_types_accepted</code> step that we will describe in a few paragraphs.</p> +<p>When the resource does not exist, and the method is PUT, Cowboy will check for conflicts and then move on to the <code>content_types_accepted</code> step. For other methods, Cowboy will figure out whether the resource existed previously, and if so whether it was moved elsewhere. If the resource is truly non-existent, the method is POST and the call for <code>allow_missing_post</code> returns <code>true</code>, then Cowboy will move on to the <code>content_types_accepted</code> step. Otherwise the request processing ends there.</p> +<p>The <code>moved_permanently</code> and <code>moved_temporarily</code> callbacks must return the new location of the resource if it was in fact moved.</p> +<p>The <code>content_types_accepted</code> returns a list of content-types it accepts, but also the name of a callback for each of them. Cowboy will select the appropriate callback for processing the request body and call it.</p> +<p>This callback may return one of three different return values.</p> +<p>If an error occurred while processing the request body, it must return <code>false</code> and Cowboy will send an appropriate error response.</p> +<p>If the method is POST, then you may return <code>true</code> with an URI of where the resource has been created. This is especially useful for writing handlers for collections.</p> +<p>Otherwise, return <code>true</code> to indicate success. Cowboy will select the appropriate response to be sent depending on whether a resource has been created, rather than modified, and on the availability of a location header or a body in the response.</p> <h2 id="_delete_method">DELETE method</h2> -<div class="sectionbody"> -<div class="paragraph"><p>This diagram only applies to DELETE requests.</p></div> -<div class="paragraph"><p>For a description of the <code>cond</code> step, please see -the "Conditional requests" diagram.</p></div> -<div class="imageblock"> -<div class="content"> -<img src="../rest_delete.png" alt="REST DELETE method flowchart" /> -</div> -</div> -<div class="paragraph"><p>When the resource exists, and the conditional steps -succeed, the resource can be deleted.</p></div> -<div class="paragraph"><p>Deleting the resource is a two steps process. First -the callback <code>delete_resource</code> is executed. Use this -callback to delete the resource.</p></div> -<div class="paragraph"><p>Because the resource may be cached, you must also -delete all cached representations of this resource -in the system. This operation may take a while though, -so you may return before it finished.</p></div> -<div class="paragraph"><p>Cowboy will then call the <code>delete_completed</code> callback. -If you know that the resource has been completely -deleted from your system, including from caches, then -you can return <code>true</code>. If any doubts persist, return -<code>false</code>. Cowboy will assume <code>true</code> by default.</p></div> -<div class="paragraph"><p>To finish, Cowboy checks if you set a response body, -and depending on that, sends the appropriate response.</p></div> -<div class="paragraph"><p>When the resource does not exist, Cowboy will figure out -whether the resource existed previously, and if so whether -it was moved elsewhere in order to redirect the client to -the new URI.</p></div> -<div class="paragraph"><p>The <code>moved_permanently</code> and <code>moved_temporarily</code> callbacks -must return the new location of the resource if it was in -fact moved.</p></div> -</div> -</div> -<div class="sect1"> +<p>This diagram only applies to DELETE requests.</p> +<p>For a description of the <code>cond</code> step, please see the "Conditional requests" diagram.</p> +<img src="../rest_delete.png" alt="REST DELETE method flowchart"/><p>When the resource exists, and the conditional steps succeed, the resource can be deleted.</p> +<p>Deleting the resource is a two steps process. First the callback <code>delete_resource</code> is executed. Use this callback to delete the resource.</p> +<p>Because the resource may be cached, you must also delete all cached representations of this resource in the system. This operation may take a while though, so you may return before it finished.</p> +<p>Cowboy will then call the <code>delete_completed</code> callback. If you know that the resource has been completely deleted from your system, including from caches, then you can return <code>true</code>. If any doubts persist, return <code>false</code>. Cowboy will assume <code>true</code> by default.</p> +<p>To finish, Cowboy checks if you set a response body, and depending on that, sends the appropriate response.</p> +<p>When the resource does not exist, Cowboy will figure out whether the resource existed previously, and if so whether it was moved elsewhere in order to redirect the client to the new URI.</p> +<p>The <code>moved_permanently</code> and <code>moved_temporarily</code> callbacks must return the new location of the resource if it was in fact moved.</p> <h2 id="_conditional_requests">Conditional requests</h2> -<div class="sectionbody"> -<div class="paragraph"><p>This diagram applies to all request methods other than -OPTIONS. It is executed right after the <code>resource_exists</code> -callback, when the resource exists.</p></div> -<div class="imageblock"> -<div class="content"> -<img src="../rest_cond.png" alt="REST conditional requests flowchart" /> -</div> -</div> -<div class="paragraph"><p>A request becomes conditional when it includes either of -the if-match header; the if-unmodified-since header; the -if-none-match header; or the if-modified-since header.</p></div> -<div class="paragraph"><p>If the condition fails, the request ends immediately -without any retrieval or modification of the resource.</p></div> -<div class="paragraph"><p>The <code>generate_etag</code> and <code>last_modified</code> are called as -needed. Cowboy will only call them once and then cache -the results for subsequent use.</p></div> -</div> -</div> +<p>This diagram applies to all request methods other than OPTIONS. It is executed right after the <code>resource_exists</code> callback, when the resource exists.</p> +<img src="../rest_cond.png" alt="REST conditional requests flowchart"/><p>A request becomes conditional when it includes either of the if-match header; the if-unmodified-since header; the if-none-match header; or the if-modified-since header.</p> +<p>If the condition fails, the request ends immediately without any retrieval or modification of the resource.</p> +<p>The <code>generate_etag</code> and <code>last_modified</code> are called as needed. Cowboy will only call them once and then cache the results for subsequent use.</p> + diff --git a/docs/en/cowboy/2.3/guide/rest_handlers/index.html b/docs/en/cowboy/2.3/guide/rest_handlers/index.html index 83d1fb46..1d2fe4e6 100644 --- a/docs/en/cowboy/2.3/guide/rest_handlers/index.html +++ b/docs/en/cowboy/2.3/guide/rest_handlers/index.html @@ -62,287 +62,162 @@ <h1 class="lined-header"><span>REST handlers</span></h1> -<div class="paragraph"><p>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’s behavior.</p></div> -<div class="paragraph"><p>The REST handler is the recommended way to handle HTTP requests.</p></div> -<div class="sect1"> +<p>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's behavior.</p> +<p>The REST handler is the recommended way to handle HTTP requests.</p> <h2 id="_initialization">Initialization</h2> -<div class="sectionbody"> -<div class="paragraph"><p>First, the <code>init/2</code> callback is called. This callback is common -to all handlers. To use REST for the current request, this function -must return a <code>cowboy_rest</code> tuple.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>First, the <code>init/2</code> callback is called. This callback is common to all handlers. To use REST for the current request, this function must return a <code>cowboy_rest</code> tuple.</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">cowboy_rest</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Cowboy will then switch to the REST protocol and start executing -the state machine.</p></div> -<div class="paragraph"><p>After reaching the end of the flowchart, the <code>terminate/3</code> callback -will be called if it is defined.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">cowboy_rest</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>Cowboy will then switch to the REST protocol and start executing the state machine.</p> +<p>After reaching the end of the flowchart, the <code>terminate/3</code> callback will be called if it is defined.</p> <h2 id="_methods">Methods</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The REST component has code for handling the following HTTP methods: -HEAD, GET, POST, PATCH, PUT, DELETE and OPTIONS.</p></div> -<div class="paragraph"><p>Other methods can be accepted, however they have no specific callback -defined for them at this time.</p></div> -</div> -</div> -<div class="sect1"> +<p>The REST component has code for handling the following HTTP methods: HEAD, GET, POST, PATCH, PUT, DELETE and OPTIONS.</p> +<p>Other methods can be accepted, however they have no specific callback defined for them at this time.</p> <h2 id="_callbacks">Callbacks</h2> -<div class="sectionbody"> -<div class="paragraph"><p>All callbacks are optional. Some may become mandatory depending -on what other defined callbacks return. The various flowcharts -in the next chapter should be a useful to determine which callbacks -you need.</p></div> -<div class="paragraph"><p>All callbacks take two arguments, the Req object and the State, -and return a three-element tuple of the form <code>{Value, Req, State}</code>.</p></div> -<div class="paragraph"><p>Nearly all callbacks can also return <code>{stop, Req, State}</code> to -stop execution of the request, and -<code>{{switch_handler, Module}, Req, State}</code> or -<code>{{switch_handler, Module, Opts}, Req, State}</code> to switch to -a different handler type. The exceptions are <code>expires</code> -<code>generate_etag</code>, <code>last_modified</code> and <code>variances</code>.</p></div> -<div class="paragraph"><p>The following table summarizes the callbacks and their default values. -If the callback isn’t defined, then the default value will be used. -Please look at the flowcharts to find out the result of each return -value.</p></div> -<div class="paragraph"><p>In the following table, "skip" means the callback is entirely skipped -if it is undefined, moving directly to the next step. Similarly, -"none" means there is no default value for this callback.</p></div> -<div class="tableblock"> -<table rules="all" -width="100%" -frame="border" -cellspacing="0" cellpadding="4"> -<col width="50%" /> -<col width="50%" /> -<thead> -<tr> -<th align="left" valign="top"> Callback name </th> -<th align="center" valign="top"> Default value</th> -</tr> -</thead> -<tbody> -<tr> -<td align="left" valign="top"><p class="table">allowed_methods</p></td> -<td align="center" valign="top"><p class="table"><code>[<<"GET">>, <<"HEAD">>, <<"OPTIONS">>]</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">allow_missing_post</p></td> -<td align="center" valign="top"><p class="table"><code>true</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">charsets_provided</p></td> -<td align="center" valign="top"><p class="table">skip</p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">content_types_accepted</p></td> -<td align="center" valign="top"><p class="table">none</p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">content_types_provided</p></td> -<td align="center" valign="top"><p class="table"><code>[{{ <<"text">>, <<"html">>, '*'}, to_html}]</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">delete_completed</p></td> -<td align="center" valign="top"><p class="table"><code>true</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">delete_resource</p></td> -<td align="center" valign="top"><p class="table"><code>false</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">expires</p></td> -<td align="center" valign="top"><p class="table"><code>undefined</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">forbidden</p></td> -<td align="center" valign="top"><p class="table"><code>false</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">generate_etag</p></td> -<td align="center" valign="top"><p class="table"><code>undefined</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">is_authorized</p></td> -<td align="center" valign="top"><p class="table"><code>true</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">is_conflict</p></td> -<td align="center" valign="top"><p class="table"><code>false</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">known_methods</p></td> -<td align="center" valign="top"><p class="table"><code>[<<"GET">>, <<"HEAD">>, <<"POST">>, <<"PUT">>, <<"PATCH">>, <<"DELETE">>, <<"OPTIONS">>]</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">languages_provided</p></td> -<td align="center" valign="top"><p class="table">skip</p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">last_modified</p></td> -<td align="center" valign="top"><p class="table"><code>undefined</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">malformed_request</p></td> -<td align="center" valign="top"><p class="table"><code>false</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">moved_permanently</p></td> -<td align="center" valign="top"><p class="table"><code>false</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">moved_temporarily</p></td> -<td align="center" valign="top"><p class="table"><code>false</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">multiple_choices</p></td> -<td align="center" valign="top"><p class="table"><code>false</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">options</p></td> -<td align="center" valign="top"><p class="table"><code>ok</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">previously_existed</p></td> -<td align="center" valign="top"><p class="table"><code>false</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">resource_exists</p></td> -<td align="center" valign="top"><p class="table"><code>true</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">service_available</p></td> -<td align="center" valign="top"><p class="table"><code>true</code></p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">uri_too_long</p></td> -<td align="center" valign="top"><p class="table"><code>false</code></p></td> +<p>All callbacks are optional. Some may become mandatory depending on what other defined callbacks return. The various flowcharts in the next chapter should be a useful to determine which callbacks you need.</p> +<p>All callbacks take two arguments, the Req object and the State, and return a three-element tuple of the form <code>{Value, Req, State}</code>.</p> +<p>Nearly all callbacks can also return <code>{stop, Req, State}</code> to stop execution of the request, and <code>{{switch_handler, Module}, Req, State}</code> or <code>{{switch_handler, Module, Opts}, Req, State}</code> to switch to a different handler type. The exceptions are <code>expires</code> <code>generate_etag</code>, <code>last_modified</code> and <code>variances</code>.</p> +<p>The following table summarizes the callbacks and their default values. If the callback isn't defined, then the default value will be used. Please look at the flowcharts to find out the result of each return value.</p> +<p>In the following table, "skip" means the callback is entirely skipped if it is undefined, moving directly to the next step. Similarly, "none" means there is no default value for this callback.</p> +<table rules="all" width="100%" frame="border" + cellspacing="0" cellpadding="4"> +<thead><tr><th>Callback name</th> +<th>Default value</th> +</tr></thead><tbody><tr><td>allowed_methods</td> +<td><code>[<<"GET">>, <<"HEAD">>, <<"OPTIONS">>]</code></td> </tr> -<tr> -<td align="left" valign="top"><p class="table">valid_content_headers</p></td> -<td align="center" valign="top"><p class="table"><code>true</code></p></td> +<tr><td>allow_missing_post</td> +<td><code>true</code></td> </tr> -<tr> -<td align="left" valign="top"><p class="table">valid_entity_length</p></td> -<td align="center" valign="top"><p class="table"><code>true</code></p></td> +<tr><td>charsets_provided</td> +<td>skip</td> </tr> -<tr> -<td align="left" valign="top"><p class="table">variances</p></td> -<td align="center" valign="top"><p class="table"><code>[]</code></p></td> +<tr><td>content_types_accepted</td> +<td>none</td> </tr> -</tbody> -</table> -</div> -<div class="paragraph"><p>As you can see, Cowboy tries to move on with the request whenever -possible by using well thought out default values.</p></div> -<div class="paragraph"><p>In addition to these, there can be any number of user-defined -callbacks that are specified through <code>content_types_accepted/2</code> -and <code>content_types_provided/2</code>. They can take any name, however -it is recommended to use a separate prefix for the callbacks of -each function. For example, <code>from_html</code> and <code>to_html</code> indicate -in the first case that we’re accepting a resource given as HTML, -and in the second case that we send one as HTML.</p></div> -</div> -</div> -<div class="sect1"> +<tr><td>content_types_provided</td> +<td><code>[{{ <<"text">>, <<"html">>, '*'}, to_html}]</code></td> +</tr> +<tr><td>delete_completed</td> +<td><code>true</code></td> +</tr> +<tr><td>delete_resource</td> +<td><code>false</code></td> +</tr> +<tr><td>expires</td> +<td><code>undefined</code></td> +</tr> +<tr><td>forbidden</td> +<td><code>false</code></td> +</tr> +<tr><td>generate_etag</td> +<td><code>undefined</code></td> +</tr> +<tr><td>is_authorized</td> +<td><code>true</code></td> +</tr> +<tr><td>is_conflict</td> +<td><code>false</code></td> +</tr> +<tr><td>known_methods</td> +<td><code>[<<"GET">>, <<"HEAD">>, <<"POST">>, <<"PUT">>, <<"PATCH">>, <<"DELETE">>, <<"OPTIONS">>]</code></td> +</tr> +<tr><td>languages_provided</td> +<td>skip</td> +</tr> +<tr><td>last_modified</td> +<td><code>undefined</code></td> +</tr> +<tr><td>malformed_request</td> +<td><code>false</code></td> +</tr> +<tr><td>moved_permanently</td> +<td><code>false</code></td> +</tr> +<tr><td>moved_temporarily</td> +<td><code>false</code></td> +</tr> +<tr><td>multiple_choices</td> +<td><code>false</code></td> +</tr> +<tr><td>options</td> +<td><code>ok</code></td> +</tr> +<tr><td>previously_existed</td> +<td><code>false</code></td> +</tr> +<tr><td>resource_exists</td> +<td><code>true</code></td> +</tr> +<tr><td>service_available</td> +<td><code>true</code></td> +</tr> +<tr><td>uri_too_long</td> +<td><code>false</code></td> +</tr> +<tr><td>valid_content_headers</td> +<td><code>true</code></td> +</tr> +<tr><td>valid_entity_length</td> +<td><code>true</code></td> +</tr> +<tr><td>variances</td> +<td><code>[]</code></td> +</tr> +</tbody></table> +<p>As you can see, Cowboy tries to move on with the request whenever possible by using well thought out default values.</p> +<p>In addition to these, there can be any number of user-defined callbacks that are specified through <code>content_types_accepted/2</code> and <code>content_types_provided/2</code>. They can take any name, however it is recommended to use a separate prefix for the callbacks of each function. For example, <code>from_html</code> and <code>to_html</code> indicate in the first case that we're accepting a resource given as HTML, and in the second case that we send one as HTML.</p> <h2 id="_meta_data">Meta data</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy will set informative values to the Req object at various -points of the execution. You can retrieve them by matching the -Req object directly. The values are defined in the following table:</p></div> -<div class="tableblock"> -<table rules="all" -width="100%" -frame="border" -cellspacing="0" cellpadding="4"> -<col width="50%" /> -<col width="50%" /> -<thead> -<tr> -<th align="left" valign="top"> Key </th> -<th align="left" valign="top"> Details</th> -</tr> -</thead> -<tbody> -<tr> -<td align="left" valign="top"><p class="table">media_type</p></td> -<td align="left" valign="top"><p class="table">The content-type negotiated for the response entity.</p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">language</p></td> -<td align="left" valign="top"><p class="table">The language negotiated for the response entity.</p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">charset</p></td> -<td align="left" valign="top"><p class="table">The charset negotiated for the response entity.</p></td> -</tr> -</tbody> -</table> -</div> -<div class="paragraph"><p>They can be used to send a proper body with the response to a -request that used a method other than HEAD or GET.</p></div> -</div> -</div> -<div class="sect1"> +<p>Cowboy will set informative values to the Req object at various points of the execution. You can retrieve them by matching the Req object directly. The values are defined in the following table:</p> +<table rules="all" width="100%" frame="border" + cellspacing="0" cellpadding="4"> +<thead><tr><th>Key</th> +<th>Details</th> +</tr></thead><tbody><tr><td>media_type</td> +<td>The content-type negotiated for the response entity.</td> +</tr> +<tr><td>language</td> +<td>The language negotiated for the response entity.</td> +</tr> +<tr><td>charset</td> +<td>The charset negotiated for the response entity.</td> +</tr> +</tbody></table> +<p>They can be used to send a proper body with the response to a request that used a method other than HEAD or GET.</p> <h2 id="_response_headers">Response headers</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy will set response headers automatically over the execution -of the REST code. They are listed in the following table.</p></div> -<div class="tableblock"> -<table rules="all" -width="100%" -frame="border" -cellspacing="0" cellpadding="4"> -<col width="50%" /> -<col width="50%" /> -<thead> -<tr> -<th align="left" valign="top"> Header name </th> -<th align="left" valign="top"> Details</th> -</tr> -</thead> -<tbody> -<tr> -<td align="left" valign="top"><p class="table">content-language</p></td> -<td align="left" valign="top"><p class="table">Language used in the response body</p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">content-type</p></td> -<td align="left" valign="top"><p class="table">Media type and charset of the response body</p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">etag</p></td> -<td align="left" valign="top"><p class="table">Etag of the resource</p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">expires</p></td> -<td align="left" valign="top"><p class="table">Expiration date of the resource</p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">last-modified</p></td> -<td align="left" valign="top"><p class="table">Last modification date for the resource</p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">location</p></td> -<td align="left" valign="top"><p class="table">Relative or absolute URI to the requested resource</p></td> -</tr> -<tr> -<td align="left" valign="top"><p class="table">vary</p></td> -<td align="left" valign="top"><p class="table">List of headers that may change the representation of the resource</p></td> -</tr> -</tbody> -</table> -</div> -</div> -</div> +<p>Cowboy will set response headers automatically over the execution of the REST code. They are listed in the following table.</p> +<table rules="all" width="100%" frame="border" + cellspacing="0" cellpadding="4"> +<thead><tr><th>Header name</th> +<th>Details</th> +</tr></thead><tbody><tr><td>content-language</td> +<td>Language used in the response body</td> +</tr> +<tr><td>content-type</td> +<td>Media type and charset of the response body</td> +</tr> +<tr><td>etag</td> +<td>Etag of the resource</td> +</tr> +<tr><td>expires</td> +<td>Expiration date of the resource</td> +</tr> +<tr><td>last-modified</td> +<td>Last modification date for the resource</td> +</tr> +<tr><td>location</td> +<td>Relative or absolute URI to the requested resource</td> +</tr> +<tr><td>vary</td> +<td>List of headers that may change the representation of the resource</td> +</tr> +</tbody></table> + diff --git a/docs/en/cowboy/2.3/guide/rest_principles/index.html b/docs/en/cowboy/2.3/guide/rest_principles/index.html index 12de886b..78687d10 100644 --- a/docs/en/cowboy/2.3/guide/rest_principles/index.html +++ b/docs/en/cowboy/2.3/guide/rest_principles/index.html @@ -62,153 +62,38 @@ <h1 class="lined-header"><span>REST principles</span></h1> -<div class="paragraph"><p>This chapter will attempt to define the concepts behind REST -and explain what makes a service RESTful.</p></div> -<div class="paragraph"><p>REST is often confused with performing a distinct operation -depending on the HTTP method, while using more than the GET -and POST methods. That’s highly misguided at best.</p></div> -<div class="paragraph"><p>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 -<a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">Roy T. Fielding’s dissertation</a> -as it does a great job explaining where it comes from and -what it achieves.</p></div> -<div class="sect1"> +<p>This chapter will attempt to define the concepts behind REST and explain what makes a service RESTful.</p> +<p>REST is often confused with performing a distinct operation depending on the HTTP method, while using more than the GET and POST methods. That's highly misguided at best.</p> +<p>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 <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">Roy T. Fielding's dissertation</a> as it does a great job explaining where it comes from and what it achieves.</p> <h2 id="_rest_architecture">REST architecture</h2> -<div class="sectionbody"> -<div class="paragraph"><p>REST is a <strong>client-server</strong> architecture. The client and the server -both have a different set of concerns. The server stores and/or -manipulates information and makes it available to the user in -an efficient manner. The client takes that information and -displays it to the user and/or uses it to perform subsequent -requests for information. This separation of concerns allows both -the client and the server to evolve independently as it only -requires that the interface stays the same.</p></div> -<div class="paragraph"><p>REST is <strong>stateless</strong>. That means the communication between the -client and the server always contains all the information needed -to perform the request. There is no session state in the server, -it is kept entirely on the client’s side. If access to a resource -requires authentication, then the client needs to authenticate -itself with every request.</p></div> -<div class="paragraph"><p>REST is <strong>cacheable</strong>. The client, the server and any intermediary -components can all cache resources in order to improve performance.</p></div> -<div class="paragraph"><p>REST provides a <strong>uniform interface</strong> between components. This -simplifies the architecture, as all components follow the same -rules to speak to one another. It also makes it easier to understand -the interactions between the different components of the system. -A number of constraints are required to achieve this. They are -covered in the rest of the chapter.</p></div> -<div class="paragraph"><p>REST is a <strong>layered system</strong>. Individual components cannot see -beyond the immediate layer with which they are interacting. This -means that a client connecting to an intermediate component, like -a proxy, has no knowledge of what lies beyond. This allows -components to be independent and thus easily replaceable or -extendable.</p></div> -<div class="paragraph"><p>REST optionally provides <strong>code on demand</strong>. Code may be downloaded -to extend client functionality. This is optional however because -the client may not be able to download or run this code, and so -a REST component cannot rely on it being executed.</p></div> -</div> -</div> -<div class="sect1"> +<p>REST is a <strong>client-server</strong> architecture. The client and the server both have a different set of concerns. The server stores and/or manipulates information and makes it available to the user in an efficient manner. The client takes that information and displays it to the user and/or uses it to perform subsequent requests for information. This separation of concerns allows both the client and the server to evolve independently as it only requires that the interface stays the same.</p> +<p>REST is <strong>stateless</strong>. That means the communication between the client and the server always contains all the information needed to perform the request. There is no session state in the server, it is kept entirely on the client's side. If access to a resource requires authentication, then the client needs to authenticate itself with every request.</p> +<p>REST is <strong>cacheable</strong>. The client, the server and any intermediary components can all cache resources in order to improve performance.</p> +<p>REST provides a <strong>uniform interface</strong> between components. This simplifies the architecture, as all components follow the same rules to speak to one another. It also makes it easier to understand the interactions between the different components of the system. A number of constraints are required to achieve this. They are covered in the rest of the chapter.</p> +<p>REST is a <strong>layered system</strong>. Individual components cannot see beyond the immediate layer with which they are interacting. This means that a client connecting to an intermediate component, like a proxy, has no knowledge of what lies beyond. This allows components to be independent and thus easily replaceable or extendable.</p> +<p>REST optionally provides <strong>code on demand</strong>. Code may be downloaded to extend client functionality. This is optional however because the client may not be able to download or run this code, and so a REST component cannot rely on it being executed.</p> <h2 id="_resources_and_resource_identifiers">Resources and resource identifiers</h2> -<div class="sectionbody"> -<div class="paragraph"><p>A resource is an abstract concept. In a REST system, any information -that can be named may be a resource. This includes documents, images, -a collection of resources and any other information. Any information -that can be the target of an hypertext link can be a resource.</p></div> -<div class="paragraph"><p>A resource is a conceptual mapping to a set of entities. The set of -entities evolves over time; a resource doesn’t. For example, a resource -can map to "users who have logged in this past month" and another -to "all users". At some point in time they may map to the same set of -entities, because all users logged in this past month. But they are -still different resources. Similarly, if nobody logged in recently, -then the first resource may map to the empty set. This resource exists -regardless of the information it maps to.</p></div> -<div class="paragraph"><p>Resources are identified by uniform resource identifiers, also known -as URIs. Sometimes internationalized resource identifiers, or IRIs, -may also be used, but these can be directly translated into a URI.</p></div> -<div class="paragraph"><p>In practice we will identify two kinds of resources. Individual -resources map to a set of one element, for example "user Joe". -Collection of resources map to a set of 0 to N elements, -for example "all users".</p></div> -</div> -</div> -<div class="sect1"> +<p>A resource is an abstract concept. In a REST system, any information that can be named may be a resource. This includes documents, images, a collection of resources and any other information. Any information that can be the target of an hypertext link can be a resource.</p> +<p>A resource is a conceptual mapping to a set of entities. The set of entities evolves over time; a resource doesn't. For example, a resource can map to "users who have logged in this past month" and another to "all users". At some point in time they may map to the same set of entities, because all users logged in this past month. But they are still different resources. Similarly, if nobody logged in recently, then the first resource may map to the empty set. This resource exists regardless of the information it maps to.</p> +<p>Resources are identified by uniform resource identifiers, also known as URIs. Sometimes internationalized resource identifiers, or IRIs, may also be used, but these can be directly translated into a URI.</p> +<p>In practice we will identify two kinds of resources. Individual resources map to a set of one element, for example "user Joe". Collection of resources map to a set of 0 to N elements, for example "all users".</p> <h2 id="_resource_representations">Resource representations</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The representation of a resource is a sequence of bytes associated -with metadata.</p></div> -<div class="paragraph"><p>The metadata comes as a list of key-value pairs, where the name -corresponds to a standard that defines the value’s structure and -semantics. With HTTP, the metadata comes in the form of request -or response headers. The headers' structure and semantics are well -defined in the HTTP standard. Metadata includes representation -metadata, resource metadata and control data.</p></div> -<div class="paragraph"><p>The representation metadata gives information about the -representation, such as its media type, the date of last -modification, or even a checksum.</p></div> -<div class="paragraph"><p>Resource metadata could be link to related resources or -information about additional representations of the resource.</p></div> -<div class="paragraph"><p>Control data allows parameterizing the request or response. -For example, we may only want the representation returned if -it is more recent than the one we have in cache. Similarly, -we may want to instruct the client about how it should cache -the representation. This isn’t restricted to caching. We may, -for example, want to store a new representation of a resource -only if it wasn’t modified since we first retrieved it.</p></div> -<div class="paragraph"><p>The data format of a representation is also known as the media -type. Some media types are intended for direct rendering to the -user, while others are intended for automated processing. The -media type is a key component of the REST architecture.</p></div> -</div> -</div> -<div class="sect1"> +<p>The representation of a resource is a sequence of bytes associated with metadata.</p> +<p>The metadata comes as a list of key-value pairs, where the name corresponds to a standard that defines the value's structure and semantics. With HTTP, the metadata comes in the form of request or response headers. The headers' structure and semantics are well defined in the HTTP standard. Metadata includes representation metadata, resource metadata and control data.</p> +<p>The representation metadata gives information about the representation, such as its media type, the date of last modification, or even a checksum.</p> +<p>Resource metadata could be link to related resources or information about additional representations of the resource.</p> +<p>Control data allows parameterizing the request or response. For example, we may only want the representation returned if it is more recent than the one we have in cache. Similarly, we may want to instruct the client about how it should cache the representation. This isn't restricted to caching. We may, for example, want to store a new representation of a resource only if it wasn't modified since we first retrieved it.</p> +<p>The data format of a representation is also known as the media type. Some media types are intended for direct rendering to the user, while others are intended for automated processing. The media type is a key component of the REST architecture.</p> <h2 id="_self_descriptive_messages">Self-descriptive messages</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Messages must be self-descriptive. That means that the data -format of a representation must always come with its media -type (and similarly requesting a resource involves choosing -the media type of the representation returned). If you are -sending HTML, then you must say it is HTML by sending the -media type with the representation. In HTTP this is done -using the content-type header.</p></div> -<div class="paragraph"><p>The media type is often an IANA registered media type, like -<code>text/html</code> or <code>image/png</code>, but does not need to be. Exactly -two things are important for respecting this constraint: that -the media type is well specified, and that the sender and -recipient agree about what the media type refers to.</p></div> -<div class="paragraph"><p>This means that you can create your own media types, like -<code>application/x-mine</code>, and that as long as you write the -specifications for it and that both endpoints agree about -it then the constraint is respected.</p></div> -</div> -</div> -<div class="sect1"> +<p>Messages must be self-descriptive. That means that the data format of a representation must always come with its media type (and similarly requesting a resource involves choosing the media type of the representation returned). If you are sending HTML, then you must say it is HTML by sending the media type with the representation. In HTTP this is done using the content-type header.</p> +<p>The media type is often an IANA registered media type, like <code>text/html</code> or <code>image/png</code>, but does not need to be. Exactly two things are important for respecting this constraint: that the media type is well specified, and that the sender and recipient agree about what the media type refers to.</p> +<p>This means that you can create your own media types, like <code>application/x-mine</code>, and that as long as you write the specifications for it and that both endpoints agree about it then the constraint is respected.</p> <h2 id="_hypermedia_as_the_engine_of_application_state">Hypermedia as the engine of application state</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The last constraint is generally where services that claim -to be RESTful fail. Interactions with a server must be -entirely driven by hypermedia. The client does not need -any prior knowledge of the service in order to use it, -other than an entry point and of course basic understanding -of the media type of the representations, at the very least -enough to find and identify hyperlinks and link relations.</p></div> -<div class="paragraph"><p>To give a simple example, if your service only works with -the <code>application/json</code> media type then this constraint -cannot be respected (as there are no concept of links in -JSON) and thus your service isn’t RESTful. This is the case -for the majority of self-proclaimed REST services.</p></div> -<div class="paragraph"><p>On the other hand if you create a JSON based media type -that has a concept of links and link relations, then -your service might be RESTful.</p></div> -<div class="paragraph"><p>Respecting this constraint means that the entirety of the -service becomes self-discoverable, not only the resources -in it, but also the operations you can perform on it. This -makes clients very thin as there is no need to implement -anything specific to the service to operate on it.</p></div> -</div> -</div> +<p>The last constraint is generally where services that claim to be RESTful fail. Interactions with a server must be entirely driven by hypermedia. The client does not need any prior knowledge of the service in order to use it, other than an entry point and of course basic understanding of the media type of the representations, at the very least enough to find and identify hyperlinks and link relations.</p> +<p>To give a simple example, if your service only works with the <code>application/json</code> media type then this constraint cannot be respected (as there are no concept of links in JSON) and thus your service isn't RESTful. This is the case for the majority of self-proclaimed REST services.</p> +<p>On the other hand if you create a JSON based media type that has a concept of links and link relations, then your service might be RESTful.</p> +<p>Respecting this constraint means that the entirety of the service becomes self-discoverable, not only the resources in it, but also the operations you can perform on it. This makes clients very thin as there is no need to implement anything specific to the service to operate on it.</p> + diff --git a/docs/en/cowboy/2.3/guide/routing/index.html b/docs/en/cowboy/2.3/guide/routing/index.html index 5f1ef914..1a7eccc6 100644 --- a/docs/en/cowboy/2.3/guide/routing/index.html +++ b/docs/en/cowboy/2.3/guide/routing/index.html @@ -62,261 +62,181 @@ <h1 class="lined-header"><span>Routing</span></h1> -<div class="paragraph"><p>Cowboy does nothing by default.</p></div> -<div class="paragraph"><p>To make Cowboy useful, you need to map URIs to Erlang modules that will -handle the requests. This is called routing.</p></div> -<div class="paragraph"><p>When Cowboy receives a request, it tries to match the requested host and -path to the configured routes. When there’s a match, the route’s -associated handler is executed.</p></div> -<div class="paragraph"><p>Routes need to be compiled before they can be used by Cowboy. -The result of the compilation is the dispatch rules.</p></div> -<div class="sect1"> +<p>Cowboy does nothing by default.</p> +<p>To make Cowboy useful, you need to map URIs to Erlang modules that will handle the requests. This is called routing.</p> +<p>When Cowboy receives a request, it tries to match the requested host and path to the configured routes. When there's a match, the route's associated handler is executed.</p> +<p>Routes need to be compiled before they can be used by Cowboy. The result of the compilation is the dispatch rules.</p> <h2 id="_syntax">Syntax</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The general structure for the routes is defined as follow.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The general structure for the routes is defined as follow.</p> +<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><span style="color: #009900">Routes</span> <span style="color: #990000">=</span> [<span style="color: #009900">Host1</span>, <span style="color: #009900">Host2</span>, <span style="color: #990000">...</span> <span style="color: #009900">HostN</span>]<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Each host contains matching rules for the host along with optional -constraints, and a list of routes for the path component.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Routes</font> <font color="#990000">=</font> [<font color="#009900">Host1</font>, <font color="#009900">Host2</font>, <font color="#990000">...</font> <font color="#009900">HostN</font>]<font color="#990000">.</font></tt></pre> +</div></div> +<p>Each host contains matching rules for the host along with optional constraints, and a list of routes for the path component.</p> +<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><span style="color: #009900">Host1</span> <span style="color: #990000">=</span> {<span style="color: #009900">HostMatch</span>, <span style="color: #009900">PathsList</span>}<span style="color: #990000">.</span> -<span style="color: #009900">Host2</span> <span style="color: #990000">=</span> {<span style="color: #009900">HostMatch</span>, <span style="color: #009900">Constraints</span>, <span style="color: #009900">PathsList</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>The list of routes for the path component is defined similar to the -list of hosts.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">Host1</font> <font color="#990000">=</font> {<font color="#009900">HostMatch</font>, <font color="#009900">PathsList</font>}<font color="#990000">.</font> +<font color="#009900">Host2</font> <font color="#990000">=</font> {<font color="#009900">HostMatch</font>, <font color="#009900">Constraints</font>, <font color="#009900">PathsList</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>The list of routes for the path component is defined similar to the list of hosts.</p> +<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><span style="color: #009900">PathsList</span> <span style="color: #990000">=</span> [<span style="color: #009900">Path1</span>, <span style="color: #009900">Path2</span>, <span style="color: #990000">...</span> <span style="color: #009900">PathN</span>]<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Finally, each path contains matching rules for the path along with -optional constraints, and gives us the handler module to be used -along with its initial state.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PathsList</font> <font color="#990000">=</font> [<font color="#009900">Path1</font>, <font color="#009900">Path2</font>, <font color="#990000">...</font> <font color="#009900">PathN</font>]<font color="#990000">.</font></tt></pre> +</div></div> +<p>Finally, each path contains matching rules for the path along with optional constraints, and gives us the handler module to be used along with its initial state.</p> +<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><span style="color: #009900">Path1</span> <span style="color: #990000">=</span> {<span style="color: #009900">PathMatch</span>, <span style="color: #009900">Handler</span>, <span style="color: #009900">InitialState</span>}<span style="color: #990000">.</span> -<span style="color: #009900">Path2</span> <span style="color: #990000">=</span> {<span style="color: #009900">PathMatch</span>, <span style="color: #009900">Constraints</span>, <span style="color: #009900">Handler</span>, <span style="color: #009900">InitialState</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Continue reading to learn more about the match syntax and the optional -constraints.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">Path1</font> <font color="#990000">=</font> {<font color="#009900">PathMatch</font>, <font color="#009900">Handler</font>, <font color="#009900">InitialState</font>}<font color="#990000">.</font> +<font color="#009900">Path2</font> <font color="#990000">=</font> {<font color="#009900">PathMatch</font>, <font color="#009900">Constraints</font>, <font color="#009900">Handler</font>, <font color="#009900">InitialState</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>Continue reading to learn more about the match syntax and the optional constraints.</p> <h2 id="_match_syntax">Match syntax</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The match syntax is used to associate host names and paths with their -respective handlers.</p></div> -<div class="paragraph"><p>The match syntax is the same for host and path with a few subtleties. -Indeed, the segments separator is different, and the host is matched -starting from the last segment going to the first. All examples will -feature both host and path match rules and explain the differences -when encountered.</p></div> -<div class="paragraph"><p>Excluding special values that we will explain at the end of this section, -the simplest match value is a host or a path. It can be given as either -a <code>string()</code> or a <code>binary()</code>.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The match syntax is used to associate host names and paths with their respective handlers.</p> +<p>The match syntax is the same for host and path with a few subtleties. Indeed, the segments separator is different, and the host is matched starting from the last segment going to the first. All examples will feature both host and path match rules and explain the differences when encountered.</p> +<p>Excluding special values that we will explain at the end of this section, the simplest match value is a host or a path. It can be given as either a <code>string()</code> or a <code>binary()</code>.</p> +<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><span style="color: #009900">PathMatch1</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"/"</span><span style="color: #990000">.</span> -<span style="color: #009900">PathMatch2</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"/path/to/resource"</span><span style="color: #990000">.</span> - -<span style="color: #009900">HostMatch1</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"cowboy.example.org"</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>As you can see, all paths defined this way must start with a slash -character. Note that these two paths are identical as far as routing -is concerned.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PathMatch1</font> <font color="#990000">=</font> <font color="#FF0000">"/"</font><font color="#990000">.</font> +<font color="#009900">PathMatch2</font> <font color="#990000">=</font> <font color="#FF0000">"/path/to/resource"</font><font color="#990000">.</font> + +<font color="#009900">HostMatch1</font> <font color="#990000">=</font> <font color="#FF0000">"cowboy.example.org"</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>As you can see, all paths defined this way must start with a slash character. Note that these two paths are identical as far as routing is concerned.</p> +<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><span style="color: #009900">PathMatch2</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"/path/to/resource"</span><span style="color: #990000">.</span> -<span style="color: #009900">PathMatch3</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"/path/to/resource/"</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Hosts with and without a trailing dot are equivalent for routing. -Similarly, hosts with and without a leading dot are also equivalent.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PathMatch2</font> <font color="#990000">=</font> <font color="#FF0000">"/path/to/resource"</font><font color="#990000">.</font> +<font color="#009900">PathMatch3</font> <font color="#990000">=</font> <font color="#FF0000">"/path/to/resource/"</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>Hosts with and without a trailing dot are equivalent for routing. Similarly, hosts with and without a leading dot are also equivalent.</p> +<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><span style="color: #009900">HostMatch1</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"cowboy.example.org"</span><span style="color: #990000">.</span> -<span style="color: #009900">HostMatch2</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"cowboy.example.org."</span><span style="color: #990000">.</span> -<span style="color: #009900">HostMatch3</span> <span style="color: #990000">=</span> <span style="color: #FF0000">".cowboy.example.org"</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>It is possible to extract segments of the host and path and to store -the values in the <code>Req</code> object for later use. We call these kind of -values bindings.</p></div> -<div class="paragraph"><p>The syntax for bindings is very simple. A segment that begins with -the <code>:</code> character means that what follows until the end of the segment -is the name of the binding in which the segment value will be stored.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">HostMatch1</font> <font color="#990000">=</font> <font color="#FF0000">"cowboy.example.org"</font><font color="#990000">.</font> +<font color="#009900">HostMatch2</font> <font color="#990000">=</font> <font color="#FF0000">"cowboy.example.org."</font><font color="#990000">.</font> +<font color="#009900">HostMatch3</font> <font color="#990000">=</font> <font color="#FF0000">".cowboy.example.org"</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>It is possible to extract segments of the host and path and to store the values in the <code>Req</code> object for later use. We call these kind of values bindings.</p> +<p>The syntax for bindings is very simple. A segment that begins with the <code>:</code> character means that what follows until the end of the segment is the name of the binding in which the segment value will be stored.</p> +<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><span style="color: #009900">PathMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"/hats/:name/prices"</span><span style="color: #990000">.</span> -<span style="color: #009900">HostMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">":subdomain.example.org"</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>If these two end up matching when routing, you will end up with two -bindings defined, <code>subdomain</code> and <code>name</code>, each containing the -segment value where they were defined. For example, the URL -<code>http://test.example.org/hats/wild_cowboy_legendary/prices</code> will -result in having the value <code>test</code> bound to the name <code>subdomain</code> -and the value <code>wild_cowboy_legendary</code> bound to the name <code>name</code>. -They can later be retrieved using <code>cowboy_req:binding/{2,3}</code>. The -binding name must be given as an atom.</p></div> -<div class="paragraph"><p>There is a special binding name you can use to mimic the underscore -variable in Erlang. Any match against the <code>_</code> binding will succeed -but the data will be discarded. This is especially useful for -matching against many domain names in one go.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PathMatch</font> <font color="#990000">=</font> <font color="#FF0000">"/hats/:name/prices"</font><font color="#990000">.</font> +<font color="#009900">HostMatch</font> <font color="#990000">=</font> <font color="#FF0000">":subdomain.example.org"</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>If these two end up matching when routing, you will end up with two bindings defined, <code>subdomain</code> and <code>name</code>, each containing the segment value where they were defined. For example, the URL <code>http://test.example.org/hats/wild_cowboy_legendary/prices</code> will result in having the value <code>test</code> bound to the name <code>subdomain</code> and the value <code>wild_cowboy_legendary</code> bound to the name <code>name</code>. They can later be retrieved using <code>cowboy_req:binding/{2,3}</code>. The binding name must be given as an atom.</p> +<p>There is a special binding name you can use to mimic the underscore variable in Erlang. Any match against the <code>_</code> binding will succeed but the data will be discarded. This is especially useful for matching against many domain names in one go.</p> +<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><span style="color: #009900">HostMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"ninenines.:_"</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Similarly, it is possible to have optional segments. Anything -between brackets is optional.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">HostMatch</font> <font color="#990000">=</font> <font color="#FF0000">"ninenines.:_"</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>Similarly, it is possible to have optional segments. Anything between brackets is optional.</p> +<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><span style="color: #009900">PathMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"/hats/[page/:number]"</span><span style="color: #990000">.</span> -<span style="color: #009900">HostMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"[www.]ninenines.eu"</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>You can also have imbricated optional segments.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PathMatch</font> <font color="#990000">=</font> <font color="#FF0000">"/hats/[page/:number]"</font><font color="#990000">.</font> +<font color="#009900">HostMatch</font> <font color="#990000">=</font> <font color="#FF0000">"[www.]ninenines.eu"</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>You can also have imbricated optional segments.</p> +<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><span style="color: #009900">PathMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"/hats/[page/[:number]]"</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>You can retrieve the rest of the host or path using <code>[...]</code>. -In the case of hosts it will match anything before, in the case -of paths anything after the previously matched segments. It is -a special case of optional segments, in that it can have -zero, one or many segments. You can then find the segments using -<code>cowboy_req:host_info/1</code> and <code>cowboy_req:path_info/1</code> respectively. -They will be represented as a list of segments.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PathMatch</font> <font color="#990000">=</font> <font color="#FF0000">"/hats/[page/[:number]]"</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>You can retrieve the rest of the host or path using <code>[...]</code>. In the case of hosts it will match anything before, in the case of paths anything after the previously matched segments. It is a special case of optional segments, in that it can have zero, one or many segments. You can then find the segments using <code>cowboy_req:host_info/1</code> and <code>cowboy_req:path_info/1</code> respectively. They will be represented as a list of segments.</p> +<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><span style="color: #009900">PathMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"/hats/[...]"</span><span style="color: #990000">.</span> -<span style="color: #009900">HostMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"[...]ninenines.eu"</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>If a binding appears twice in the routing rules, then the match -will succeed only if they share the same value. This copies the -Erlang pattern matching behavior.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PathMatch</font> <font color="#990000">=</font> <font color="#FF0000">"/hats/[...]"</font><font color="#990000">.</font> +<font color="#009900">HostMatch</font> <font color="#990000">=</font> <font color="#FF0000">"[...]ninenines.eu"</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>If a binding appears twice in the routing rules, then the match will succeed only if they share the same value. This copies the Erlang pattern matching behavior.</p> +<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><span style="color: #009900">PathMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"/hats/:name/:name"</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>This is also true when an optional segment is present. In this -case the two values must be identical only if the segment is -available.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PathMatch</font> <font color="#990000">=</font> <font color="#FF0000">"/hats/:name/:name"</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>This is also true when an optional segment is present. In this case the two values must be identical only if the segment is available.</p> +<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><span style="color: #009900">PathMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"/hats/:name/[:name]"</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>If a binding is defined in both the host and path, then they must -also share the same value.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PathMatch</font> <font color="#990000">=</font> <font color="#FF0000">"/hats/:name/[:name]"</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>If a binding is defined in both the host and path, then they must also share the same value.</p> +<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><span style="color: #009900">PathMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"/:user/[...]"</span><span style="color: #990000">.</span> -<span style="color: #009900">HostMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">":user.github.com"</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Finally, there are two special match values that can be used. The -first is the atom <code>'_'</code> which will match any host or path.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PathMatch</font> <font color="#990000">=</font> <font color="#FF0000">"/:user/[...]"</font><font color="#990000">.</font> +<font color="#009900">HostMatch</font> <font color="#990000">=</font> <font color="#FF0000">":user.github.com"</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>Finally, there are two special match values that can be used. The first is the atom <code>'_'</code> which will match any host or path.</p> +<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><span style="color: #009900">PathMatch</span> <span style="color: #990000">=</span> <span style="color: #FF6600">'_'</span><span style="color: #990000">.</span> -<span style="color: #009900">HostMatch</span> <span style="color: #990000">=</span> <span style="color: #FF6600">'_'</span><span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>The second is the special host match <code>"*"</code> which will match the -wildcard path, generally used alongside the <code>OPTIONS</code> method.</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><font color="#009900">PathMatch</font> <font color="#990000">=</font> <font color="#FF6600">'_'</font><font color="#990000">.</font> +<font color="#009900">HostMatch</font> <font color="#990000">=</font> <font color="#FF6600">'_'</font><font color="#990000">.</font></tt></pre> +</div></div> +<p>The second is the special host match <code>"*"</code> which will match the wildcard path, generally used alongside the <code>OPTIONS</code> method.</p> +<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><span style="color: #009900">HostMatch</span> <span style="color: #990000">=</span> <span style="color: #FF0000">"*"</span><span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><font color="#009900">HostMatch</font> <font color="#990000">=</font> <font color="#FF0000">"*"</font><font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_constraints">Constraints</h2> -<div class="sectionbody"> -<div class="paragraph"><p>After the matching has completed, the resulting bindings can be tested -against a set of constraints. Constraints are only tested when the -binding is defined. They run in the order you defined them. The match -will succeed only if they all succeed. If the match fails, then Cowboy -tries the next route in the list.</p></div> -<div class="paragraph"><p>The format used for constraints is the same as match functions in -<code>cowboy_req</code>: they are provided as a list of fields which may have -one or more constraints. While the router accepts the same format, -it will skip fields with no constraints and will also ignore default -values, if any.</p></div> -<div class="paragraph"><p>Read more about <a href="../constraints">constraints</a>.</p></div> -</div> -</div> -<div class="sect1"> +<p>After the matching has completed, the resulting bindings can be tested against a set of constraints. Constraints are only tested when the binding is defined. They run in the order you defined them. The match will succeed only if they all succeed. If the match fails, then Cowboy tries the next route in the list.</p> +<p>The format used for constraints is the same as match functions in <code>cowboy_req</code>: they are provided as a list of fields which may have one or more constraints. While the router accepts the same format, it will skip fields with no constraints and will also ignore default values, if any.</p> +<p>Read more about <a href="../constraints">constraints</a>.</p> <h2 id="_compilation">Compilation</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The routes must be compiled before Cowboy can use them. The compilation -step normalizes the routes to simplify the code and speed up the -execution, but the routes are still looked up one by one in the end. -Faster compilation strategies could be to compile the routes directly -to Erlang code, but would require heavier dependencies.</p></div> -<div class="paragraph"><p>To compile routes, just call the appropriate function:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The routes must be compiled before Cowboy can use them. The compilation step normalizes the routes to simplify the code and speed up the execution, but the routes are still looked up one by one in the end. Faster compilation strategies could be to compile the routes directly to Erlang code, but would require heavier dependencies.</p> +<p>To compile routes, just call the appropriate function:</p> +<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><span style="color: #009900">Dispatch</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_router:compile</span></span>([ - <span style="font-style: italic"><span style="color: #9A1900">%% {HostMatch, list({PathMatch, Handler, InitialState})}</span></span> - {<span style="color: #FF6600">'_'</span>, [{<span style="color: #FF6600">'_'</span>, <span style="color: #FF6600">my_handler</span>, #{}}]} +<pre><tt><font color="#009900">Dispatch</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_router:compile</font></b>([ + <i><font color="#9A1900">%% {HostMatch, list({PathMatch, Handler, InitialState})}</font></i> + {<font color="#FF6600">'_'</font>, [{<font color="#FF6600">'_'</font>, <font color="#FF6600">my_handler</font>, #{}}]} ]), -<span style="font-style: italic"><span style="color: #9A1900">%% Name, NbAcceptors, TransOpts, ProtoOpts</span></span> -<span style="font-weight: bold"><span style="color: #000000">cowboy:start_clear</span></span>(<span style="color: #FF6600">my_http_listener</span>, - [{<span style="color: #FF6600">port</span>, <span style="color: #993399">8080</span>}], - #{<span style="color: #0000FF">env</span> <span style="color: #990000">=></span> #{<span style="color: #0000FF">dispatch</span> <span style="color: #990000">=></span> <span style="color: #009900">Dispatch</span>}} -)<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<i><font color="#9A1900">%% Name, NbAcceptors, TransOpts, ProtoOpts</font></i> +<b><font color="#000000">cowboy:start_clear</font></b>(<font color="#FF6600">my_http_listener</font>, + [{<font color="#FF6600">port</font>, <font color="#993399">8080</font>}], + #{<font color="#0000FF">env</font> <font color="#990000">=></font> #{<font color="#0000FF">dispatch</font> <font color="#990000">=></font> <font color="#009900">Dispatch</font>}} +)<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_live_update">Live update</h2> -<div class="sectionbody"> -<div class="paragraph"><p>You can use the <code>cowboy:set_env/3</code> function for updating the dispatch -list used by routing. This will apply to all new connections accepted -by the listener:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>You can use the <code>cowboy:set_env/3</code> function for updating the dispatch list used by routing. This will apply to all new connections accepted by the listener:</p> +<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><span style="color: #009900">Dispatch</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_router:compile</span></span>(<span style="color: #009900">Routes</span>), -<span style="font-weight: bold"><span style="color: #000000">cowboy:set_env</span></span>(<span style="color: #FF6600">my_http_listener</span>, <span style="color: #FF6600">dispatch</span>, <span style="color: #009900">Dispatch</span>)<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Note that you need to compile the routes again before updating.</p></div> -</div> -</div> +<pre><tt><font color="#009900">Dispatch</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_router:compile</font></b>(<font color="#009900">Routes</font>), +<b><font color="#000000">cowboy:set_env</font></b>(<font color="#FF6600">my_http_listener</font>, <font color="#FF6600">dispatch</font>, <font color="#009900">Dispatch</font>)<font color="#990000">.</font></tt></pre> +</div></div> +<p>Note that you need to compile the routes again before updating.</p> + diff --git a/docs/en/cowboy/2.3/guide/specs/index.html b/docs/en/cowboy/2.3/guide/specs/index.html index 49ba1e1a..b16bd2fa 100644 --- a/docs/en/cowboy/2.3/guide/specs/index.html +++ b/docs/en/cowboy/2.3/guide/specs/index.html @@ -62,859 +62,345 @@ <h1 class="lined-header"><span>HTTP and other specifications</span></h1> -<div class="paragraph"><p>This chapter intends to list all the specification documents -for or related to HTTP.</p></div> -<div class="sect1"> +<p>This chapter intends to list all the specification documents for or related to HTTP.</p> <h2 id="_http">HTTP</h2> -<div class="sectionbody"> -<div class="sect3"> <h4 id="_iana_registries">IANA Registries</h4> -<div class="ulist"><ul> -<li> -<p> -<a href="https://www.iana.org/assignments/http-methods/http-methods.xhtml">HTTP Method Registry</a> -</p> -</li> -<li> -<p> -<a href="https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml">HTTP Status Code Registry</a> -</p> -</li> -<li> -<p> -<a href="https://www.iana.org/assignments/message-headers/message-headers.xhtml">Message Headers</a> -</p> -</li> -<li> -<p> -<a href="https://www.iana.org/assignments/http-parameters/http-parameters.xhtml">HTTP Parameters</a> -</p> -</li> -<li> -<p> -<a href="https://www.iana.org/assignments/http-alt-svc-parameters/http-alt-svc-parameters.xhtml">HTTP Alt-Svc Parameter Registry</a> -</p> -</li> -<li> -<p> -<a href="https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">HTTP Authentication Scheme Registry</a> -</p> -</li> -<li> -<p> -<a href="https://www.iana.org/assignments/http-cache-directives/http-cache-directives.xhtml">HTTP Cache Directive Registry</a> -</p> -</li> -<li> -<p> -<a href="https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml">HTTP Digest Algorithm Values</a> -</p> -</li> -<li> -<p> -<a href="https://www.iana.org/assignments/hoba-device-identifiers/hoba-device-identifiers.xhtml">HTTP Origin-Bound Authentication Device Identifier Types</a> -</p> -</li> -<li> -<p> -<a href="https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml">HTTP Upgrade Token Registry</a> -</p> -</li> -<li> -<p> -<a href="https://www.iana.org/assignments/http-warn-codes/http-warn-codes.xhtml">HTTP Warn Codes</a> -</p> -</li> -<li> -<p> -<a href="https://www.iana.org/assignments/http2-parameters/http2-parameters.xhtml">HTTP/2 Parameters</a> -</p> -</li> -<li> -<p> -<a href="https://www.ietf.org/assignments/websocket/websocket.xml">WebSocket Protocol Registries</a> -</p> -</li> -</ul></div> -</div> -<div class="sect3"> +<ul><li><a href="https://www.iana.org/assignments/http-methods/http-methods.xhtml">HTTP Method Registry</a> +</li> +<li><a href="https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml">HTTP Status Code Registry</a> +</li> +<li><a href="https://www.iana.org/assignments/message-headers/message-headers.xhtml">Message Headers</a> +</li> +<li><a href="https://www.iana.org/assignments/http-parameters/http-parameters.xhtml">HTTP Parameters</a> +</li> +<li><a href="https://www.iana.org/assignments/http-alt-svc-parameters/http-alt-svc-parameters.xhtml">HTTP Alt-Svc Parameter Registry</a> +</li> +<li><a href="https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">HTTP Authentication Scheme Registry</a> +</li> +<li><a href="https://www.iana.org/assignments/http-cache-directives/http-cache-directives.xhtml">HTTP Cache Directive Registry</a> +</li> +<li><a href="https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml">HTTP Digest Algorithm Values</a> +</li> +<li><a href="https://www.iana.org/assignments/hoba-device-identifiers/hoba-device-identifiers.xhtml">HTTP Origin-Bound Authentication Device Identifier Types</a> +</li> +<li><a href="https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml">HTTP Upgrade Token Registry</a> +</li> +<li><a href="https://www.iana.org/assignments/http-warn-codes/http-warn-codes.xhtml">HTTP Warn Codes</a> +</li> +<li><a href="https://www.iana.org/assignments/http2-parameters/http2-parameters.xhtml">HTTP/2 Parameters</a> +</li> +<li><a href="https://www.ietf.org/assignments/websocket/websocket.xml">WebSocket Protocol Registries</a> +</li> +</ul> <h4 id="_current">Current</h4> -<div class="ulist"><ul> -<li> -<p> -<a href="http://www.w3.org/TR/cors/">CORS</a>: Cross-Origin Resource Sharing -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/CSP2/">CSP2</a>: Content Security Policy Level 2 -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/tracking-dnt/">DNT</a>: Tracking Preference Expression (DNT) -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/eventsource/">eventsource</a>: Server-Sent Events -</p> -</li> -<li> -<p> -<a href="https://www.w3.org/TR/html4/interact/forms.html#h-17.13.4">Form content types</a>: Form content types -</p> -</li> -<li> -<p> -<a href="https://www.w3.org/TR/preload/">Preload</a>: Preload -</p> -</li> -<li> -<p> -<a href="https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt">PROXY</a>: The PROXY protocol -</p> -</li> -<li> -<p> -<a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm">REST</a>: Fielding’s Dissertation -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc1945">RFC 1945</a>: HTTP/1.0 -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc1951">RFC 1951</a>: DEFLATE Compressed Data Format Specification version 1.3 -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc1952">RFC 1952</a>: GZIP file format specification version 4.3 -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2046#section-5.1">RFC 2046</a>: Multipart media type (in MIME Part Two: Media Types) -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2295">RFC 2295</a>: Transparent Content Negotiation in HTTP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2296">RFC 2296</a>: HTTP Remote Variant Selection Algorithm: RVSA/1.0 -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2817">RFC 2817</a>: Upgrading to TLS Within HTTP/1.1 -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2818">RFC 2818</a>: HTTP Over TLS -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc3230">RFC 3230</a>: Instance Digests in HTTP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc4559">RFC 4559</a>: SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc5789">RFC 5789</a>: PATCH Method for HTTP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc5843">RFC 5843</a>: Additional Hash Algorithms for HTTP Instance Digests -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc5861">RFC 5861</a>: HTTP Cache-Control Extensions for Stale Content -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc5988">RFC 5988</a>: Web Linking -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6265">RFC 6265</a>: HTTP State Management Mechanism -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6266">RFC 6266</a>: Use of the Content-Disposition Header Field -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6454">RFC 6454</a>: The Web Origin Concept -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6455">RFC 6455</a>: The WebSocket Protocol -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6585">RFC 6585</a>: Additional HTTP Status Codes -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6750">RFC 6750</a>: The OAuth 2.0 Authorization Framework: Bearer Token Usage -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6797">RFC 6797</a>: HTTP Strict Transport Security (HSTS) -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6903">RFC 6903</a>: Additional Link Relation Types -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7034">RFC 7034</a>: HTTP Header Field X-Frame-Options -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7089">RFC 7089</a>: Time-Based Access to Resource States: Memento -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7230">RFC 7230</a>: HTTP/1.1 Message Syntax and Routing -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7231">RFC 7231</a>: HTTP/1.1 Semantics and Content -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7232">RFC 7232</a>: HTTP/1.1 Conditional Requests -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7233">RFC 7233</a>: HTTP/1.1 Range Requests -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7234">RFC 7234</a>: HTTP/1.1 Caching -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7235">RFC 7235</a>: HTTP/1.1 Authentication -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7239">RFC 7239</a>: Forwarded HTTP Extension -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7240">RFC 7240</a>: Prefer Header for HTTP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7469">RFC 7469</a>: Public Key Pinning Extension for HTTP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7486">RFC 7486</a>: HTTP Origin-Bound Authentication (HOBA) -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7538">RFC 7538</a>: HTTP Status Code 308 (Permanent Redirect) -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7540">RFC 7540</a>: Hypertext Transfer Protocol Version 2 (HTTP/2) -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7541">RFC 7541</a>: HPACK: Header Compression for HTTP/2 -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7578">RFC 7578</a>: Returning Values from Forms: multipart/form-data -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7615">RFC 7615</a>: HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7616">RFC 7616</a>: HTTP Digest Access Authentication -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7617">RFC 7617</a>: The <em>Basic</em> HTTP Authentication Scheme -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7639">RFC 7639</a>: The ALPN HTTP Header Field -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7692">RFC 7692</a>: Compression Extensions for WebSocket -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7694">RFC 7694</a>: HTTP Client-Initiated Content-Encoding -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7725">RFC 7725</a>: An HTTP Status Code to Report Legal Obstacles -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7804">RFC 7804</a>: Salted Challenge Response HTTP Authentication Mechanism -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7838">RFC 7838</a>: HTTP Alternative Services -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7932">RFC 7932</a>: Brotli Compressed Data Format -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7936">RFC 7936</a>: Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8053">RFC 8053</a>: HTTP Authentication Extensions for Interactive Clients -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8164">RFC 8164</a>: Opportunistic Security for HTTP/2 -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8187">RFC 8187</a>: Indicating Character Encoding and Language for HTTP Header Field Parameters -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8188">RFC 8188</a>: Encrypted Content-Encoding for HTTP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8246">RFC 8246</a>: HTTP Immutable Responses -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8297">RFC 8297</a>: An HTTP Status Code for Indicating Hints -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8336">RFC 8336</a>: The ORIGIN HTTP/2 Frame -</p> -</li> -<li> -<p> -<a href="https://www.w3.org/TR/webmention/">Webmention</a>: Webmention -</p> -</li> -</ul></div> -</div> -<div class="sect3"> +<ul><li><a href="http://www.w3.org/TR/cors/">CORS</a>: Cross-Origin Resource Sharing +</li> +<li><a href="http://www.w3.org/TR/CSP2/">CSP2</a>: Content Security Policy Level 2 +</li> +<li><a href="http://www.w3.org/TR/tracking-dnt/">DNT</a>: Tracking Preference Expression (DNT) +</li> +<li><a href="http://www.w3.org/TR/eventsource/">eventsource</a>: Server-Sent Events +</li> +<li><a href="https://www.w3.org/TR/html4/interact/forms.html#h-17.13.4">Form content types</a>: Form content types +</li> +<li><a href="https://www.w3.org/TR/preload/">Preload</a>: Preload +</li> +<li><a href="https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt">PROXY</a>: The PROXY protocol +</li> +<li><a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm">REST</a>: Fielding's Dissertation +</li> +<li><a href="https://tools.ietf.org/html/rfc1945">RFC 1945</a>: HTTP/1.0 +</li> +<li><a href="https://tools.ietf.org/html/rfc1951">RFC 1951</a>: DEFLATE Compressed Data Format Specification version 1.3 +</li> +<li><a href="https://tools.ietf.org/html/rfc1952">RFC 1952</a>: GZIP file format specification version 4.3 +</li> +<li><a href="https://tools.ietf.org/html/rfc2046#section-5.1">RFC 2046</a>: Multipart media type (in MIME Part Two: Media Types) +</li> +<li><a href="https://tools.ietf.org/html/rfc2295">RFC 2295</a>: Transparent Content Negotiation in HTTP +</li> +<li><a href="https://tools.ietf.org/html/rfc2296">RFC 2296</a>: HTTP Remote Variant Selection Algorithm: RVSA/1.0 +</li> +<li><a href="https://tools.ietf.org/html/rfc2817">RFC 2817</a>: Upgrading to TLS Within HTTP/1.1 +</li> +<li><a href="https://tools.ietf.org/html/rfc2818">RFC 2818</a>: HTTP Over TLS +</li> +<li><a href="https://tools.ietf.org/html/rfc3230">RFC 3230</a>: Instance Digests in HTTP +</li> +<li><a href="https://tools.ietf.org/html/rfc4559">RFC 4559</a>: SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows +</li> +<li><a href="https://tools.ietf.org/html/rfc5789">RFC 5789</a>: PATCH Method for HTTP +</li> +<li><a href="https://tools.ietf.org/html/rfc5843">RFC 5843</a>: Additional Hash Algorithms for HTTP Instance Digests +</li> +<li><a href="https://tools.ietf.org/html/rfc5861">RFC 5861</a>: HTTP Cache-Control Extensions for Stale Content +</li> +<li><a href="https://tools.ietf.org/html/rfc5988">RFC 5988</a>: Web Linking +</li> +<li><a href="https://tools.ietf.org/html/rfc6265">RFC 6265</a>: HTTP State Management Mechanism +</li> +<li><a href="https://tools.ietf.org/html/rfc6266">RFC 6266</a>: Use of the Content-Disposition Header Field +</li> +<li><a href="https://tools.ietf.org/html/rfc6454">RFC 6454</a>: The Web Origin Concept +</li> +<li><a href="https://tools.ietf.org/html/rfc6455">RFC 6455</a>: The WebSocket Protocol +</li> +<li><a href="https://tools.ietf.org/html/rfc6585">RFC 6585</a>: Additional HTTP Status Codes +</li> +<li><a href="https://tools.ietf.org/html/rfc6750">RFC 6750</a>: The OAuth 2.0 Authorization Framework: Bearer Token Usage +</li> +<li><a href="https://tools.ietf.org/html/rfc6797">RFC 6797</a>: HTTP Strict Transport Security (HSTS) +</li> +<li><a href="https://tools.ietf.org/html/rfc6903">RFC 6903</a>: Additional Link Relation Types +</li> +<li><a href="https://tools.ietf.org/html/rfc7034">RFC 7034</a>: HTTP Header Field X-Frame-Options +</li> +<li><a href="https://tools.ietf.org/html/rfc7089">RFC 7089</a>: Time-Based Access to Resource States: Memento +</li> +<li><a href="https://tools.ietf.org/html/rfc7230">RFC 7230</a>: HTTP/1.1 Message Syntax and Routing +</li> +<li><a href="https://tools.ietf.org/html/rfc7231">RFC 7231</a>: HTTP/1.1 Semantics and Content +</li> +<li><a href="https://tools.ietf.org/html/rfc7232">RFC 7232</a>: HTTP/1.1 Conditional Requests +</li> +<li><a href="https://tools.ietf.org/html/rfc7233">RFC 7233</a>: HTTP/1.1 Range Requests +</li> +<li><a href="https://tools.ietf.org/html/rfc7234">RFC 7234</a>: HTTP/1.1 Caching +</li> +<li><a href="https://tools.ietf.org/html/rfc7235">RFC 7235</a>: HTTP/1.1 Authentication +</li> +<li><a href="https://tools.ietf.org/html/rfc7239">RFC 7239</a>: Forwarded HTTP Extension +</li> +<li><a href="https://tools.ietf.org/html/rfc7240">RFC 7240</a>: Prefer Header for HTTP +</li> +<li><a href="https://tools.ietf.org/html/rfc7469">RFC 7469</a>: Public Key Pinning Extension for HTTP +</li> +<li><a href="https://tools.ietf.org/html/rfc7486">RFC 7486</a>: HTTP Origin-Bound Authentication (HOBA) +</li> +<li><a href="https://tools.ietf.org/html/rfc7538">RFC 7538</a>: HTTP Status Code 308 (Permanent Redirect) +</li> +<li><a href="https://tools.ietf.org/html/rfc7540">RFC 7540</a>: Hypertext Transfer Protocol Version 2 (HTTP/2) +</li> +<li><a href="https://tools.ietf.org/html/rfc7541">RFC 7541</a>: HPACK: Header Compression for HTTP/2 +</li> +<li><a href="https://tools.ietf.org/html/rfc7578">RFC 7578</a>: Returning Values from Forms: multipart/form-data +</li> +<li><a href="https://tools.ietf.org/html/rfc7615">RFC 7615</a>: HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields +</li> +<li><a href="https://tools.ietf.org/html/rfc7616">RFC 7616</a>: HTTP Digest Access Authentication +</li> +<li><a href="https://tools.ietf.org/html/rfc7617">RFC 7617</a>: The <em>Basic</em> HTTP Authentication Scheme +</li> +<li><a href="https://tools.ietf.org/html/rfc7639">RFC 7639</a>: The ALPN HTTP Header Field +</li> +<li><a href="https://tools.ietf.org/html/rfc7692">RFC 7692</a>: Compression Extensions for WebSocket +</li> +<li><a href="https://tools.ietf.org/html/rfc7694">RFC 7694</a>: HTTP Client-Initiated Content-Encoding +</li> +<li><a href="https://tools.ietf.org/html/rfc7725">RFC 7725</a>: An HTTP Status Code to Report Legal Obstacles +</li> +<li><a href="https://tools.ietf.org/html/rfc7804">RFC 7804</a>: Salted Challenge Response HTTP Authentication Mechanism +</li> +<li><a href="https://tools.ietf.org/html/rfc7838">RFC 7838</a>: HTTP Alternative Services +</li> +<li><a href="https://tools.ietf.org/html/rfc7932">RFC 7932</a>: Brotli Compressed Data Format +</li> +<li><a href="https://tools.ietf.org/html/rfc7936">RFC 7936</a>: Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry +</li> +<li><a href="https://tools.ietf.org/html/rfc8053">RFC 8053</a>: HTTP Authentication Extensions for Interactive Clients +</li> +<li><a href="https://tools.ietf.org/html/rfc8164">RFC 8164</a>: Opportunistic Security for HTTP/2 +</li> +<li><a href="https://tools.ietf.org/html/rfc8187">RFC 8187</a>: Indicating Character Encoding and Language for HTTP Header Field Parameters +</li> +<li><a href="https://tools.ietf.org/html/rfc8188">RFC 8188</a>: Encrypted Content-Encoding for HTTP +</li> +<li><a href="https://tools.ietf.org/html/rfc8246">RFC 8246</a>: HTTP Immutable Responses +</li> +<li><a href="https://tools.ietf.org/html/rfc8297">RFC 8297</a>: An HTTP Status Code for Indicating Hints +</li> +<li><a href="https://tools.ietf.org/html/rfc8336">RFC 8336</a>: The ORIGIN HTTP/2 Frame +</li> +<li><a href="https://www.w3.org/TR/webmention/">Webmention</a>: Webmention +</li> +</ul> <h4 id="_upcoming">Upcoming</h4> -<div class="ulist"><ul> -<li> -<p> -<a href="https://www.w3.org/TR/csp-cookies/">Content Security Policy: Cookie Controls</a> -</p> -</li> -<li> -<p> -<a href="https://www.w3.org/TR/csp-embedded-enforcement/">Content Security Policy: Embedded Enforcement</a> -</p> -</li> -<li> -<p> -<a href="https://www.w3.org/TR/CSP3/">Content Security Policy Level 3</a> -</p> -</li> -<li> -<p> -<a href="https://www.w3.org/TR/csp-pinning/">Content Security Policy Pinning</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/referrer-policy/">Referrer Policy</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/UISecurity/">User Interface Security Directives for Content Security Policy</a> -</p> -</li> -</ul></div> -</div> -<div class="sect3"> +<ul><li><a href="https://www.w3.org/TR/csp-cookies/">Content Security Policy: Cookie Controls</a> +</li> +<li><a href="https://www.w3.org/TR/csp-embedded-enforcement/">Content Security Policy: Embedded Enforcement</a> +</li> +<li><a href="https://www.w3.org/TR/CSP3/">Content Security Policy Level 3</a> +</li> +<li><a href="https://www.w3.org/TR/csp-pinning/">Content Security Policy Pinning</a> +</li> +<li><a href="http://www.w3.org/TR/referrer-policy/">Referrer Policy</a> +</li> +<li><a href="http://www.w3.org/TR/UISecurity/">User Interface Security Directives for Content Security Policy</a> +</li> +</ul> <h4 id="_informative">Informative</h4> -<div class="ulist"><ul> -<li> -<p> -<a href="http://www.w3.org/TR/webarch/">Architecture of the World Wide Web</a> -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2936">RFC 2936</a>: HTTP MIME Type Handler Detection -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2964">RFC 2964</a>: Use of HTTP State Management -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc3143">RFC 3143</a>: Known HTTP Proxy/Caching Problems -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6202">RFC 6202</a>: Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6838">RFC 6838</a>: Media Type Specifications and Registration Procedures -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7478">RFC 7478</a>: Web Real-Time Communication Use Cases and Requirements -</p> -</li> -</ul></div> -</div> -<div class="sect3"> +<ul><li><a href="http://www.w3.org/TR/webarch/">Architecture of the World Wide Web</a> +</li> +<li><a href="https://tools.ietf.org/html/rfc2936">RFC 2936</a>: HTTP MIME Type Handler Detection +</li> +<li><a href="https://tools.ietf.org/html/rfc2964">RFC 2964</a>: Use of HTTP State Management +</li> +<li><a href="https://tools.ietf.org/html/rfc3143">RFC 3143</a>: Known HTTP Proxy/Caching Problems +</li> +<li><a href="https://tools.ietf.org/html/rfc6202">RFC 6202</a>: Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP +</li> +<li><a href="https://tools.ietf.org/html/rfc6838">RFC 6838</a>: Media Type Specifications and Registration Procedures +</li> +<li><a href="https://tools.ietf.org/html/rfc7478">RFC 7478</a>: Web Real-Time Communication Use Cases and Requirements +</li> +</ul> <h4 id="_related">Related</h4> -<div class="ulist"><ul> -<li> -<p> -<a href="http://www.w3.org/TR/app-uri/">app: URL Scheme</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/beacon/">Beacon</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/FileAPI/">File API</a> -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8030">Generic Event Delivery Using HTTP Push</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/capability-urls/">Good Practices for Capability URLs</a> -</p> -</li> -<li> -<p> -<a href="https://html.spec.whatwg.org/multipage/">HTML Living Standard</a> -</p> -</li> -<li> -<p> -<a href="https://developers.whatwg.org/">HTML Living Standard for Web developers</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/html401/">HTML4.01</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/html5/">HTML5</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/html51/">HTML5.1</a> -</p> -</li> -<li> -<p> -<a href="https://www.w3.org/TR/html52/">HTML5.2</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/media-frags/">Media Fragments URI 1.0</a> -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6690">RFC 6690</a>: Constrained RESTful Environments (CoRE) Link Format -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7807">RFC 7807</a>: Problem Details for HTTP APIs -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6906">RFC 6906</a>: The <em>profile</em> Link Relation Type -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/SRI/">Subresource Integrity</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/tracking-compliance/">Tracking Compliance and Scope</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/media-frags-reqs/">Use cases and requirements for Media Fragments</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/webrtc/">WebRTC 1.0: Real-time Communication Between Browsers</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/websockets/">Websocket API</a> -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/XMLHttpRequest/">XMLHttpRequest Level 1</a> -</p> -</li> -<li> -<p> -<a href="https://xhr.spec.whatwg.org/">XMLHttpRequest Living Standard</a> -</p> -</li> -</ul></div> -</div> -<div class="sect3"> +<ul><li><a href="http://www.w3.org/TR/app-uri/">app: URL Scheme</a> +</li> +<li><a href="http://www.w3.org/TR/beacon/">Beacon</a> +</li> +<li><a href="http://www.w3.org/TR/FileAPI/">File API</a> +</li> +<li><a href="https://tools.ietf.org/html/rfc8030">Generic Event Delivery Using HTTP Push</a> +</li> +<li><a href="http://www.w3.org/TR/capability-urls/">Good Practices for Capability URLs</a> +</li> +<li><a href="https://html.spec.whatwg.org/multipage/">HTML Living Standard</a> +</li> +<li><a href="https://developers.whatwg.org/">HTML Living Standard for Web developers</a> +</li> +<li><a href="http://www.w3.org/TR/html401/">HTML4.01</a> +</li> +<li><a href="http://www.w3.org/TR/html5/">HTML5</a> +</li> +<li><a href="http://www.w3.org/TR/html51/">HTML5.1</a> +</li> +<li><a href="https://www.w3.org/TR/html52/">HTML5.2</a> +</li> +<li><a href="http://www.w3.org/TR/media-frags/">Media Fragments URI 1.0</a> +</li> +<li><a href="https://tools.ietf.org/html/rfc6690">RFC 6690</a>: Constrained RESTful Environments (CoRE) Link Format +</li> +<li><a href="https://tools.ietf.org/html/rfc7807">RFC 7807</a>: Problem Details for HTTP APIs +</li> +<li><a href="https://tools.ietf.org/html/rfc6906">RFC 6906</a>: The <em>profile</em> Link Relation Type +</li> +<li><a href="http://www.w3.org/TR/SRI/">Subresource Integrity</a> +</li> +<li><a href="http://www.w3.org/TR/tracking-compliance/">Tracking Compliance and Scope</a> +</li> +<li><a href="http://www.w3.org/TR/media-frags-reqs/">Use cases and requirements for Media Fragments</a> +</li> +<li><a href="http://www.w3.org/TR/webrtc/">WebRTC 1.0: Real-time Communication Between Browsers</a> +</li> +<li><a href="http://www.w3.org/TR/websockets/">Websocket API</a> +</li> +<li><a href="http://www.w3.org/TR/XMLHttpRequest/">XMLHttpRequest Level 1</a> +</li> +<li><a href="https://xhr.spec.whatwg.org/">XMLHttpRequest Living Standard</a> +</li> +</ul> <h4 id="_seemingly_obsolete">Seemingly obsolete</h4> -<div class="ulist"><ul> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2227">RFC 2227</a>: Simple Hit-Metering and Usage-Limiting for HTTP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2310">RFC 2310</a>: The Safe Response Header Field -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2324">RFC 2324</a>: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2660">RFC 2660</a>: The Secure HyperText Transfer Protocol -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2774">RFC 2774</a>: An HTTP Extension Framework -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc2965">RFC 2965</a>: HTTP State Management Mechanism (Cookie2) -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc3229">RFC 3229</a>: Delta encoding in HTTP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7168">RFC 7168</a>: The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) -</p> -</li> -<li> -<p> -<a href="http://dev.chromium.org/spdy/spdy-protocol">SPDY</a>: SPDY Protocol -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-06">x-webkit-deflate-frame</a>: Deprecated Websocket compression -</p> -</li> -</ul></div> -</div> -</div> -</div> -<div class="sect1"> +<ul><li><a href="https://tools.ietf.org/html/rfc2227">RFC 2227</a>: Simple Hit-Metering and Usage-Limiting for HTTP +</li> +<li><a href="https://tools.ietf.org/html/rfc2310">RFC 2310</a>: The Safe Response Header Field +</li> +<li><a href="https://tools.ietf.org/html/rfc2324">RFC 2324</a>: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) +</li> +<li><a href="https://tools.ietf.org/html/rfc2660">RFC 2660</a>: The Secure HyperText Transfer Protocol +</li> +<li><a href="https://tools.ietf.org/html/rfc2774">RFC 2774</a>: An HTTP Extension Framework +</li> +<li><a href="https://tools.ietf.org/html/rfc2965">RFC 2965</a>: HTTP State Management Mechanism (Cookie2) +</li> +<li><a href="https://tools.ietf.org/html/rfc3229">RFC 3229</a>: Delta encoding in HTTP +</li> +<li><a href="https://tools.ietf.org/html/rfc7168">RFC 7168</a>: The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) +</li> +<li><a href="http://dev.chromium.org/spdy/spdy-protocol">SPDY</a>: SPDY Protocol +</li> +<li><a href="https://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-06">x-webkit-deflate-frame</a>: Deprecated Websocket compression +</li> +</ul> <h2 id="_url">URL</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc3986">RFC 3986</a>: URI Generic Syntax -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6570">RFC 6570</a>: URI Template -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6874">RFC 6874</a>: Representing IPv6 Zone Identifiers in Address Literals and URIs -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7320">RFC 7320</a>: URI Design and Ownership -</p> -</li> -<li> -<p> -<a href="http://www.w3.org/TR/url-1/">URL</a> -</p> -</li> -<li> -<p> -<a href="https://url.spec.whatwg.org/">URL Living Standard</a> -</p> -</li> -</ul></div> -</div> -</div> -<div class="sect1"> +<ul><li><a href="https://tools.ietf.org/html/rfc3986">RFC 3986</a>: URI Generic Syntax +</li> +<li><a href="https://tools.ietf.org/html/rfc6570">RFC 6570</a>: URI Template +</li> +<li><a href="https://tools.ietf.org/html/rfc6874">RFC 6874</a>: Representing IPv6 Zone Identifiers in Address Literals and URIs +</li> +<li><a href="https://tools.ietf.org/html/rfc7320">RFC 7320</a>: URI Design and Ownership +</li> +<li><a href="http://www.w3.org/TR/url-1/">URL</a> +</li> +<li><a href="https://url.spec.whatwg.org/">URL Living Standard</a> +</li> +</ul> <h2 id="_webdav">WebDAV</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc3253">RFC 3253</a>: Versioning Extensions to WebDAV -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc3648">RFC 3648</a>: WebDAV Ordered Collections Protocol -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc3744">RFC 3744</a>: WebDAV Access Control Protocol -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc4316">RFC 4316</a>: Datatypes for WebDAV Properties -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc4331">RFC 4331</a>: Quota and Size Properties for DAV Collections -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc4437">RFC 4437</a>: WebDAV Redirect Reference Resources -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc4709">RFC 4709</a>: Mounting WebDAV Servers -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc4791">RFC 4791</a>: Calendaring Extensions to WebDAV (CalDAV) -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc4918">RFC 4918</a>: HTTP Extensions for WebDAV -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc5323">RFC 5323</a>: WebDAV SEARCH -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc5397">RFC 5397</a>: WebDAV Current Principal Extension -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc5689">RFC 5689</a>: Extended MKCOL for WebDAV -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc5842">RFC 5842</a>: Binding Extensions to WebDAV -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc5995">RFC 5995</a>: Using POST to Add Members to WebDAV Collections -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6352">RFC 6352</a>: CardDAV: vCard Extensions to WebDAV -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6578">RFC 6578</a>: Collection Synchronization for WebDAV -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6638">RFC 6638</a>: Scheduling Extensions to CalDAV -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc6764">RFC 6764</a>: Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7809">RFC 7809</a>: Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7953">RFC 7953</a>: Calendar Availability -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8144">RFC 8144</a>: Use of the Prefer Header Field in WebDAV -</p> -</li> -</ul></div> -</div> -</div> -<div class="sect1"> +<ul><li><a href="https://tools.ietf.org/html/rfc3253">RFC 3253</a>: Versioning Extensions to WebDAV +</li> +<li><a href="https://tools.ietf.org/html/rfc3648">RFC 3648</a>: WebDAV Ordered Collections Protocol +</li> +<li><a href="https://tools.ietf.org/html/rfc3744">RFC 3744</a>: WebDAV Access Control Protocol +</li> +<li><a href="https://tools.ietf.org/html/rfc4316">RFC 4316</a>: Datatypes for WebDAV Properties +</li> +<li><a href="https://tools.ietf.org/html/rfc4331">RFC 4331</a>: Quota and Size Properties for DAV Collections +</li> +<li><a href="https://tools.ietf.org/html/rfc4437">RFC 4437</a>: WebDAV Redirect Reference Resources +</li> +<li><a href="https://tools.ietf.org/html/rfc4709">RFC 4709</a>: Mounting WebDAV Servers +</li> +<li><a href="https://tools.ietf.org/html/rfc4791">RFC 4791</a>: Calendaring Extensions to WebDAV (CalDAV) +</li> +<li><a href="https://tools.ietf.org/html/rfc4918">RFC 4918</a>: HTTP Extensions for WebDAV +</li> +<li><a href="https://tools.ietf.org/html/rfc5323">RFC 5323</a>: WebDAV SEARCH +</li> +<li><a href="https://tools.ietf.org/html/rfc5397">RFC 5397</a>: WebDAV Current Principal Extension +</li> +<li><a href="https://tools.ietf.org/html/rfc5689">RFC 5689</a>: Extended MKCOL for WebDAV +</li> +<li><a href="https://tools.ietf.org/html/rfc5842">RFC 5842</a>: Binding Extensions to WebDAV +</li> +<li><a href="https://tools.ietf.org/html/rfc5995">RFC 5995</a>: Using POST to Add Members to WebDAV Collections +</li> +<li><a href="https://tools.ietf.org/html/rfc6352">RFC 6352</a>: CardDAV: vCard Extensions to WebDAV +</li> +<li><a href="https://tools.ietf.org/html/rfc6578">RFC 6578</a>: Collection Synchronization for WebDAV +</li> +<li><a href="https://tools.ietf.org/html/rfc6638">RFC 6638</a>: Scheduling Extensions to CalDAV +</li> +<li><a href="https://tools.ietf.org/html/rfc6764">RFC 6764</a>: Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) +</li> +<li><a href="https://tools.ietf.org/html/rfc7809">RFC 7809</a>: Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference +</li> +<li><a href="https://tools.ietf.org/html/rfc7953">RFC 7953</a>: Calendar Availability +</li> +<li><a href="https://tools.ietf.org/html/rfc8144">RFC 8144</a>: Use of the Prefer Header Field in WebDAV +</li> +</ul> <h2 id="_coap">CoAP</h2> -<div class="sectionbody"> -<div class="ulist"><ul> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7252">RFC 7252</a>: The Constrained Application Protocol (CoAP) -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7390">RFC 7390</a>: Group Communication for CoAP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7641">RFC 7641</a>: Observing Resources in CoAP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7650">RFC 7650</a>: A CoAP Usage for REsource LOcation And Discovery (RELOAD) -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7959">RFC 7959</a>: Block-Wise Transfers in CoAP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc7967">RFC 7967</a>: CoAP Option for No Server Response -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8075">RFC 8075</a>: Guidelines for Mapping Implementations: HTTP to CoAP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8132">RFC 8132</a>: PATCH and FETCH Methods for CoAP -</p> -</li> -<li> -<p> -<a href="https://tools.ietf.org/html/rfc8323">RFC 8323</a>: CoAP over TCP, TLS, and WebSockets -</p> -</li> -</ul></div> -</div> -</div> +<ul><li><a href="https://tools.ietf.org/html/rfc7252">RFC 7252</a>: The Constrained Application Protocol (CoAP) +</li> +<li><a href="https://tools.ietf.org/html/rfc7390">RFC 7390</a>: Group Communication for CoAP +</li> +<li><a href="https://tools.ietf.org/html/rfc7641">RFC 7641</a>: Observing Resources in CoAP +</li> +<li><a href="https://tools.ietf.org/html/rfc7650">RFC 7650</a>: A CoAP Usage for REsource LOcation And Discovery (RELOAD) +</li> +<li><a href="https://tools.ietf.org/html/rfc7959">RFC 7959</a>: Block-Wise Transfers in CoAP +</li> +<li><a href="https://tools.ietf.org/html/rfc7967">RFC 7967</a>: CoAP Option for No Server Response +</li> +<li><a href="https://tools.ietf.org/html/rfc8075">RFC 8075</a>: Guidelines for Mapping Implementations: HTTP to CoAP +</li> +<li><a href="https://tools.ietf.org/html/rfc8132">RFC 8132</a>: PATCH and FETCH Methods for CoAP +</li> +<li><a href="https://tools.ietf.org/html/rfc8323">RFC 8323</a>: CoAP over TCP, TLS, and WebSockets +</li> +</ul> + diff --git a/docs/en/cowboy/2.3/guide/static_files/index.html b/docs/en/cowboy/2.3/guide/static_files/index.html index 5b5bbd0b..f3fe3254 100644 --- a/docs/en/cowboy/2.3/guide/static_files/index.html +++ b/docs/en/cowboy/2.3/guide/static_files/index.html @@ -62,173 +62,101 @@ <h1 class="lined-header"><span>Static files</span></h1> -<div class="paragraph"><p>Cowboy comes with a ready to use handler for serving static -files. It is provided as a convenience for serving files -during development.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>The static handler can serve either one file or all files -from a given directory. The etag generation and mime types -can be configured.</p></div> -<div class="sect1"> +<p>Cowboy comes with a ready to use handler for serving static files. It is provided as a convenience for serving files during development.</p> +<p>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.</p> +<p>The static handler can serve either one file or all files from a given directory. The etag generation and mime types can be configured.</p> <h2 id="_serve_one_file">Serve one file</h2> -<div class="sectionbody"> -<div class="paragraph"><p>You can use the static handler to serve one specific file -from an application’s private directory. This is particularly -useful to serve an <em>index.html</em> file when the client requests -the <code>/</code> path, for example. The path configured is relative -to the given application’s private directory.</p></div> -<div class="paragraph"><p>The following rule will serve the file <em>static/index.html</em> -from the application <code>my_app</code>'s priv directory whenever the -path <code>/</code> is accessed:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>You can use the static handler to serve one specific file from an application's private directory. This is particularly useful to serve an <em>index.html</em> file when the client requests the <code>/</code> path, for example. The path configured is relative to the given application's private directory.</p> +<p>The following rule will serve the file <em>static/index.html</em> from the application <code>my_app</code>'s priv directory whenever the path <code>/</code> is accessed:</p> +<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>{<span style="color: #FF0000">"/"</span>, <span style="color: #FF6600">cowboy_static</span>, {<span style="color: #FF6600">priv_file</span>, <span style="color: #FF6600">my_app</span>, <span style="color: #FF0000">"static/index.html"</span>}}</tt></pre></div></div> -<div class="paragraph"><p>You can also specify the absolute path to a file, or the -path to the file relative to the current directory:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>{<font color="#FF0000">"/"</font>, <font color="#FF6600">cowboy_static</font>, {<font color="#FF6600">priv_file</font>, <font color="#FF6600">my_app</font>, <font color="#FF0000">"static/index.html"</font>}}</tt></pre> +</div></div> +<p>You can also specify the absolute path to a file, or the path to the file relative to the current directory:</p> +<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>{<span style="color: #FF0000">"/"</span>, <span style="color: #FF6600">cowboy_static</span>, {<span style="color: #FF6600">file</span>, <span style="color: #FF0000">"/var/www/index.html"</span>}}</tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt>{<font color="#FF0000">"/"</font>, <font color="#FF6600">cowboy_static</font>, {<font color="#FF6600">file</font>, <font color="#FF0000">"/var/www/index.html"</font>}}</tt></pre> +</div></div> <h2 id="_serve_all_files_from_a_directory">Serve all files from a directory</h2> -<div class="sectionbody"> -<div class="paragraph"><p>You can also use the static handler to serve all files that -can be found in the configured directory. The handler will -use the <code>path_info</code> information to resolve the file location, -which means that your route must end with a <code>[...]</code> pattern -for it to work. All files are served, including the ones that -may be found in subfolders.</p></div> -<div class="paragraph"><p>You can specify the directory relative to an application’s -private directory.</p></div> -<div class="paragraph"><p>The following rule will serve any file found in the application -<code>my_app</code>'s priv directory inside the <code>static/assets</code> folder -whenever the requested path begins with <code>/assets/</code>:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>You can also use the static handler to serve all files that can be found in the configured directory. The handler will use the <code>path_info</code> information to resolve the file location, which means that your route must end with a <code>[...]</code> pattern for it to work. All files are served, including the ones that may be found in subfolders.</p> +<p>You can specify the directory relative to an application's private directory.</p> +<p>The following rule will serve any file found in the application <code>my_app</code>'s priv directory inside the <code>static/assets</code> folder whenever the requested path begins with <code>/assets/</code>:</p> +<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>{<span style="color: #FF0000">"/assets/[...]"</span>, <span style="color: #FF6600">cowboy_static</span>, {<span style="color: #FF6600">priv_dir</span>, <span style="color: #FF6600">my_app</span>, <span style="color: #FF0000">"static/assets"</span>}}</tt></pre></div></div> -<div class="paragraph"><p>You can also specify the absolute path to the directory or -set it relative to the current directory:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>{<font color="#FF0000">"/assets/[...]"</font>, <font color="#FF6600">cowboy_static</font>, {<font color="#FF6600">priv_dir</font>, <font color="#FF6600">my_app</font>, <font color="#FF0000">"static/assets"</font>}}</tt></pre> +</div></div> +<p>You can also specify the absolute path to the directory or set it relative to the current directory:</p> +<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>{<span style="color: #FF0000">"/assets/[...]"</span>, <span style="color: #FF6600">cowboy_static</span>, {<span style="color: #FF6600">dir</span>, <span style="color: #FF0000">"/var/www/assets"</span>}}</tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt>{<font color="#FF0000">"/assets/[...]"</font>, <font color="#FF6600">cowboy_static</font>, {<font color="#FF6600">dir</font>, <font color="#FF0000">"/var/www/assets"</font>}}</tt></pre> +</div></div> <h2 id="_customize_the_mimetype_detection">Customize the mimetype detection</h2> -<div class="sectionbody"> -<div class="paragraph"><p>By default, Cowboy will attempt to recognize the mimetype -of your static files by looking at the extension.</p></div> -<div class="paragraph"><p>You can override the function that figures out the mimetype -of the static files. It can be useful when Cowboy is missing -a mimetype you need to handle, or when you want to reduce -the list to make lookups faster. You can also give a -hard-coded mimetype that will be used unconditionally.</p></div> -<div class="paragraph"><p>Cowboy comes with two functions built-in. The default -function only handles common file types used when building -Web applications. The other function is an extensive list -of hundreds of mimetypes that should cover almost any need -you may have. You can of course create your own function.</p></div> -<div class="paragraph"><p>To use the default function, you should not have to configure -anything, as it is the default. If you insist, though, the -following will do the job:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>By default, Cowboy will attempt to recognize the mimetype of your static files by looking at the extension.</p> +<p>You can override the function that figures out the mimetype of the static files. It can be useful when Cowboy is missing a mimetype you need to handle, or when you want to reduce the list to make lookups faster. You can also give a hard-coded mimetype that will be used unconditionally.</p> +<p>Cowboy comes with two functions built-in. The default function only handles common file types used when building Web applications. The other function is an extensive list of hundreds of mimetypes that should cover almost any need you may have. You can of course create your own function.</p> +<p>To use the default function, you should not have to configure anything, as it is the default. If you insist, though, the following will do the job:</p> +<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>{<span style="color: #FF0000">"/assets/[...]"</span>, <span style="color: #FF6600">cowboy_static</span>, {<span style="color: #FF6600">priv_dir</span>, <span style="color: #FF6600">my_app</span>, <span style="color: #FF0000">"static/assets"</span>, - [{<span style="color: #FF6600">mimetypes</span>, <span style="color: #FF6600">cow_mimetypes</span>, <span style="color: #FF6600">web</span>}]}}</tt></pre></div></div> -<div class="paragraph"><p>As you can see, there is an optional field that may contain -a list of less used options, like mimetypes or etag. All option -types have this optional field.</p></div> -<div class="paragraph"><p>To use the function that will detect almost any mimetype, -the following configuration will do:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>{<font color="#FF0000">"/assets/[...]"</font>, <font color="#FF6600">cowboy_static</font>, {<font color="#FF6600">priv_dir</font>, <font color="#FF6600">my_app</font>, <font color="#FF0000">"static/assets"</font>, + [{<font color="#FF6600">mimetypes</font>, <font color="#FF6600">cow_mimetypes</font>, <font color="#FF6600">web</font>}]}}</tt></pre> +</div></div> +<p>As you can see, there is an optional field that may contain a list of less used options, like mimetypes or etag. All option types have this optional field.</p> +<p>To use the function that will detect almost any mimetype, the following configuration will do:</p> +<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>{<span style="color: #FF0000">"/assets/[...]"</span>, <span style="color: #FF6600">cowboy_static</span>, {<span style="color: #FF6600">priv_dir</span>, <span style="color: #FF6600">my_app</span>, <span style="color: #FF0000">"static/assets"</span>, - [{<span style="color: #FF6600">mimetypes</span>, <span style="color: #FF6600">cow_mimetypes</span>, <span style="color: #FF6600">all</span>}]}}</tt></pre></div></div> -<div class="paragraph"><p>You probably noticed the pattern by now. The configuration -expects a module and a function name, so you can use any -of your own functions instead:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>{<font color="#FF0000">"/assets/[...]"</font>, <font color="#FF6600">cowboy_static</font>, {<font color="#FF6600">priv_dir</font>, <font color="#FF6600">my_app</font>, <font color="#FF0000">"static/assets"</font>, + [{<font color="#FF6600">mimetypes</font>, <font color="#FF6600">cow_mimetypes</font>, <font color="#FF6600">all</font>}]}}</tt></pre> +</div></div> +<p>You probably noticed the pattern by now. The configuration expects a module and a function name, so you can use any of your own functions instead:</p> +<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>{<span style="color: #FF0000">"/assets/[...]"</span>, <span style="color: #FF6600">cowboy_static</span>, {<span style="color: #FF6600">priv_dir</span>, <span style="color: #FF6600">my_app</span>, <span style="color: #FF0000">"static/assets"</span>, - [{<span style="color: #FF6600">mimetypes</span>, <span style="color: #009900">Module</span>, <span style="color: #009900">Function</span>}]}}</tt></pre></div></div> -<div class="paragraph"><p>The function that performs the mimetype detection receives -a single argument that is the path to the file on disk. It -is recommended to return the mimetype in tuple form, although -a binary string is also allowed (but will require extra -processing). If the function can’t figure out the mimetype, -then it should return <code>{<<"application">>, <<"octet-stream">>, []}</code>.</p></div> -<div class="paragraph"><p>When the static handler fails to find the extension, -it will send the file as <code>application/octet-stream</code>. -A browser receiving such file will attempt to download it -directly to disk.</p></div> -<div class="paragraph"><p>Finally, the mimetype can be hard-coded for all files. -This is especially useful in combination with the <code>file</code> -and <code>priv_file</code> options as it avoids needless computation:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>{<font color="#FF0000">"/assets/[...]"</font>, <font color="#FF6600">cowboy_static</font>, {<font color="#FF6600">priv_dir</font>, <font color="#FF6600">my_app</font>, <font color="#FF0000">"static/assets"</font>, + [{<font color="#FF6600">mimetypes</font>, <font color="#009900">Module</font>, <font color="#009900">Function</font>}]}}</tt></pre> +</div></div> +<p>The function that performs the mimetype detection receives a single argument that is the path to the file on disk. It is recommended to return the mimetype in tuple form, although a binary string is also allowed (but will require extra processing). If the function can't figure out the mimetype, then it should return <code>{<<"application">>, <<"octet-stream">>, []}</code>.</p> +<p>When the static handler fails to find the extension, it will send the file as <code>application/octet-stream</code>. A browser receiving such file will attempt to download it directly to disk.</p> +<p>Finally, the mimetype can be hard-coded for all files. This is especially useful in combination with the <code>file</code> and <code>priv_file</code> options as it avoids needless computation:</p> +<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>{<span style="color: #FF0000">"/"</span>, <span style="color: #FF6600">cowboy_static</span>, {<span style="color: #FF6600">priv_file</span>, <span style="color: #FF6600">my_app</span>, <span style="color: #FF0000">"static/index.html"</span>, - [{<span style="color: #FF6600">mimetypes</span>, {<span style="color: #990000"><<</span><span style="color: #FF0000">"text"</span><span style="color: #990000">>></span>, <span style="color: #990000"><<</span><span style="color: #FF0000">"html"</span><span style="color: #990000">>></span>, []}}]}}</tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt>{<font color="#FF0000">"/"</font>, <font color="#FF6600">cowboy_static</font>, {<font color="#FF6600">priv_file</font>, <font color="#FF6600">my_app</font>, <font color="#FF0000">"static/index.html"</font>, + [{<font color="#FF6600">mimetypes</font>, {<font color="#990000"><<</font><font color="#FF0000">"text"</font><font color="#990000">>></font>, <font color="#990000"><<</font><font color="#FF0000">"html"</font><font color="#990000">>></font>, []}}]}}</tt></pre> +</div></div> <h2 id="_generate_an_etag">Generate an etag</h2> -<div class="sectionbody"> -<div class="paragraph"><p>By default, the static handler will generate an etag header -value based on the size and modified time. This solution -can not be applied to all systems though. It would perform -rather poorly over a cluster of nodes, for example, as the -file metadata will vary from server to server, giving a -different etag on each server.</p></div> -<div class="paragraph"><p>You can however change the way the etag is calculated:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>By default, the static handler will generate an etag header value based on the size and modified time. This solution can not be applied to all systems though. It would perform rather poorly over a cluster of nodes, for example, as the file metadata will vary from server to server, giving a different etag on each server.</p> +<p>You can however change the way the etag is calculated:</p> +<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>{<span style="color: #FF0000">"/assets/[...]"</span>, <span style="color: #FF6600">cowboy_static</span>, {<span style="color: #FF6600">priv_dir</span>, <span style="color: #FF6600">my_app</span>, <span style="color: #FF0000">"static/assets"</span>, - [{<span style="color: #FF6600">etag</span>, <span style="color: #009900">Module</span>, <span style="color: #009900">Function</span>}]}}</tt></pre></div></div> -<div class="paragraph"><p>This function will receive three arguments: the path to the -file on disk, the size of the file and the last modification -time. In a distributed setup, you would typically use the -file path to retrieve an etag value that is identical across -all your servers.</p></div> -<div class="paragraph"><p>You can also completely disable etag handling:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt>{<font color="#FF0000">"/assets/[...]"</font>, <font color="#FF6600">cowboy_static</font>, {<font color="#FF6600">priv_dir</font>, <font color="#FF6600">my_app</font>, <font color="#FF0000">"static/assets"</font>, + [{<font color="#FF6600">etag</font>, <font color="#009900">Module</font>, <font color="#009900">Function</font>}]}}</tt></pre> +</div></div> +<p>This function will receive three arguments: the path to the file on disk, the size of the file and the last modification time. In a distributed setup, you would typically use the file path to retrieve an etag value that is identical across all your servers.</p> +<p>You can also completely disable etag handling:</p> +<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>{<span style="color: #FF0000">"/assets/[...]"</span>, <span style="color: #FF6600">cowboy_static</span>, {<span style="color: #FF6600">priv_dir</span>, <span style="color: #FF6600">my_app</span>, <span style="color: #FF0000">"static/assets"</span>, - [{<span style="color: #FF6600">etag</span>, <span style="color: #000080">false</span>}]}}</tt></pre></div></div> -</div> -</div> +<pre><tt>{<font color="#FF0000">"/assets/[...]"</font>, <font color="#FF6600">cowboy_static</font>, {<font color="#FF6600">priv_dir</font>, <font color="#FF6600">my_app</font>, <font color="#FF0000">"static/assets"</font>, + [{<font color="#FF6600">etag</font>, <font color="#000080">false</font>}]}}</tt></pre> +</div></div> + diff --git a/docs/en/cowboy/2.3/guide/streams/index.html b/docs/en/cowboy/2.3/guide/streams/index.html index 4c621525..7f936431 100644 --- a/docs/en/cowboy/2.3/guide/streams/index.html +++ b/docs/en/cowboy/2.3/guide/streams/index.html @@ -62,61 +62,23 @@ <h1 class="lined-header"><span>Streams</span></h1> -<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"> +<p>A stream is the set of messages that form an HTTP request/response pair.</p> +<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> +<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> <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"> +<p>Stream handlers must implement five different callbacks. Four of them are directly related; one is special.</p> +<p>All callbacks receives the stream ID as first argument.</p> +<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> +<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> +<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> +<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> +<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> +<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> <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> +<p>Cowboy comes with two handlers.</p> +<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> +<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> + diff --git a/docs/en/cowboy/2.3/guide/ws_handlers/index.html b/docs/en/cowboy/2.3/guide/ws_handlers/index.html index ab028875..6fca9cf9 100644 --- a/docs/en/cowboy/2.3/guide/ws_handlers/index.html +++ b/docs/en/cowboy/2.3/guide/ws_handlers/index.html @@ -62,297 +62,190 @@ <h1 class="lined-header"><span>Websocket handlers</span></h1> -<div class="paragraph"><p>Websocket handlers provide an interface for upgrading HTTP/1.1 -connections to Websocket and sending or receiving frames on -the Websocket connection.</p></div> -<div class="paragraph"><p>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.</p></div> -<div class="sect1"> +<p>Websocket handlers provide an interface for upgrading HTTP/1.1 connections to Websocket and sending or receiving frames on the Websocket connection.</p> +<p>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.</p> <h2 id="_upgrade">Upgrade</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The <code>init/2</code> callback is called when the request is received. -To establish a Websocket connection, you must switch to the -<code>cowboy_websocket</code> module:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The <code>init/2</code> callback is called when the request is received. To establish a Websocket connection, you must switch to the <code>cowboy_websocket</code> module:</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">cowboy_websocket</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Cowboy will perform the Websocket handshake immediately. Note -that the handshake will fail if the client did not request an -upgrade to Websocket.</p></div> -<div class="paragraph"><p>The Req object becomes unavailable after this function returns. -Any information required for proper execution of the Websocket -handler must be saved in the state.</p></div> -</div> -</div> -<div class="sect1"> -<h2 id="_subprotocol">Subprotocol</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The client may provide a list of Websocket subprotocols it -supports in the sec-websocket-protocol header. The server <strong>must</strong> -select one of them and send it back to the client or the -handshake will fail.</p></div> -<div class="paragraph"><p>For example, a client could understand both STOMP and MQTT over -Websocket, and provide the header:</p></div> -<div class="listingblock"> -<div class="content"> -<pre><code>sec-websocket-protocol: v12.stomp, mqtt</code></pre> +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">cowboy_websocket</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> </div></div> -<div class="paragraph"><p>If the server only understands MQTT it can return:</p></div> -<div class="listingblock"> -<div class="content"> -<pre><code>sec-websocket-protocol: mqtt</code></pre> -</div></div> -<div class="paragraph"><p>This selection must be done in <code>init/2</code>. An example usage could -be:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy will perform the Websocket handshake immediately. Note that the handshake will fail if the client did not request an upgrade to Websocket.</p> +<p>The Req object becomes unavailable after this function returns. Any information required for proper execution of the Websocket handler must be saved in the state.</p> +<h2 id="_subprotocol">Subprotocol</h2> +<p>The client may provide a list of Websocket subprotocols it supports in the sec-websocket-protocol header. The server <strong>must</strong> select one of them and send it back to the client or the handshake will fail.</p> +<p>For example, a client could understand both STOMP and MQTT over Websocket, and provide the header:</p> +<div class="listingblock"><div class="content"><pre>sec-websocket-protocol: v12.stomp, mqtt</pre></div></div> +<p>If the server only understands MQTT it can return:</p> +<div class="listingblock"><div class="content"><pre>sec-websocket-protocol: mqtt</pre></div></div> +<p>This selection must be done in <code>init/2</code>. An example usage could be:</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req0</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #0000FF">case</span></span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:parse_header</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"sec-websocket-protocol"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req0</span>) <span style="font-weight: bold"><span style="color: #0000FF">of</span></span> - <span style="color: #000080">undefined</span> <span style="color: #990000">-></span> - {<span style="color: #FF6600">cowboy_websocket</span>, <span style="color: #009900">Req0</span>, <span style="color: #009900">State</span>}; - <span style="color: #009900">Subprotocols</span> <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #0000FF">case</span></span> <span style="font-weight: bold"><span style="color: #000000">lists:keymember</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"mqtt"</span><span style="color: #990000">>></span>, <span style="color: #993399">1</span>, <span style="color: #009900">Subprotocols</span>) <span style="font-weight: bold"><span style="color: #0000FF">of</span></span> - <span style="color: #000080">true</span> <span style="color: #990000">-></span> - <span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:set_resp_header</span></span>(<span style="color: #990000"><<</span><span style="color: #FF0000">"sec-websocket-protocol"</span><span style="color: #990000">>></span>, - <span style="color: #990000"><<</span><span style="color: #FF0000">"mqtt"</span><span style="color: #990000">>></span>, <span style="color: #009900">Req0</span>), - {<span style="color: #FF6600">cowboy_websocket</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>}; - <span style="color: #000080">false</span> <span style="color: #990000">-></span> - <span style="color: #009900">Req</span> <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #000000">cowboy_req:reply</span></span>(<span style="color: #993399">400</span>, <span style="color: #009900">Req0</span>), - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>} - <span style="font-weight: bold"><span style="color: #0000FF">end</span></span> - <span style="font-weight: bold"><span style="color: #0000FF">end</span></span><span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req0</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + <b><font color="#0000FF">case</font></b> <b><font color="#000000">cowboy_req:parse_header</font></b>(<font color="#990000"><<</font><font color="#FF0000">"sec-websocket-protocol"</font><font color="#990000">>></font>, <font color="#009900">Req0</font>) <b><font color="#0000FF">of</font></b> + <font color="#000080">undefined</font> <font color="#990000">-></font> + {<font color="#FF6600">cowboy_websocket</font>, <font color="#009900">Req0</font>, <font color="#009900">State</font>}; + <font color="#009900">Subprotocols</font> <font color="#990000">-></font> + <b><font color="#0000FF">case</font></b> <b><font color="#000000">lists:keymember</font></b>(<font color="#990000"><<</font><font color="#FF0000">"mqtt"</font><font color="#990000">>></font>, <font color="#993399">1</font>, <font color="#009900">Subprotocols</font>) <b><font color="#0000FF">of</font></b> + <font color="#000080">true</font> <font color="#990000">-></font> + <font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:set_resp_header</font></b>(<font color="#990000"><<</font><font color="#FF0000">"sec-websocket-protocol"</font><font color="#990000">>></font>, + <font color="#990000"><<</font><font color="#FF0000">"mqtt"</font><font color="#990000">>></font>, <font color="#009900">Req0</font>), + {<font color="#FF6600">cowboy_websocket</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>}; + <font color="#000080">false</font> <font color="#990000">-></font> + <font color="#009900">Req</font> <font color="#990000">=</font> <b><font color="#000000">cowboy_req:reply</font></b>(<font color="#993399">400</font>, <font color="#009900">Req0</font>), + {<font color="#FF6600">ok</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>} + <b><font color="#0000FF">end</font></b> + <b><font color="#0000FF">end</font></b><font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_post_upgrade_initialization">Post-upgrade initialization</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy has separate processes for handling the connection -and requests. Because Websocket takes over the connection, -the Websocket protocol handling occurs in a different -process than the request handling.</p></div> -<div class="paragraph"><p>This is reflected in the different callbacks Websocket -handlers have. The <code>init/2</code> callback is called from the -temporary request process and the <code>websocket_</code> callbacks -from the connection process.</p></div> -<div class="paragraph"><p>This means that some initialization cannot be done from -<code>init/2</code>. Anything that would require the current pid, -or be tied to the current pid, will not work as intended. -The optional <code>websocket_init/1</code> can be used instead:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy has separate processes for handling the connection and requests. Because Websocket takes over the connection, the Websocket protocol handling occurs in a different process than the request handling.</p> +<p>This is reflected in the different callbacks Websocket handlers have. The <code>init/2</code> callback is called from the temporary request process and the <code>websocket_</code> callbacks from the connection process.</p> +<p>This means that some initialization cannot be done from <code>init/2</code>. Anything that would require the current pid, or be tied to the current pid, will not work as intended. The optional <code>websocket_init/1</code> can be used instead:</p> +<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><span style="font-weight: bold"><span style="color: #000000">websocket_init</span></span>(<span style="color: #009900">State</span>) <span style="color: #990000">-></span> - <span style="font-weight: bold"><span style="color: #000000">erlang:start_timer</span></span>(<span style="color: #993399">1000</span>, <span style="font-weight: bold"><span style="color: #000080">self</span></span>(), <span style="color: #990000"><<</span><span style="color: #FF0000">"Hello!"</span><span style="color: #990000">>></span>), - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>All Websocket callbacks share the same return values. This -means that we can send frames to the client right after -the upgrade:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">websocket_init</font></b>(<font color="#009900">State</font>) <font color="#990000">-></font> + <b><font color="#000000">erlang:start_timer</font></b>(<font color="#993399">1000</font>, <b><font color="#000080">self</font></b>(), <font color="#990000"><<</font><font color="#FF0000">"Hello!"</font><font color="#990000">>></font>), + {<font color="#FF6600">ok</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>All Websocket callbacks share the same return values. This means that we can send frames to the client right after the upgrade:</p> +<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><span style="font-weight: bold"><span style="color: #000000">websocket_init</span></span>(<span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">reply</span>, {<span style="color: #FF6600">text</span>, <span style="color: #990000"><<</span><span style="color: #FF0000">"Hello!"</span><span style="color: #990000">>></span>}, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">websocket_init</font></b>(<font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">reply</font>, {<font color="#FF6600">text</font>, <font color="#990000"><<</font><font color="#FF0000">"Hello!"</font><font color="#990000">>></font>}, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_receiving_frames">Receiving frames</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy will call <code>websocket_handle/2</code> whenever a text, binary, -ping or pong frame arrives from the client.</p></div> -<div class="paragraph"><p>The handler can handle or ignore the frames. It can also -send frames back to the client or stop the connection.</p></div> -<div class="paragraph"><p>The following snippet echoes back any text frame received and -ignores all others:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy will call <code>websocket_handle/2</code> whenever a text, binary, ping or pong frame arrives from the client.</p> +<p>The handler can handle or ignore the frames. It can also send frames back to the client or stop the connection.</p> +<p>The following snippet echoes back any text frame received and ignores all others:</p> +<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><span style="font-weight: bold"><span style="color: #000000">websocket_handle</span></span>(<span style="color: #009900">Frame</span> <span style="color: #990000">=</span> {<span style="color: #FF6600">text</span>, <span style="color: #990000">_</span>}, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">reply</span>, <span style="color: #009900">Frame</span>, <span style="color: #009900">State</span>}; -<span style="font-weight: bold"><span style="color: #000000">websocket_handle</span></span>(<span style="color: #009900">_Frame</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Note that ping and pong frames require no action from the -handler as Cowboy will automatically reply to ping frames. -They are provided for informative purposes only.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">websocket_handle</font></b>(<font color="#009900">Frame</font> <font color="#990000">=</font> {<font color="#FF6600">text</font>, <font color="#990000">_</font>}, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">reply</font>, <font color="#009900">Frame</font>, <font color="#009900">State</font>}; +<b><font color="#000000">websocket_handle</font></b>(<font color="#009900">_Frame</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">ok</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>Note that ping and pong frames require no action from the handler as Cowboy will automatically reply to ping frames. They are provided for informative purposes only.</p> <h2 id="_receiving_erlang_messages">Receiving Erlang messages</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy will call <code>websocket_info/2</code> whenever an Erlang message -arrives.</p></div> -<div class="paragraph"><p>The handler can handle or ignore the messages. It can also -send frames to the client or stop the connection.</p></div> -<div class="paragraph"><p>The following snippet forwards log messages to the client -and ignores all others:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy will call <code>websocket_info/2</code> whenever an Erlang message arrives.</p> +<p>The handler can handle or ignore the messages. It can also send frames to the client or stop the connection.</p> +<p>The following snippet forwards log messages to the client and ignores all others:</p> +<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><span style="font-weight: bold"><span style="color: #000000">websocket_info</span></span>({<span style="font-weight: bold"><span style="color: #000080">log</span></span>, <span style="color: #009900">Text</span>}, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">reply</span>, {<span style="color: #FF6600">text</span>, <span style="color: #009900">Text</span>}, <span style="color: #009900">State</span>}; -<span style="font-weight: bold"><span style="color: #000000">websocket_info</span></span>(<span style="color: #009900">_Info</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">websocket_info</font></b>({<b><font color="#000080">log</font></b>, <font color="#009900">Text</font>}, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">reply</font>, {<font color="#FF6600">text</font>, <font color="#009900">Text</font>}, <font color="#009900">State</font>}; +<b><font color="#000000">websocket_info</font></b>(<font color="#009900">_Info</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">ok</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> <h2 id="_sending_frames">Sending frames</h2> -<div class="sectionbody"> -<div class="paragraph"><p>All <code>websocket_</code> callbacks share return values. They may -send zero, one or many frames to the client.</p></div> -<div class="paragraph"><p>To send nothing, just return an ok tuple:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<!-- @todo This will be deprecated and eventually replaced with a--> +<!-- {Commands, State} interface that allows providing more--> +<!-- functionality easily.--> +<p>All <code>websocket_</code> callbacks share return values. They may send zero, one or many frames to the client.</p> +<p>To send nothing, just return an ok tuple:</p> +<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><span style="font-weight: bold"><span style="color: #000000">websocket_info</span></span>(<span style="color: #009900">_Info</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>To send one frame, return a reply tuple with the frame to send:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">websocket_info</font></b>(<font color="#009900">_Info</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">ok</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>To send one frame, return a reply tuple with the frame to send:</p> +<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><span style="font-weight: bold"><span style="color: #000000">websocket_info</span></span>(<span style="color: #009900">_Info</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">reply</span>, {<span style="color: #FF6600">text</span>, <span style="color: #990000"><<</span><span style="color: #FF0000">"Hello!"</span><span style="color: #990000">>></span>}, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>You can send frames of any type: text, binary, ping, pong -or close frames.</p></div> -<div class="paragraph"><p>To send many frames at once, return a reply tuple with the -list of frames to send:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">websocket_info</font></b>(<font color="#009900">_Info</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">reply</font>, {<font color="#FF6600">text</font>, <font color="#990000"><<</font><font color="#FF0000">"Hello!"</font><font color="#990000">>></font>}, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>You can send frames of any type: text, binary, ping, pong or close frames.</p> +<p>To send many frames at once, return a reply tuple with the list of frames to send:</p> +<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><span style="font-weight: bold"><span style="color: #000000">websocket_info</span></span>(<span style="color: #009900">_Info</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">reply</span>, [ - {<span style="color: #FF6600">text</span>, <span style="color: #FF0000">"Hello"</span>}, - {<span style="color: #FF6600">text</span>, <span style="color: #990000"><<</span><span style="color: #FF0000">"world!"</span><span style="color: #990000">>></span>}, - {<span style="font-weight: bold"><span style="color: #000080">binary</span></span>, <span style="color: #990000"><<</span><span style="color: #993399">0</span><span style="color: #990000">:</span><span style="color: #993399">8000</span><span style="color: #990000">>></span>} - ], <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>They are sent in the given order.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">websocket_info</font></b>(<font color="#009900">_Info</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">reply</font>, [ + {<font color="#FF6600">text</font>, <font color="#FF0000">"Hello"</font>}, + {<font color="#FF6600">text</font>, <font color="#990000"><<</font><font color="#FF0000">"world!"</font><font color="#990000">>></font>}, + {<b><font color="#000080">binary</font></b>, <font color="#990000"><<</font><font color="#993399">0</font><font color="#990000">:</font><font color="#993399">8000</font><font color="#990000">>></font>} + ], <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>They are sent in the given order.</p> <h2 id="_keeping_the_connection_alive">Keeping the connection alive</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy will automatically respond to ping frames sent by -the client. They are still forwarded to the handler for -informative purposes, but no further action is required.</p></div> -<div class="paragraph"><p>Cowboy does not send ping frames itself. The handler can -do it if required. A better solution in most cases is to -let the client handle pings. Doing it from the handler -would imply having an additional timer per connection and -this can be a considerable cost for servers that need to -handle large numbers of connections.</p></div> -<div class="paragraph"><p>Cowboy can be configured to close idle connections -automatically. It is highly recommended to configure -a timeout here, to avoid having processes linger longer -than needed.</p></div> -<div class="paragraph"><p>The <code>init/2</code> callback can set the timeout to be used -for the connection. For example, this would make Cowboy -close connections idle for more than 30 seconds:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy will automatically respond to ping frames sent by the client. They are still forwarded to the handler for informative purposes, but no further action is required.</p> +<p>Cowboy does not send ping frames itself. The handler can do it if required. A better solution in most cases is to let the client handle pings. Doing it from the handler would imply having an additional timer per connection and this can be a considerable cost for servers that need to handle large numbers of connections.</p> +<p>Cowboy can be configured to close idle connections automatically. It is highly recommended to configure a timeout here, to avoid having processes linger longer than needed.</p> +<p>The <code>init/2</code> callback can set the timeout to be used for the connection. For example, this would make Cowboy close connections idle for more than 30 seconds:</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">cowboy_websocket</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>, #{ - <span style="color: #0000FF">idle_timeout</span> <span style="color: #990000">=></span> <span style="color: #993399">30000</span>}}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>This value cannot be changed once it is set. It defaults to -<code>60000</code>.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">cowboy_websocket</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>, #{ + <font color="#0000FF">idle_timeout</font> <font color="#990000">=></font> <font color="#993399">30000</font>}}<font color="#990000">.</font></tt></pre> +</div></div> +<p>This value cannot be changed once it is set. It defaults to <code>60000</code>.</p> <h2 id="_limiting_frame_sizes">Limiting frame sizes</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy accepts frames of any size by default. You should -limit the size depending on what your handler may handle. -You can do this via the <code>init/2</code> callback:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>Cowboy accepts frames of any size by default. You should limit the size depending on what your handler may handle. You can do this via the <code>init/2</code> callback:</p> +<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><span style="font-weight: bold"><span style="color: #000000">init</span></span>(<span style="color: #009900">Req</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">cowboy_websocket</span>, <span style="color: #009900">Req</span>, <span style="color: #009900">State</span>, #{ - <span style="color: #0000FF">max_frame_size</span> <span style="color: #990000">=></span> <span style="color: #993399">8000000</span>}}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>The lack of limit is historical. A future version of -Cowboy will have a more reasonable default.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">init</font></b>(<font color="#009900">Req</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">cowboy_websocket</font>, <font color="#009900">Req</font>, <font color="#009900">State</font>, #{ + <font color="#0000FF">max_frame_size</font> <font color="#990000">=></font> <font color="#993399">8000000</font>}}<font color="#990000">.</font></tt></pre> +</div></div> +<p>The lack of limit is historical. A future version of Cowboy will have a more reasonable default.</p> <h2 id="_saving_memory">Saving memory</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The Websocket connection process can be set to hibernate -after the callback returns.</p></div> -<div class="paragraph"><p>Simply add an <code>hibernate</code> field to the ok or reply tuples:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The Websocket connection process can be set to hibernate after the callback returns.</p> +<p>Simply add an <code>hibernate</code> field to the ok or reply tuples:</p> +<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><span style="font-weight: bold"><span style="color: #000000">websocket_init</span></span>(<span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">State</span>, <span style="color: #FF6600">hibernate</span>}<span style="color: #990000">.</span> - -<span style="font-weight: bold"><span style="color: #000000">websocket_handle</span></span>(<span style="color: #009900">_Frame</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">ok</span>, <span style="color: #009900">State</span>, <span style="color: #FF6600">hibernate</span>}<span style="color: #990000">.</span> - -<span style="font-weight: bold"><span style="color: #000000">websocket_info</span></span>(<span style="color: #009900">_Info</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">reply</span>, {<span style="color: #FF6600">text</span>, <span style="color: #990000"><<</span><span style="color: #FF0000">"Hello!"</span><span style="color: #990000">>></span>}, <span style="color: #009900">State</span>, <span style="color: #FF6600">hibernate</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>It is highly recommended to write your handlers with -hibernate enabled, as this allows to greatly reduce the -memory usage. Do note however that an increase in the -CPU usage or latency can be observed instead, in particular -for the more busy connections.</p></div> -</div> -</div> -<div class="sect1"> +<pre><tt><b><font color="#000000">websocket_init</font></b>(<font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">ok</font>, <font color="#009900">State</font>, <font color="#FF6600">hibernate</font>}<font color="#990000">.</font> + +<b><font color="#000000">websocket_handle</font></b>(<font color="#009900">_Frame</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">ok</font>, <font color="#009900">State</font>, <font color="#FF6600">hibernate</font>}<font color="#990000">.</font> + +<b><font color="#000000">websocket_info</font></b>(<font color="#009900">_Info</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">reply</font>, {<font color="#FF6600">text</font>, <font color="#990000"><<</font><font color="#FF0000">"Hello!"</font><font color="#990000">>></font>}, <font color="#009900">State</font>, <font color="#FF6600">hibernate</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>It is highly recommended to write your handlers with hibernate enabled, as this allows to greatly reduce the memory usage. Do note however that an increase in the CPU usage or latency can be observed instead, in particular for the more busy connections.</p> <h2 id="_closing_the_connection">Closing the connection</h2> -<div class="sectionbody"> -<div class="paragraph"><p>The connection can be closed at any time, either by telling -Cowboy to stop it or by sending a close frame.</p></div> -<div class="paragraph"><p>To tell Cowboy to close the connection, use a stop tuple:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<p>The connection can be closed at any time, either by telling Cowboy to stop it or by sending a close frame.</p> +<p>To tell Cowboy to close the connection, use a stop tuple:</p> +<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><span style="font-weight: bold"><span style="color: #000000">websocket_info</span></span>(<span style="color: #009900">_Info</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">stop</span>, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -<div class="paragraph"><p>Sending a <code>close</code> frame will immediately initiate the closing -of the Websocket connection. Note that when sending a list of -frames that include a close frame, any frame found after the -close frame will not be sent.</p></div> -<div class="paragraph"><p>The following example sends a close frame with a reason message:</p></div> -<div class="listingblock"> -<div class="content"><!-- Generator: GNU source-highlight +<pre><tt><b><font color="#000000">websocket_info</font></b>(<font color="#009900">_Info</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">stop</font>, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> +<p>Sending a <code>close</code> frame will immediately initiate the closing of the Websocket connection. Note that when sending a list of frames that include a close frame, any frame found after the close frame will not be sent.</p> +<p>The following example sends a close frame with a reason message:</p> +<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><span style="font-weight: bold"><span style="color: #000000">websocket_info</span></span>(<span style="color: #009900">_Info</span>, <span style="color: #009900">State</span>) <span style="color: #990000">-></span> - {<span style="color: #FF6600">reply</span>, {<span style="color: #FF6600">close</span>, <span style="color: #993399">1000</span>, <span style="color: #990000"><<</span><span style="color: #FF0000">"some-reason"</span><span style="color: #990000">>></span>}, <span style="color: #009900">State</span>}<span style="color: #990000">.</span></tt></pre></div></div> -</div> -</div> +<pre><tt><b><font color="#000000">websocket_info</font></b>(<font color="#009900">_Info</font>, <font color="#009900">State</font>) <font color="#990000">-></font> + {<font color="#FF6600">reply</font>, {<font color="#FF6600">close</font>, <font color="#993399">1000</font>, <font color="#990000"><<</font><font color="#FF0000">"some-reason"</font><font color="#990000">>></font>}, <font color="#009900">State</font>}<font color="#990000">.</font></tt></pre> +</div></div> + diff --git a/docs/en/cowboy/2.3/guide/ws_protocol/index.html b/docs/en/cowboy/2.3/guide/ws_protocol/index.html index b6748a82..6f6c593a 100644 --- a/docs/en/cowboy/2.3/guide/ws_protocol/index.html +++ b/docs/en/cowboy/2.3/guide/ws_protocol/index.html @@ -62,70 +62,22 @@ <h1 class="lined-header"><span>The Websocket protocol</span></h1> -<div class="paragraph"><p>This chapter explains what Websocket is and why it is -a vital component of soft realtime Web applications.</p></div> -<div class="sect1"> +<p>This chapter explains what Websocket is and why it is a vital component of soft realtime Web applications.</p> <h2 id="_description">Description</h2> -<div class="sectionbody"> -<div class="paragraph"><p>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.</p></div> -<div class="paragraph"><p>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). -With Websocket, the client and the server can both send -frames at any time without any restriction. It is closer -to TCP than any of the HTTP protocols.</p></div> -<div class="paragraph"><p>Websocket is an IETF standard. Cowboy supports the standard -and all drafts that were previously implemented by browsers, -excluding the initial flawed draft sometimes known as -"version 0".</p></div> -</div> -</div> -<div class="sect1"> +<p>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.</p> +<p>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). With Websocket, the client and the server can both send frames at any time without any restriction. It is closer to TCP than any of the HTTP protocols.</p> +<p>Websocket is an IETF standard. Cowboy supports the standard and all drafts that were previously implemented by browsers, excluding the initial flawed draft sometimes known as "version 0".</p> <h2 id="_websocket_vs_http_2">Websocket vs HTTP/2</h2> -<div class="sectionbody"> -<div class="paragraph"><p>For a few years Websocket was the only way to have a -bidirectional asynchronous connection with the server. -This changed when HTTP/2 was introduced. While HTTP/2 -requires the client to first perform a request before -the server can push data, this is only a minor restriction -as the client can do so just as it connects.</p></div> -<div class="paragraph"><p>Websocket was designed as a kind-of-TCP channel to a -server. It only defines the framing and connection -management and lets the developer implement a protocol -on top of it. For example you could implement IRC over -Websocket and use a Javascript IRC client to speak to -the server.</p></div> -<div class="paragraph"><p>HTTP/2 on the other hand is just an improvement over -the HTTP/1.1 connection and request/response mechanism. -It has the same semantics as HTTP/1.1.</p></div> -<div class="paragraph"><p>If all you need is to access an HTTP API, then HTTP/2 -should be your first choice. On the other hand, if what -you need is a different protocol, then you can use -Websocket to implement it.</p></div> -</div> -</div> -<div class="sect1"> +<p>For a few years Websocket was the only way to have a bidirectional asynchronous connection with the server. This changed when HTTP/2 was introduced. While HTTP/2 requires the client to first perform a request before the server can push data, this is only a minor restriction as the client can do so just as it connects.</p> +<p>Websocket was designed as a kind-of-TCP channel to a server. It only defines the framing and connection management and lets the developer implement a protocol on top of it. For example you could implement IRC over Websocket and use a Javascript IRC client to speak to the server.</p> +<p>HTTP/2 on the other hand is just an improvement over the HTTP/1.1 connection and request/response mechanism. It has the same semantics as HTTP/1.1.</p> +<p>If all you need is to access an HTTP API, then HTTP/2 should be your first choice. On the other hand, if what you need is a different protocol, then you can use Websocket to implement it.</p> <h2 id="_implementation">Implementation</h2> -<div class="sectionbody"> -<div class="paragraph"><p>Cowboy implements Websocket as a protocol upgrade. Once the -upgrade is performed from the <code>init/2</code> callback, Cowboy -switches to Websocket. Please consult the next chapter for -more information on initiating and handling Websocket -connections.</p></div> -<div class="paragraph"><p>The implementation of Websocket in Cowboy is validated using -the Autobahn test suite, which is an extensive suite of tests -covering all aspects of the protocol. Cowboy passes the -suite with 100% success, including all optional tests.</p></div> -<div class="paragraph"><p>Cowboy’s Websocket implementation also includes the -permessage-deflate and x-webkit-deflate-frame compression -extensions.</p></div> -<div class="paragraph"><p>Cowboy will automatically use compression when the -<code>compress</code> option is returned from the <code>init/2</code> function.</p></div> -</div> -</div> +<p>Cowboy implements Websocket as a protocol upgrade. Once the upgrade is performed from the <code>init/2</code> callback, Cowboy switches to Websocket. Please consult the next chapter for more information on initiating and handling Websocket connections.</p> +<p>The implementation of Websocket in Cowboy is validated using the Autobahn test suite, which is an extensive suite of tests covering all aspects of the protocol. Cowboy passes the suite with 100% success, including all optional tests.</p> +<p>Cowboy's Websocket implementation also includes the permessage-deflate and x-webkit-deflate-frame compression extensions.</p> +<p>Cowboy will automatically use compression when the <code>compress</code> option is returned from the <code>init/2</code> function.</p> + |