Minor Description
When a response to a PUT, POST, or DELETE carries a Content-Location header, there are certain cases where the cache MUST invalidate its entry for the URI in the Content-Location header, namely:
1. If the Date on the response is later than the Date on the entry; OR
2. If the Etag on the response is different than the one on the entry.
The tricky bit is when the Dates match, as it isn't a priori clear which is more up-to-date, as responses can be received out-of-order. Right now the caching client errs on the side of caching things and relying on the Cache-Control semantics of the existing entry to specify freshness. I'm wondering if this isn't the wrong tradeoff, as the cache is receiving the response after the entry already exists, so there is a strong likelihood that the response is actually fresher (even though we can't tell due to the 1-second granularity of the Date headers) and we probably ought to invalidate in this case.
The HTTP/1.1 spec does not require one behavior or the other (both are compliant – I have a patch with this behavior that passes all the ProtocolRequirements/Recommendations unit tests), so this is listed as an improvement. I'll upload a patch shortly.