Changeset 919 for draft-ietf-httpbis/latest
- Timestamp:
- 24/07/10 13:33:35 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r911 r919 1344 1344 response smuggling. 1345 1345 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. 1347 1347 If this is a response message received by a proxy or gateway, the proxy 1348 1348 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. 1350 1350 If this is a response message received by a user-agent, the message-body 1351 1351 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. 1590 1590 A server &MUST; be prepared to receive URIs of unbounded length and 1591 respond with the 414 (URI Too Long) status if the received1591 respond with the 414 (URI Too Long) status code if the received 1592 1592 request-target would be longer than the server wishes to handle 1593 1593 (see &status-414;). … … 2396 2396 indeterminate results. A client wishing to send a non-idempotent 2397 2397 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. 2399 2399 </t> 2400 2400 </section> … … 2615 2615 <t> 2616 2616 An HTTP/1.1 (or later) client sending a message-body &SHOULD; monitor 2617 the network connection for an error status while it is transmitting2618 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; 2619 2619 immediately cease transmitting the body. If the body is being sent 2620 2620 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"> 2628 2628 <t> 2629 The purpose of the 100 (Continue) status (see &status-100;) is to2629 The purpose of the 100 (Continue) status code (see &status-100;) is to 2630 2630 allow a client that is sending a request message with a request body 2631 2631 to determine if the origin server is willing to accept the request … … 2653 2653 Because of the presence of older implementations, the protocol allows 2654 2654 ambiguous situations in which a client might send "Expect: 100-continue" 2655 without receiving either a 417 (Expectation Failed) status2656 or a 100 (Continue) status . Therefore, when a client sends this2655 without receiving either a 417 (Expectation Failed) 2656 or a 100 (Continue) status code. Therefore, when a client sends this 2657 2657 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; wait2659 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. 2660 2660 </t> 2661 2661 <t> … … 2664 2664 <t> Upon receiving a request which includes an Expect request-header 2665 2665 field with the "100-continue" expectation, an origin server &MUST; 2666 either respond with 100 (Continue) status and continue to read2666 either respond with 100 (Continue) status code and continue to read 2667 2667 from the input stream, or respond with a final status code. The 2668 2668 origin server &MUST-NOT; wait for the request body before sending … … 2678 2678 (or earlier) client. There is an exception to this rule: for 2679 2679 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 does2680 status code in response to an HTTP/1.1 PUT or POST request that does 2681 2681 not include an Expect request-header field with the "100-continue" 2682 2682 expectation. This exception, the purpose of which is 2683 2683 to minimize any client processing delays associated with an 2684 undeclared wait for 100 (Continue) status , applies only to2684 undeclared wait for 100 (Continue) status code, applies only to 2685 2685 HTTP/1.1 requests, and not to requests with any other HTTP-version 2686 2686 value. … … 2721 2721 <t> If the proxy knows that the version of the next-hop server is 2722 2722 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. 2724 2724 </t> 2725 2725 <t> Proxies &SHOULD; maintain a cache recording the HTTP version … … 2742 2742 "100-continue" expectation, and if the client is not directly 2743 2743 connected to an HTTP/1.1 origin server, and if the client sees the 2744 connection close before receiving a ny statusfrom the server, the2744 connection close before receiving a status line from the server, the 2745 2745 client &SHOULD; retry the request. If the client does retry this 2746 2746 request, it &MAY; use the following "binary exponential backoff" … … 2780 2780 </t> 2781 2781 <t> 2782 If at any point an error status is received, the client2782 If at any point an error status code is received, the client 2783 2783 <list style="symbols"> 2784 2784 <t>&SHOULD-NOT; continue and</t>
Note: See TracChangeset
for help on using the changeset viewer.