Changeset 347 for draft-ietf-httpbis/latest-roy
- Timestamp:
- 12/11/08 22:09:04 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest-roy/p6-cache.xml
r345 r347 193 193 The Hypertext Transfer Protocol (HTTP) is an application-level 194 194 protocol for distributed, collaborative, hypermedia information 195 systems. HTTP has been in use by the World Wide Web global information196 initiative since 1990.This document is Part 6 of the seven-part specification195 systems. 196 This document is Part 6 of the seven-part specification 197 197 that defines the protocol referred to as "HTTP/1.1" and, taken together, 198 198 obsoletes RFC 2616. Part 6 defines requirements on HTTP caches … … 219 219 <t> 220 220 HTTP is typically used for distributed information systems, where 221 performance can be improved by the use of response caches, and includes 222 a number of elements intended to make caching work as well as possible. 223 Because these elements interact with each other, it is useful to describe 224 the caching design of HTTP separately. This document defines aspects of 225 HTTP/1.1 related to caching and reusing response messages. 221 performance can be improved by the use of response caches. This document 222 defines aspects of HTTP/1.1 related to caching and reusing response messages. 226 223 </t> 227 224 … … 521 518 &MUST; attach a warning to that effect, using a Warning general-header. 522 519 The Warning header and the currently defined warnings are described 523 in <xref target="header.warning"/>. The warning allows clients to take appropriate 524 action. 525 </t> 526 <t> 527 Warnings &MAY; be used for other purposes, both cache-related and 528 otherwise. The use of a warning, rather than an error status code, 529 distinguish these responses from true failures. 530 </t> 531 <t> 532 Warnings are assigned three digit warn-codes. The first digit 533 indicates whether the Warning &MUST; or &MUST-NOT; be deleted from a 534 stored cache entry after a successful revalidation: 535 </t> 536 <t> 537 <list style="hanging"> 538 <t hangText="1xx">Warnings that describe the freshness or revalidation status of 539 the response, and so &MUST; be deleted after a successful 540 revalidation. 1xx warn-codes &MAY; be generated by a cache only when 541 validating a cached entry. It &MUST-NOT; be generated by clients.</t> 542 543 <t hangText="2xx">Warnings that describe some aspect of the entity body or entity 544 headers that is not rectified by a revalidation (for example, a 545 lossy compression of the entity bodies) and which &MUST-NOT; be 546 deleted after a successful revalidation.</t> 547 </list> 548 </t> 549 <t> 550 See <xref target="header.warning"/> for the definitions of the codes themselves. 551 </t> 552 <t> 553 HTTP/1.0 caches will cache all Warnings in responses, without 554 deleting the ones in the first category. Warnings in responses that 555 are passed to HTTP/1.0 caches carry an extra warning-date field, 556 which prevents a future HTTP/1.1 recipient from believing an 557 erroneously cached Warning. 558 </t> 559 <t> 560 Warnings also carry a warning text. The text &MAY; be in any 561 appropriate natural language (perhaps based on the client's Accept 562 headers), and include an &OPTIONAL; indication of what character set is 563 used. 564 </t> 565 <t> 566 Multiple warnings &MAY; be attached to a response (either by the origin 567 server or by a cache), including multiple warnings with the same code 568 number. For example, a server might provide the same warning with 569 texts in both English and Basque. 570 </t> 571 <t> 572 When multiple warnings are attached to a response, it might not be 573 practical or reasonable to display all of them to the user. This 574 version of HTTP does not specify strict priority rules for deciding 575 which warnings to display and in what order, but does suggest some 576 heuristics. 520 in <xref target="header.warning"/>. 577 521 </t> 578 522 </section> … … 2259 2203 </t> 2260 2204 <t> 2261 Warning headers are sent with responses using: 2262 </t> 2205 Warnings MAY be used for other purposes, both cache-related and 2206 otherwise. The use of a warning, rather than an error status code, 2207 distinguish these responses from true failures. 2208 </t> 2209 2210 <t> 2211 Warning headers can in general be applied to any message, however 2212 some warn-codes are specific to caches and can only be 2213 applied to response messages. 2214 </t> 2215 2263 2216 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Warning"/><iref primary="true" item="Grammar" subitem="warning-value"/><iref primary="true" item="Grammar" subitem="warn-code"/><iref primary="true" item="Grammar" subitem="warn-agent"/><iref primary="true" item="Grammar" subitem="warn-text"/><iref primary="true" item="Grammar" subitem="warn-date"/> 2264 2217 <x:ref>Warning</x:ref> = "Warning" ":" 1#<x:ref>warning-value</x:ref> … … 2274 2227 <x:ref>warn-date</x:ref> = <x:ref>DQUOTE</x:ref> <x:ref>HTTP-date</x:ref> <x:ref>DQUOTE</x:ref> 2275 2228 </artwork></figure> 2276 <t> 2277 A response &MAY; carry more than one Warning header. 2229 2230 <t> 2231 Multiple warnings &MAY; be attached to a response (either by the origin 2232 server or by a cache), including multiple warnings with the same code 2233 number. For example, a server might provide the same warning with 2234 texts in both English and Basque. 2235 </t> 2236 <t> 2237 When this occurs, the user agent ought to inform the user of as many 2238 of them as possible, in the order that they appear in the response. 2239 If it is not possible to inform the user of all of the warnings, 2240 the user agent SHOULD follow these heuristics: 2241 <list style="symbols"> 2242 <t>Warnings that appear early in the response take priority over 2243 those appearing later in the response.</t> 2244 2245 <t>Warnings in the user's preferred character set take priority 2246 over warnings in other character sets but with identical warn-codes 2247 and warn-agents.</t> 2248 </list> 2249 </t> 2250 <t> 2251 Systems that generate multiple Warning headers &SHOULD; order them with 2252 this user agent behavior in mind. New Warning headers &SHOULD; be added 2253 after any existing Warning headers. 2254 </t> 2255 <t> 2256 Warnings are assigned three digit warn-codes. The first digit 2257 indicates whether the Warning is required to be deleted from a 2258 stored cache entry after validation: 2259 <list style="symbols"> 2260 <t>1xx Warnings that describe the freshness or revalidation status of 2261 the response, and so MUST be deleted by caches after validation.</t> 2262 <t> 2xx Warnings that describe some aspect of the entity body or entity 2263 headers that is not rectified by a revalidation (for example, a 2264 lossy compression of the entity bodies) and which MUST NOT be 2265 deleted by caches after validation, unless a full response is 2266 returned, in which case they MUST be.</t> 2267 </list> 2278 2268 </t> 2279 2269 <t> … … 2290 2280 </t> 2291 2281 <t> 2292 Warning headers can in general be applied to any message, however 2293 some specific warn-codes are specific to caches and can only be 2294 applied to response messages. New Warning headers &SHOULD; be added 2295 after any existing Warning headers. A cache &MUST-NOT; delete any 2296 Warning header that it received with a message. However, if a cache 2297 successfully validates a cache entry, it &SHOULD; remove any Warning 2298 headers previously attached to that entry except as specified for 2299 specific Warning codes. It &MUST; then add any Warning headers received 2300 in the validating response. In other words, Warning headers are those 2301 that would be attached to the most recent relevant response. 2302 </t> 2303 <t> 2304 When multiple Warning headers are attached to a response, the user 2305 agent ought to inform the user of as many of them as possible, in the 2306 order that they appear in the response. If it is not possible to 2307 inform the user of all of the warnings, the user agent &SHOULD; follow 2308 these heuristics: 2309 <list style="symbols"> 2310 <t>Warnings that appear early in the response take priority over 2311 those appearing later in the response.</t> 2312 2313 <t>Warnings in the user's preferred character set take priority 2314 over warnings in other character sets but with identical warn-codes 2315 and warn-agents.</t> 2316 </list> 2317 </t> 2318 <t> 2319 Systems that generate multiple Warning headers &SHOULD; order them with 2320 this user agent behavior in mind. 2321 </t> 2322 <t> 2323 Requirements for the behavior of caches with respect to Warnings are 2324 stated in <xref target="warnings"/>. 2325 </t> 2326 <t> 2327 This is a list of the currently-defined warn-codes, each with a 2282 If an implementation sends a message with one or more Warning headers 2283 to a receiver whose version is HTTP/1.0 or lower, then the sender &MUST; 2284 include in each warning-value a warn-date that matches the Date header 2285 in the message. 2286 </t> 2287 <t> 2288 If an implementation receives a message with a warning-value that 2289 includes a warn-date, and that warn-date is different from the Date 2290 value in the response, then that warning-value &MUST; be deleted from 2291 the message before storing, forwarding, or using it. (This prevents 2292 bad consequences of naive caching of Warning header fields.) If all 2293 of the warning-values are deleted for this reason, the Warning header 2294 &MUST; be deleted as well. 2295 </t> 2296 <t> 2297 The following warn-codes are defined by this specification, each with a 2328 2298 recommended warn-text in English, and a description of its meaning. 2329 2299 </t> … … 2383 2353 take any automated action. 2384 2354 </t></list> 2385 </t>2386 <t>2387 If an implementation sends a message with one or more Warning headers2388 whose version is HTTP/1.0 or lower, then the sender &MUST; include in2389 each warning-value a warn-date that matches the date in the response.2390 </t>2391 <t>2392 If an implementation receives a message with a warning-value that2393 includes a warn-date, and that warn-date is different from the Date2394 value in the response, then that warning-value &MUST; be deleted from2395 the message before storing, forwarding, or using it. (This prevents2396 bad consequences of naive caching of Warning header fields.) If all2397 of the warning-values are deleted for this reason, the Warning header2398 &MUST; be deleted as well.2399 2355 </t> 2400 2356 </section>
Note: See TracChangeset
for help on using the changeset viewer.