![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 575 for draft-ietf-httpbis
- Timestamp:
- May 5, 2009, 11:34:04 PM (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p6-cache.html (modified) (3 diffs)
-
p6-cache.xml (modified) (11 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r573 r575 468 468 <tr> 469 469 <td class="header left"></td> 470 <td class="header right">May 1, 2009</td>470 <td class="header right">May 6, 2009</td> 471 471 </tr> 472 472 </table> … … 1358 1358 documents. 1359 1359 </p> 1360 <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. 1361 <d l class="empty">1362 < dd> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors1360 <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> 1361 <div class="note"> 1362 <p> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors 1363 1363 to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider 1364 1364 it important that users not be presented with error messages or warning messages when they use navigation controls (such as … … 1366 1366 user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) 1367 1367 in order not to suffer the effects of improperly functioning history mechanisms. 1368 </ dd>1369 </d l>1368 </p> 1369 </div> 1370 1370 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1371 1371 <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> -
draft-ietf-httpbis/latest/p6-cache.xml
r573 r575 245 245 246 246 <section anchor="intro.terminology" title="Terminology"> 247 <t 248 >This specification uses a number of terms to refer to the roles played by participants247 <t> 248 This specification uses a number of terms to refer to the roles played by participants 249 249 in, and objects of, HTTP caching. 250 250 </t> … … 453 453 <section anchor="constructing.responses.from.caches" title="Constructing Responses from Caches"> 454 454 <t> 455 For a presented request, a cache &MUST-NOT; return a stored response, unless:455 For a presented request, a cache &MUST-NOT; return a stored response, unless: 456 456 <list style="symbols"> 457 457 <t>The presented Request-URI and that of the stored response match … … 532 532 <figure> 533 533 <preamble> 534 The calculation to determine if a response is fresh is:534 The calculation to determine if a response is fresh is: 535 535 </preamble> 536 536 <artwork type="code"> … … 625 625 synchronize their clocks to a globally accurate time standard. 626 626 </t> 627 <t>A response's age can be calculated in two entirely independent ways: 627 <t> 628 A response's age can be calculated in two entirely independent ways: 628 629 <list style="numbers"> 629 630 <t>now minus date_value, if the local clock is reasonably well synchronized to the … … 868 869 869 870 <section anchor="header.fields" title="Header Field Definitions"> 870 <t>This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</t> 871 <t>For entity-header fields, both sender and recipient refer to either the client or the 872 server, depending on who sends and who receives the entity.</t> 871 <t> 872 This section defines the syntax and semantics of HTTP/1.1 header fields 873 related to caching. 874 </t> 875 <t> 876 For entity-header fields, both sender and recipient refer to either the client or the 877 server, depending on who sends and who receives the entity. 878 </t> 873 879 874 880 <section anchor="header.age" title="Age"> … … 924 930 </t> 925 931 <x:note> 926 <t>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement 927 Pragma: no-cache (see <xref target="header.pragma" />).</t> 932 <t> 933 Note that HTTP/1.0 caches might not implement Cache-Control and might only implement 934 Pragma: no-cache (see <xref target="header.pragma" />). 935 </t> 928 936 </x:note> 929 937 <t> … … 1253 1261 </artwork></figure> 1254 1262 <x:note> 1255 <t> 1256 <x:h>Note:</x:h> if a response includes a Cache-Control field with the max-age 1257 directive (see <xref target="cache-response-directive" />), that directive overrides 1258 the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.</t> 1263 <t> 1264 <x:h>Note:</x:h> if a response includes a Cache-Control field with the max-age 1265 directive (see <xref target="cache-response-directive" />), that directive overrides 1266 the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches. 1267 </t> 1259 1268 </x:note> 1260 1269 <t> … … 1274 1283 <x:anchor-alias value="Pragma-v"/> 1275 1284 <x:anchor-alias value="pragma-directive"/> 1276 <t 1277 >The general-header field "Pragma" is used to include implementation-specific directives1285 <t> 1286 The general-header field "Pragma" is used to include implementation-specific directives 1278 1287 that might apply to any recipient along the request/response chain. All pragma directives 1279 1288 specify optional behavior from the viewpoint of the protocol; however, some systems … … 1299 1308 <x:h>Note:</x:h> because the meaning of "Pragma: no-cache" as a response-header field 1300 1309 is not actually specified, it does not provide a reliable replacement for 1301 "Cache-Control: no-cache" in a response.</t> 1310 "Cache-Control: no-cache" in a response. 1311 </t> 1302 1312 </x:note> 1303 1313 <t> … … 1518 1528 history mechanism is meant to show exactly what the user saw at the time when the resource 1519 1529 was retrieved. 1520 1530 </t> 1521 1531 <t> 1522 1532 By default, an expiration time does not apply to history mechanisms. If the entity is still … … 1527 1537 This is not to be construed to prohibit the history mechanism from telling the user that a 1528 1538 view might be stale. 1529 <list> 1530 <t> 1531 <x:h>Note:</x:h> if history list mechanisms unnecessarily prevent users from viewing 1532 stale resources, this will tend to force service authors to avoid using HTTP expiration 1533 controls and cache controls when they would otherwise like to. Service authors may 1534 consider it important that users not be presented with error messages or warning 1535 messages when they use navigation controls (such as BACK) to view previously fetched 1536 resources. Even though sometimes such resources ought not be cached, or ought to expire 1537 quickly, user interface considerations may force service authors to resort to other 1538 means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects 1539 of improperly functioning history mechanisms.</t> 1540 </list> 1541 </t> 1539 </t> 1540 <x:note> 1541 <t> 1542 <x:h>Note:</x:h> if history list mechanisms unnecessarily prevent users from viewing 1543 stale resources, this will tend to force service authors to avoid using HTTP expiration 1544 controls and cache controls when they would otherwise like to. Service authors may 1545 consider it important that users not be presented with error messages or warning 1546 messages when they use navigation controls (such as BACK) to view previously fetched 1547 resources. Even though sometimes such resources ought not be cached, or ought to expire 1548 quickly, user interface considerations may force service authors to resort to other 1549 means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects 1550 of improperly functioning history mechanisms. 1551 </t> 1552 </x:note> 1542 1553 </section> 1543 1554
Note: See TracChangeset
for help on using the changeset viewer.
