Changeset 1737 for draft-ietf-httpbis
- Timestamp:
- 08/07/12 13:02:45 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1735 r1737 449 449 } 450 450 @bottom-center { 451 content: "Expires January 7, 2013";451 content: "Expires January 9, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 6">493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-08"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: January 7, 2013</td>525 <td class="left">Expires: January 9, 2013</td> 526 526 <td class="right">greenbytes</td> 527 527 </tr> 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">July 6, 2012</td>530 <td class="right">July 8, 2012</td> 531 531 </tr> 532 532 </tbody> … … 561 561 in progress”. 562 562 </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> 564 564 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 565 565 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1947 1947 </p> 1948 1948 <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. 1952 1953 </p> 1953 1954 <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: … … 1958 1959 <li>Content-Type</li> 1959 1960 </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>). 1961 1962 </p> 1962 1963 <div class="note" id="rfc.section.5.6.2.p.7"> … … 1994 1995 </p> 1995 1996 <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>). 1997 1998 </p> 1998 1999 <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 … … 3756 3757 </ul> 3757 3758 </li> 3758 <li><em>Part6</em> <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> <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> 3759 3760 <li><em>Section 2</em> <a href="#rfc.xref.Part6.2">2.4</a></li> 3760 3761 <li><em>Section 2.1</em> <a href="#rfc.xref.Part6.4">3.4</a></li> 3761 <li><em>Section 3.2</em> <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> <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> <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> <a href="#rfc.xref.Part6.6">5.6.2</a></li> 3764 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.7">5.6.2</a></li> 3763 3765 </ul> 3764 3766 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1735 r1737 29 29 <!ENTITY header-date "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 30 <!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'/>"> 31 32 <!ENTITY header-mime-version "<xref target='Part2' x:rel='#mime-version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 33 <!ENTITY header-pragma "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 2614 2615 response: 2615 2616 <list style="symbols"> 2616 <t> Expires</t>2617 <t><x:ref>Expires</x:ref> (&header-expires;)</t> 2617 2618 </list> 2618 2619 </t> 2619 2620 <t> 2620 2621 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 to2622 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. 2623 2624 </t> 2624 2625 <t> … … 4181 4182 </front> 4182 4183 <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> 4184 4187 </reference> 4185 4188 -
draft-ietf-httpbis/latest/p2-semantics.html
r1735 r1737 449 449 } 450 450 @bottom-center { 451 content: "Expires January 7, 2013";451 content: "Expires January 9, 2013"; 452 452 } 453 453 @bottom-right { … … 497 497 <meta name="dct.creator" content="Reschke, J. F."> 498 498 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 499 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 6">499 <meta name="dct.issued" scheme="ISO8601" content="2012-07-08"> 500 500 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 501 501 <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 "HTTP/1.1" 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."> … … 528 528 </tr> 529 529 <tr> 530 <td class="left">Expires: January 7, 2013</td>530 <td class="left">Expires: January 9, 2013</td> 531 531 <td class="right">greenbytes</td> 532 532 </tr> 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">July 6, 2012</td>535 <td class="right">July 8, 2012</td> 536 536 </tr> 537 537 </tbody> … … 563 563 in progress”. 564 564 </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> 566 566 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 567 567 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 2553 2553 </p> 2554 2554 </div> 2555 <p id="rfc.section.8.1.p.8">The Varyheader 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. 2556 2556 </p> 2557 2557 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2> … … 3673 3673 <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 3674 3674 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 Varyheader 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. 3676 3676 </p> 3677 3677 <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 2944 2944 </x:note> 2945 2945 <t> 2946 The Vary header field (&header-vary;) can be used to express the parameters the2947 server uses to select a representation that is subject to server-driven2948 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. 2949 2949 </t> 2950 2950 </section> … … 4572 4572 to omit the sending of Accept-Language header fields by default, and to ask 4573 4573 the user whether or not to start sending Accept-Language header fields to a 4574 server if it detects, by looking for any Varyheader fields4574 server if it detects, by looking for any <x:ref>Vary</x:ref> header fields 4575 4575 generated by the server, that such sending could improve the quality 4576 4576 of service. … … 4697 4697 </front> 4698 4698 <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> 4700 4702 </reference> 4701 4703 -
draft-ietf-httpbis/latest/p4-conditional.html
r1734 r1737 449 449 } 450 450 @bottom-center { 451 content: "Expires January 7, 2013";451 content: "Expires January 9, 2013"; 452 452 } 453 453 @bottom-right { … … 490 490 <meta name="dct.creator" content="Reschke, J. F."> 491 491 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 492 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 6">492 <meta name="dct.issued" scheme="ISO8601" content="2012-07-08"> 493 493 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 494 494 <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 "HTTP/1.1" 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."> … … 516 516 </tr> 517 517 <tr> 518 <td class="left">Expires: January 7, 2013</td>518 <td class="left">Expires: January 9, 2013</td> 519 519 <td class="right">J. Reschke, Editor</td> 520 520 </tr> … … 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">July 6, 2012</td>527 <td class="right">July 8, 2012</td> 528 528 </tr> 529 529 </tbody> … … 555 555 in progress”. 556 556 </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> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1107 1107 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. 1108 1108 </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. 1112 1110 </p> 1113 1111 <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 1012 1012 A 304 response &MUST; include a Date header field (&header-date;) 1013 1013 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. 1018 1019 </t> 1019 1020 <t> … … 1248 1249 </front> 1249 1250 <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> 1251 1255 </reference> 1252 1256 -
draft-ietf-httpbis/latest/p5-range.html
r1735 r1737 449 449 } 450 450 @bottom-center { 451 content: "Expires January 7, 2013";451 content: "Expires January 9, 2013"; 452 452 } 453 453 @bottom-right { … … 492 492 <meta name="dct.creator" content="Reschke, J. F."> 493 493 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 494 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 6">494 <meta name="dct.issued" scheme="ISO8601" content="2012-07-08"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 496 496 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests."> … … 518 518 </tr> 519 519 <tr> 520 <td class="left">Expires: January 7, 2013</td>520 <td class="left">Expires: January 9, 2013</td> 521 521 <td class="right">J. Reschke, Editor</td> 522 522 </tr> … … 527 527 <tr> 528 528 <td class="left"></td> 529 <td class="right">July 6, 2012</td>529 <td class="right">July 8, 2012</td> 530 530 </tr> 531 531 </tbody> … … 555 555 in progress”. 556 556 </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> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 742 742 </li> 743 743 <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 request744 <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 745 745 </li> 746 746 </ul> -
draft-ietf-httpbis/latest/p5-range.xml
r1735 r1737 335 335 </t> 336 336 <t> 337 Cache-Control, ETag, Expires, Content-Location and/or Vary, if338 the header field would have been sent in a <x:ref>200 (OK)</x:ref> response to the339 same request337 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 340 340 </t> 341 341 </list> … … 1072 1072 </front> 1073 1073 <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> 1075 1077 </reference> 1076 1078 -
draft-ietf-httpbis/latest/p6-cache.html
r1736 r1737 856 856 <li>the response either: 857 857 <ul> 858 <li>contains an Expiresheader field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section 3.3</a>), or858 <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 3.3</a>), or 859 859 </li> 860 860 <li>contains a max-age response cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>), or … … 908 908 <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 3.2.3</a>. 909 909 </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 Ageheader field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 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 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 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 2.3.2</a>. 911 911 </p> 912 912 <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 … … 925 925 </p> 926 926 <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 Expiresheader field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section 3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation927 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 3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation 928 928 is not likely to change in a semantically significant way before the expiration time is reached. 929 929 </p> … … 953 953 <li>If the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) is present, use its value, or 954 954 </li> 955 <li>If the Expiresresponse header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section 3.3</a>) is present, use its value minus the value of the Date response header field, or955 <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 3.3</a>) is present, use its value minus the value of the Date response header field, or 956 956 </li> 957 957 <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 2.3.1.1</a>. … … 959 959 </ul> 960 960 <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. 964 963 </p> 965 964 <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a> <a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4> … … 968 967 (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. 969 968 </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 warning971 is not alreadypresent.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. 972 971 </p> 973 972 <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 … … 981 980 </div> 982 981 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <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 Age984 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 path986 from the origin server, plusthe 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. 987 986 </p> 988 987 <p id="rfc.section.2.3.2.p.2">The following data is used for the age calculation:</p> … … 990 989 </p> 991 990 <ul class="empty"> 992 <li>The term "age_value" denotes the value of the Ageheader field (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section 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 3.1</a>), in a form appropriate for arithmetic operation; or 0, if not available. 993 992 </li> 994 993 </ul> … … 1032 1031 <p>These <em class="bcp14">SHOULD</em> be combined as 1033 1032 </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. 1036 1034 </p> 1037 1035 <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 … … 1048 1046 <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. 1049 1047 </li> 1050 <li>An HTTP/1.1 implementation <em class="bcp14">MAY</em> internally represent a parsed Expiresdate 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. 1051 1049 </li> 1052 1050 <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. … … 1066 1064 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 3.2.1</a>). 1067 1065 </p> 1068 <p id="rfc.section.2.3.3.p.4">A cache <em class="bcp14">SHOULD</em> append a Warningheader field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section 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 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. 1069 1067 </p> 1070 1068 <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 becausethat 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. 1073 1071 </p> 1074 1072 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="validation.model" href="#validation.model">Validation Model</a></h2> … … 1116 1114 </p> 1117 1115 <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 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 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> 1121 1120 <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. 1122 1121 </li> … … 1133 1132 </p> 1134 1133 <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 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 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> 1138 1138 <li>use other header fields provided in the response to replace all instances of the corresponding header fields in the stored 1139 1139 response. … … 1162 1162 <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. 1163 1163 </p> 1164 <p id="rfc.section.2.7.p.2">In this specification, the following Cache-Controlresponse directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 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 3.2.2</a>) have such an effect: must-revalidate, public, s-maxage. 1165 1165 </p> 1166 1166 <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 … … 1169 1169 </p> 1170 1170 <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a> <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 Varyheader field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 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 original1171 <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 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 1172 1172 request (i.e., that associated with the stored response), and the presented request. 1173 1173 </p> … … 1186 1186 if it is also absent there. 1187 1187 </p> 1188 <p id="rfc.section.2.8.p.4">A Varyheader field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted1188 <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 1189 1189 by the origin server. 1190 1190 </p> … … 1203 1203 </p> 1204 1204 <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 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 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> 1208 1209 <li>use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding 1209 1210 header fields in the stored response. … … 1420 1421 </ul> 1421 1422 <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. 1424 1424 </p> 1425 1425 <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. … … 1489 1489 </p> 1490 1490 <div class="note" id="rfc.section.3.3.p.7"> 1491 <p> <b>Note:</b> If a response includes a Cache-Controlfield with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 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 3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches. 1492 1492 </p> 1493 1493 </div> … … 1505 1505 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.pragma" href="#header.pragma">Pragma</a></h2> 1506 1506 <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 present1508 and understood in a request, Pragma isignored.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. 1509 1509 </p> 1510 1510 <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 … … 1514 1514 <a href="#header.pragma" class="smpl">pragma-directive</a> = "no-cache" / <a href="#header.pragma" class="smpl">extension-pragma</a> 1515 1515 <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 headeris 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 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 3.2.1</a>). 1517 1517 </p> 1518 1518 <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-Controlresponse 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: 1520 1520 </p> 1521 1521 <div id="rfc.figure.u.14"></div> <pre class="text">GET / HTTP/1.1 … … 1525 1525 1526 1526 </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-Controlfrom serving a cached response.1527 understand <a href="#header.cache-control" class="smpl">Cache-Control</a> from serving a cached response. 1528 1528 </p> 1529 1529 <div class="note" id="rfc.section.3.4.p.8"> … … 1984 1984 <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 3</a>) 1985 1985 </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 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 3.6</a>) 1988 1987 </p> 1989 1988 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> -
draft-ietf-httpbis/latest/p6-cache.xml
r1736 r1737 471 471 <t>the response either: 472 472 <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> 475 475 <t>contains a max-age response cache directive (see <xref 476 476 target="cache-response-directive" />), or</t> … … 564 564 <t> 565 565 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's568 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" />. 569 569 </t> 570 570 <t> … … 601 601 <t> 602 602 The primary mechanism for determining freshness is for an origin server to 603 provide an explicit expiration time in the future, using either the Expires603 provide an explicit expiration time in the future, using either the <x:ref>Expires</x:ref> 604 604 header field (<xref target="header.expires" />) or the max-age response cache 605 605 directive (<xref target="cache-response-directive" />). Generally, origin … … 660 660 <t>If the max-age response cache directive (<xref 661 661 target="cache-response-directive" />) is present, use its value, or</t> 662 <t>If the Expires response header field (<xref target="header.expires" />) is663 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> 665 665 <t>Otherwise, no explicit expiration time is present in the response. A 666 666 heuristic freshness lifetime might be applicable; see <xref … … 674 674 <t> 675 675 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 is677 considered invalid. Caches are encouraged to consider responses that have678 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. 679 679 </t> 680 680 … … 691 691 </t> 692 692 <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 if695 its current_age is more than 24 hours and such a warning is not already696 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. 697 697 </t> 698 698 <t> … … 717 717 <section anchor="age.calculations" title="Calculating Age"> 718 718 <t> 719 HTTP/1.1 uses the Age header field to convey the estimated age of the720 response message when obtained from a cache. The Age field value is the721 cache's estimate of the amount of time since the response was generated or719 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 722 722 validated by the origin server. In essence, the Age value is the sum of the 723 723 time that the response has been resident in each of the caches along the … … 732 732 <list> 733 733 <t> 734 The term "age_value" denotes the value of the Age header field (<xref735 target="header.age"/>), in a form appropriate for arithmetic736 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. 737 737 </t> 738 738 </list> … … 806 806 </artwork></figure> 807 807 <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> 811 812 <t> 812 813 The current_age of a stored response can then be calculated by adding the … … 832 833 833 834 <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 the835 <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 836 837 proper value.</t> 837 838 … … 867 868 </t> 868 869 <t> 869 A cache &SHOULD; append a Warning header field with the 110 warn-code (see870 <xref target="header.warning" />) to stale responses. Likewise, a cache871 &SHOULD; add the 112 warn-code to stale responses if the cache is872 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. 873 874 </t> 874 875 <t> … … 876 877 <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward to the 877 878 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 (but879 without removing any existing Warning header fields). A cache shouldn't879 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 880 881 attempt to validate a response simply because that response became stale in 881 882 transit. … … 965 966 If a stored response is selected for update, the cache &MUST;: 966 967 <list style="symbols"> 967 <t>delete any Warning header fields in the stored response with968 w arn-code 1xx (see <xref target="header.warning" />);</t>969 <t>retain any Warning header fields in the stored response with970 w arn-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> 971 972 <t>use other header fields provided in the <x:ref>304 (Not Modified)</x:ref> 972 973 response to replace all instances of the corresponding header … … 998 999 remaining headers in the stored response using the following rules: 999 1000 <list style="symbols"> 1000 <t>delete any Warning header fields in the stored response with1001 w arn-code 1xx (see <xref target="header.warning" />);</t>1002 <t>retain any Warning header fields in the stored response with1003 w arn-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> 1004 1005 <t>use other header fields provided in the response to replace 1005 1006 all instances of the corresponding header fields in the stored … … 1059 1060 1060 1061 <t> 1061 In this specification, the following Cache-Control response directives1062 (<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: 1063 1064 must-revalidate, public, s-maxage. 1064 1065 </t> … … 1078 1079 <t> 1079 1080 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 by1082 the Vary header field match in both the original request (i.e., that associated1083 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. 1084 1085 </t> 1085 1086 <t> … … 1109 1110 </t> 1110 1111 <t> 1111 A Vary header field-value of "*" always fails to match, and subsequent1112 requests to that resource can only be properly interpreted by the origin1113 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. 1114 1115 </t> 1115 1116 <t> … … 1143 1144 cache &MUST;: 1144 1145 <list style="symbols"> 1145 <t>delete any Warning header fields in the stored response with1146 w arn-code 1xx (see <xref target="header.warning" />);</t>1147 <t>retain any Warning header fields in the stored response with1148 w arn-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> 1149 1150 <t>use other header fields provided in the new response, aside 1150 1151 from Content-Range, to replace all instances of the corresponding … … 1569 1570 The s-maxage response directive indicates that, in shared caches, the 1570 1571 maximum age specified by this directive overrides the maximum age 1571 specified by either the max-age directive or the Expires header field. The1572 s-maxage directive also implies the semantics of the proxy-revalidate1573 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. 1574 1575 </t> 1575 1576 <t> … … 1705 1706 <x:note> 1706 1707 <t> 1707 &Note; If a response includes a Cache-Control field with the1708 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" />), 1709 1710 that directive overrides the Expires field. Likewise, the s-maxage 1710 1711 directive overrides Expires in shared caches. … … 1739 1740 The "Pragma" header field allows backwards compatibility with HTTP/1.0 1740 1741 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 the1742 Cache-Control header is also present and understood in a request, Pragma is1743 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. 1744 1745 </t> 1745 1746 <t> … … 1754 1755 </artwork></figure> 1755 1756 <t> 1756 When the Cache-Control header is not present in a request, the no-cache1757 request pragma-directive &MUST; have the same effect on caches as if1758 "Cache-Control: no-cache" were present (see <xref1757 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 1759 1760 target="cache-request-directive" />). 1760 1761 </t> … … 1762 1763 When sending a no-cache request, a client ought to include both the pragma 1763 1764 and cache-control directives, unless Cache-Control: no-cache is 1764 purposefully omitted to target other Cache-Control response directives at1765 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: 1766 1767 </t> 1767 1768 <figure> … … 1777 1778 will constrain HTTP/1.1 caches to serve a response no older than 30 1778 1779 seconds, while precluding implementations that do not understand 1779 Cache-Controlfrom serving a cached response.1780 <x:ref>Cache-Control</x:ref> from serving a cached response. 1780 1781 </t> 1781 1782 <x:note> … … 2536 2537 </t> 2537 2538 <t> 2538 Do not mention RFC 2047 encoding and multiple languages in Warning header fields2539 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. 2540 2541 (<xref target="header.warning" />) 2541 2542 </t>
Note: See TracChangeset
for help on using the changeset viewer.