Changeset 1374
- Timestamp:
- 04/08/11 05:41:28 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1373 r1374 17 17 <!ENTITY mdash "—"> 18 18 <!ENTITY caching-overview "<xref target='Part6' x:rel='#caching.overview' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 <!ENTITY cache-incomplete "<xref target='Part6' x:rel='# errors.or.incomplete.response.cache.behavior' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">19 <!ENTITY cache-incomplete "<xref target='Part6' x:rel='#response.cacheability' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 20 <!ENTITY payload "<xref target='Part3' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 21 <!ENTITY media-types "<xref target='Part3' x:rel='#media.types' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 1561 1561 received response. 1562 1562 </t> 1563 </section> 1564 1565 <section anchor="incomplete.messages" title="Incomplete Messages"> 1563 1566 <t> 1564 1567 Request messages that are prematurely terminated, possibly due to a … … 1566 1569 result in closure of the connection; sending an HTTP/1.1 error response 1567 1570 prior to closing the connection is &OPTIONAL;. 1571 </t> 1572 <t> 1568 1573 Response messages that are prematurely terminated, usually by closure 1569 1574 of the connection prior to receiving the expected number of octets or by 1570 1575 failure to decode a transfer-encoded message-body, &MUST; be recorded 1571 as incomplete. A user agent &MUST-NOT; render an incomplete response 1572 message-body as if it were complete (i.e., some indication must be given 1573 to the user that an error occurred). Cache requirements for incomplete 1574 responses are defined in &cache-incomplete;. 1576 as incomplete. A response that terminates in the middle of the header 1577 block (before the empty line is received) cannot be assumed to convey the 1578 full semantics of the response and &MUST-NOT; be stored by a cache. 1579 </t> 1580 <t> 1581 A message-body that uses the chunked transfer encoding is 1582 incomplete if the zero-sized chunk that terminates the encoding has not 1583 been received. A message that uses a valid Content-Length is incomplete 1584 if the size of the message-body received (in octets) is less than the 1585 value given by Content-Length. A response that has neither chunked 1586 transfer encoding nor Content-Length is terminated by closure of the 1587 connection, and thus is considered complete regardless of the number of 1588 message-body octets received, provided that the header block was received 1589 intact. 1590 </t> 1591 <t> 1592 A user agent &MUST-NOT; render an incomplete response message-body as if 1593 it were complete (i.e., some indication must be given to the user that an 1594 error occurred). Cache requirements for incomplete responses are defined 1595 in &cache-incomplete;. 1575 1596 </t> 1576 1597 <t> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1373 r1374 24 24 <!ENTITY caching "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 25 <!ENTITY auth "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 <!ENTITY combining-responses "<xref target='Part6' x:rel='#combining.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">27 26 <!ENTITY content-negotiation "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 27 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 725 724 <t>If the response status code is 204, 206, or 304 and the request method was GET 726 725 or HEAD, the response payload is a partial representation of the target 727 resource (see &combining-responses;).</t>726 resource.</t> 728 727 <t>If the response has a Content-Location header field, and that URI is the same 729 728 as the effective request URI, the response payload is a representation of the -
draft-ietf-httpbis/latest/p5-range.xml
r1373 r1374 216 216 <t> 217 217 HTTP clients often encounter interrupted data transfers as a result 218 of cancelled requests or dropped connections. When a c achehas stored218 of cancelled requests or dropped connections. When a client has stored 219 219 a partial representation, it is desirable to request the remainder 220 220 of that representation in a subsequent request rather than transfer … … 407 407 with a 200 (OK) response to the same request. 408 408 </t> 409 <t>410 A cache &MUST-NOT; combine a 206 response with other previously cached411 content if the ETag or Last-Modified header fields do not match exactly,412 see <xref target="combining.byte.ranges"/>.413 </t>414 <t>415 A cache that does not support the Range and Content-Range header fields416 &MUST-NOT; cache 206 (Partial Content) responses. Furthermore,417 if a response uses a range unit that is not understood by the cache,418 then it &MUST-NOT; be cached either.419 </t>420 409 </section> 421 410 … … 443 432 <section title="Combining Ranges" anchor="combining.byte.ranges"> 444 433 <t> 445 A response might transfer only a subrange of a representation, either because 446 the request included one or more Range specifications, or because 447 a connection closed prematurely. 448 After several such transfers, a cache might have received several 449 ranges of the same representation. 450 </t> 451 <t> 452 If a cache has a stored non-empty set of subranges for a representation, and 453 an incoming response transfers another subrange, the cache &MAY; 454 combine the new subrange with the existing set if both the following 455 conditions are met: 456 <list style="symbols"> 457 <t>Both the incoming response and the cache entry have a cache 458 validator.</t> 459 <t>The two cache validators match using the strong comparison 460 function (see &weak-and-strong-validators;).</t> 461 </list> 462 </t> 463 <t> 464 If either requirement is not met, the cache &MUST; use only the most 465 recent partial response (based on the Date values transmitted with 466 every response, and using the incoming response if these values are 467 equal or missing), and &MUST; discard the other partial information. 434 A response might transfer only a subrange of a representation if the 435 connection closed prematurely or if the request used one or more Range 436 specifications. After several such transfers, a client might have 437 received several ranges of the same representation. These ranges can only 438 be safely combined if they all have in common the same strong validator, 439 where "strong validator" is defined to be either an entity-tag that is 440 not marked as weak (&entity-tags;) or, if no entity-tag is provided, a 441 Last-Modified value that is strong in the sense defined by 442 &lastmod-comparison;. 443 </t> 444 <t> 445 When a client receives an incomplete 200 (OK) or 206 (Partial Content) 446 response and already has one or more stored responses for the same method 447 and effective request URI, all of the stored responses with the same 448 strong validator &MAY; be combined with the partial content in this new 449 response. If none of the stored responses contain the same strong 450 validator, then this new response corresponds to a new representation 451 and &MUST-NOT; be combined with the existing stored responses. 452 </t> 453 <t> 454 If the new response is an incomplete 200 (OK) response, then the header 455 fields of that new response are used for any combined response and replace 456 those of the matching stored responses. 457 </t> 458 <t> 459 If the new response is a 206 (Partial Content) response and at least one 460 of the matching stored responses is a 200 (OK), then the combined response 461 header fields consist of the most recent 200 response's header fields. 462 If all of the matching stored responses are 206 responses, then the 463 stored response with the most header fields is used as the source of 464 header fields for the combined response, except that the client &MUST; 465 use other header fields provided in the new response, aside from 466 Content-Range, to replace all instances of the corresponding header 467 fields in the stored response. 468 </t> 469 <t> 470 The combined response message-body consists of the union of partial 471 content ranges in the new response and each of the selected responses. 472 If the union consists of the entire range of the representation, then the 473 combined response &MUST; be recorded as a complete 200 (OK) response 474 with a Content-Length header field that reflects the complete length. 475 Otherwise, the combined response(s) &MUST; include a Content-Range 476 header field describing the included range(s) and be recorded as 477 incomplete. If the union consists of a discontinuous range of the 478 representation, then the client &MAY; store it as either a multipart range 479 response or as multiple 206 responses with one continuous range each. 468 480 </t> 469 481 </section> … … 668 680 <x:anchor-alias value="If-Range"/> 669 681 <t> 670 If a client has a partial copy of a representation in its cache,and wishes671 to have an up-to-date copy of the entire representation in its cache, it682 If a client has a partial copy of a representation and wishes 683 to have an up-to-date copy of the entire representation, it 672 684 could use the Range header field with a conditional GET (using 673 685 either or both of If-Unmodified-Since and If-Match.) However, if the … … 686 698 </artwork></figure> 687 699 <t> 688 Only a strong validator (&weak-and-strong-validators;) is usable for 689 range retrieval, since otherwise the client might end up with an 690 internally inconsistent representation. 691 Clients &MUST-NOT; use weak validators in range requests. 692 A cache or origin server receiving a conditional range request 693 &MUST; use the strong comparison function to evaluate the condition. 694 </t> 695 <t> 696 If the client has no entity-tag for a representation, but does have a Last-Modified 697 date, it &MAY; use that date in an If-Range header field. (The 698 server can distinguish between a valid HTTP-date and any form of 699 entity-tag by examining no more than two characters.) The If-Range 700 header field &SHOULD; only be used together with a Range header field, and &MUST; be 701 ignored if the request does not include a Range header field, or if the 702 server does not support the sub-range operation. 703 </t> 704 <t> 705 If a client wishes to perform a sub-range retrieval on a value for 706 which it has only a Last-Modified time and no opaque validator, it 707 &MAY; do this only if the Last-Modified time is strong in the sense 708 described in &lastmod-comparison;. 709 </t> 710 <t> 711 If the entity-tag given in the If-Range header field matches the current 712 cache validator for the representation, then the server &SHOULD; provide the 713 specified sub-range of the representation using a 206 (Partial Content) 714 response. If the cache validator does not match, then the server &SHOULD; 715 return the entire representation using a 200 (OK) response. 700 Clients &MUST-NOT; use an entity-tag marked as weak in an If-Range 701 field value and &MUST-NOT; use a Last-Modified date in an If-Range 702 field value unless it has no entity-tag for the representation and 703 the Last-Modified date it does have for the representation is strong 704 in the sense defined by &lastmod-comparison;. 705 </t> 706 <t> 707 A server that evaluates a conditional range request that is applicable 708 to one of its representations &MUST; evaluate the condition as false if 709 the entity-tag used as a validator is marked as weak or, when an HTTP-date 710 is used as the validator, if the date value is not strong in the sense 711 defined by &lastmod-comparison;. (A server can distinguish between a 712 valid HTTP-date and any form of entity-tag by examining the first 713 two characters.) 714 </t> 715 <t> 716 The If-Range header field &SHOULD; only be sent by clients together with 717 a Range header field. The If-Range header field &MUST; be ignored if it 718 is received in a request that does not include a Range header field. 719 The If-Range header field &MUST; be ignored by a server that does not 720 support the sub-range operation. 721 </t> 722 <t> 723 If the validator given in the If-Range header field matches the current 724 validator for the selected representation of the target resource, then 725 the server &SHOULD; send the specified sub-range of the representation 726 using a 206 (Partial Content) response. If the validator does not match, 727 then the server &SHOULD; send the entire representation using a 200 (OK) 728 response. 716 729 </t> 717 730 </section> … … 851 864 </artwork></figure> 852 865 <t> 853 A server &MAY; ignore the Range header field. However, HTTP/1.1origin866 A server &MAY; ignore the Range header field. However, origin 854 867 servers and intermediate caches ought to support byte ranges when 855 868 possible, since Range supports efficient recovery from partially … … 1384 1397 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 1385 1398 <t> 1386 Clarify that it is not ok to use a weak cachevalidator in a 206 response.1399 Clarify that it is not ok to use a weak validator in a 206 response. 1387 1400 (<xref target="status.206"/>) 1388 1401 </t> -
draft-ietf-httpbis/latest/p6-cache.xml
r1373 r1374 21 21 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 22 22 <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 23 <!ENTITY semantics "<xref target='Part2' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 23 24 <!ENTITY conditional "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 24 25 <!ENTITY partial "<xref target='Part5' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 32 33 <!ENTITY header-fields "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 34 <!ENTITY safe-methods "<xref target='Part2' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 35 <!ENTITY entity-tags "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 34 36 <!ENTITY weak-and-strong "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 37 <!ENTITY lastmod-comparison "<xref target='Part4' x:rel='#lastmod.comparison' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 35 38 <!ENTITY status-codes "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 36 39 <!ENTITY status.2xx "<xref target='Part2' x:rel='#status.2xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 252 255 </t> 253 256 <t> 254 Caching would be useless if it did not significantly improve performance.255 The goal of caching in HTTP/1.1 is to reuse a prior response message to256 satisfy a current request. In some cases, a stored response can be reused257 without the need for a network request, reducing latency and network258 round-trips; a "freshness" mechanism is used for this purpose (see <xref259 target="expiration.model" />). Even when a new request is required, it is260 often possible to reuse all or parts of the payload of a prior response to261 satisfy the request, thereby reducing network bandwidth usage; a262 "validation" mechanism is used for this purpose (see <xref263 target="validation.model" />).257 The goal of caching in HTTP/1.1 is to significantly improve performance 258 by reusing a prior response message to satisfy a current request. 259 A stored response is considered "fresh", as defined in 260 <xref target="expiration.model" />, if the response can be reused without 261 "validation" (checking with the origin server to see if the cached response 262 remains valid for this request). A fresh cache response can therefore 263 reduce both latency and network transfers each time it is reused. 264 When a cached response is not fresh, it might still be reusable if it can 265 be freshened by validation (<xref target="validation.model" />) or if the 266 origin is unavailable. 264 267 </t> 265 268 </section> … … 283 286 <x:dfn>shared cache</x:dfn> 284 287 <list> 285 <t>A cache that is accessible to more than one user; usually (but286 not always) deployed as part of an intermediary.</t>288 <t>A cache that stores responses to be reused by more than one user; 289 usually (but not always) deployed as part of an intermediary.</t> 287 290 </list> 288 291 </t> … … 366 369 <t>A protocol element (e.g., an entity-tag or a Last-Modified time) that 367 370 is used to find out whether a stored response is an equivalent copy of 368 a representation.</t> 371 a representation. See &weak-and-strong;.</t> 372 </list> 373 </t> 374 <t> 375 <iref item="strong validator" /> 376 <iref item="validator, strong" /> 377 <x:dfn>strong validator</x:dfn> 378 <list> 379 <t>A validator that is defined by the origin server such that its 380 current value will change if the representation body changes; i.e., 381 an entity-tag that is not marked as weak (&entity-tags;) or, 382 if no entity-tag is provided, a Last-Modified value that is strong 383 in the sense defined by &lastmod-comparison;.</t> 369 384 </list> 370 385 </t> … … 468 483 469 484 <section anchor="caching.overview" title="Cache Operation"> 485 <iref item="cache entry" /> 486 <iref item="cache key" /> 487 <t> 488 Proper cache operation preserves the semantics of HTTP transfers 489 (&semantics;) while eliminating the transfer of information already held 490 in the cache. Although caching is an entirely &OPTIONAL; feature of HTTP, 491 we assume that reusing the cached response is desirable and that such 492 reuse is the default behavior when no requirement or locally-desired 493 configuration prevents it. Therefore, HTTP cache requirements are focused 494 on preventing a cache from either storing a non-reusable response or 495 reusing a stored response inappropriately. 496 </t> 497 <t> 498 Each <x:dfn>cache entry</x:dfn> consists of a cache key and one or more 499 HTTP responses corresponding to prior requests that used the same key. 500 The most common form of cache entry is a successful result of a retrieval 501 request: i.e., a 200 (OK) response containing a representation of the 502 resource identified by the request target. However, it is also possible 503 to cache negative results (e.g., 404 not found), incomplete results 504 (e.g., 206 partial content), and responses to safe methods other than 505 GET if the method's definition allows such caching and defines something 506 suitable for use as a cache key. 507 </t> 508 <t> 509 The default <x:dfn>cache key</x:dfn> consists of the request method and 510 target URI. However, since HTTP caches in common use today are typically 511 limited to caching responses to GET, most implementations simply decline 512 other methods and use only the URI as the key. 513 </t> 514 <t> 515 If a request target is subject to content negotiation, its cache entry 516 might consist of multiple stored responses, each differentiated by a 517 secondary key for the values of the original request's selecting header 518 fields (<xref target="caching.negotiated.responses"/>). 519 </t> 470 520 471 521 <section anchor="response.cacheability" title="Response Cacheability"> … … 509 559 <t> 510 560 In this context, a cache has "understood" a request method or a response 511 status code if it recognises it and implements any cache-specific 512 behavior. In particular, 206 Partial Content responses cannot be cached by 513 an implementation that does not handle partial content (see <xref 514 target="errors.or.incomplete.response.cache.behavior" />). 515 </t> 516 <t> 517 Note that in normal operation, most caches will not store a response that 561 status code if it recognizes it and implements any cache-specific 562 behavior. 563 </t> 564 <t> 565 Note that, in normal operation, most caches will not store a response that 518 566 has neither a cache validator nor an explicit expiration time, as such 519 567 responses are not usually useful to store. However, caches are not 520 568 prohibited from storing such responses. 521 569 </t> 522 523 <section anchor="errors.or.incomplete.response.cache.behavior" 524 title="Storing Partial and Incomplete Responses"> 525 <t> 526 A cache that receives an incomplete response (for example, with fewer bytes 527 of data than specified in a Content-Length header field) can store the response, 528 but &MUST; treat it as a partial response &partial;. Partial responses can 529 be combined as described in &combining-byte-ranges;; the result might be a 530 full response or might still be partial. A cache &MUST-NOT; return a 531 partial response to a client without explicitly marking it as such using 532 the 206 (Partial Content) status code. 533 </t> 534 <t> 535 A cache that does not support the Range and Content-Range header fields 536 &MUST-NOT; store incomplete or partial responses. 537 </t> 538 </section> 539 570 <t> 571 A response message is considered complete when all of the octets 572 indicated by the message framing (&messaging;) are received 573 prior to the connection being closed. 574 If the request is GET, the response status is 200 (OK), and the entire 575 response header block has been received, a cache &MAY; store an incomplete 576 response message-body if the cache entry is recorded as incomplete. 577 Likewise, a 206 (Partial Content) response &MAY; be stored as if it were 578 an incomplete 200 (OK) cache entry. However, a cache &MUST-NOT; store 579 incomplete or partial content responses if it does not support the Range 580 and Content-Range header fields or if it does not understand the 581 range units used in those fields. 582 </t> 583 <t> 584 A cache &MAY; complete a stored incomplete response by making a subsequent 585 range request (&partial;) and combining the successful response with the 586 stored entry, as defined in <xref target="combining.responses"/>. 587 A cache &MUST-NOT; use an incomplete response to answer requests 588 unless the response has been made complete or the request is partial and 589 specifies a range that is wholly within the incomplete response. 590 A cache &MUST-NOT; send a partial response to a client without explicitly 591 marking it as such using the 206 (Partial Content) status code. 592 </t> 540 593 </section> 541 594 … … 881 934 <t> 882 935 A 304 (Not Modified) response status code indicates that the stored 883 response can be updated and reused; see <xref target=" combining.responses"/>.936 response can be updated and reused; see <xref target="freshening.responses"/>. 884 937 </t> 885 938 <t> … … 887 940 stored responses nominated in the conditional request is suitable. Instead, 888 941 a cache &SHOULD; use the full response to satisfy the request and &MAY; 889 replace the stored response .942 replace the stored response(s). 890 943 </t> 891 944 <t> … … 1016 1069 </section> 1017 1070 1018 <section anchor="combining.responses" title="Combining Responses"> 1019 <t> 1020 When a cache receives a 304 (Not Modified) response or a 206 (Partial 1021 Content) response (in this section, the "new" response"), it needs to 1022 create an updated response by combining the stored response with the new 1023 one, so that the updated response can be used to satisfy the request, and 1024 potentially update the cached response. 1025 </t> 1026 <t> 1027 If the new response contains an ETag, it identifies the stored response to 1028 use. <cref anchor="TODO-mention-CL">might need language about 1029 Content-Location here</cref><cref 1030 anchor="TODO-select-for-combine">Shouldn't this be the selected 1031 response?</cref> 1032 </t> 1033 <t> 1034 When the new response's status code is 206 (partial content), a cache 1035 &MUST-NOT; combine it with the old response if either response does not 1036 have a validator, and &MUST-NOT; combine it with the old response when 1037 those validators do not match with the strong comparison function 1038 (see &weak-and-strong;). 1039 </t> 1040 <t> 1041 The stored response header fields are used as those of the updated response, 1042 except that 1071 <section anchor="combining.responses" title="Combining Partial Content"> 1072 <t> 1073 A response might transfer only a partial representation if the 1074 connection closed prematurely or if the request used one or more Range 1075 specifiers (&partial;). After several such transfers, a cache might have 1076 received several ranges of the same representation. A cache &MAY; combine 1077 these ranges into a single stored response, and reuse that response to 1078 satisfy later requests, if they all share the same strong validator and 1079 the cache complies with the client requirements in &combining-byte-ranges;. 1080 </t> 1081 <t> 1082 When combining the new response with one or more stored responses, a 1083 cache &MUST;: 1043 1084 <list style="symbols"> 1044 <t>a cache &MUST; delete any stored Warning header fields with warn-code 1xx (see <xref 1045 target="header.warning" />).</t> 1046 <t>a cache &MUST; retain any stored Warning header fields with warn-code 2xx.</t> 1047 <t>a cache &MUST; use other header fields provided in the new response to replace all 1048 instances of the corresponding header fields from the stored response.</t> 1049 </list> 1050 </t> 1051 <t> 1052 A cache &MUST; use the updated response header fields to replace those of the stored 1053 response (unless the stored response is removed). In 1054 the case of a 206 response, a cache &MAY; store the combined representation. 1085 <t>delete any Warning header fields in the stored response with 1086 warn-code 1xx (see <xref target="header.warning" />);</t> 1087 <t>retain any Warning header fields in the stored response with 1088 warn-code 2xx; and,</t> 1089 <t>use other header fields provided in the new response, aside 1090 from Content-Range, to replace all instances of the corresponding 1091 header fields in the stored response.</t> 1092 </list> 1093 </t> 1094 </section> 1095 1096 <section anchor="freshening.responses" title="Freshening Responses"> 1097 <t> 1098 When a cache receives a 304 (Not Modified) response and already has one 1099 or more stored 200 (OK) responses for the same cache key, the cache needs 1100 to identify which of the stored responses are updated by this new response 1101 and then update the stored response(s) with the new information provided in 1102 the 304 response. 1103 <list style="symbols"> 1104 <t> 1105 If the new response contains a strong validator, then that strong 1106 validator identifies the selected representation. All of the stored 1107 responses with the same strong validator are selected. 1108 If none of the stored responses contain the same strong validator, then 1109 this new response corresponds to a new selected representation and 1110 &MUST-NOT; update the existing stored responses. 1111 </t> 1112 <t> 1113 If the new response contains a weak validator and that validator 1114 corresponds to one of the cache's stored responses, then the most 1115 recent of those matching stored responses is selected. 1116 </t> 1117 <t> 1118 If the new response does not include any form of validator, there is 1119 only one stored response, and that stored response also lacks a 1120 validator, then that stored response is selected. 1121 </t> 1122 </list> 1123 </t> 1124 <t> 1125 If a stored response is selected for update, the cache &MUST;: 1126 <list style="symbols"> 1127 <t>delete any Warning header fields in the stored response with 1128 warn-code 1xx (see <xref target="header.warning" />);</t> 1129 <t>retain any Warning header fields in the stored response with 1130 warn-code 2xx; and,</t> 1131 <t>use other header fields provided in the 304 response to replace 1132 all instances of the corresponding header fields in the stored 1133 response.</t> 1134 </list> 1055 1135 </t> 1056 1136 </section>
Note: See TracChangeset
for help on using the changeset viewer.