Ignore:
Timestamp:
Jul 22, 2010, 2:10:39 AM (9 years ago)
Author:
fielding@…
Message:

regenerate html

File:
1 edited

Legend:

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

    r865 r868  
    680680      </p>
    681681      <ul class="empty">
    682          <li>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a stored response is an
    683             equivalent copy of an entity.
     682         <li>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a stored response has an
     683            equivalent copy of a representation.
    684684         </li>
    685685      </ul>
     
    799799      </p>
    800800      <p id="rfc.section.2.3.p.2">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
    801          using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not
    802          likely to change in a semantically significant way before the expiration time is reached.
     801         using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
     802         is not likely to change in a semantically significant way before the expiration time is reached.
    803803      </p>
    804804      <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past.
     
    10251025      <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
    10261026      <p id="rfc.section.3.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    1027          receives the entity.
     1027         receives the message.
    10281028      </p>
    10291029      <div id="rfc.iref.a.2"></div>
     
    11961196            an HTTP/1.1 cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a 504 (Gateway Timeout) response.
    11971197         </li>
    1198          <li>Servers <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to validate a request on the entity could result in incorrect operation,
    1199             such as a silently unexecuted financial transaction.
     1198         <li>Servers <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to validate a request on the representation could result in incorrect
     1199            operation, such as a silently unexecuted financial transaction.
    12001200         </li>
    12011201      </ul>
     
    13361336      <p id="rfc.section.3.6.p.1">The "Warning" general-header field is used to carry additional information about the status or transformation of a message
    13371337         that might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced
    1338          by caching operations or transformations applied to the entity body of the message.
     1338         by caching operations or transformations applied to the payload of the message.
    13391339      </p>
    13401340      <p id="rfc.section.3.6.p.2">Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status
     
    13691369         <li>1xx Warnings describe the freshness or validation status of the response, and so <em class="bcp14">MUST</em> be deleted by caches after validation. They can only be generated by a cache when validating a cached entry, and <em class="bcp14">MUST NOT</em> be generated in any other situation.
    13701370         </li>
    1371          <li>2xx Warnings describe some aspect of the entity body or entity headers that is not rectified by a validation (for example,
    1372             a lossy compression of the entity bodies) and <em class="bcp14">MUST NOT</em> be deleted by caches after validation, unless a full response is returned, in which case they <em class="bcp14">MUST</em> be.
     1371         <li>2xx Warnings describe some aspect of the representation that is not rectified by a validation (for example, a lossy compression
     1372            of the representation) and <em class="bcp14">MUST NOT</em> be deleted by caches after validation, unless a full response is returned, in which case they <em class="bcp14">MUST</em> be.
    13731373         </li>
    13741374      </ul>
Note: See TracChangeset for help on using the changeset viewer.