Changeset 1531


Ignore:
Timestamp:
Feb 7, 2012, 2:44:42 AM (7 years ago)
Author:
julian.reschke@…
Message:

regen HTML

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r1528 r1531  
    11911191         to keep their contents up-to-date.
    11921192      </p>
    1193       <p id="rfc.section.2.5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present) when a non-error response to a request
    1194          with an unsafe method is received.
    1195       </p>
    1196       <p id="rfc.section.2.5.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part
    1197          in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
     1193      <p id="rfc.section.2.5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error response
     1194         to a request with an unsafe method is received.
     1195      </p>
     1196      <p id="rfc.section.2.5.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location response header field if the host part of that URI differs from the host
     1197         part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
    11981198      </p>
    11991199      <p id="rfc.section.2.5.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
     
    13881388            with the listed response header fields. That is, a shared cache <em class="bcp14">MUST NOT</em> store the specified field-names(s), whereas it <em class="bcp14">MAY</em> store the remainder of the response message.
    13891389         </li>
    1390          <li> <b>Note:</b> This usage of the word private only controls where the response can be stored; it cannot ensure the privacy of the message
     1390         <li> <b>Note:</b> This usage of the word "private" only controls where the response can be stored; it cannot ensure the privacy of the message
    13911391            content. Also, private response directives with field-names are often handled by implementations as if an unqualified private
    13921392            directive was received; i.e., the special handling for the qualified form is not widely implemented.
Note: See TracChangeset for help on using the changeset viewer.