Changeset 1310 for draft-ietf-httpbis

Timestamp:

Jun 22, 2011, 4:53:33 AM (9 years ago)

Author:

julian.reschke@…

Message:

slightly expand the scope of 503 to include scenarios like rate limiting (see #255)

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (5 diffs)
• p2-semantics.xml (modified) (2 diffs)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -1935 +1935 @@
       <div id="rfc.iref.s.41"></div>
       <h3 id="rfc.section.8.5.4"><a href="#rfc.section.8.5.4">8.5.4</a>&nbsp;<a id="status.503" href="#status.503">503 Service Unavailable</a></h3>
-      <p id="rfc.section.8.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication
-         is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
-      </p>
-      <div class="note" id="rfc.section.8.5.4.p.2"> 
+      <p id="rfc.section.8.5.4.p.1">The server is currently unable or unwilling to handle the request due to reasons such as temporary overloading, maintenance
+         of the server, or rate limiting of the client.
+      </p>
+      <p id="rfc.section.8.5.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the
+         delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;9.7</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
+      </p>
+      <div class="note" id="rfc.section.8.5.4.p.3"> 
          <p> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers might
             wish to simply refuse the connection.
@@ -2508 +2511 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;9.7</a> 
+                  <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section&nbsp;9.7</a> 
                   </td>
                </tr>
@@ -3048 +3051 @@
       <p id="rfc.section.C.16.p.1">Closed issues: </p>
       <ul>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/255">http://tools.ietf.org/wg/httpbis/trac/ticket/255</a>&gt;: "Clarify status code for rate limiting"
+         </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/294">http://tools.ietf.org/wg/httpbis/trac/ticket/294</a>&gt;: "clarify 403 forbidden"
          </li>
@@ -3170 +3175 @@
                         <li>Max-Forwards&nbsp;&nbsp;<a href="#rfc.xref.header.max-forwards.1">3</a>, <a href="#rfc.xref.header.max-forwards.2">7.2</a>, <a href="#rfc.xref.header.max-forwards.3">7.8</a>, <a href="#rfc.iref.h.6"><b>9.5</b></a>, <a href="#rfc.xref.header.max-forwards.4">10.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>
                         <li>Referer&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3</a>, <a href="#rfc.iref.h.7"><b>9.6</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>
-                        <li>Retry-After&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">5</a>, <a href="#rfc.iref.h.8"><b>9.7</b></a>, <a href="#rfc.xref.header.retry-after.2">10.3</a></li>
+                        <li>Retry-After&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">5</a>, <a href="#rfc.xref.header.retry-after.2">8.5.4</a>, <a href="#rfc.iref.h.8"><b>9.7</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>
                         <li>Server&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">5</a>, <a href="#rfc.iref.h.9"><b>9.8</b></a>, <a href="#rfc.xref.header.server.2">10.3</a>, <a href="#rfc.xref.header.server.3">11.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>
                         <li>User-Agent&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3</a>, <a href="#rfc.iref.h.10"><b>9.9</b></a>, <a href="#rfc.xref.header.user-agent.2">10.3</a>, <a href="#rfc.xref.header.user-agent.3">11.1</a></li>
@@ -3282 +3287 @@
             <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
                   <li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3</a>, <a href="#rfc.iref.r.1"><b>9.6</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>
-                  <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">5</a>, <a href="#rfc.iref.r.2"><b>9.7</b></a>, <a href="#rfc.xref.header.retry-after.2">10.3</a></li>
+                  <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">5</a>, <a href="#rfc.xref.header.retry-after.2">8.5.4</a>, <a href="#rfc.iref.r.2"><b>9.7</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>
                   <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">8.3.3</a>, <a href="#RFC1945"><b>13.2</b></a><ul>
                         <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">8.3.3</a></li>

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -2078 +2078 @@
   <iref primary="true" item="Status Codes" subitem="503 Service Unavailable" x:for-anchor=""/>
 <t>
-   The server is currently unable to handle the request due to a
-   temporary overloading or maintenance of the server. The implication
-   is that this is a temporary condition which will be alleviated after
-   some delay. If known, the length of the delay &MAY; be indicated in a
-   Retry-After header field. If no Retry-After is given, the client &SHOULD;
-   handle the response as it would for a 500 response.
+   The server is currently unable or unwilling to handle the request due to 
+   reasons such as temporary overloading, maintenance of the server, or rate
+   limiting of the client.
+</t>
+<t>
+   The implication is that this is a temporary condition which will be
+   alleviated after some delay. If known, the length of the delay &MAY; be
+   indicated in a Retry-After header field (<xref target="header.retry-after"/>).
+   If no Retry-After is given, the client &SHOULD; handle the response as it
+   would for a 500 response.
 </t>
 <x:note>
@@ -4133 +4137 @@
   <list style="symbols"> 
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/255"/>:
+      "Clarify status code for rate limiting"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/294"/>:
       "clarify 403 forbidden"