Source: http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1453
Timestamp: 2014-12-18 23:46:49
Document Index: 179846803

Matched Legal Cases: ['art2', 'art2', 'art 2', 'art2', 'art2', 'art2', 'art 2', 'art2', 'art2', 'art2', 'art 2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2']

Changeset 1453 – httpbis
Changeset 1453
2011-10-25 00:31:53
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> draft-ietf-httpbis/latest/p1-messaging.xml
26352635</t> 26362636<t> 2637 This means that clients, servers, and proxies &MUST; be able to recover 2638 from asynchronous close events. Client software &SHOULD; reopen the 2637 Servers &SHOULD; always respond to at least one request per connection, 2638 if at all possible. Servers &SHOULD-NOT; close a connection in the 2639 middle of transmitting a response, unless a network or client failure 2640 is suspected. 2641</t> 2642<t> 2643 Clients (including proxies) &SHOULD; limit the number of simultaneous 2644 connections that they maintain to a given server (including proxies). 2645</t> 2646<t> 2647 Previous revisions of HTTP gave a specific number of connections as a 2648 ceiling, but this was found to be impractical for many applications. As a 2649 result, this specification does not mandate a particular maximum number of 2650 connections, but instead encourages clients to be conservative when opening 2651 multiple connections. 2652</t> 2653<t> 2654 In particular, while using multiple connections avoids the "head-of-line 2655 blocking" problem (whereby a request that takes significant server-side 2656 processing and/or has a large payload can block subsequent requests on the 2657 same connection), each connection used consumes server resources (sometimes 2658 significantly), and furthermore using multiple connections can cause 2659 undesirable side effects in congested networks. 2660</t> 2661<t> 2662 Note that servers might reject traffic that they deem abusive, including an 2663 excessive number of connections from a client. 2664</t> 2665</section> 2666 2667<section title="Retrying Requests" anchor="persistent.retrying.requests"> 2668<t> 2669 Senders can close the transport connection at any time. Therefore, 2670 clients, servers, and proxies &MUST; be able to recover 2671 from asynchronous close events. Client software &MAY; reopen the 26392672 transport connection and retransmit the aborted sequence of requests 26402673 without user interaction so long as the request sequence is …
26462679 be repeated if the second sequence of requests fails. 26472680</t> 2648 <t> 2649 Servers &SHOULD; always respond to at least one request per connection, 2650 if at all possible. Servers &SHOULD-NOT; close a connection in the 2651 middle of transmitting a response, unless a network or client failure 2652 is suspected. 2653 </t> 2654 <t> 2655 Clients (including proxies) &SHOULD; limit the number of simultaneous 2656 connections that they maintain to a given server (including proxies). 2657 </t> 2658 <t> 2659 Previous revisions of HTTP gave a specific number of connections as a 2660 ceiling, but this was found to be impractical for many applications. As a 2661 result, this specification does not mandate a particular maximum number of 2662 connections, but instead encourages clients to be conservative when opening 2663 multiple connections. 2664 </t> 2665 <t> 2666 In particular, while using multiple connections avoids the "head-of-line 2667 blocking" problem (whereby a request that takes significant server-side 2668 processing and/or has a large payload can block subsequent requests on the 2669 same connection), each connection used consumes server resources (sometimes 2670 significantly), and furthermore using multiple connections can cause 2671 undesirable side effects in congested networks. 2672 </t> 2673 <t> 2674 Note that servers might reject traffic that they deem abusive, including an 2675 excessive number of connections from a client. 2676 </t> 2677 </section> 2681</section> 2682 26782683</section> 26792684 …
28132818</section> 28142819 2815 <section title="Client Behavior if Server Prematurely Closes Connection" anchor="connection.premature"> 2816 <t> 2817 If an HTTP/1.1 client sends a request which includes a request body, 2818 but which does not include an Expect header field with the 2819 "100-continue" expectation, and if the client is not directly 2820 connected to an HTTP/1.1 origin server, and if the client sees the 2821 connection close before receiving a status line from the server, the 2822 client &SHOULD; retry the request. If the client does retry this 2823 request, it &MAY; use the following "binary exponential backoff" 2824 algorithm to be assured of obtaining a reliable response: 2825 <list style="numbers"> 2826 <t> 2827 Initiate a new connection to the server 2828 </t> 2829 <t> 2830 Transmit the request-line, header fields, and the CRLF that 2831 indicates the end of header fields. 2832 </t> 2833 <t> 2834 Initialize a variable R to the estimated round-trip time to the 2835 server (e.g., based on the time it took to establish the 2836 connection), or to a constant value of 5 seconds if the round-trip 2837 time is not available. 2838 </t> 2839 <t> 2840 Compute T = R * (2**N), where N is the number of previous 2841 retries of this request. 2842 </t> 2843 <t> 2844 Wait either for an error response from the server, or for T 2845 seconds (whichever comes first) 2846 </t> 2847 <t> 2848 If no error response is received, after T seconds transmit the 2849 body of the request. 2850 </t> 2851 <t> 2852 If client sees that the connection is closed prematurely, 2853 repeat from step 1 until the request is accepted, an error 2854 response is received, or the user becomes impatient and 2855 terminates the retry process. 2856 </t> 2857 </list> 2858 </t> 2859 <t> 2860 If at any point an error status code is received, the client 2861 <list style="symbols"> 2862 <t>&SHOULD-NOT; continue and</t> 2863 2864 <t>&SHOULD; close the connection if it has not completed sending the 2865 request message.</t> 2866 </list> 2867 </t> 2868 </section> 28692820</section> 28702821</section> …
50214972<t> 50224973 Remove hard limit of two connections per server. 4974 Remove requirement to retry a sequence of requests as long it was idempotent. 50234975 (<xref target="persistent.practical"/>) 4976</t> 4977<t> 4978 Remove requirement to retry requests under certain cirumstances when the 4979 server prematurely closes the connection. 4980 (<xref target="message.transmission.requirements"/>) 50244981</t> 50254982<t> …
58895846 "Revise Acknowledgements Sections" 58905847 </t> 5848 <t> 5849 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/297"/>: 5850 "Retrying Requests" 5851 </t> 58915852 </list> 58925853</t> Note: See TracChangeset