![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 920 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 24/07/10 13:43:06 (11 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p1-messaging.html (modified) (9 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r912 r920 392 392 <link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"> 393 393 <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/"> 395 395 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 396 396 <meta name="dct.creator" content="Fielding, R."> … … 1255 1255 </p> 1256 1256 <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 or1258 gateway, the proxy or gateway <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) statusas 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. 1259 1259 If this is a response message received by a user-agent, the message-body length is determined by reading the connection until 1260 1260 it is closed; an error <em class="bcp14">SHOULD</em> be indicated to the user. … … 1373 1373 </p> 1374 1374 </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-target1375 <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 1376 1376 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>). 1377 1377 </p> … … 1775 1775 </p> 1776 1776 <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. 1778 1778 </p> 1779 1779 <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a> <a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3> … … 1881 1881 </p> 1882 1882 <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <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 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 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. 1885 1885 </p> 1886 1886 <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <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 willing1887 <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 1888 1888 to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either 1889 1889 be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking … … 1898 1898 </ul> 1899 1899 <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 client1901 sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status , the1902 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. 1903 1903 </p> 1904 1904 <p id="rfc.section.7.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p> 1905 1905 <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. 1908 1908 </li> 1909 1909 <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" 1910 1910 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-header1911 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 1912 1912 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 with1914 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. 1915 1915 </li> 1916 1916 <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. … … 1932 1932 server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field. 1933 1933 </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. 1935 1935 </li> 1936 1936 <li>Proxies <em class="bcp14">SHOULD</em> maintain a cache recording the HTTP version numbers received from recently-referenced next-hop servers. … … 1944 1944 <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 1945 1945 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 a ny statusfrom 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: 1947 1947 </p> 1948 1948 <ol> … … 1959 1959 </li> 1960 1960 </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> 1962 1962 <ul> 1963 1963 <li><em class="bcp14">SHOULD NOT</em> continue and
Note: See TracChangeset
for help on using the changeset viewer.
