Changeset 1964 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 01/11/12 18:46:15 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1963 r1964 907 907 </p> 908 908 <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations 909 depend on HTTP's stateless design in order to reuse proxied connections or dynamically load 909 depend on HTTP's stateless design in order to reuse proxied connections or dynamically load-balance requests across multiple 910 910 servers. Hence, servers <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific 911 911 to that agent. Some non-standard HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) have been known to violate this requirement, resulting in security and interoperability problems. … … 1004 1004 is introduced, and that the minor number will only be incremented when changes made to the protocol have the effect of adding 1005 1005 to the message semantics or implying additional capabilities of the sender. However, the minor version was not incremented 1006 for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol.1006 for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision has specifically avoiding any such changes to the protocol. 1007 1007 </p> 1008 1008 <div id="rfc.iref.r.5"></div> … … 2068 2068 <p id="rfc.section.6.2.5.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request. 2069 2069 </p> 2070 <p id="rfc.section.6.2.5.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> include a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.2070 <p id="rfc.section.6.2.5.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close (see below) of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> include a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. 2071 2071 </p> 2072 2072 <p id="rfc.section.6.2.5.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. … … 2511 2511 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="dns.related.attacks" href="#dns.related.attacks">DNS-related Attacks</a></h2> 2512 2512 <p id="rfc.section.8.4.p.1">HTTP clients rely heavily on the Domain Name Service (DNS), and are thus generally prone to security attacks based on the 2513 deliberate misassociation of IP addresses and DNS names not protected by DNSS ec. Clients need to be cautious in assuming the2514 validity of an IP number/DNS name association unless the response is protected by DNSS ec(<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>).2513 deliberate misassociation of IP addresses and DNS names not protected by DNSSEC. Clients need to be cautious in assuming the 2514 validity of an IP number/DNS name association unless the response is protected by DNSSEC (<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>). 2515 2515 </p> 2516 2516 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="attack.intermediaries" href="#attack.intermediaries">Intermediaries and Caching</a></h2>
Note: See TracChangeset
for help on using the changeset viewer.