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

generated after [919] (see #234)

File:
1 edited

Legend:

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

    r912 r920  
    392392      <link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C">
    393393      <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D">
    394       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.518, 2010-06-27 12:07:31, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     394      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.518, 2010-06-27 12:07:31, XSLT vendor: SAXON 8.9.0.4 from Saxonica http://www.saxonica.com/">
    395395      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    396396      <meta name="dct.creator" content="Fielding, R.">
     
    12551255            </p>
    12561256            <p>If a message is received with multiple Content-Length header fields or a Content-Length header field with an invalid value,
    1257                the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status and then close the connection. If this is a response message received by a proxy or
    1258                gateway, the proxy or gateway <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status as its downstream response, and then close the connection.
     1257               the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy
     1258               or gateway, the proxy or gateway <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status code as its downstream response, and then close the connection.
    12591259               If this is a response message received by a user-agent, the message-body length is determined by reading the connection until
    12601260               it is closed; an error <em class="bcp14">SHOULD</em> be indicated to the user.
     
    13731373         </p>
    13741374      </div>
    1375       <p id="rfc.section.4.1.2.p.19">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status if the received request-target
     1375      <p id="rfc.section.4.1.2.p.19">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target
    13761376         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    13771377      </p>
     
    17751775      </p>
    17761776      <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    1777          send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status for the previous request.
     1777         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    17781778      </p>
    17791779      <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;<a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>
     
    18811881      </p>
    18821882      <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
    1883       <p id="rfc.section.7.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status while it is transmitting the request. If the client sees an error status,
    1884          it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client <em class="bcp14">MUST</em> close the connection.
     1883      <p id="rfc.section.7.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
     1884         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client <em class="bcp14">MUST</em> close the connection.
    18851885      </p>
    18861886      <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    1887       <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     1887      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    18881888         to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either
    18891889         be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking
     
    18981898      </ul>
    18991899      <p id="rfc.section.7.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
    1900          100-continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client
    1901          sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the
    1902          client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
     1900         100-continue" without receiving either a 417 (Expectation Failed) or a 100 (Continue) status code. Therefore, when a client
     1901         sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status code,
     1902         the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
    19031903      </p>
    19041904      <p id="rfc.section.7.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
    19051905      <ul>
    1906          <li>Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status and continue to read from the input stream, or respond with a final status code.
    1907             The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the requested method if it returns a final status code.
     1906         <li>Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status
     1907            code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the requested method if it returns a final status code.
    19081908         </li>
    19091909         <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue"
    19101910            expectation, and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this
    1911             rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header
     1911            rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header
    19121912            field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays
    1913             associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with
    1914             any other HTTP-version value.
     1913            associated with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests
     1914            with any other HTTP-version value.
    19151915         </li>
    19161916         <li>An origin server <em class="bcp14">MAY</em> omit a 100 (Continue) response if it has already received some or all of the request body for the corresponding request.
     
    19321932            server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
    19331933         </li>
    1934          <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status.
     1934         <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code.
    19351935         </li>
    19361936         <li>Proxies <em class="bcp14">SHOULD</em> maintain a cache recording the HTTP version numbers received from recently-referenced next-hop servers.
     
    19441944      <p id="rfc.section.7.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field
    19451945         with the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the
    1946          client sees the connection close before receiving any status from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response:
     1946         client sees the connection close before receiving a status line from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response:
    19471947      </p>
    19481948      <ol>
     
    19591959         </li>
    19601960      </ol>
    1961       <p id="rfc.section.7.2.4.p.2">If at any point an error status is received, the client </p>
     1961      <p id="rfc.section.7.2.4.p.2">If at any point an error status code is received, the client </p>
    19621962      <ul>
    19631963         <li><em class="bcp14">SHOULD NOT</em> continue and
Note: See TracChangeset for help on using the changeset viewer.