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.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.