Changeset 1531 for draft-ietf-httpbis/latest

Timestamp:

07/02/12 10:44:42 (11 years ago)

Author:

julian.reschke@…

Message:

regen HTML

File:

• draft-ietf-httpbis/latest/p6-cache.html (modified) (2 diffs)

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

@@ -1191 +1191 @@
          to keep their contents up-to-date.
       </p>
-      <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
-         with an unsafe method is received.
-      </p>
-      <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
-         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.
+      <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
+         to a request with an unsafe method is received.
+      </p>
+      <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
+         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.
       </p>
       <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.
@@ -1388 +1388 @@
             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.
          </li>
-         <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
+         <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
             content. Also, private response directives with field-names are often handled by implementations as if an unqualified private
             directive was received; i.e., the special handling for the qualified form is not widely implemented.