Ignore:
Timestamp:
Jan 31, 2009, 12:56:49 PM (11 years ago)
Author:
julian.reschke@…
Message:

re-generate HTML, P6: fix a few formatting issues, add a few crefs

File:
1 edited

Legend:

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

    r437 r441  
    382382        </t>
    383383        <t>Note that in normal operation, most caches will not store a response that has neither a
    384           cache validator nor an explicitly expiration time, as such responses are not usually
     384          cache validator nor an explicit expiration time, as such responses are not usually
    385385          useful to store. However, caches are not prohibited from storing such responses.</t>
    386386
     
    388388          title="Storing Incomplete Responses">
    389389          <t>A cache that receives an incomplete response (for example, with fewer bytes of data
    390             than specified in a Content-Length header) &MAY; store the response. However, the
     390            than specified in a Content-Length header) &MAY; store the response <cref source="JRE">Indeed? Is this new?</cref>. However, the
    391391            cache &MUST; treat this as a partial response &partial;. Partial responses
    392392            &MAY; be combined as described in &combining-byte-ranges;; the result might be a
     
    451451        <t>HTTP caching works best when caches can entirely avoid making requests to the origin
    452452          server. When a response is "fresh" in the cache, it can be used to satisfy subsequent
    453           requests without contacting the origin server. This is also referred to as "expiration."</t>
     453          requests without contacting the origin server. This is also referred to as "expiration."<cref source="JRE">What exactly is called 'expiration'?</cref>.</t>
    454454        <t>Expiration applies only to responses taken from a cache and not to first-hand responses.
    455455          It cannot be used to force a user agent to refresh its display or reload a resource; its
     
    457457          the difference between caches and history mechanisms.</t>
    458458        <t>The primary mechanism for avoiding requests is for an origin server to provide an
    459           explicit expiration time in the future, using either the Expires header <xref
    460             target="header.expires" /> or the max-age response cache directive <xref
    461             target="cache-response-directive" />. Generally, origin servers will assign future
     459          explicit expiration time in the future, using either the Expires header (<xref
     460            target="header.expires" />) or the max-age response cache directive (<xref
     461            target="cache-response-directive" />). Generally, origin servers will assign future
    462462          explicit expiration times to responses in the belief that the entity is not likely to
    463463          change in a semantically significant way before the expiration time is reached. This
     
    512512              attach a Warning header with a 113 warn-code to the response if its current_age is
    513513              more than 24 hours and such a warning is not already present.</t>
    514             <t>Also, if the response has a Last-Modified header &header-last-modified;, the
     514            <t>Also, if the response has a Last-Modified header (&header-last-modified;), the
    515515              heuristic expiration value &SHOULD; be no more than some fraction of the interval
    516516              since that time. A typical setting of this fraction might be 10%.</t>
     
    610610          <t>Otherwise, caches &SHOULD-NOT; return stale responses.</t>
    611611          <t>Stale responses &SHOULD; have a Warning header with the 110 warn-code (see <xref
    612               format="counter" target="header.warning" />).</t>
     612              target="header.warning" />).</t>
    613613          <t>If a cache receives a first-hand response (either an entire response, or a 304 (Not
    614614            Modified) response) that it would normally forward to the requesting client, and the
     
    627627        <t>HTTP's conditional request mechanism, defined in &conditional;, is used to avoid
    628628          retransmitting the response payload when the stored response is valid. When a stored
    629           response includes one or more "cache validators," such as the field values of an ETag or
     629          response includes one or more "cache validators", such as the field values of an ETag or
    630630          Last-Modified header field, then a validating GET request &SHOULD; be made conditional
    631631          to those field values. The server checks the conditional request's validator against the
     
    682682      <section anchor="caching.negotiated.responses" title="Caching Negotiated Responses">
    683683        <t>Use of server-driven content negotiation (&server-driven-negotiation;), as indicated
    684           by the presence of a Vary header field <xref target="header.vary" /> in a response, alters
     684          by the presence of a Vary header field (<xref target="header.vary" />) in a response, alters
    685685          the conditions and procedure by which a cache can use the response for subsequent
    686686          requests.</t>
     
    17921792        <t>A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add
    17931793          this missing case. (Sections <xref format="counter" target="response.cacheability" />,
    1794             <xref format="counter" target="header.cache-control" />.</t>
     1794            <xref format="counter" target="header.cache-control" />).</t>
    17951795        <t>Transfer-coding and message lengths all interact in ways that required fixing exactly
    17961796          when chunked encoding is used (to allow for transfer encoding that may not be self
Note: See TracChangeset for help on using the changeset viewer.