Validation, Last-Modified and scope of updates #839

Caching 3.4.3 says:

The stored response(s) to update are identified by using the first match (if any) of:
[...]
If the new response contains one or more strong validators (see Section 8.8.1 of [Semantics]), then each of those strong validators identify the selected representation for update. All the stored responses with one of those same strong validators are identified for update.

Semantics 8.8.2.2 says about Last-Modified:

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 being compared by an intermediate cache to the validator stored in its cache entry for the representation, and [t]hat cache entry includes a Date value which is at least one second after the Last-Modified value and the cache has reason to believe that they were generated by the same clock or that there is enough difference between the Last-Modified and Date values to make clock synchronization issues unlikely.

Because we're saying that validation occurs against all responses for a given URI (see #832), this has the effect of allowing a 304 response with a Last-Modified header to update all of the responses sent for that URI in that second (provided the requirement about Date is met) -- which would lead to e.g., 304 response with Content-Language: English updating other languages. That probably isn't desirable.

The obvious way to fix this is to avoid promoting Last-Modified to a strong validator when it's being used by a cache. However, see #510 -- it's necessary for it to be strong for If-Range.

It might also be worth refining caching 3.4.3 to differentiate between entity-tag updates and last-modified updates.