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

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

File:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (6 diffs)

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>