Changeset 2400

Timestamp:

15/09/13 00:57:24 (9 years ago)

Author:

fielding@…

Message:

uniform terminology for status code and request method (except where it is obvious by context)

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (3 diffs)
• p1-messaging.xml (modified) (3 diffs)
• p2-semantics.html (modified) (5 diffs)
• p2-semantics.xml (modified) (5 diffs)
• p6-cache.html (modified) (2 diffs)
• p6-cache.xml (modified) (2 diffs)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -1017 +1017 @@
       </p>
       <p id="rfc.section.2.6.p.10">A client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after
-         the client has attempted at least one normal request and determined from the response status or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.
+         the client has attempted at least one normal request and determined from the response status code or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.
       </p>
       <p id="rfc.section.2.6.p.11">A server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than
@@ -1194 +1194 @@
       </div>
       <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
-</pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
+</pre><p id="rfc.section.3.1.1.p.5">The request methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
       </p>
       <div id="rfc.iref.r.6"></div>
@@ -3015 +3015 @@
       </p>
       <p id="rfc.section.A.2.p.15">The segment + query components of RFC 3986 have been used to define the request-target, instead of abs_path from RFC 1808.
-         The asterisk-form of the request-target is only allowed in the OPTIONS method. (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>)
+         The asterisk-form of the request-target is only allowed with the OPTIONS method. (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>)
       </p>
       <p id="rfc.section.A.2.p.16">The term "Effective Request URI" has been introduced. (<a href="#effective.request.uri" title="Effective Request URI">Section&nbsp;5.5</a>)

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -758 +758 @@
    the server incorrectly implements the HTTP specification, but only
    after the client has attempted at least one normal request and determined
-   from the response status or header fields (e.g., <x:ref>Server</x:ref>) that
+   from the response status code or header fields (e.g., <x:ref>Server</x:ref>) that
    the server improperly handles higher request versions.
 </t>
@@ -1124 +1124 @@
 </artwork></figure>
 <t>
-   The methods defined by this specification can be found in
+   The request methods defined by this specification can be found in
    &methods;, along with information regarding the HTTP method registry
    and considerations for defining new methods.
@@ -5121 +5121 @@
   The segment + query components of RFC 3986 have been used to define the
   request-target, instead of abs_path from RFC 1808.
-  The asterisk-form of the request-target is only allowed in the OPTIONS
+  The asterisk-form of the request-target is only allowed with the OPTIONS
   method.
   (<xref target="request-target"/>)

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

@@ -1740 +1740 @@
       <div id="rfc.iref.m.1"></div>
       <h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h3>
-      <p id="rfc.section.5.1.2.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;4.3.7</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting
-         to trace a request that appears to be failing or looping mid-chain.
+      <p id="rfc.section.5.1.2.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;4.3.7</a>) request methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client
+         is attempting to trace a request that appears to be failing or looping mid-chain.
       </p>
       <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.18"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
@@ -2420 +2420 @@
          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 able to parse one or more 1xx status responses received 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 id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user
+         agent <em class="bcp14">MAY</em> ignore unexpected 1xx responses.
       </p>
       <p id="rfc.section.6.2.p.3">A proxy <em class="bcp14">MUST</em> forward 1xx responses unless the proxy itself requested the generation of the 1xx response. For example, if a proxy adds an
@@ -2688 +2688 @@
       <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.4"><a href="#rfc.section.6.5.4">6.5.4</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
-      <p id="rfc.section.6.5.4.p.1">The <dfn>404 (Not Found)</dfn> status code indicates that the origin server did not find a current representation for the <a href="#resources" class="smpl">target resource</a> or is not willing to disclose that one exists. A 404 status does not indicate whether this lack of representation is temporary
-         or permanent; the <a href="#status.410" class="smpl">410 (Gone)</a> status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition
+      <p id="rfc.section.6.5.4.p.1">The <dfn>404 (Not Found)</dfn> status code indicates that the origin server did not find a current representation for the <a href="#resources" class="smpl">target resource</a> or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is
+         temporary or permanent; the <a href="#status.410" class="smpl">410 (Gone)</a> status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition
          is likely to be permanent.
       </p>
@@ -2696 +2696 @@
       <div id="rfc.iref.71"></div>
       <h3 id="rfc.section.6.5.5"><a href="#rfc.section.6.5.5">6.5.5</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
