Ignore:
Timestamp:
Jul 8, 2012, 6:02:45 AM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions(P6)

File:
1 edited

Legend:

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

    r1736 r1737  
    471471      <t>the response either:
    472472         <list style="symbols">
    473             <t>contains an Expires header field (see <xref target="header.expires"
    474             />), or</t>
     473            <t>contains an <x:ref>Expires</x:ref> header field (see
     474            <xref target="header.expires"/>), or</t>
    475475            <t>contains a max-age response cache directive (see <xref
    476476            target="cache-response-directive" />), or</t>
     
    564564<t>
    565565   When a stored response is used to satisfy a request without validation,
    566    a cache &MUST; include a single Age header field (<xref target="header.age"
    567    />) in the response with a value equal to the stored response's
    568    current_age; see <xref target="age.calculations" />.
     566   a cache &MUST; include a single <x:ref>Age</x:ref> header field
     567   (<xref target="header.age"/>) in the response with a value equal to the
     568   stored response's current_age; see <xref target="age.calculations" />.
    569569</t>
    570570<t>
     
    601601<t>
    602602   The primary mechanism for determining freshness is for an origin server to
    603    provide an explicit expiration time in the future, using either the Expires
     603   provide an explicit expiration time in the future, using either the <x:ref>Expires</x:ref>
    604604   header field (<xref target="header.expires" />) or the max-age response cache
    605605   directive (<xref target="cache-response-directive" />). Generally, origin
     
    660660      <t>If the max-age response cache directive (<xref
    661661      target="cache-response-directive" />) is present, use its value, or</t>
    662       <t>If the Expires response header field (<xref target="header.expires" />) is
    663       present, use its value minus the value of the Date response header field,
    664       or</t>
     662      <t>If the <x:ref>Expires</x:ref> response header field
     663      (<xref target="header.expires" />) is present, use its value minus the
     664      value of the Date response header field, or</t>
    665665      <t>Otherwise, no explicit expiration time is present in the response. A
    666666      heuristic freshness lifetime might be applicable; see <xref
     
    674674<t>
    675675   When there is more than one value present for a given directive (e.g., two
    676    Expires header fields, multiple Cache-Control: max-age directives), it is
    677    considered invalid. Caches are encouraged to consider responses that have
    678    invalid freshness information to be stale.
     676   <x:ref>Expires</x:ref> header fields, multiple Cache-Control: max-age
     677   directives), it is considered invalid. Caches are encouraged to consider
     678   responses that have invalid freshness information to be stale.
    679679</t>
    680680
     
    691691</t>
    692692<t>
    693    When a heuristic is used to calculate freshness lifetime, a cache
    694    &SHOULD; attach a Warning header field with a 113 warn-code to the response if
    695    its current_age is more than 24 hours and such a warning is not already
    696    present.
     693   When a heuristic is used to calculate freshness lifetime, a cache &SHOULD;
     694   attach a <x:ref>Warning</x:ref> header field with a 113 warn-code to the
     695   response if its current_age is more than 24 hours and such a warning is not
     696   already present.
    697697</t>
    698698<t>
     
    717717<section anchor="age.calculations" title="Calculating Age">
    718718<t>
    719    HTTP/1.1 uses the Age header field to convey the estimated age of the
    720    response message when obtained from a cache. The Age field value is the
    721    cache's estimate of the amount of time since the response was generated or
     719   HTTP/1.1 uses the <x:ref>Age</x:ref> header field to convey the estimated
     720   age of the response message when obtained from a cache. The Age field value
     721   is the cache's estimate of the amount of time since the response was generated or
    722722   validated by the origin server. In essence, the Age value is the sum of the
    723723   time that the response has been resident in each of the caches along the
     
    732732   <list>
    733733      <t>
    734          The term "age_value" denotes the value of the Age header field (<xref
    735          target="header.age"/>), in a form appropriate for arithmetic
    736          operation; or 0, if not available.
     734         The term "age_value" denotes the value of the <x:ref>Age</x:ref>
     735         header field (<xref target="header.age"/>), in a form appropriate for
     736         arithmetic operation; or 0, if not available.
    737737      </t>
    738738   </list>
     
    806806</artwork></figure>
    807807<t>
    808    unless the cache is confident in the value of the Age header (e.g., because
    809    there are no HTTP/1.0 hops in the Via header), in which case the
    810    corrected_age_value &MAY; be used as the corrected_initial_age.</t>
     808   unless the cache is confident in the value of the <x:ref>Age</x:ref> header
     809   field (e.g., because there are no HTTP/1.0 hops in the Via header field), in
     810   which case the corrected_age_value &MAY; be used as the
     811   corrected_initial_age.</t>
    811812<t>
    812813   The current_age of a stored response can then be calculated by adding the
     
    832833             
    833834     <t>An HTTP/1.1 implementation &MAY; internally represent a parsed
    834         Expires date as earlier than the proper value, but &MUST-NOT;
    835         internally represent a parsed Expires date as later than the
     835        <x:ref>Expires</x:ref> date as earlier than the proper value, but
     836        &MUST-NOT; internally represent a parsed Expires date as later than the
    836837        proper value.</t>
    837838
     
    867868</t>
    868869<t>
    869    A cache &SHOULD; append a Warning header field with the 110 warn-code (see
    870    <xref target="header.warning" />) to stale responses. Likewise, a cache
    871    &SHOULD; add the 112 warn-code to stale responses if the cache is
    872    disconnected.
     870   A cache &SHOULD; append a <x:ref>Warning</x:ref> header field with the 110
     871   warn-code (see <xref target="header.warning"/>) to stale responses.
     872   Likewise, a cache &SHOULD; add the 112 warn-code to stale responses if the
     873   cache is disconnected.
    873874</t>
    874875<t>
     
    876877   <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward to the
    877878   requesting client, and the received response is no longer fresh, the cache
    878    can forward it to the requesting client without adding a new Warning (but
    879    without removing any existing Warning header fields). A cache shouldn't
     879   can forward it to the requesting client without adding a new <x:ref>Warning</x:ref>
     880   (but without removing any existing Warning header fields). A cache shouldn't
    880881   attempt to validate a response simply because that response became stale in
    881882   transit.
     
    965966   If a stored response is selected for update, the cache &MUST;:
    966967   <list style="symbols">
    967       <t>delete any Warning header fields in the stored response with
    968          warn-code 1xx (see <xref target="header.warning" />);</t>
    969       <t>retain any Warning header fields in the stored response with
    970          warn-code 2xx; and,</t>
     968      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
     969         with warn-code 1xx (see <xref target="header.warning" />);</t>
     970      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
     971         with warn-code 2xx; and,</t>
    971972      <t>use other header fields provided in the <x:ref>304 (Not Modified)</x:ref>
    972973         response to replace all instances of the corresponding header
     
    998999   remaining headers in the stored response using the following rules:
    9991000   <list style="symbols">
    1000       <t>delete any Warning header fields in the stored response with
    1001          warn-code 1xx (see <xref target="header.warning" />);</t>
    1002       <t>retain any Warning header fields in the stored response with
    1003          warn-code 2xx; and,</t>
     1001      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
     1002         with warn-code 1xx (see <xref target="header.warning" />);</t>
     1003      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
     1004         with warn-code 2xx; and,</t>
    10041005      <t>use other header fields provided in the response to replace
    10051006         all instances of the corresponding header fields in the stored
     
    10591060
    10601061<t>
    1061    In this specification, the following Cache-Control response directives
    1062    (<xref target="cache-response-directive"/>) have such an effect:
     1062   In this specification, the following <x:ref>Cache-Control</x:ref> response
     1063   directives (<xref target="cache-response-directive"/>) have such an effect:
    10631064   must-revalidate, public, s-maxage.
    10641065</t>
     
    10781079<t>
    10791080   When a cache receives a request that can be satisfied by a stored response
    1080    that has a Vary header field (<xref target="header.vary"/>), it &MUST-NOT;
    1081    use that response unless all of the selecting header fields nominated by
    1082    the Vary header field match in both the original request (i.e., that associated
    1083    with the stored response), and the presented request.
     1081   that has a <x:ref>Vary</x:ref> header field (<xref target="header.vary"/>),
     1082   it &MUST-NOT; use that response unless all of the selecting header fields
     1083   nominated by the Vary header field match in both the original request (i.e.,
     1084   that associated with the stored response), and the presented request.
    10841085</t>
    10851086<t>
     
    11091110</t>
    11101111<t>
    1111    A Vary header field-value of "*" always fails to match, and subsequent
    1112    requests to that resource can only be properly interpreted by the origin
    1113    server.
     1112   A <x:ref>Vary</x:ref> header field-value of "*" always fails to match, and
     1113   subsequent requests to that resource can only be properly interpreted by the
     1114   origin server.
    11141115</t>
    11151116<t>
     
    11431144   cache &MUST;:
    11441145   <list style="symbols">
    1145       <t>delete any Warning header fields in the stored response with
    1146          warn-code 1xx (see <xref target="header.warning" />);</t>
    1147       <t>retain any Warning header fields in the stored response with
    1148          warn-code 2xx; and,</t>
     1146      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
     1147         with warn-code 1xx (see <xref target="header.warning" />);</t>
     1148      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
     1149         with warn-code 2xx; and,</t>
    11491150      <t>use other header fields provided in the new response, aside
    11501151         from Content-Range, to replace all instances of the corresponding
     
    15691570   The s-maxage response directive indicates that, in shared caches, the
    15701571   maximum age specified by this directive overrides the maximum age
    1571    specified by either the max-age directive or the Expires header field. The
    1572    s-maxage directive also implies the semantics of the proxy-revalidate
    1573    response directive.
     1572   specified by either the max-age directive or the <x:ref>Expires</x:ref>
     1573   header field. The s-maxage directive also implies the semantics of the
     1574   proxy-revalidate response directive.
    15741575</t>
    15751576<t>
     
    17051706<x:note>
    17061707   <t>
    1707        &Note; If a response includes a Cache-Control field with the
    1708        max-age directive (see <xref target="cache-response-directive" />),
     1708       &Note; If a response includes a <x:ref>Cache-Control</x:ref> field with
     1709       the max-age directive (see <xref target="cache-response-directive" />),
    17091710       that directive overrides the Expires field. Likewise, the s-maxage
    17101711       directive overrides Expires in shared caches.
     
    17391740   The "Pragma" header field allows backwards compatibility with HTTP/1.0
    17401741   caches, so that clients can specify a "no-cache" request that they will
    1741    understand (as Cache-Control was not defined until HTTP/1.1). When the
    1742    Cache-Control header is also present and understood in a request, Pragma is
    1743    ignored.
     1742   understand (as <x:ref>Cache-Control</x:ref> was not defined until HTTP/1.1).
     1743   When the Cache-Control header field is also present and understood in a
     1744   request, Pragma is ignored.
    17441745</t>
    17451746<t>
     
    17541755</artwork></figure>
    17551756<t>
    1756    When the Cache-Control header is not present in a request, the no-cache
    1757    request pragma-directive &MUST; have the same effect on caches as if
    1758    "Cache-Control: no-cache" were present (see <xref
     1757   When the <x:ref>Cache-Control</x:ref> header field is not present in a
     1758   request, the no-cache request pragma-directive &MUST; have the same effect
     1759   on caches as if "Cache-Control: no-cache" were present (see <xref
    17591760   target="cache-request-directive" />).
    17601761</t>
     
    17621763   When sending a no-cache request, a client ought to include both the pragma
    17631764   and cache-control directives, unless Cache-Control: no-cache is
    1764    purposefully omitted to target other Cache-Control response directives at
    1765    HTTP/1.1 caches. For example:
     1765   purposefully omitted to target other <x:ref>Cache-Control</x:ref> response
     1766   directives at HTTP/1.1 caches. For example:
    17661767</t>
    17671768<figure>
     
    17771778   will constrain HTTP/1.1 caches to serve a response no older than 30
    17781779   seconds, while precluding implementations that do not understand
    1779    Cache-Control from serving a cached response.
     1780   <x:ref>Cache-Control</x:ref> from serving a cached response.
    17801781</t>
    17811782<x:note>
     
    25362537</t>
    25372538<t>
    2538   Do not mention RFC 2047 encoding and multiple languages in Warning header fields
    2539   anymore, as these aspects never were implemented.
     2539  Do not mention RFC 2047 encoding and multiple languages in <x:ref>Warning</x:ref>
     2540  header fields anymore, as these aspects never were implemented.
    25402541  (<xref target="header.warning" />)
    25412542</t>
Note: See TracChangeset for help on using the changeset viewer.