Ignore:
Timestamp:
Jul 8, 2012, 11:15:03 AM (8 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions, plus minor editorial improvements (P2)

File:
1 edited

Legend:

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

    r1739 r1740  
    794794         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    795795         different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    796          the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type
    797          of error recovery could lead to dangerous consequences.
     796         the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery
     797         could lead to dangerous consequences.
    798798      </p>
    799799      <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
     
    913913      <p id="rfc.section.2.2.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.6</a>.
    914914      </p>
    915       <p id="rfc.section.2.2.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header field). It can also forward a request with "Cache-Control:
    916          max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
     915      <p id="rfc.section.2.2.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field). It can also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate
     916         which response to use.
    917917      </p>
    918918      <p id="rfc.section.2.2.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them on every use. A cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard.
     
    951951         <li>If the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) is present, use its value, or
    952952         </li>
    953          <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;3.3</a>) is present, use its value minus the value of the Date response header field, or
     953         <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;3.3</a>) is present, use its value minus the value of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> response header field, or
    954954         </li>
    955955         <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;2.3.1.1</a>.
     
    993993      </p>
    994994      <ul class="empty">
    995          <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the
    996             response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic
    997             operations. See <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
     995         <li>HTTP/1.1 requires origin servers to send a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field, if possible, with every response, giving the time at which the response was generated. The term "date_value"
     996            denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
    998997         </li>
    999998      </ul>
     
    11381137         to keep their contents up-to-date.
    11391138      </p>
    1140       <p id="rfc.section.2.6.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 5.5</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
    1141          to a request with an unsafe method is received.
    1142       </p>
    1143       <p id="rfc.section.2.6.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
    1144          part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</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.
     1139      <p id="rfc.section.2.6.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 5.5</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 <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received.
     1140      </p>
     1141      <p id="rfc.section.2.6.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> 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 5.5</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.
    11451142      </p>
    11461143      <p id="rfc.section.2.6.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 5.5</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.
     
    11841181      </p>
    11851182      <p id="rfc.section.2.8.p.5">The stored response with matching selecting header fields is known as the selected response.</p>
    1186       <p id="rfc.section.2.8.p.6">If multiple selected responses are available, the most recent response (as determined by the Date header field) is used; see <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section&nbsp;2.2</a>.
     1183      <p id="rfc.section.2.8.p.6">If multiple selected responses are available, the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field) is used; see <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section&nbsp;2.2</a>.
    11871184      </p>
    11881185      <p id="rfc.section.2.8.p.7">If no selected response is available, the cache can forward the presented request to the origin server in a conditional request;
     
    13051302      <div id="rfc.iref.n.3"></div>
    13061303      <h4 id="rfc.section.3.2.1.6"><a href="#rfc.section.3.2.1.6">3.2.1.6</a>&nbsp;<a id="cache-request-directive.no-transform" href="#cache-request-directive.no-transform">no-transform</a></h4>
    1307       <p id="rfc.section.3.2.1.6.p.1">The no-transform request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> change the Content-Encoding, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or Content-Type request header fields, nor the request representation.
     1304      <p id="rfc.section.3.2.1.6.p.1">The no-transform request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> change the <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> request header fields, nor the request representation.
    13081305      </p>
    13091306      <div id="rfc.iref.c.13"></div>
     
    14211418      <div id="rfc.iref.n.6"></div>
    14221419      <h4 id="rfc.section.3.2.2.9"><a href="#rfc.section.3.2.2.9">3.2.2.9</a>&nbsp;<a id="cache-response-directive.no-transform" href="#cache-response-directive.no-transform">no-transform</a></h4>
    1423       <p id="rfc.section.3.2.2.9.p.1">The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> change the Content-Encoding, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or Content-Type response header fields, nor the response representation.
     1420      <p id="rfc.section.3.2.2.9.p.1">The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> change the <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> or <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> response header fields, nor the response representation.
    14241421      </p>
    14251422      <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
     
    15921589      </ul>
    15931590      <p id="rfc.section.3.6.p.9">If an implementation sends a message with one or more Warning header fields to a receiver whose version is HTTP/1.0 or lower,
    1594          then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date header field in the message.
    1595       </p>
    1596       <p id="rfc.section.3.6.p.10">If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the Date
    1597          value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning
     1591         then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in the message.
     1592      </p>
     1593      <p id="rfc.section.3.6.p.10">If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the <a href="p2-semantics.html#header.date" class="smpl">Date</a> value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning
    15981594         header fields.) If all of the warning-values are deleted for this reason, the Warning header field <em class="bcp14">MUST</em> be deleted as well.
    15991595      </p>
     
    19701966      <p id="rfc.section.A.p.1">Make the specified age calculation algorithm less conservative. (<a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>)
    19711967      </p>
    1972       <p id="rfc.section.A.p.2">Remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to
    1973          use. (<a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>)
     1968      <p id="rfc.section.A.p.2">Remove requirement to consider <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> in successful responses in order to determine the appropriate response to use. (<a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>)
    19741969      </p>
    19751970      <p id="rfc.section.A.p.3">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.6</a>)
Note: See TracChangeset for help on using the changeset viewer.