Changeset 766 for draft-ietf-httpbis/latest
- Timestamp:
- 03/03/10 09:19:25 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r764 r766 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-03-0 1">404 <meta name="dct.issued" scheme="ISO8601" content="2010-03-03"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: September 2, 2010</td>430 <td class="left">Expires: September 4, 2010</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">March 1, 2010</td>491 <td class="right">March 3, 2010</td> 492 492 </tr> 493 493 </tbody> … … 519 519 <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>. 520 520 </p> 521 <p>This Internet-Draft will expire in September 2, 2010.</p>521 <p>This Internet-Draft will expire in September 4, 2010.</p> 522 522 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 523 523 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1377 1377 retrieved earlier in a session. 1378 1378 </p> 1379 <p id="rfc.section.4.p.2">History mechanisms and caches are different. In particular history mechanisms <em class="bcp14">SHOULD NOT</em> try to show a correct view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the 1380 user saw at the time when the resource was retrieved. 1381 </p> 1382 <p id="rfc.section.4.p.3">By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism <em class="bcp14">SHOULD</em> display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history 1383 documents. 1384 </p> 1385 <p id="rfc.section.4.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.</p> 1386 <div class="note" id="rfc.section.4.p.5"> 1387 <p> <b>Note:</b> If history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors 1388 to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider 1389 it important that users not be presented with error messages or warning messages when they use navigation controls (such as 1390 BACK) to view previously fetched resources. Even though sometimes such resources ought not be cached, or ought to expire quickly, 1391 user interface considerations may force service authors to resort to other means of preventing caching (e.g., "once-only" 1392 URLs) in order not to suffer the effects of improperly functioning history mechanisms. 1393 </p> 1394 </div> 1379 <p id="rfc.section.4.p.2">The freshness model (<a href="#expiration.model" title="Freshness Model">Section 2.3</a>) does not necessarily apply to history mechanisms. I.e., a history mechanism can display a previous representation even if 1380 it has expired. 1381 </p> 1382 <p id="rfc.section.4.p.3">This does not prohibit the history mechanism from telling the user that a view might be stale, or from honoring cache directives 1383 (e.g., Cache-Control: no-store). 1384 </p> 1395 1385 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1396 1386 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="message.header.registration" href="#message.header.registration">Message Header Registration</a></h2> … … 1754 1744 </ul> 1755 1745 <h2 id="rfc.section.C.10"><a href="#rfc.section.C.10">C.10</a> <a id="changes.since.08" href="#changes.since.08">Since draft-ietf-httpbis-p6-cache-08</a></h2> 1756 <p id="rfc.section.C.10.p.1">Affected issues: </p> 1746 <p id="rfc.section.C.10.p.1">Closed issues: </p> 1747 <ul> 1748 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/197">http://tools.ietf.org/wg/httpbis/trac/ticket/197</a>>: "Effect of CC directives on history lists" 1749 </li> 1750 </ul> 1751 <p id="rfc.section.C.10.p.2">Affected issues: </p> 1757 1752 <ul> 1758 1753 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/199">http://tools.ietf.org/wg/httpbis/trac/ticket/199</a>>: Status codes and caching -
draft-ietf-httpbis/latest/p6-cache.xml
r764 r766 1545 1545 </t> 1546 1546 <t> 1547 History mechanisms and caches are different. In particular history mechanisms 1548 &SHOULD-NOT; try to show a correct view of the current state of a resource. Rather, a 1549 history mechanism is meant to show exactly what the user saw at the time when the resource 1550 was retrieved. 1551 </t> 1552 <t> 1553 By default, an expiration time does not apply to history mechanisms. If the entity is still 1554 in storage, a history mechanism &SHOULD; display it even if the entity has expired, 1555 unless the user has specifically configured the agent to refresh expired history documents. 1556 </t> 1557 <t> 1558 This is not to be construed to prohibit the history mechanism from telling the user that a 1559 view might be stale. 1560 </t> 1561 <x:note> 1547 The freshness model (<xref target="expiration.model"/>) does not necessarily apply to history mechanisms. I.e., 1548 a history mechanism can display a previous representation even if it has expired. 1549 </t> 1562 1550 <t> 1563 <x:h>Note:</x:h> If history list mechanisms unnecessarily prevent users from viewing 1564 stale resources, this will tend to force service authors to avoid using HTTP expiration 1565 controls and cache controls when they would otherwise like to. Service authors may 1566 consider it important that users not be presented with error messages or warning 1567 messages when they use navigation controls (such as BACK) to view previously fetched 1568 resources. Even though sometimes such resources ought not be cached, or ought to expire 1569 quickly, user interface considerations may force service authors to resort to other 1570 means of preventing caching (e.g., "once-only" URLs) in order not to suffer the effects 1571 of improperly functioning history mechanisms. 1551 This does not prohibit the history mechanism from telling the user that a 1552 view might be stale, or from honoring cache directives (e.g., Cache-Control: no-store). 1572 1553 </t> 1573 </x:note>1574 1554 </section> 1575 1555 … … 2344 2324 <section anchor="changes.since.08" title="Since draft-ietf-httpbis-p6-cache-08"> 2345 2325 <t> 2326 Closed issues: 2327 <list style="symbols"> 2328 <t> 2329 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/197" />: 2330 "Effect of CC directives on history lists" 2331 </t> 2332 </list> 2333 </t> 2334 <t> 2346 2335 Affected issues: 2347 2336 <list style="symbols">
Note: See TracChangeset
for help on using the changeset viewer.