* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #235 (closed design: fixed)

Opened 4 years ago

Last modified 3 years ago

Cache Invalidation only happens upon successful responses

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

Description

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

Change History

comment:1 Changed 4 years ago by ylafon@w3.org

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 4 years ago by ylafon@w3.org

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

comment:3 Changed 4 years ago by julian.reschke@gmx.de

From [944]:

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

comment:4 Changed 4 years ago by julian.reschke@gmx.de

From [951]:

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

comment:5 Changed 4 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 11

comment:6 Changed 4 years ago by mnot@pobox.com

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

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

comment:7 Changed 4 years ago by mnot@pobox.com

  • Owner set to mnot@pobox.com
  • Status changed from reopened to new

comment:8 Changed 3 years ago by mnot@pobox.com

Prague editors discussion: 2xx only

comment:9 Changed 3 years ago by fielding@gbiv.com

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 3 years ago by mnot@pobox.com

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 3 years ago by mnot@pobox.com

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 3 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 15

comment:13 Changed 3 years ago by mnot@pobox.com

From [1314]:

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

comment:14 Changed 3 years ago by mnot@pobox.com

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

comment:15 Changed 3 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:16 Changed 3 years ago by mnot@pobox.com

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