-      <p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method specified in the request-line is known by the origin server but not supported by the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in a 405 response containing a list of the target resource's currently supported methods.
+      <p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method received in the request-line is known by the origin server but not supported by the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in a 405 response containing a list of the target resource's currently supported methods.
       </p>
       <p id="rfc.section.6.5.5.p.2">A 405 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
@@ -2761 +2761 @@
       <h3 id="rfc.section.6.5.13"><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
       <p id="rfc.section.6.5.13.p.1">The <dfn>415 (Unsupported Media Type)</dfn> status code indicates that the origin server is refusing to service the request because the payload is in a format not supported
-         by the <a href="#resources" class="smpl">target resource</a> for this method. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly.
+         by this method on the <a href="#resources" class="smpl">target resource</a>. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly.
       </p>
       <div id="rfc.iref.71"></div>

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

@@ -1968 +1968 @@
    The "Max-Forwards" header field provides a mechanism with the
    TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
-   methods to limit the number of times that the request is forwarded by
+   request methods to limit the number of times that the request is forwarded by
    proxies. This can be useful when the client is attempting to
    trace a request that appears to be failing or looping mid-chain.
@@ -2729 +2729 @@
 </t>
 <t>
-   A client &MUST; be able to parse one or more 1xx status responses received
+   A client &MUST; be able to parse one or more 1xx responses received
    prior to a final response, even if the client does not expect one.
-   A user agent &MAY; ignore unexpected 1xx status responses.
+   A user agent &MAY; ignore unexpected 1xx responses.
 </t>
 <t>
@@ -3322 +3322 @@
    server did not find a current representation for the
    <x:ref>target resource</x:ref> or is not willing to disclose that one
-   exists. A 404 status does not indicate whether this lack of representation
+   exists. A 404 status code does not indicate whether this lack of representation
    is temporary or permanent; the <x:ref>410 (Gone)</x:ref> status code is
    preferred over 404 if the origin server knows, presumably through some
@@ -3338 +3338 @@
 <t>
    The <x:dfn>405 (Method Not Allowed)</x:dfn> status code indicates that the
-   method specified in the request-line is known by the origin server but
+   method received in the request-line is known by the origin server but
    not supported by the <x:ref>target resource</x:ref>.
    The origin server &MUST; generate an <x:ref>Allow</x:ref> header field in
@@ -3494 +3494 @@
    The <x:dfn>415 (Unsupported Media Type)</x:dfn> status code indicates that
    the origin server is refusing to service the request because the payload is
-   in a format not supported by the <x:ref>target resource</x:ref> for this
-   method. The format problem might be due to the request's indicated
+   in a format not supported by this method on the <x:ref>target resource</x:ref>.
+   The format problem might be due to the request's indicated
    <x:ref>Content-Type</x:ref> or <x:ref>Content-Encoding</x:ref>, or as a
    result of inspecting the data directly.

draft-ietf-httpbis/latest/p6-cache.html

@@ -779 +779 @@
       </p>
       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="incomplete.responses" href="#incomplete.responses">Storing Incomplete Responses</a></h2>
-      <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200
-            (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200
+      <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request method is GET, the response status code is <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200
             (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the <a href="p5-range.html#header.range" class="smpl">Range</a> and <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields.
       </p>
@@ -1155 +1154 @@
          to keep their contents up-to-date.
       </p>
-      <p id="rfc.section.4.4.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received.
+      <p id="rfc.section.4.4.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error status code is received in response to an unsafe request method.
       </p>
       <p id="rfc.section.4.4.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This helps prevent denial of service attacks.

draft-ietf-httpbis/latest/p6-cache.xml

@@ -322 +322 @@
    A response message is considered complete when all of the octets indicated
    by the message framing (&messaging;) are received prior to the connection
-   being closed. If the request is GET, the response status is <x:ref>200
-   (OK)</x:ref>, and the entire response header block has been received, a
+   being closed. If the request method is GET, the response status code is
+   <x:ref>200 (OK)</x:ref>, and the entire response header block has been received, a
    cache &MAY; store an incomplete response message body if the cache entry is
    recorded as incomplete. Likewise, a <x:ref>206 (Partial Content)</x:ref>
@@ -1113 +1113 @@
    (&effective-request-uri;) as well as the URI(s) in the
    <x:ref>Location</x:ref> and <x:ref>Content-Location</x:ref> response header
-   fields (if present) when a non-error response to a request with an unsafe
-   method is received.
+   fields (if present) when a non-error status code is received in response to
+   an unsafe request method.
 </t>
 <t>