Validation, Last-Modified and scope of updates

[mnot]

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.

[mnot]

In 4.3.5, updating is done like this:

When a cache makes an inbound HEAD request for a target URI and receives a 200 (OK) response, the cache should update or invalidate each of its stored GET responses that could have been selected for that request (see Section 4.1).

Note that it's specified in terms of responses that could have been selected for that request, rather than "stored... responses for the applicable request URI."

If we modified 4.3.4 to specify that responses that could have been selected for the request sent are updated (still subject to further filtering down by any validators in the 304 response), I think it should work.