Changeset 1737


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

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

Location:
draft-ietf-httpbis/latest
Files:
10 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1735 r1737  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 7, 2013";
     451       content: "Expires January 9, 2013";
    452452  }
    453453  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: January 7, 2013</td>
     525               <td class="left">Expires: January 9, 2013</td>
    526526               <td class="right">greenbytes</td>
    527527            </tr>
    528528            <tr>
    529529               <td class="left"></td>
    530                <td class="right">July 6, 2012</td>
     530               <td class="right">July 8, 2012</td>
    531531            </tr>
    532532         </tbody>
     
    561561         in progress”.
    562562      </p>
    563       <p>This Internet-Draft will expire on January 7, 2013.</p>
     563      <p>This Internet-Draft will expire on January 9, 2013.</p>
    564564      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    565565      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    19471947      </p>
    19481948      <ul>
    1949          <li>Expires</li>
    1950       </ul>
    1951       <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response.
     1949         <li><a href="p6-cache.html#header.expires" class="smpl">Expires</a> (<a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)
     1950         </li>
     1951      </ul>
     1952      <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response.
    19521953      </p>
    19531954      <p id="rfc.section.5.6.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request:
     
    19581959         <li>Content-Type</li>
    19591960      </ul>
    1960       <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1961      <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    19611962      </p>
    19621963      <div class="note" id="rfc.section.5.6.2.p.7">
     
    19941995      </p>
    19951996      <p id="rfc.section.6.1.p.6">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients
    1996          in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1997         in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    19971998      </p>
    19981999      <p id="rfc.section.6.1.p.7">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
     
    37563757                     </ul>
    37573758                  </li>
    3758                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.6.2</a>, <a href="#rfc.xref.Part6.7">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
     3759                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.6.2</a>, <a href="#rfc.xref.Part6.7">5.6.2</a>, <a href="#rfc.xref.Part6.8">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
    37593760                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a></li>
    37603761                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.4</a></li>
    3761                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a></li>
    3762                         <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.6">5.6.2</a></li>
     3762                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.8">6.1</a></li>
     3763                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">5.6.2</a></li>
     3764                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.7">5.6.2</a></li>
    37633765                     </ul>
    37643766                  </li>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1735 r1737  
    2929  <!ENTITY header-date            "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3030  <!ENTITY header-expect          "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     31  <!ENTITY header-expires         "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3132  <!ENTITY header-mime-version    "<xref target='Part2' x:rel='#mime-version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3233  <!ENTITY header-pragma          "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    26142615   response:
    26152616  <list style="symbols">
    2616     <t>Expires</t>
     2617    <t><x:ref>Expires</x:ref> (&header-expires;)</t>
    26172618  </list>
    26182619</t>
    26192620<t>
    26202621   but it &MAY; add any of these fields if not already present. If an
    2621    Expires header field is added, it &MUST; be given a field-value identical to
    2622    that of the Date header field in that response.
     2622   <x:ref>Expires</x:ref> header field is added, it &MUST; be given a
     2623   field-value identical to that of the Date header field in that response.
    26232624</t>
    26242625<t>
     
    41814182  </front>
    41824183  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
    4183   <x:source href="p6-cache.xml" basename="p6-cache"/>
     4184  <x:source href="p6-cache.xml" basename="p6-cache">
     4185    <x:defines>Expires</x:defines>
     4186  </x:source>
    41844187</reference>
    41854188
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1735 r1737  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 7, 2013";
     451       content: "Expires January 9, 2013";
    452452  }
    453453  @bottom-right {
     
    497497      <meta name="dct.creator" content="Reschke, J. F.">
    498498      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    499       <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
     499      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
    500500      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    501501      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields. Furthermore, it defines HTTP message content, metadata, and content negotiation.">
     
    528528            </tr>
    529529            <tr>
    530                <td class="left">Expires: January 7, 2013</td>
     530               <td class="left">Expires: January 9, 2013</td>
    531531               <td class="right">greenbytes</td>
    532532            </tr>
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">July 6, 2012</td>
     535               <td class="right">July 8, 2012</td>
    536536            </tr>
    537537         </tbody>
     
    563563         in progress”.
    564564      </p>
    565       <p>This Internet-Draft will expire on January 7, 2013.</p>
     565      <p>This Internet-Draft will expire on January 9, 2013.</p>
    566566      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    567567      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    25532553         </p>
    25542554      </div>
    2555       <p id="rfc.section.8.1.p.8">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
     2555      <p id="rfc.section.8.1.p.8">The <a href="p6-cache.html#header.vary" class="smpl">Vary</a> header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
    25562556      </p>
    25572557      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>
     
    36733673      <p id="rfc.section.11.5.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields
    36743674         by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by
    3675          looking for any Vary header fields generated by the server, that such sending could improve the quality of service.
     3675         looking for any <a href="p6-cache.html#header.vary" class="smpl">Vary</a> header fields generated by the server, that such sending could improve the quality of service.
    36763676      </p>
    36773677      <p id="rfc.section.11.5.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1735 r1737  
    29442944</x:note>
    29452945<t>
    2946    The Vary header field (&header-vary;) can be used to express the parameters the
    2947    server uses to select a representation that is subject to server-driven
    2948    negotiation.
     2946   The <x:ref>Vary</x:ref> header field (&header-vary;) can be used to express
     2947   the parameters the server uses to select a representation that is subject to
     2948   server-driven negotiation.
    29492949</t>
    29502950</section>
     
    45724572   to omit the sending of Accept-Language header fields by default, and to ask
    45734573   the user whether or not to start sending Accept-Language header fields to a
    4574    server if it detects, by looking for any Vary header fields
     4574   server if it detects, by looking for any <x:ref>Vary</x:ref> header fields
    45754575   generated by the server, that such sending could improve the quality
    45764576   of service.
     
    46974697  </front>
    46984698  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
    4699   <x:source href="p6-cache.xml" basename="p6-cache"/>
     4699  <x:source href="p6-cache.xml" basename="p6-cache">
     4700    <x:defines>Vary</x:defines>
     4701  </x:source>
    47004702</reference>
    47014703
  • draft-ietf-httpbis/latest/p4-conditional.html

    r1734 r1737  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 7, 2013";
     451       content: "Expires January 9, 2013";
    452452  }
    453453  @bottom-right {
     
    490490      <meta name="dct.creator" content="Reschke, J. F.">
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    492       <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
     492      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    494494      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
     
    516516            </tr>
    517517            <tr>
    518                <td class="left">Expires: January 7, 2013</td>
     518               <td class="left">Expires: January 9, 2013</td>
    519519               <td class="right">J. Reschke, Editor</td>
    520520            </tr>
     
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">July 6, 2012</td>
     527               <td class="right">July 8, 2012</td>
    528528            </tr>
    529529         </tbody>
     
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on January 7, 2013.</p>
     557      <p>This Internet-Draft will expire on January 9, 2013.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    11071107         as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
    11081108      </p>
    1109       <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<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>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a 200
    1110          response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, Expires,
    1111          or Vary, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
     1109      <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<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>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
    11121110      </p>
    11131111      <p id="rfc.section.4.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1734 r1737  
    10121012   A 304 response &MUST; include a Date header field (&header-date;)
    10131013   unless the origin server does not have a clock that can provide a
    1014    reasonable approximation of the current time.  If a 200 response
    1015    to the same request would have included any of the header fields
    1016    Cache-Control, Content-Location, ETag, Expires, or Vary, then
    1017    those same header fields &MUST; be sent in a 304 response.
     1014   reasonable approximation of the current time.  If a <x:ref>200 (OK)</x:ref>
     1015   response to the same request would have included any of the header fields
     1016   Cache-Control, Content-Location, ETag, <x:ref>Expires</x:ref>, or
     1017   <x:ref>Vary</x:ref>, then those same header fields &MUST; be sent in a 304
     1018   response.
    10181019</t>
    10191020<t>
     
    12481249  </front>
    12491250  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
    1250   <x:source href="p6-cache.xml" basename="p6-cache"/>
     1251  <x:source href="p6-cache.xml" basename="p6-cache">
     1252    <x:defines>Expires</x:defines>
     1253    <x:defines>Vary</x:defines>
     1254  </x:source>
    12511255</reference>
    12521256
  • draft-ietf-httpbis/latest/p5-range.html

    r1735 r1737  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 7, 2013";
     451       content: "Expires January 9, 2013";
    452452  }
    453453  @bottom-right {
     
    492492      <meta name="dct.creator" content="Reschke, J. F.">
    493493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    494       <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
     494      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    496496      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests.">
     
    518518            </tr>
    519519            <tr>
    520                <td class="left">Expires: January 7, 2013</td>
     520               <td class="left">Expires: January 9, 2013</td>
    521521               <td class="right">J. Reschke, Editor</td>
    522522            </tr>
     
    527527            <tr>
    528528               <td class="left"></td>
    529                <td class="right">July 6, 2012</td>
     529               <td class="right">July 8, 2012</td>
    530530            </tr>
    531531         </tbody>
     
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on January 7, 2013.</p>
     557      <p>This Internet-Draft will expire on January 9, 2013.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    742742         </li>
    743743         <li>Date</li>
    744          <li>Cache-Control, ETag, Expires, Content-Location and/or Vary, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request
     744         <li>Cache-Control, ETag, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, Content-Location and/or Vary, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request
    745745         </li>
    746746      </ul>
  • draft-ietf-httpbis/latest/p5-range.xml

    r1735 r1737  
    335335    </t>
    336336    <t>
    337         Cache-Control, ETag, Expires, Content-Location and/or Vary, if
    338         the header field would have been sent in a <x:ref>200 (OK)</x:ref> response to the
    339         same request
     337        Cache-Control, ETag, <x:ref>Expires</x:ref>, Content-Location and/or
     338        Vary, if the header field would have been sent in a <x:ref>200 (OK)</x:ref>
     339        response to the same request
    340340    </t>
    341341  </list>
     
    10721072  </front>
    10731073  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
    1074   <x:source href="p6-cache.xml" basename="p6-cache"/>
     1074  <x:source href="p6-cache.xml" basename="p6-cache">
     1075    <x:defines>Expires</x:defines>
     1076  </x:source>
    10751077</reference>
    10761078
  • draft-ietf-httpbis/latest/p6-cache.html

    r1736 r1737  
    856856         <li>the response either:
    857857            <ul>
    858                <li>contains an Expires header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;3.3</a>), or
     858               <li>contains an <a href="#header.expires" class="smpl">Expires</a> header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;3.3</a>), or
    859859               </li>
    860860               <li>contains a max-age response cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), or
     
    908908      <p id="rfc.section.2.2.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;3.2.3</a>.
    909909      </p>
    910       <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
     910      <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
    911911      </p>
    912912      <p id="rfc.section.2.2.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 2.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request
     
    925925      </p>
    926926      <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,
    927          using either the Expires header field (<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
     927         using either the <a href="#header.expires" class="smpl">Expires</a> header field (<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
    928928         is not likely to change in a semantically significant way before the expiration time is reached.
    929929      </p>
     
    953953         <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
    954954         </li>
    955          <li>If the Expires 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
     955         <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
    956956         </li>
    957957         <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>.
     
    959959      </ul>
    960960      <p id="rfc.section.2.3.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p>
    961       <p id="rfc.section.2.3.1.p.3">When there is more than one value present for a given directive (e.g., two Expires header fields, multiple Cache-Control:
    962          max-age directives), it is considered invalid. Caches are encouraged to consider responses that have invalid freshness information
    963          to be stale.
     961      <p id="rfc.section.2.3.1.p.3">When there is more than one value present for a given directive (e.g., two <a href="#header.expires" class="smpl">Expires</a> header fields, multiple Cache-Control: max-age directives), it is considered invalid. Caches are encouraged to consider responses
     962         that have invalid freshness information to be stale.
    964963      </p>
    965964      <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4>
     
    968967            (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, <a href="p2-semantics.html#status.300" class="smpl">300 (Multiple Choices)</a>, <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="p2-semantics.html#status.410" class="smpl">410 (Gone)</a>), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
    969968      </p>
    970       <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning
    971          is not already present.
     969      <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a <a href="#header.warning" class="smpl">Warning</a> header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is not already
     970         present.
    972971      </p>
    973972      <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
     
    981980      </div>
    982981      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
    983       <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the Age header field to convey the estimated age of the response message when obtained from a cache. The Age
    984          field value is the cache's estimate of the amount of time since the response was generated or validated by the origin server.
    985          In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the path
    986          from the origin server, plus the amount of time it has been in transit along network paths.
     982      <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the <a href="#header.age" class="smpl">Age</a> header field to convey the estimated age of the response message when obtained from a cache. The Age field value is the cache's
     983         estimate of the amount of time since the response was generated or validated by the origin server. In essence, the Age value
     984         is the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus
     985         the amount of time it has been in transit along network paths.
    987986      </p>
    988987      <p id="rfc.section.2.3.2.p.2">The following data is used for the age calculation:</p>
     
    990989      </p>
    991990      <ul class="empty">
    992          <li>The term "age_value" denotes the value of the Age header field (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;3.1</a>), in a form appropriate for arithmetic operation; or 0, if not available.
     991         <li>The term "age_value" denotes the value of the <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;3.1</a>), in a form appropriate for arithmetic operation; or 0, if not available.
    993992         </li>
    994993      </ul>
     
    10321031      <p>These <em class="bcp14">SHOULD</em> be combined as
    10331032      </p>  <pre class="text">  corrected_initial_age = max(apparent_age, corrected_age_value);
    1034 </pre><p id="rfc.section.2.3.2.p.11">unless the cache is confident in the value of the Age header (e.g., because there are no HTTP/1.0 hops in the Via header),
    1035          in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.
     1033</pre><p id="rfc.section.2.3.2.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the Via header field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.
    10361034      </p>
    10371035      <p id="rfc.section.2.3.2.p.12">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
     
    10481046         <li>Although all date formats are specified to be case-sensitive, recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively.
    10491047         </li>
    1050          <li>An HTTP/1.1 implementation <em class="bcp14">MAY</em> internally represent a parsed Expires date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value.
     1048         <li>An HTTP/1.1 implementation <em class="bcp14">MAY</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value.
    10511049         </li>
    10521050         <li>All expiration-related calculations <em class="bcp14">MUST</em> be done in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time.
     
    10661064         or doing so is explicitly allowed (e.g., by the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
    10671065      </p>
    1068       <p id="rfc.section.2.3.3.p.4">A cache <em class="bcp14">SHOULD</em> append a Warning header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.
     1066      <p id="rfc.section.2.3.3.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.
    10691067      </p>
    10701068      <p id="rfc.section.2.3.3.p.5">If a cache receives a first-hand response (either an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache
    1071          can forward it to the requesting client without adding a new Warning (but without removing any existing Warning header fields).
    1072          A cache shouldn't attempt to validate a response simply because that response became stale in transit.
     1069         can forward it to the requesting client without adding a new <a href="#header.warning" class="smpl">Warning</a> (but without removing any existing Warning header fields). A cache shouldn't attempt to validate a response simply because
     1070         that response became stale in transit.
    10731071      </p>
    10741072      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
     
    11161114      </p>
    11171115      <ul>
    1118          <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>);
    1119          </li>
    1120          <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li>
     1116         <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>);
     1117         </li>
     1118         <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and,
     1119         </li>
    11211120         <li>use other header fields provided in the <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response to replace all instances of the corresponding header fields in the stored response.
    11221121         </li>
     
    11331132      </p>
    11341133      <ul>
    1135          <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>);
    1136          </li>
    1137          <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li>
     1134         <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>);
     1135         </li>
     1136         <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and,
     1137         </li>
    11381138         <li>use other header fields provided in the response to replace all instances of the corresponding header fields in the stored
    11391139            response.
     
    11621162      <p id="rfc.section.2.7.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
    11631163      </p>
    1164       <p id="rfc.section.2.7.p.2">In this specification, the following Cache-Control response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) have such an effect: must-revalidate, public, s-maxage.
     1164      <p id="rfc.section.2.7.p.2">In this specification, the following <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) have such an effect: must-revalidate, public, s-maxage.
    11651165      </p>
    11661166      <p id="rfc.section.2.7.p.3">Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be
     
    11691169      </p>
    11701170      <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
    1171       <p id="rfc.section.2.8.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original
     1171      <p id="rfc.section.2.8.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="#header.vary" class="smpl">Vary</a> header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original
    11721172         request (i.e., that associated with the stored response), and the presented request.
    11731173      </p>
     
    11861186         if it is also absent there.
    11871187      </p>
    1188       <p id="rfc.section.2.8.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted
     1188      <p id="rfc.section.2.8.p.4">A <a href="#header.vary" class="smpl">Vary</a> header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted
    11891189         by the origin server.
    11901190      </p>
     
    12031203      </p>
    12041204      <ul>
    1205          <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;3.6</a>);
    1206          </li>
    1207          <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li>
     1205         <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;3.6</a>);
     1206         </li>
     1207         <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and,
     1208         </li>
    12081209         <li>use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding
    12091210            header fields in the stored response.
     
    14201421      </ul>
    14211422      <p id="rfc.section.3.2.2.8.p.2">The s-maxage response directive indicates that, in shared caches, the maximum age specified by this directive overrides the
    1422          maximum age specified by either the max-age directive or the Expires header field. The s-maxage directive also implies the
    1423          semantics of the proxy-revalidate response directive.
     1423         maximum age specified by either the max-age directive or the <a href="#header.expires" class="smpl">Expires</a> header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive.
    14241424      </p>
    14251425      <p id="rfc.section.3.2.2.8.p.3"> <b>Note:</b> This directive uses the token form of the argument syntax; e.g., 's-maxage=10', not 's-maxage="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     
    14891489      </p>
    14901490      <div class="note" id="rfc.section.3.3.p.7">
    1491          <p> <b>Note:</b> If a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.
     1491         <p> <b>Note:</b> If a response includes a <a href="#header.cache-control" class="smpl">Cache-Control</a> field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.
    14921492         </p>
    14931493      </div>
     
    15051505      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.pragma" href="#header.pragma">Pragma</a></h2>
    15061506      <p id="rfc.section.3.4.p.1">The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request
    1507          that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header is also present
    1508          and understood in a request, Pragma is ignored.
     1507         that they will understand (as <a href="#header.cache-control" class="smpl">Cache-Control</a> was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is
     1508         ignored.
    15091509      </p>
    15101510      <p id="rfc.section.3.4.p.2">In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification
     
    15141514  <a href="#header.pragma" class="smpl">pragma-directive</a> = "no-cache" / <a href="#header.pragma" class="smpl">extension-pragma</a>
    15151515  <a href="#header.pragma" class="smpl">extension-pragma</a> = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ]
    1516 </pre><p id="rfc.section.3.4.p.4">When the Cache-Control header is not present in a request, the no-cache request pragma-directive <em class="bcp14">MUST</em> have the same effect on caches as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
     1516</pre><p id="rfc.section.3.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, the no-cache request pragma-directive <em class="bcp14">MUST</em> have the same effect on caches as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
    15171517      </p>
    15181518      <p id="rfc.section.3.4.p.5">When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control:
    1519          no-cache is purposefully omitted to target other Cache-Control response directives at HTTP/1.1 caches. For example:
     1519         no-cache is purposefully omitted to target other <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives at HTTP/1.1 caches. For example:
    15201520      </p>
    15211521      <div id="rfc.figure.u.14"></div> <pre class="text">GET / HTTP/1.1
     
    15251525
    15261526</pre> <p id="rfc.section.3.4.p.7">will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not
    1527          understand Cache-Control from serving a cached response.
     1527         understand <a href="#header.cache-control" class="smpl">Cache-Control</a> from serving a cached response.
    15281528      </p>
    15291529      <div class="note" id="rfc.section.3.4.p.8">
     
    19841984      <p id="rfc.section.A.p.4">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;3</a>)
    19851985      </p>
    1986       <p id="rfc.section.A.p.5">Do not mention RFC 2047 encoding and multiple languages in Warning header fields anymore, as these aspects never were implemented.
    1987          (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section&nbsp;3.6</a>)
     1986      <p id="rfc.section.A.p.5">Do not mention RFC 2047 encoding and multiple languages in <a href="#header.warning" class="smpl">Warning</a> header fields anymore, as these aspects never were implemented. (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section&nbsp;3.6</a>)
    19881987      </p>
    19891988      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
  • 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.