Ignore:
Timestamp:
Oct 25, 2011, 12:31:53 AM (8 years ago)
Author:
julian.reschke@…
Message:

Remove requirement to retry in certain cirumstances, pull other instructions about retries into a separate subsection and downgrade them from SHOULD to MAY (see #297)

File:
1 edited

Legend:

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

    r1452 r1453  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 25, 2012";
     361       content: "Expires April 27, 2012";
    362362  }
    363363  @bottom-right {
     
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-10-23">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-10-25">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: April 25, 2012</td>
     442               <td class="left">Expires: April 27, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
     
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">October 23, 2011</td>
     495               <td class="right">October 25, 2011</td>
    496496            </tr>
    497497         </tbody>
     
    526526         in progress”.
    527527      </p>
    528       <p>This Internet-Draft will expire on April 25, 2012.</p>
     528      <p>This Internet-Draft will expire on April 27, 2012.</p>
    529529      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    530530      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    629629                     </li>
    630630                     <li>6.1.4&nbsp;&nbsp;&nbsp;<a href="#persistent.practical">Practical Considerations</a></li>
     631                     <li>6.1.5&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
    631632                  </ul>
    632633               </li>
     
    635636                     <li>6.2.2&nbsp;&nbsp;&nbsp;<a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>
    636637                     <li>6.2.3&nbsp;&nbsp;&nbsp;<a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>
    637                      <li>6.2.4&nbsp;&nbsp;&nbsp;<a href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></li>
    638638                  </ul>
    639639               </li>
     
    18821882         while it was idle, but from the client's point of view, a request is in progress.
    18831883      </p>
    1884       <p id="rfc.section.6.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    1885          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[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
    1886          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.
    1887       </p>
    1888       <p id="rfc.section.6.1.4.p.5">Servers <em class="bcp14">SHOULD</em> always respond to at least one request per connection, if at all possible. Servers <em class="bcp14">SHOULD NOT</em> close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
    1889       </p>
    1890       <p id="rfc.section.6.1.4.p.6">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).
    1891       </p>
    1892       <p id="rfc.section.6.1.4.p.7">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many
     1884      <p id="rfc.section.6.1.4.p.4">Servers <em class="bcp14">SHOULD</em> always respond to at least one request per connection, if at all possible. Servers <em class="bcp14">SHOULD NOT</em> close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
     1885      </p>
     1886      <p id="rfc.section.6.1.4.p.5">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).
     1887      </p>
     1888      <p id="rfc.section.6.1.4.p.6">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many
    18931889         applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages
    18941890         clients to be conservative when opening multiple connections.
    18951891      </p>
    1896       <p id="rfc.section.6.1.4.p.8">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
     1892      <p id="rfc.section.6.1.4.p.7">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
    18971893         server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used
    18981894         consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side
    18991895         effects in congested networks.
    19001896      </p>
    1901       <p id="rfc.section.6.1.4.p.9">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>
     1897      <p id="rfc.section.6.1.4.p.8">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>
     1898      <h3 id="rfc.section.6.1.5"><a href="#rfc.section.6.1.5">6.1.5</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
     1899      <p id="rfc.section.6.1.5.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
     1900         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[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
     1901         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.
     1902      </p>
    19021903      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>
    19031904      <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>
     
    19641965            an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of
    19651966            1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    1966          </li>
    1967       </ul>
    1968       <h3 id="rfc.section.6.2.4"><a href="#rfc.section.6.2.4">6.2.4</a>&nbsp;<a id="connection.premature" href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></h3>
    1969       <p id="rfc.section.6.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect header field with
    1970          the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the client
    1971          sees the connection close before receiving a status line from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response:
    1972       </p>
    1973       <ol>
    1974          <li>Initiate a new connection to the server</li>
    1975          <li>Transmit the request-line, header fields, and the CRLF that indicates the end of header fields.</li>
    1976          <li>Initialize a variable R to the estimated round-trip time to the server (e.g., based on the time it took to establish the connection),
    1977             or to a constant value of 5 seconds if the round-trip time is not available.
    1978          </li>
    1979          <li>Compute T = R * (2**N), where N is the number of previous retries of this request.</li>
    1980          <li>Wait either for an error response from the server, or for T seconds (whichever comes first)</li>
    1981          <li>If no error response is received, after T seconds transmit the body of the request.</li>
    1982          <li>If client sees that the connection is closed prematurely, repeat from step 1 until the request is accepted, an error response
    1983             is received, or the user becomes impatient and terminates the retry process.
    1984          </li>
    1985       </ol>
    1986       <p id="rfc.section.6.2.4.p.2">If at any point an error status code is received, the client </p>
    1987       <ul>
    1988          <li><em class="bcp14">SHOULD NOT</em> continue and
    1989          </li>
    1990          <li><em class="bcp14">SHOULD</em> close the connection if it has not completed sending the request message.
    19911967         </li>
    19921968      </ul>
     
    29942970         disallowed line folding in chunk extensions. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1.1</a>)
    29952971      </p>
    2996       <p id="rfc.section.A.2.p.10">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;6.1.4</a>)
    2997       </p>
    2998       <p id="rfc.section.A.2.p.11">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;8</a>)
    2999       </p>
    3000       <p id="rfc.section.A.2.p.12">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.13" title="Connection">Section&nbsp;8.1</a>)
    3001       </p>
    3002       <p id="rfc.section.A.2.p.13">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;8.7</a>)
     2972      <p id="rfc.section.A.2.p.10">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent.
     2973         (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;6.1.4</a>)
     2974      </p>
     2975      <p id="rfc.section.A.2.p.11">Remove requirement to retry requests under certain cirumstances when the server prematurely closes the connection. (<a href="#message.transmission.requirements" title="Message Transmission Requirements">Section&nbsp;6.2</a>)
     2976      </p>
     2977      <p id="rfc.section.A.2.p.12">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;8</a>)
     2978      </p>
     2979      <p id="rfc.section.A.2.p.13">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.13" title="Connection">Section&nbsp;8.1</a>)
     2980      </p>
     2981      <p id="rfc.section.A.2.p.14">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;8.7</a>)
    30032982      </p>
    30042983      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
     
    34893468         </li>
    34903469         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/219">http://tools.ietf.org/wg/httpbis/trac/ticket/219</a>&gt;: "Revise Acknowledgements Sections"
     3470         </li>
     3471         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/297">http://tools.ietf.org/wg/httpbis/trac/ticket/297</a>&gt;: "Retrying Requests"
    34913472         </li>
    34923473      </ul>
     
    36913672            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    36923673                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li>
    3693                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">4.1</a>, <a href="#rfc.xref.Part2.9">6.1.2.2</a>, <a href="#rfc.xref.Part2.10">6.1.4</a>, <a href="#rfc.xref.Part2.11">6.2.3</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">8.7</a>, <a href="#rfc.xref.Part2.16">10.6</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
     3674                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">4.1</a>, <a href="#rfc.xref.Part2.9">6.1.2.2</a>, <a href="#rfc.xref.Part2.10">6.1.5</a>, <a href="#rfc.xref.Part2.11">6.2.3</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">8.7</a>, <a href="#rfc.xref.Part2.16">10.6</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
    36943675                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1.1</a></li>
    36953676                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    36963677                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li>
    3697                         <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">6.1.2.2</a>, <a href="#rfc.xref.Part2.10">6.1.4</a></li>
     3678                        <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">6.1.2.2</a>, <a href="#rfc.xref.Part2.10">6.1.5</a></li>
    36983679                        <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">4.1</a></li>
    36993680                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">6.2.3</a></li>
Note: See TracChangeset for help on using the changeset viewer.