Changeset 2122 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

14/01/13 02:39:35 (9 years ago)

Author:

fielding@…

Message:

(editorial) explain empty Allow field for 405; misc typos; partly addresses #426

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (4 diffs)

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

@@ -2382 +2382 @@
                <tr>
                   <td class="left">505</td>
-                  <td class="left">HTTP Version not supported</td>
+                  <td class="left">HTTP Version Not Supported</td>
                   <td class="left"><a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section&nbsp;6.6.6</a></td>
                </tr>
@@ -2394 +2394 @@
       <p id="rfc.section.6.2.p.1">The <dfn>1xx (Informational)</dfn> class of status code indicates an interim response for communicating connection status or request progress prior to completing
          the requested action and sending a final response. All 1xx responses consist of only the status-line and optional header fields,
-         and thus are terminated by the empty line at the end of the header block. There are no required header fields for this class
-         of status code. Since HTTP/1.0 did not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
-      </p>
-      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a final response, even if the client does not expect a <a href="#status.100" class="smpl">100 (Continue)</a> status message. A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses.
+         and thus are terminated by the empty line at the end of the header block. Since HTTP/1.0 did not define any 1xx status codes,
+         servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
+      </p>
+      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a final response, even if the client does not expect one.
+         A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses.
       </p>
       <p id="rfc.section.6.2.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself
@@ -2414 +2415 @@
       <div id="rfc.iref.72"></div>
       <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
-      <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch to the protocol(s) indicated
-         within the response's Upgrade header field immediately after the empty line that terminates the 101 response.
+      <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server <em class="bcp14">MUST</em> generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the
+         empty line that terminates the 101 response.
       </p>
       <p id="rfc.section.6.2.2.p.2">It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching
@@ -3137 +3138 @@
 </pre><p id="rfc.section.7.4.1.p.3">Example of use:</p>
       <div id="rfc.figure.u.60"></div><pre class="text">  Allow: GET, HEAD, PUT
-</pre><p id="rfc.section.7.4.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>
-      <p id="rfc.section.7.4.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according
+</pre><p id="rfc.section.7.4.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request. An origin server <em class="bcp14">MUST</em> generate an Allow field in a <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> response and <em class="bcp14">MAY</em> do so in any other response. An empty Allow field value indicates that the resource allows no methods, which might occur in
+         a 405 response if the resource has been temporarily disabled by configuration.
+      </p>
+      <p id="rfc.section.7.4.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all of the indicated methods in order to handle them according
          to the generic message handling rules.
       </p>