If-Range should be listed when dicussing contexts where L-M can be considered strong

[julian.reschke@…]

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?

[julian.reschke@…]

From [1339]:

If-Range should be listed when dicussing contexts where L-M can be considered strong (see #304)

[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.