The 60 second strong Last-Modified window

[mnot-fastly]

7.9.2.2. Comparison:

A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules:

...

• The validator is about to be used by a client in an If-Modified-Since, If-Unmodified-Since, or If-Range header field, because the client has a cache entry for the associated representation, and
• That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
• The presented Last-Modified time is at least 60 seconds before the Date value.

I'm hearing that this 60-second window is problematic for videos, where clients often request a partial video segment within a minute of it being published (thanks to e.g., CMAF). Since those requests use If-Range, they require a strong validator.

Should we revisit this, given that it is an arbitrarily chosen value by our own admission? I agree that some caution is necessary here, but a one-size-fits-all approach doesn't seem viable.

[mnot]

Discussed on call. Sense is to make this much more based upon the judgement of the implementation, rather than just an arbitrary number.

[mnot]

Suggestion:

• The presented Last-Modified time is at least 1 second before the Date value, If the cache has reason to believe that they were generated by the same clock, or
• There is enough difference between the presented Last-Modified time and Date value to make clock synchronisation issues unlikely, in the judgement of the cache (previous revisions of this specification mandated 60 seconds).

[reschke]

@mnot @royfielding - this creates a nested unordered list which comes out really strangely in HTML, please check. Maybe it would be better to have the two statements (that are nested) in a single list entry.