Changeset 860
- Timestamp:
- 22/07/10 03:03:27 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.xml
r848 r860 357 357 </artwork></figure> 358 358 <t> 359 In this case, the response may use the gzip Content Coding or not.360 If it does , it might look like that:359 In this case, the response may or may not use the gzip content coding. 360 If it does not, the response might look like: 361 361 </t> 362 362 <figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype="response"" x:indent-with=" "> … … 375 375 </x:span></artwork></figure> 376 376 <t> 377 A variant that does use gzip Content Coding would be:377 An alternative representation that does use gzip content coding would be: 378 378 </t> 379 379 <figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype="response"" x:indent-with=" "> … … 389 389 <x:note> 390 390 <t> 391 <x:h>Note:</x:h> Content Codings are a property of the response 392 entity, thus affect the Entity Tag. An alternative are Transfer 393 Codings (&transfer-codings;) which apply only to the transfer of 394 the message, and thus do not require assigning distinct entity tags. 391 <x:h>Note:</x:h> Content codings are a property of the representation, 392 so therefore an entity tag of an encoded representation must be distinct 393 from an unencoded representation to prevent conflicts during cache updates 394 and range requests. In contrast, transfer codings (&transfer-codings;) 395 apply only during message transfer and do not require distinct entity tags. 395 396 </t> 396 397 </x:note> … … 410 411 </t> 411 412 <t> 412 The response &MUST; include the following header fields: 413 <list style="symbols"> 414 <x:lt> 415 <t>Date, unless its omission is required by &clockless;.</t> 416 <t> 417 If a clockless origin server obeys these rules, and proxies and 418 clients add their own Date to any response received without one (as 419 already specified by &header-date;, caches will operate 420 correctly.</t> 421 </x:lt> 422 <x:lt> 423 <t>ETag and/or Content-Location, if the header would have been sent 424 in a 200 response to the same request.</t> 425 </x:lt> 426 <x:lt> 427 <t>Expires, Cache-Control, and/or Vary, if the field-value might 428 differ from that sent in any previous response for the same 429 variant.</t> 430 </x:lt> 431 </list> 432 </t> 433 <t> 434 If the conditional GET used a strong cache validator (see <xref target="weak.and.strong.validators"/>), 435 the response &SHOULD-NOT; include other entity-headers. 436 Otherwise (i.e., the conditional GET used a weak validator), the 437 response &MUST-NOT; include other entity-headers; this prevents 438 inconsistencies between cached entity-bodies and updated headers. 439 </t> 440 <t> 441 If a 304 response indicates an entity not currently cached, then the 442 cache &MUST; disregard the response and repeat the request without the 443 conditional. 413 A 304 response &MUST; include a Date header field (&header-date;) 414 unless its omission is required by &clockless;. If a 200 response 415 to the same request would have included any of the header fields 416 Cache-Control, Content-Location, ETag, Expires, Last-Modified, or 417 Vary, then those same header fields &MUST; be sent in a 304 response. 418 </t> 419 <t> 420 Since the goal of a 304 response is to minimize information transfer 421 when the recipient already has one or more cached representations, 422 the response &SHOULD-NOT; include representation metadata other 423 than the above listed fields unless said metadata exists for the 424 purpose of guiding cache updates (e.g., future HTTP extensions). 425 </t> 426 <t> 427 If a 304 response includes an entity-tag that indicates a 428 representation not currently cached, then the recipient &MUST-NOT; 429 use the 304 to update its own cache. If that conditional request originated 430 with an outbound client, such as a user agent with its own cache sending a 431 conditional GET to a shared proxy, then the 304 response &MUST; be 432 forwarded to the outbound client. Otherwise, disregard the response 433 and repeat the request without the conditional. 444 434 </t> 445 435 <t> … … 746 736 <t> 747 737 The "ETag" response-header field provides the current value of the 748 entity tag (see <xref target="entity.tags"/>) for the requested variant, 749 which may be used for comparison with other entities from the same resource 750 (see <xref target="weak.and.strong.validators"/>). 738 entity tag (see <xref target="entity.tags"/>) for one representation of 739 the resource identified by the Effective Request URI. An entity tag 740 is intended for use as a resource-local identifier for differentiating 741 between representations of the same resource that vary over time or via 742 content negotiation (see <xref target="weak.and.strong.validators"/>). 751 743 </t> 752 744 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ETag"/><iref primary="true" item="Grammar" subitem="ETag-v"/> … … 763 755 </artwork></figure> 764 756 <t> 765 The ETag response-header field value, an entity tag, provides for an766 "opaque" cache validator. This might allow more reliable validation767 i n situations where it is inconvenient to store modification dates,757 An entity tag provides an "opaque" cache validator that allows for 758 more reliable validation than modification dates in situations where 759 it is inconvenient to store modification dates, 768 760 where the one-second resolution of HTTP date values is not 769 761 sufficient, or where the origin server wishes to avoid certain … … 858 850 <t> 859 851 The "If-Modified-Since" request-header field is used to make a request 860 method conditional: if the requested variant has not been modified since the 861 time specified in this field, the server will not return an entity; instead, 862 a 304 (Not Modified) response will be returned. 852 method conditional by date: if the representation that would have been 853 transferred in a 200 response to a GET request has not been modified since 854 the time specified in this field, then do not perform the method; 855 instead, respond as detailed below. 863 856 </t> 864 857 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/><iref primary="true" item="Grammar" subitem="If-Modified-Since-v"/> … … 875 868 <t> 876 869 A GET method with an If-Modified-Since header and no Range header 877 requests that the identified entitybe transferred only if it has870 requests that the representation be transferred only if it has 878 871 been modified since the date given by the If-Modified-Since header. 879 872 The algorithm for determining this includes the following cases: … … 885 878 invalid.</t> 886 879 887 <t>If the varianthas been modified since the If-Modified-Since880 <t>If the representation has been modified since the If-Modified-Since 888 881 date, the response is exactly the same as for a normal GET.</t> 889 882 890 <t>If the variant has not been modified since a valid If-Modified-Since891 date, the server &SHOULD; return a 304 (Not892 Modified) response.</t>883 <t>If the representation has not been modified since a valid 884 If-Modified-Since date, the server &SHOULD; return a 885 304 (Not Modified) response.</t> 893 886 </list> 894 887 </t> … … 1021 1014 <t> 1022 1015 The "If-Unmodified-Since" request-header field is used to make a request 1023 method conditional. If the requested resource has not been modified 1016 method conditional. If the representation that would have been transferred 1017 in a 200 response to a GET request on the same resource has not been modified 1024 1018 since the time specified in this field, the server &SHOULD; perform the 1025 1019 requested operation as if the If-Unmodified-Since header were not … … 1027 1021 </t> 1028 1022 <t> 1029 If the re quested varianthas been modified since the specified time,1023 If the representation has been modified since the specified time, 1030 1024 the server &MUST-NOT; perform the requested operation, and &MUST; return 1031 1025 a 412 (Precondition Failed). … … 1064 1058 <t> 1065 1059 The "Last-Modified" entity-header field indicates the date and time at 1066 which the origin server believes the variantwas last modified.1060 which the origin server believes the representation was last modified. 1067 1061 </t> 1068 1062 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Last-Modified"/><iref primary="true" item="Grammar" subitem="Last-Modified-v"/> … … 1105 1099 The Last-Modified entity-header field value is often used as a cache 1106 1100 validator. In simple terms, a cache entry is considered to be valid 1107 if the entityhas not been modified since the Last-Modified value.1101 if the representation has not been modified since the Last-Modified value. 1108 1102 </t> 1109 1103 </section> -
draft-ietf-httpbis/latest/p5-range.xml
r859 r860 364 364 </t> 365 365 <t> 366 ETag and/or Content-Location, if the header would have been sent 367 in a 200 response to the same request 368 </t> 369 <t> 370 Expires, Cache-Control, and/or Vary, if the field-value might 371 differ from that sent in any previous response for the same 372 variant 366 Cache-Control, ETag, Expires, Content-Location, Last-Modified, 367 and/or Vary, if the header field would have been sent in a 200 368 response to the same request 373 369 </t> 374 370 </list>
Note: See TracChangeset
for help on using the changeset viewer.