Cache Invalidation only happens upon successful responses

[mnot@…]

The cache invalidation text doesn't disambiguate between successful and unsuccessful responses. Only successful responses should invalidate caches.

[ylafon@…]

From [943]:

clarify that only successful exchanges (2xx) are mandating invalidation on caches for PUT/POST/DELETE and unknown methods. (See #235)

[julian.reschke@…]

From [944]:

Note change in [943] relating to issue 235 (see #235)

[julian.reschke@…]

From [951]:

Note we undid change in [943] relating to issue 235 (see #235), regen HTML.

[mnot@…]

This should have been reopened when the change was backed out.

[mnot@…]

Prague editors discussion: 2xx only

[fielding@…]

Specifically, p6-cache.html#invalidation.after.updates.or.deletions should emphasize that only successful responses to a state-changing method MUST result in cache invalidation. Otherwise, an unauthenticated client can kill a cache hierarchy.

Actually, that whole section needs to be rewritten. The first paragraph is missing a word or two (to make sense), the list of methods should be replaced by "any state-changing method or method unrecognized by the cache", and the whole notion of invalidating on the basis of Location or Content-Location has been abandoned. We probably have other issues for those.

[mnot@…]

Rewrite started as part of #289.

Content-Location and Location *are* important; the very common use case is to redirect back to a blog entry after entering a comment or edit.

I forgot about that case when we discussed this in Prague; I think "successful" really needs to be 2xx *or* 3xx.

[mnot@…]

Revised proposal:

""" A cache MUST invalidate the effective Request URI (Section 4.3 of [Part1]) as well as the URI(s) in the Location and Content-Location header fields (if present) when a non-error response to a request with an unsafe method is received.

However, a cache MUST NOT invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part in the effective request URI (Section 4.3 of [Part1]). This helps prevent denial of service attacks.

A cache SHOULD invalidate the effective request URI (Section 4.3 of [Part1]) when it receives a non-error response to a request with a method whose safety is unknown.

Here, a non-error response is one with a 2xx or 3xx status code. """

[mnot@…]

From [1314]:

Cache invalidation only happens on non-error responses; addresses #235