12/01/13 08:24:10 (8 years ago)

rewrite the sections on retrying requests and pipelining to resolve nonsense about non-idempotent sequences; partly addresses #426

1 edited


  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2110 r2116  
    4444  <!ENTITY header-warning         "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4545  <!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'/>">
    4647  <!ENTITY methods                "<xref target='Part2' x:rel='#methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4748  <!ENTITY OPTIONS                "<xref target='Part2' x:rel='#OPTIONS' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2839 <section title="Pipelining" anchor="pipelining">
    2840 <t>
    2841    A client that supports persistent connections &MAY; "pipeline" its
    2842    requests (i.e., send multiple requests without waiting for each
    2843    response). A server &MUST; send its responses to those requests in the
    2844    same order that the requests were received.
    2845 </t>
    2846 <t>
    2847    Clients that assume persistent connections and pipeline immediately
    2848    after connection establishment &SHOULD; be prepared to retry their
    2849    connection if the first pipelined attempt fails. If a client does
    2850    such a retry, it &MUST-NOT; pipeline before it knows the connection is
    2851    persistent. Clients &MUST; also be prepared to resend their requests if
    2852    the server closes the connection before sending all of the
    2853    corresponding responses.
    2854 </t>
    2855 <t>
    2856    Clients &SHOULD-NOT; pipeline requests using non-idempotent request methods
    2857    or non-idempotent sequences of request methods (see &idempotent-methods;).
    2858    Otherwise, a premature termination of the transport connection could lead
    2859    to indeterminate results. A client wishing to send a non-idempotent
    2860    request &SHOULD; wait to send that request until it has received the
    2861    response status line for the previous request.
    2862 </t>
    2863 </section>
    28652840<section title="Retrying Requests" anchor="persistent.retrying.requests">
    28682843   Implementations ought to anticipate the need to recover
    28692844   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.
     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.
     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.
     2866   An automatic retry &SHOULD-NOT; be repeated if it fails.
     2870<section title="Pipelining" anchor="pipelining">
     2871   <x:anchor-alias value="pipeline"/>
     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.
     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.
     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.
     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.
Note: See TracChangeset for help on using the changeset viewer.