Changeset 157 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 08/01/08 03:19:58 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r154 r157 215 215 </front> 216 216 <middle> 217 <section title="Introduction" anchor="introduction"> 218 <t> 219 This document will define aspects of HTTP related to caching response 220 messages. Right now it only includes the extracted relevant sections 221 of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> without edit. 222 </t> 223 224 <section title="Requirements" anchor="intro.requirements"> 225 <t> 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in <xref target="RFC2119"/>. 229 </t> 230 <t> 231 An implementation is not compliant if it fails to satisfy one or more 232 of the &MUST; or &REQUIRED; level requirements for the protocols it 233 implements. An implementation that satisfies all the &MUST; or &REQUIRED; 234 level and all the &SHOULD; level requirements for its protocols is said 235 to be "unconditionally compliant"; one that satisfies all the &MUST; 236 level requirements but not all the &SHOULD; level requirements for its 237 protocols is said to be "conditionally compliant." 217 <section title="Introduction" anchor="caching"> 218 <t> 219 HTTP is typically used for distributed information systems, where 220 performance can be improved by the use of response caches. The 221 HTTP/1.1 protocol includes a number of elements intended to make 222 caching work as well as possible. Because these elements are 223 inextricable from other aspects of the protocol, and because they 224 interact with each other, it is useful to describe the basic caching 225 design of HTTP separately from the detailed descriptions of methods, 226 headers, response codes, etc. This document defines aspects of HTTP 227 related to caching response messages. 228 </t> 229 230 <section title="Purpose" anchor="intro.purpose"> 231 <iref item="cache"/> 232 <t> 233 An HTTP <x:dfn>cache</x:dfn> is a local store of response messages 234 and the subsystem that controls its message storage, retrieval, and 235 deletion. A cache stores cacheable responses in order to reduce the 236 response time and network bandwidth consumption on future, equivalent 237 requests. Any client or server may include a cache, though a cache 238 cannot be used by a server that is acting as a tunnel. 239 </t> 240 <t> 241 Caching would be useless if it did not significantly improve 242 performance. The goal of caching in HTTP/1.1 is to eliminate the need 243 to send requests in many cases, and to eliminate the need to send 244 full responses in many other cases. The former reduces the number of 245 network round-trips required for many operations; we use an 246 "expiration" mechanism for this purpose (see <xref target="expiration.model"/>). The 247 latter reduces network bandwidth requirements; we use a "validation" 248 mechanism for this purpose (see <xref target="validation.model"/>). 249 </t> 250 <iref item="semantically transparent"/> 251 <t> 252 A cache behaves in a "<x:dfn>semantically transparent</x:dfn>" manner, with 253 respect to a particular response, when its use affects neither the 254 requesting client nor the origin server, except to improve 255 performance. When a cache is semantically transparent, the client 256 receives exactly the same response (except for hop-by-hop headers) 257 that it would have received had its request been handled directly 258 by the origin server. 259 </t> 260 <t> 261 In an ideal world, all interactions with an HTTP cache would be 262 semantically transparent. However, for some resources, semantic 263 transparency is not always necessary and can be effectively traded 264 for the sake of bandwidth scaling, disconnected operation, and 265 high availability. HTTP/1.1 allows origin servers, caches, 266 and clients to explicitly reduce transparency when necessary. 267 However, because non-transparent operation may confuse non-expert 268 users and might be incompatible with certain server applications 269 (such as those for ordering merchandise), the protocol requires that 270 transparency be relaxed 271 <list style="symbols"> 272 <t>only by an explicit protocol-level request when relaxed by 273 client or origin server</t> 274 275 <t>only with an explicit warning to the end user when relaxed by 276 cache or client</t> 277 </list> 278 </t> 279 <t> 280 Therefore, HTTP/1.1 provides these important elements: 281 <list style="numbers"> 282 <t>Protocol features that provide full semantic transparency when 283 this is required by all parties.</t> 284 285 <t>Protocol features that allow an origin server or user agent to 286 explicitly request and control non-transparent operation.</t> 287 288 <t>Protocol features that allow a cache to attach warnings to 289 responses that do not preserve the requested approximation of 290 semantic transparency.</t> 291 </list> 292 </t> 293 <t> 294 A basic principle is that it must be possible for the clients to 295 detect any potential relaxation of semantic transparency. 296 <list><t> 297 <x:h>Note:</x:h> The server, cache, or client implementor might be faced with 298 design decisions not explicitly discussed in this specification. 299 If a decision might affect semantic transparency, the implementor 300 ought to err on the side of maintaining transparency unless a 301 careful and complete analysis shows significant benefits in 302 breaking transparency. 303 </t></list> 238 304 </t> 239 305 </section> … … 242 308 <t> 243 309 This specification uses a number of terms to refer to the roles 244 played by participants in, and objects of, the HTTP communication. 245 </t> 246 <t> 247 <iref item="cache"/> 248 <x:dfn>cache</x:dfn> 249 <list> 250 <t> 251 A program's local store of response messages and the subsystem 252 that controls its message storage, retrieval, and deletion. A 253 cache stores cacheable responses in order to reduce the response 254 time and network bandwidth consumption on future, equivalent 255 requests. Any client or server may include a cache, though a cache 256 cannot be used by a server that is acting as a tunnel. 257 </t> 258 </list> 310 played by participants in, and objects of, HTTP caching. 259 311 </t> 260 312 <t> … … 264 316 <t> 265 317 A response is cacheable if a cache is allowed to store a copy of 266 the response message for use in answering subsequent requests. The 267 rules for determining the cacheability of HTTP responses are 268 defined in <xref target="caching"/>. Even if a resource is cacheable, there may 318 the response message for use in answering subsequent requests. 319 Even if a resource is cacheable, there may 269 320 be additional constraints on whether a cache can use the cached 270 321 copy for a particular request. … … 344 395 </t> 345 396 <t> 346 <iref item="semantically transparent"/>347 <x:dfn>semantically transparent</x:dfn>348 <list>349 <t>350 A cache behaves in a "semantically transparent" manner, with351 respect to a particular response, when its use affects neither the352 requesting client nor the origin server, except to improve353 performance. When a cache is semantically transparent, the client354 receives exactly the same response (except for hop-by-hop headers)355 that it would have received had its request been handled directly356 by the origin server.357 </t>358 </list>359 </t>360 <t>361 397 <iref item="validator"/> 362 398 <x:dfn>validator</x:dfn> … … 371 407 </section> 372 408 373 <section title="Delta Seconds" anchor="delta.seconds"> 374 <t> 375 Some HTTP header fields allow a time value to be specified as an 376 integer number of seconds, represented in decimal, after the time 377 that the message was received. 378 </t> 379 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/> 380 delta-seconds = 1*DIGIT 381 </artwork></figure> 382 </section> 383 </section> 384 385 <section title="Caching in HTTP" anchor="caching"> 409 <section title="Requirements" anchor="intro.requirements"> 410 <t> 411 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 412 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 413 document are to be interpreted as described in <xref target="RFC2119"/>. 414 </t> 415 <t> 416 An implementation is not compliant if it fails to satisfy one or more 417 of the &MUST; or &REQUIRED; level requirements for the protocols it 418 implements. An implementation that satisfies all the &MUST; or &REQUIRED; 419 level and all the &SHOULD; level requirements for its protocols is said 420 to be "unconditionally compliant"; one that satisfies all the &MUST; 421 level requirements but not all the &SHOULD; level requirements for its 422 protocols is said to be "conditionally compliant." 423 </t> 424 </section> 425 </section> 426 386 427 <section title="Overview" anchor="caching.overview"> 387 <t>388 HTTP is typically used for distributed information systems, where389 performance can be improved by the use of response caches. The390 HTTP/1.1 protocol includes a number of elements intended to make391 caching work as well as possible. Because these elements are392 inextricable from other aspects of the protocol, and because they393 interact with each other, it is useful to describe the basic caching394 design of HTTP separately from the detailed descriptions of methods,395 headers, response codes, etc.396 </t>397 <t>398 Caching would be useless if it did not significantly improve399 performance. The goal of caching in HTTP/1.1 is to eliminate the need400 to send requests in many cases, and to eliminate the need to send401 full responses in many other cases. The former reduces the number of402 network round-trips required for many operations; we use an403 "expiration" mechanism for this purpose (see <xref target="expiration.model"/>). The404 latter reduces network bandwidth requirements; we use a "validation"405 mechanism for this purpose (see <xref target="validation.model"/>).406 </t>407 <t>408 Requirements for performance, availability, and disconnected409 operation require us to be able to relax the goal of semantic410 transparency. The HTTP/1.1 protocol allows origin servers, caches,411 and clients to explicitly reduce transparency when necessary.412 However, because non-transparent operation may confuse non-expert413 users, and might be incompatible with certain server applications414 (such as those for ordering merchandise), the protocol requires that415 transparency be relaxed416 <list style="symbols">417 <t>only by an explicit protocol-level request when relaxed by418 client or origin server</t>419 420 <t>only with an explicit warning to the end user when relaxed by421 cache or client</t>422 </list>423 </t>424 <t>425 Therefore, the HTTP/1.1 protocol provides these important elements:426 <list style="numbers">427 <t>Protocol features that provide full semantic transparency when428 this is required by all parties.</t>429 430 <t>Protocol features that allow an origin server or user agent to431 explicitly request and control non-transparent operation.</t>432 433 <t>Protocol features that allow a cache to attach warnings to434 responses that do not preserve the requested approximation of435 semantic transparency.</t>436 </list>437 </t>438 <t>439 A basic principle is that it must be possible for the clients to440 detect any potential relaxation of semantic transparency.441 <list><t>442 <x:h>Note:</x:h> The server, cache, or client implementor might be faced with443 design decisions not explicitly discussed in this specification.444 If a decision might affect semantic transparency, the implementor445 ought to err on the side of maintaining transparency unless a446 careful and complete analysis shows significant benefits in447 breaking transparency.448 </t></list>449 </t>450 451 428 <section title="Cache Correctness" anchor="cache.correctness"> 452 429 <t> … … 1532 1509 </t> 1533 1510 </section> 1534 </section>1535 1511 1536 1512 <section title="Header Field Definitions" anchor="header.fields"> … … 1562 1538 seconds. 1563 1539 </t> 1540 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/> 1541 delta-seconds = 1*DIGIT 1542 </artwork></figure> 1564 1543 <t> 1565 1544 If a cache receives a value larger than the largest positive
Note: See TracChangeset
for help on using the changeset viewer.