Opened 9 years ago

Closed 8 years ago

#235 closed design (fixed)

Cache Invalidation only happens upon successful responses

Reported by: mnot@… Owned by: mnot@…
Priority: normal Milestone: 15
Component: p6-cache Severity: Active WG Document
Keywords: Cc:

Description

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

Change History (16)

comment:1 Changed 9 years ago by ylafon@…

From [943]:

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

comment:2 Changed 9 years ago by ylafon@…

  • Resolution set to incorporated
  • Status changed from new to closed

comment:3 Changed 9 years ago by julian.reschke@…

From [944]:

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

comment:4 Changed 9 years ago by julian.reschke@…

From [951]:

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

comment:5 Changed 9 years ago by mnot@…

  • Milestone changed from unassigned to 11

comment:6 Changed 9 years ago by mnot@…

  • Milestone changed from 11 to unassigned
  • Resolution incorporated deleted
  • Status changed from closed to reopened

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

comment:7 Changed 8 years ago by mnot@…

  • Owner set to mnot@…
  • Status changed from reopened to new

comment:8 Changed 8 years ago by mnot@…

Prague editors discussion: 2xx only

comment:9 Changed 8 years ago by 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.

comment:10 Changed 8 years ago by 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.

comment:11 Changed 8 years ago by 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. """

comment:12 Changed 8 years ago by mnot@…

  • Milestone changed from unassigned to 15

comment:13 Changed 8 years ago by mnot@…

From [1314]:

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

comment:14 Changed 8 years ago by mnot@…

  • Resolution set to incorporated
  • Status changed from new to closed

comment:15 Changed 8 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:16 Changed 8 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.