Changeset 2122 for draft-ietf-httpbis/latest

Timestamp:

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

Author:

fielding@…

Message:

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

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (4 diffs)
• p2-semantics.xml (modified) (6 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>

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

@@ -2655 +2655 @@
   <c>503</c> <c>Service Unavailable</c> <c><xref target="status.503"/></c>
   <c>504</c> <c>Gateway Time-out</c> <c><xref target="status.504"/></c>
-  <c>505</c> <c>HTTP Version not supported</c> <c><xref target="status.505"/></c>
+  <c>505</c> <c>HTTP Version Not Supported</c> <c><xref target="status.505"/></c>
 </texttable>
 <t>
@@ -2674 +2674 @@
    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.
+   block.
    Since HTTP/1.0 did not define any 1xx status codes, servers &MUST-NOT; send
    a 1xx response to an HTTP/1.0 client except under experimental conditions.
@@ -2680 +2680 @@
 <t>
    A client &MUST; be prepared to accept one or more 1xx status responses
-   prior to a final response, even if the client does not expect a
-   <x:ref>100 (Continue)</x:ref> status message.
+   prior to a final response, even if the client does not expect one.
    A user agent &MAY; ignore unexpected 1xx status responses.
 </t>
@@ -2723 +2722 @@
    server understands and is willing to comply with the client's request,
    via the <x:ref>Upgrade</x:ref> header field (&header-upgrade;), 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.
+   a change in the application protocol being used on this connection.
+   The server &MUST; 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.
 </t>
 <t>
@@ -4042 +4041 @@
 <t>
    The "Allow" header field lists the set of methods advertised as
-   supported by the <x:ref>target resource</x:ref>. The purpose of this field is strictly to
-   inform the recipient of valid request methods associated with the resource.
+   supported by the <x:ref>target resource</x:ref>. The purpose of this field
+   is strictly to inform the recipient of valid request methods associated
+   with the resource.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/>
@@ -4056 +4056 @@
 <t>
    The actual set of allowed methods is defined by the origin server at the
-   time of each request.
-</t>
-<t>
-   A proxy &MUST-NOT; modify the Allow header field &mdash; it does not need to
-   understand all the methods specified in order to handle them according to
-   the generic message handling rules.
+   time of each request. An origin server &MUST; generate an Allow field in a
+   <x:ref>405 (Method Not Allowed)</x:ref> response and &MAY; 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.
+</t>
+<t>
+   A proxy &MUST-NOT; modify the Allow header field &mdash; it does not need
+   to understand all of the indicated methods in order to handle them
+   according to the generic message handling rules.
 </t>
 </section>