Changeset 919 for draft-ietf-httpbis/latest

Timestamp:

24/07/10 13:33:35 (11 years ago)

Author:

ylafon@…

Message:

uniform use of 'status' (status code or status line) (see #234)

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (11 diffs)

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

@@ -1344 +1344 @@
      response smuggling.
      If this is a request message, the server &MUST; respond with
-     a 400 (Bad Request) status and then close the connection.
+     a 400 (Bad Request) status code and then close the connection.
      If this is a response message received by a proxy or gateway, the proxy
      or gateway &MUST; discard the received response, send a 502 (Bad Gateway)
-     status as its downstream response, and then close the connection.
+     status code as its downstream response, and then close the connection.
      If this is a response message received by a user-agent, the message-body
      length is determined by reading the connection until it is closed;
@@ -1589 +1589 @@
    HTTP does not place a pre-defined limit on the length of a request-target.
    A server &MUST; be prepared to receive URIs of unbounded length and
-   respond with the 414 (URI Too Long) status if the received
+   respond with the 414 (URI Too Long) status code if the received
    request-target would be longer than the server wishes to handle
    (see &status-414;).
@@ -2396 +2396 @@
    indeterminate results. A client wishing to send a non-idempotent
    request &SHOULD; wait to send that request until it has received the
-   response status for the previous request.
+   response status line for the previous request.
 </t>
 </section>
@@ -2615 +2615 @@
 <t>
    An HTTP/1.1 (or later) client sending a message-body &SHOULD; monitor
-   the network connection for an error status while it is transmitting
-   the request. If the client sees an error status, it &SHOULD;
+   the network connection for an error status code while it is transmitting
+   the request. If the client sees an error status code, it &SHOULD;
    immediately cease transmitting the body. If the body is being sent
    using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and
@@ -2627 +2627 @@
 <section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">
 <t>
-   The purpose of the 100 (Continue) status (see &status-100;) is to
+   The purpose of the 100 (Continue) status code (see &status-100;) is to
    allow a client that is sending a request message with a request body
    to determine if the origin server is willing to accept the request
@@ -2653 +2653 @@
    Because of the presence of older implementations, the protocol allows
    ambiguous situations in which a client might send "Expect: 100-continue"
-   without receiving either a 417 (Expectation Failed) status
-   or a 100 (Continue) status. Therefore, when a client sends this
+   without receiving either a 417 (Expectation Failed) 
+   or a 100 (Continue) status code. Therefore, when a client sends this
    header field to an origin server (possibly via a proxy) from which it
-   has never seen a 100 (Continue) status, the client &SHOULD-NOT;  wait
-   for an indefinite period before sending the request body.
+   has never seen a 100 (Continue) status code, the client &SHOULD-NOT;  
+   wait for an indefinite period before sending the request body.
 </t>
 <t>
@@ -2664 +2664 @@
     <t> Upon receiving a request which includes an Expect request-header
         field with the "100-continue" expectation, an origin server &MUST;
-        either respond with 100 (Continue) status and continue to read
+        either respond with 100 (Continue) status code and continue to read
         from the input stream, or respond with a final status code. The
         origin server &MUST-NOT; wait for the request body before sending
@@ -2678 +2678 @@
         (or earlier) client. There is an exception to this rule: for
         compatibility with <xref target="RFC2068"/>, a server &MAY; send a 100 (Continue)
-        status in response to an HTTP/1.1 PUT or POST request that does
+        status code in response to an HTTP/1.1 PUT or POST request that does
         not include an Expect request-header field with the "100-continue"
         expectation. This exception, the purpose of which is
         to minimize any client processing delays associated with an
-        undeclared wait for 100 (Continue) status, applies only to
+        undeclared wait for 100 (Continue) status code, applies only to
         HTTP/1.1 requests, and not to requests with any other HTTP-version
         value.
@@ -2721 +2721 @@
     <t> If the proxy knows that the version of the next-hop server is
         HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST;
-        respond with a 417 (Expectation Failed) status.
+        respond with a 417 (Expectation Failed) status code.
     </t>
     <t> Proxies &SHOULD; maintain a cache recording the HTTP version
@@ -2742 +2742 @@
    "100-continue" expectation, and if the client is not directly
    connected to an HTTP/1.1 origin server, and if the client sees the
-   connection close before receiving any status from the server, the
+   connection close before receiving a status line from the server, the
    client &SHOULD; retry the request.  If the client does retry this
    request, it &MAY; use the following "binary exponential backoff"
@@ -2780 +2780 @@
 </t>
 <t>
-   If at any point an error status is received, the client
+   If at any point an error status code is received, the client
   <list style="symbols">
       <t>&SHOULD-NOT;  continue and</t>