Ignore:
Timestamp:
Nov 28, 2012, 12:21:03 AM (7 years ago)
Author:
fielding@…
Message:

remove bogus (non-interop) requirement on being able to recover from asynchronous close events

File:
1 edited

Legend:

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

    r2004 r2005  
    20282028      </p>
    20292029      <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h4>
    2030       <p id="rfc.section.6.2.2.2.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    2031          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding
    2032          of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
     2030      <p id="rfc.section.6.2.2.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover
     2031         from asynchronous close events. A client <em class="bcp14">MAY</em> open a new connection and retransmit an aborted sequence of requests without user interaction so long as the request sequence
     2032         is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding
     2033         of the application <em class="bcp14">MAY</em> substitute for user confirmation. An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if a second sequence of requests fails.
    20332034      </p>
    20342035      <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;<a id="persistent.concurrency" href="#persistent.concurrency">Concurrency</a></h3>
Note: See TracChangeset for help on using the changeset viewer.