Changeset 924 for draft-ietf-httpbis/latest

Timestamp:

24/07/10 13:56:20 (12 years ago)

Author:

ylafon@…

Message:

uniform use of 'status' (see #234)

File:

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

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

@@ -616 +616 @@
 <t>
   The HTTP Status Code Registry defines the name space for the Status-Code
-  token in the Status line of an HTTP response.
+  token in the Status-Line of an HTTP response.
 </t>
 <t>
@@ -695 +695 @@
    <t>If the response status code is 200 or 203 and the request method was GET,
    the response is a representation of the resource at the Effective Request URI.</t>
-   <t>If the response status is 204, 206, or 304 and the request method was GET
+   <t>If the response status code is 204, 206, or 304 and the request method was GET
    or HEAD, the response is a partial representation of the resource at the
    Effective Request URI (see &caching-combining-headers;).</t>
@@ -929 +929 @@
    The action performed by the POST method might not result in a
    resource that can be identified by a URI. In this case, either 200
-   (OK) or 204 (No Content) is the appropriate response status,
+   (OK) or 204 (No Content) is the appropriate response status code,
    depending on whether or not the response includes a representation that
    describes the result.
@@ -985 +985 @@
    responses for the Effective Request URI, those stored responses
    &SHOULD; be marked as stale if the response to the PUT request
-   is a success status. Responses to the PUT method are not cacheable.
+   has a success status code. Responses to the PUT method are 
+   not cacheable.
 </t>
 <t>
@@ -1267 +1268 @@
    header fields refer to the requested resource and its current
    representation, respectively, after the requested action.
-   For example, if a 204 status is received in response to a PUT
+   For example, if a 204 status code is received in response to a PUT
    and the response contains an ETag header field, then the value of
    that field is the current entity-tag for the representation that
@@ -1459 +1460 @@
 </t>
 <t>
-   The 303 status is generally applicable to any HTTP method.  It is
+   The 303 status code is generally applicable to any HTTP method.  It is
    primarily used to allow the output of a POST action to redirect
    the user agent to a selected resource, since doing so provides the
@@ -1501 +1502 @@
   <iref primary="true" item="Status Codes" subitem="305 Use Proxy" x:for-anchor=""/>
 <t>
-   The 305 status was defined in a previous version of this specification
+   The 305 status code was defined in a previous version of this specification
    (see <xref target="changes.from.rfc.2616"/>), and is now deprecated.
 </t>
@@ -1528 +1529 @@
    response &SHOULD; contain a short hypertext note with a hyperlink to
    the new URI(s) , since many pre-HTTP/1.1 user agents do not
-   understand the 307 status. Therefore, the note &SHOULD; contain the
+   understand the 307 status code. Therefore, the note &SHOULD; contain the
    information necessary for a user to repeat the original request on
    the new URI.
@@ -1992 +1993 @@
    A server that does not understand or is unable to comply with any of
    the expectation values in the Expect field of a request &MUST; respond
-   with appropriate error status. The server &MUST; respond with a 417
-   (Expectation Failed) status if any of the expectations cannot be met
+   with appropriate error status code. The server &MUST; respond with a 417
+   (Expectation Failed) status code if any of the expectations cannot be met
    or, if there are other problems with the request, some other 4xx
-   status.
+   status code.
 </t>
 <t>
@@ -2001 +2002 @@
    future extensions. If a server receives a request containing an
    Expect field that includes an expectation-extension that it does not
-   support, it &MUST; respond with a 417 (Expectation Failed) status.
+   support, it &MUST; respond with a 417 (Expectation Failed) status code.
 </t>
 <t>
@@ -2010 +2011 @@
 <t>
    The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy &MUST;
-   return a 417 (Expectation Failed) status if it receives a request
+   return a 417 (Expectation Failed) status code if it receives a request
    with an expectation that it cannot meet. However, the Expect
    request-header itself is end-to-end; it &MUST; be forwarded if the
@@ -2020 +2021 @@
 </t>
 <t>
-   See &use100; for the use of the 100 (Continue) status.
+   See &use100; for the use of the 100 (Continue) status code.
 </t>
 </section>