Ignore:
Timestamp:
12/01/13 08:24:10 (10 years ago)
Author:
fielding@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
8 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p0-introduction.html

    r2080 r2116  
    393393  }
    394394  @bottom-center {
    395        content: "Expires July 6, 2013";
     395       content: "Expires July 16, 2013";
    396396  }
    397397  @bottom-right {
    … …  
    426426      <meta name="dct.creator" content="Reschke, J. F.">
    427427      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest">
    428       <meta name="dct.issued" scheme="ISO8601" content="2013-01-02">
     428      <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
    429429      <meta name="dct.abstract" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
    430430      <meta name="description" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
    … …  
    446446            </tr>
    447447            <tr>
    448                <td class="left">Expires: July 6, 2013</td>
     448               <td class="left">Expires: July 16, 2013</td>
    449449               <td class="right">W3C</td>
    450450            </tr>
    … …  
    467467            <tr>
    468468               <td class="left"></td>
    469                <td class="right">January 2, 2013</td>
     469               <td class="right">January 12, 2013</td>
    470470            </tr>
    471471         </tbody>
    … …  
    490490         in progress”.
    491491      </p>
    492       <p>This Internet-Draft will expire on July 6, 2013.</p>
     492      <p>This Internet-Draft will expire on July 16, 2013.</p>
    493493      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    494494      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

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

    r2110 r2116  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 15, 2013";
     451       content: "Expires July 16, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-01-11">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">January 11, 2013</td>
     522               <td class="right">January 12, 2013</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: July 15, 2013</td>
     525               <td class="left">Expires: July 16, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
    … …  
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on July 15, 2013.</p>
     553      <p>This Internet-Draft will expire on July 16, 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    647647               <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.establishment">Establishment</a></li>
    648648               <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.connections">Persistence</a><ul>
    649                      <li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
    650                      <li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
     649                     <li><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#persistent.retrying.requests">Retrying Requests</a></li>
     650                     <li><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#pipelining">Pipelining</a></li>
    651651                  </ul>
    652652               </li>
    … …  
    19901990      <p id="rfc.section.6.3.p.7">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    19911991      </p>
    1992       <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h3>
    1993       <p id="rfc.section.6.3.1.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.
    1994       </p>
    1995       <p id="rfc.section.6.3.1.p.2">Clients that assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    1996       </p>
    1997       <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    1998          send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    1999       </p>
    2000       <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
    2001       <p id="rfc.section.6.3.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover
    2002          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
    2003          is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><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
    2004          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.
     1992      <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
     1993      <p id="rfc.section.6.3.1.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover
     1994         from asynchronous close events.
     1995      </p>
     1996      <p id="rfc.section.6.3.1.p.2">When an inbound connection is closed prematurely, a client <em class="bcp14">MAY</em> open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent
     1997         methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
     1998      </p>
     1999      <p id="rfc.section.6.3.1.p.3">A user agent <em class="bcp14">MUST NOT</em> automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are
     2000         actually idempotent, regardless of the method, or some means to detect that the original request was never applied. For example,
     2001         a user agent that knows (through design or configuration) that a POST request to a given resource is safe can repeat that
     2002         request automatically. Likewise, a user agent designed specifically to operate on a version control repository might be able
     2003         to recover from partial failure conditions by checking the target resource revision(s) after a failed connection, reverting
     2004         or fixing any changes that were partially applied, and then automatically retrying the requests that failed.
     2005      </p>
     2006      <p id="rfc.section.6.3.1.p.4">An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if it fails.
     2007      </p>
     2008      <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h3>
     2009      <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
     2010      </p>
     2011      <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">MUST</em> be prepared to retry those requests if the connection closes before it receives all of the corresponding responses. A client
     2012         that assumes a persistent connection and pipelines immediately after connection establishment <em class="bcp14">MUST NOT</em> pipeline on a retry connection until it knows the connection is persistent.
     2013      </p>
     2014      <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method until the final response status code for that method has been received, unless
     2015         the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.
     2016      </p>
     2017      <p id="rfc.section.6.3.2.p.4">An intermediary that receives pipelined requests <em class="bcp14">MAY</em> pipeline those requests when forwarding them inbound, since it can rely on the outbound user agent(s) to determine what requests
     2018         can be safely pipelined. If the inbound connection fails before receiving a response, the pipelining intermediary <em class="bcp14">MAY</em> attempt to retry a sequence of requests that have yet to receive a response if the requests all have idempotent methods; otherwise,
     2019         the pipelining intermediary <em class="bcp14">SHOULD</em> forward any received responses and then close the corresponding outbound connection(s) so that the outbound user agent(s)
     2020         can recover accordingly.
    20052021      </p>
    20062022      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="persistent.concurrency" href="#persistent.concurrency">Concurrency</a></h2>
    … …  
    20952111      </p>
    20962112      <p id="rfc.section.6.7.p.9">The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used
    2097          to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2113         to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    20982114      </p>
    20992115      <p id="rfc.section.6.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    … …  
    23562372         <li>Pointer to specification text</li>
    23572373      </ul>
    2358       <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2374      <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    23592375      </p>
    23602376      <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. Use of program names for the identification of encoding
    … …  
    24812497         that most implementations will choose substantially higher limits.
    24822498      </p>
    2483       <p id="rfc.section.8.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2499      <p id="rfc.section.8.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    24842500      </p>
    24852501      <p id="rfc.section.8.3.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status
    … …  
    32573273            </li>
    32583274            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3259                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a>, <a href="#rfc.xref.Part2.25">6.7</a>, <a href="#rfc.xref.Part2.26">7.4</a>, <a href="#rfc.xref.Part2.27">8.3</a>, <a href="#rfc.xref.Part2.28">8.3</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3275                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a>, <a href="#rfc.xref.Part2.25">6.3.2</a>, <a href="#rfc.xref.Part2.26">6.7</a>, <a href="#rfc.xref.Part2.27">7.4</a>, <a href="#rfc.xref.Part2.28">8.3</a>, <a href="#rfc.xref.Part2.29">8.3</a>, <a href="#Part2"><b>10.1</b></a><ul>
    32603276                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    32613277                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3.2</a></li>
    3262                         <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.26">7.4</a></li>
     3278                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.27">7.4</a></li>
    32633279                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.7.2</a></li>
    32643280                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    3265                         <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a></li>
     3281                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.3.2</a></li>
     3282                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.25">6.3.2</a></li>
    32663283                        <li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.2</a></li>
    32673284                        <li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.19">5.3</a></li>
    … …  
    32713288                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.6</a></li>
    32723289                        <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a></li>
    3273                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.7</a></li>
    3274                         <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">8.3</a></li>
    3275                         <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.27">8.3</a></li>
     3290                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">6.7</a></li>
     3291                        <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">8.3</a></li>
     3292                        <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.28">8.3</a></li>
    32763293                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    32773294                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>

  • 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'/>">
    … …  
    28372838</t>
    28382839
    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>
    2864 
    28652840<section title="Retrying Requests" anchor="persistent.retrying.requests">
    28662841<t>
    … …  
    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.
     2845</t>
     2846<t>
     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.
     2851</t>
     2852<t>
     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.
     2864</t>
     2865<t>
     2866   An automatic retry &SHOULD-NOT; be repeated if it fails.
     2867</t>
     2868</section>
     2869
     2870<section title="Pipelining" anchor="pipelining">
     2871   <x:anchor-alias value="pipeline"/>
     2872<t>
     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.
     2879</t>
     2880<t>
     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.
     2886</t>
     2887<t>
     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.
     2894</t>
     2895<t>
     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.
    28792905</t>
    28802906</section>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2115 r2116  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 15, 2013";
     451       content: "Expires July 16, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    494494      <meta name="dct.creator" content="Reschke, J. F.">
    495495      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    496       <meta name="dct.issued" scheme="ISO8601" content="2013-01-11">
     496      <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    498498      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
    … …  
    522522            <tr>
    523523               <td class="left">Intended status: Standards Track</td>
    524                <td class="right">January 11, 2013</td>
     524               <td class="right">January 12, 2013</td>
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: July 15, 2013</td>
     527               <td class="left">Expires: July 16, 2013</td>
    528528               <td class="right"></td>
    529529            </tr>
    … …  
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on July 15, 2013.</p>
     555      <p>This Internet-Draft will expire on July 16, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r2105 r2116  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 14, 2013";
     451       content: "Expires July 16, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-01-10">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
    … …  
    517517            </tr>
    518518            <tr>
    519                <td class="left">Expires: July 14, 2013</td>
    520                <td class="right">January 10, 2013</td>
     519               <td class="left">Expires: July 16, 2013</td>
     520               <td class="right">January 12, 2013</td>
    521521            </tr>
    522522         </tbody>
    … …  
    545545         in progress”.
    546546      </p>
    547       <p>This Internet-Draft will expire on July 14, 2013.</p>
     547      <p>This Internet-Draft will expire on July 16, 2013.</p>
    548548      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    549549      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p5-range.html

    r2080 r2116  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 6, 2013";
     451       content: "Expires July 16, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    493493      <meta name="dct.creator" content="Reschke, J. F.">
    494494      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    495       <meta name="dct.issued" scheme="ISO8601" content="2013-01-02">
     495      <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    497497      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.">
    … …  
    519519            </tr>
    520520            <tr>
    521                <td class="left">Expires: July 6, 2013</td>
     521               <td class="left">Expires: July 16, 2013</td>
    522522               <td class="right">J. Reschke, Editor</td>
    523523            </tr>
    … …  
    528528            <tr>
    529529               <td class="left"></td>
    530                <td class="right">January 2, 2013</td>
     530               <td class="right">January 12, 2013</td>
    531531            </tr>
    532532         </tbody>
    … …  
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on July 6, 2013.</p>
     555      <p>This Internet-Draft will expire on July 16, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p6-cache.html

    r2109 r2116  
    452452  }
    453453  @bottom-center {
    454        content: "Expires July 14, 2013";
     454       content: "Expires July 16, 2013";
    455455  }
    456456  @bottom-right {
    … …  
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2013-01-10">
     500      <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
    … …  
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: July 14, 2013</td>
     526               <td class="left">Expires: July 16, 2013</td>
    527527               <td class="right">J. Reschke, Editor</td>
    528528            </tr>
    … …  
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">January 10, 2013</td>
     535               <td class="right">January 12, 2013</td>
    536536            </tr>
    537537         </tbody>
    … …  
    559559         in progress”.
    560560      </p>
    561       <p>This Internet-Draft will expire on July 14, 2013.</p>
     561      <p>This Internet-Draft will expire on July 16, 2013.</p>
    562562      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    563563      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p7-auth.html

    r2080 r2116  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 6, 2013";
     451       content: "Expires July 16, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2013-01-02">
     491      <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.">
    … …  
    517517            <tr>
    518518               <td class="left">Intended status: Standards Track</td>
    519                <td class="right">January 2, 2013</td>
     519               <td class="right">January 12, 2013</td>
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: July 6, 2013</td>
     522               <td class="left">Expires: July 16, 2013</td>
    523523               <td class="right"></td>
    524524            </tr>
    … …  
    546546         in progress”.
    547547      </p>
    548       <p>This Internet-Draft will expire on July 6, 2013.</p>
     548      <p>This Internet-Draft will expire on July 16, 2013.</p>
    549549      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    550550      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset for help on using the changeset viewer.