Changeset 2116 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 12/01/13 08:24:10 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r2110 r2116 44 44 <!ENTITY header-warning "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 45 45 <!ENTITY idempotent-methods "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 46 <!ENTITY safe-methods "<xref target='Part2' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 46 47 <!ENTITY methods "<xref target='Part2' x:rel='#methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 47 48 <!ENTITY OPTIONS "<xref target='Part2' x:rel='#OPTIONS' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 2837 2838 </t> 2838 2839 2839 <section title="Pipelining" anchor="pipelining">2840 <t>2841 A client that supports persistent connections &MAY; "pipeline" its2842 requests (i.e., send multiple requests without waiting for each2843 response). A server &MUST; send its responses to those requests in the2844 same order that the requests were received.2845 </t>2846 <t>2847 Clients that assume persistent connections and pipeline immediately2848 after connection establishment &SHOULD; be prepared to retry their2849 connection if the first pipelined attempt fails. If a client does2850 such a retry, it &MUST-NOT; pipeline before it knows the connection is2851 persistent. Clients &MUST; also be prepared to resend their requests if2852 the server closes the connection before sending all of the2853 corresponding responses.2854 </t>2855 <t>2856 Clients &SHOULD-NOT; pipeline requests using non-idempotent request methods2857 or non-idempotent sequences of request methods (see &idempotent-methods;).2858 Otherwise, a premature termination of the transport connection could lead2859 to indeterminate results. A client wishing to send a non-idempotent2860 request &SHOULD; wait to send that request until it has received the2861 response status line for the previous request.2862 </t>2863 </section>2864 2865 2840 <section title="Retrying Requests" anchor="persistent.retrying.requests"> 2866 2841 <t> … … 2868 2843 Implementations ought to anticipate the need to recover 2869 2844 from asynchronous close events. 2870 A client &MAY; open a new connection and retransmit an aborted sequence 2871 of requests without user interaction so long as the request sequence is 2872 idempotent (see &idempotent-methods;). 2873 A client &MUST-NOT; automatically retry non-idempotent request sequences, 2874 although user agents &MAY; offer a human operator the choice of retrying 2875 the request(s). Confirmation by 2876 user agent software with semantic understanding of the application 2877 &MAY; substitute for user confirmation. An automatic retry &SHOULD-NOT; 2878 be repeated if a second sequence of requests fails. 2845 </t> 2846 <t> 2847 When an inbound connection is closed prematurely, a client &MAY; open a new 2848 connection and automatically retransmit an aborted sequence of requests if 2849 all of those requests have idempotent methods (&idempotent-methods;). 2850 A proxy &MUST-NOT; automatically retry non-idempotent requests. 2851 </t> 2852 <t> 2853 A user agent &MUST-NOT; automatically retry a request with a non-idempotent 2854 method unless it has some means to know that the request semantics are 2855 actually idempotent, regardless of the method, or some means to detect that 2856 the original request was never applied. For example, a user agent that 2857 knows (through design or configuration) that a POST request to a given 2858 resource is safe can repeat that request automatically. 2859 Likewise, a user agent designed specifically to operate on a version 2860 control repository might be able to recover from partial failure conditions 2861 by checking the target resource revision(s) after a failed connection, 2862 reverting or fixing any changes that were partially applied, and then 2863 automatically retrying the requests that failed. 2864 </t> 2865 <t> 2866 An automatic retry &SHOULD-NOT; be repeated if it fails. 2867 </t> 2868 </section> 2869 2870 <section title="Pipelining" anchor="pipelining"> 2871 <x:anchor-alias value="pipeline"/> 2872 <t> 2873 A client that supports persistent connections &MAY; "<x:dfn>pipeline</x:dfn>" 2874 its requests (i.e., send multiple requests without waiting for each 2875 response). A server &MAY; process a sequence of pipelined requests in 2876 parallel if they all have safe methods (&safe-methods;), but &MUST; send 2877 the corresponding responses in the same order that the requests were 2878 received. 2879 </t> 2880 <t> 2881 A client that pipelines requests &MUST; be prepared to retry those 2882 requests if the connection closes before it receives all of the 2883 corresponding responses. A client that assumes a persistent connection and 2884 pipelines immediately after connection establishment &MUST-NOT; pipeline 2885 on a retry connection until it knows the connection is persistent. 2886 </t> 2887 <t> 2888 Idempotent methods (&idempotent-methods;) are significant to pipelining 2889 because they can be automatically retried after a connection failure. 2890 A user agent &SHOULD-NOT; pipeline requests after a non-idempotent method 2891 until the final response status code for that method has been received, 2892 unless the user agent has a means to detect and recover from partial 2893 failure conditions involving the pipelined sequence. 2894 </t> 2895 <t> 2896 An intermediary that receives pipelined requests &MAY; pipeline those 2897 requests when forwarding them inbound, since it can rely on the outbound 2898 user agent(s) to determine what requests can be safely pipelined. If the 2899 inbound connection fails before receiving a response, the pipelining 2900 intermediary &MAY; attempt to retry a sequence of requests that have yet 2901 to receive a response if the requests all have idempotent methods; 2902 otherwise, the pipelining intermediary &SHOULD; forward any received 2903 responses and then close the corresponding outbound connection(s) so that 2904 the outbound user agent(s) can recover accordingly. 2879 2905 </t> 2880 2906 </section>
Note: See TracChangeset
for help on using the changeset viewer.