Ignore:
Timestamp:
Oct 26, 2011, 12:39:00 AM (8 years ago)
Author:
julian.reschke@…
Message:

Remove requirements about when servers are allowed to close the connection prematurely ((see #318)

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

Legend:

Unmodified
Added
Removed

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

    r1453 r1455  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 27, 2012";
     361       content: "Expires April 28, 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-25">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-10-26">
    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 27, 2012</td>
     442               <td class="left">Expires: April 28, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
    … …  
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">October 25, 2011</td>
     495               <td class="right">October 26, 2011</td>
    496496            </tr>
    497497         </tbody>
    … …  
    526526         in progress”.
    527527      </p>
    528       <p>This Internet-Draft will expire on April 27, 2012.</p>
     528      <p>This Internet-Draft will expire on April 28, 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>
    … …  
    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">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
     1884      <p id="rfc.section.6.1.4.p.4">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).
     1885      </p>
     1886      <p id="rfc.section.6.1.4.p.5">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many
    18891887         applications. As a result, this specification does not mandate a particular maximum number of connections, but instead encourages
    18901888         clients to be conservative when opening multiple connections.
    18911889      </p>
    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
     1890      <p id="rfc.section.6.1.4.p.6">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant
    18931891         server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used
    18941892         consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side
    18951893         effects in congested networks.
    18961894      </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>
     1895      <p id="rfc.section.6.1.4.p.7">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p>
    18981896      <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>
    18991897      <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
    … …  
    29712969      </p>
    29722970      <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>)
     2971         Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.practical" title="Practical Considerations">Section&nbsp;6.1.4</a>)
    29742972      </p>
    29752973      <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>)
    … …  
    34703468         </li>
    34713469         <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"
     3470         </li>
     3471         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/318">http://tools.ietf.org/wg/httpbis/trac/ticket/318</a>&gt;: "Closing the connection on server error"
    34723472         </li>
    34733473      </ul>

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

    r1454 r1455  
    26332633   closed while it was idle, but from the client's point of view, a
    26342634   request is in progress.
    2635 </t>
    2636 <t>
    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.
    26412635</t>
    26422636<t>
    … …  
    49734967  Remove hard limit of two connections per server.
    49744968  Remove requirement to retry a sequence of requests as long it was idempotent.
     4969  Remove requirements about when servers are allowed to close connections
     4970  prematurely.
    49754971  (<xref target="persistent.practical"/>)
    49764972</t>
    … …  
    58505846      "Retrying Requests"
    58515847    </t>
     5848    <t>
     5849      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/318"/>:
     5850      "Closing the connection on server error"
     5851    </t>
    58525852  </list>
    58535853</t>

  • draft-ietf-httpbis/latest/p3-payload.html

    r1454 r1455  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 27, 2012";
     361       content: "Expires April 28, 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-p3-payload-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-10-25">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-10-26">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    412412      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: April 27, 2012</td>
     436               <td class="left">Expires: April 28, 2012</td>
    437437               <td class="right">J. Mogul</td>
    438438            </tr>
    … …  
    491491            <tr>
    492492               <td class="left"></td>
    493                <td class="right">October 25, 2011</td>
     493               <td class="right">October 26, 2011</td>
    494494            </tr>
    495495         </tbody>
    … …  
    519519         in progress”.
    520520      </p>
    521       <p>This Internet-Draft will expire on April 27, 2012.</p>
     521      <p>This Internet-Draft will expire on April 28, 2012.</p>
    522522      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    523523      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset for help on using the changeset viewer.