#304 closed editorial (incorporated)
If-Range should be listed when dicussing contexts where L-M can be considered strong
Reported by: | julian.reschke@… | Owned by: | ylafon@… |
---|---|---|---|
Priority: | normal | Milestone: | 16 |
Component: | p4-conditional | Severity: | Active WG Document |
Keywords: | Cc: |
Description
Raised by Matthew Cox:
Part 5 section 5.3 If-Range has the following text in the case that the response has no etag and only Last-Modified.
If a client wishes to perform a sub-range retrieval on a value for which it has only a Last-Modified time and no opaque validator, it MAY do this only if the Last-Modified time is strong in the sense described in Section 2.1.2 of [Part4].
Section 2.1.2 in Part 4 has this text:
o The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header field, because the client has a cache entry for the associated representation, and
o That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
o The presented Last-Modified time is at least 60 seconds before the Date value.
This seems to exclude If-Range which is strange since the If-Range text pointed to this section. Is it possible to add If-Range to the text in the first bullet point, or make the text more generic such that it doesn't exclude other methods that use the Last-Modified time?
Change History (4)
comment:1 Changed 11 years ago by julian.reschke@…
- Owner changed from draft-ietf-httpbis-p4-conditional@… to ylafon@…
comment:2 Changed 11 years ago by julian.reschke@…
comment:3 Changed 11 years ago by julian.reschke@…
- Resolution set to incorporated
- Status changed from new to closed
comment:4 Changed 11 years ago by fielding@…
From [1374]:
Clarify what should happen when a response is incomplete. Disentangle the requirements surrounding conditional range requests, strong validators, and recombining partial content to remove redundant redundancy. Separate handling of 304 responses into a separate section on cache freshening.
Add definitions for "cache entry" and "cache key". Improve introductions for caching and cache operation.
These changes should all be editorial, hopefully. Tangentially related to #101 and #304.
From [1339]:
If-Range should be listed when dicussing contexts where L-M can be considered strong (see #304)