Changeset 2005


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

Location:
draft-ietf-httpbis/latest
Files:
2 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>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2004 r2005  
    29032903<section title="Retrying Requests" anchor="persistent.retrying.requests">
    29042904<t>
    2905    Senders can close the transport connection at any time. Therefore,
    2906    clients, servers, and proxies &MUST; be able to recover
    2907    from asynchronous close events. Client software &MAY; reopen the
    2908    transport connection and retransmit the aborted sequence of requests
    2909    without user interaction so long as the request sequence is
    2910    idempotent (see &idempotent-methods;). Non-idempotent request methods or sequences
    2911    &MUST-NOT; be automatically retried, although user agents &MAY; offer a
    2912    human operator the choice of retrying the request(s). Confirmation by
     2905   Connections can be closed at any time, with or without intention.
     2906   Implementations ought to anticipate the need to recover
     2907   from asynchronous close events.
     2908   A client &MAY; open a new connection and retransmit an aborted sequence
     2909   of requests without user interaction so long as the request sequence is
     2910   idempotent (see &idempotent-methods;).
     2911   A client &MUST-NOT; automatically retry non-idempotent request sequences,
     2912   although user agents &MAY; offer a human operator the choice of retrying
     2913   the request(s). Confirmation by
    29132914   user agent software with semantic understanding of the application
    2914    &MAY; substitute for user confirmation. The automatic retry &SHOULD-NOT;
    2915    be repeated if the second sequence of requests fails.
     2915   &MAY; substitute for user confirmation. An automatic retry &SHOULD-NOT;
     2916   be repeated if a second sequence of requests fails.
    29162917</t>
    29172918</section>
Note: See TracChangeset for help on using the changeset viewer.