Changeset 919


Ignore:
Timestamp:
Jul 24, 2010, 6:33:35 AM (9 years ago)
Author:
ylafon@…
Message:

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r911 r919  
    13441344     response smuggling.
    13451345     If this is a request message, the server &MUST; respond with
    1346      a 400 (Bad Request) status and then close the connection.
     1346     a 400 (Bad Request) status code and then close the connection.
    13471347     If this is a response message received by a proxy or gateway, the proxy
    13481348     or gateway &MUST; discard the received response, send a 502 (Bad Gateway)
    1349      status as its downstream response, and then close the connection.
     1349     status code as its downstream response, and then close the connection.
    13501350     If this is a response message received by a user-agent, the message-body
    13511351     length is determined by reading the connection until it is closed;
     
    15891589   HTTP does not place a pre-defined limit on the length of a request-target.
    15901590   A server &MUST; be prepared to receive URIs of unbounded length and
    1591    respond with the 414 (URI Too Long) status if the received
     1591   respond with the 414 (URI Too Long) status code if the received
    15921592   request-target would be longer than the server wishes to handle
    15931593   (see &status-414;).
     
    23962396   indeterminate results. A client wishing to send a non-idempotent
    23972397   request &SHOULD; wait to send that request until it has received the
    2398    response status for the previous request.
     2398   response status line for the previous request.
    23992399</t>
    24002400</section>
     
    26152615<t>
    26162616   An HTTP/1.1 (or later) client sending a message-body &SHOULD; monitor
    2617    the network connection for an error status while it is transmitting
    2618    the request. If the client sees an error status, it &SHOULD;
     2617   the network connection for an error status code while it is transmitting
     2618   the request. If the client sees an error status code, it &SHOULD;
    26192619   immediately cease transmitting the body. If the body is being sent
    26202620   using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and
     
    26272627<section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">
    26282628<t>
    2629    The purpose of the 100 (Continue) status (see &status-100;) is to
     2629   The purpose of the 100 (Continue) status code (see &status-100;) is to
    26302630   allow a client that is sending a request message with a request body
    26312631   to determine if the origin server is willing to accept the request
     
    26532653   Because of the presence of older implementations, the protocol allows
    26542654   ambiguous situations in which a client might send "Expect: 100-continue"
    2655    without receiving either a 417 (Expectation Failed) status
    2656    or a 100 (Continue) status. Therefore, when a client sends this
     2655   without receiving either a 417 (Expectation Failed)
     2656   or a 100 (Continue) status code. Therefore, when a client sends this
    26572657   header field to an origin server (possibly via a proxy) from which it
    2658    has never seen a 100 (Continue) status, the client &SHOULD-NOT;  wait
    2659    for an indefinite period before sending the request body.
     2658   has never seen a 100 (Continue) status code, the client &SHOULD-NOT; 
     2659   wait for an indefinite period before sending the request body.
    26602660</t>
    26612661<t>
     
    26642664    <t> Upon receiving a request which includes an Expect request-header
    26652665        field with the "100-continue" expectation, an origin server &MUST;
    2666         either respond with 100 (Continue) status and continue to read
     2666        either respond with 100 (Continue) status code and continue to read
    26672667        from the input stream, or respond with a final status code. The
    26682668        origin server &MUST-NOT; wait for the request body before sending
     
    26782678        (or earlier) client. There is an exception to this rule: for
    26792679        compatibility with <xref target="RFC2068"/>, a server &MAY; send a 100 (Continue)
    2680         status in response to an HTTP/1.1 PUT or POST request that does
     2680        status code in response to an HTTP/1.1 PUT or POST request that does
    26812681        not include an Expect request-header field with the "100-continue"
    26822682        expectation. This exception, the purpose of which is
    26832683        to minimize any client processing delays associated with an
    2684         undeclared wait for 100 (Continue) status, applies only to
     2684        undeclared wait for 100 (Continue) status code, applies only to
    26852685        HTTP/1.1 requests, and not to requests with any other HTTP-version
    26862686        value.
     
    27212721    <t> If the proxy knows that the version of the next-hop server is
    27222722        HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST;
    2723         respond with a 417 (Expectation Failed) status.
     2723        respond with a 417 (Expectation Failed) status code.
    27242724    </t>
    27252725    <t> Proxies &SHOULD; maintain a cache recording the HTTP version
     
    27422742   "100-continue" expectation, and if the client is not directly
    27432743   connected to an HTTP/1.1 origin server, and if the client sees the
    2744    connection close before receiving any status from the server, the
     2744   connection close before receiving a status line from the server, the
    27452745   client &SHOULD; retry the request.  If the client does retry this
    27462746   request, it &MAY; use the following "binary exponential backoff"
     
    27802780</t>
    27812781<t>
    2782    If at any point an error status is received, the client
     2782   If at any point an error status code is received, the client
    27832783  <list style="symbols">
    27842784      <t>&SHOULD-NOT;  continue and</t>
Note: See TracChangeset for help on using the changeset viewer.