Opened 7 years ago

Closed 6 years ago

#225 closed design (fixed)

PUT side effect: invalidation or just stale?

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


p2 7.6 (PUT):

If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those entries SHOULD be treated as stale.

p6 2.5 (Request Methods that Invalidate):

Here, "invalidate" means that the cache will either remove all stored responses related to the Effective Request URI, or will mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request.

These sections conflict regarding the side effects of PUT; p2 only wants it marked stale, whereas p6 says it cannot be served stale, but must (at least) be revalidated.

Change History (12)

comment:1 Changed 7 years ago by mnot@…

Same problem for DELETE

comment:2 Changed 7 years ago by fielding@…

The usecase for these is authoring: a user, having edited a page and done a PUT or DELETE with a successful response, would be alarmed if a subsequent GET via the same request path resulted in the old cached content.

In that sense, I think it is clear that the result should invalidate the cached entry, though only if the response was successful. Invalidation on unsuccessful responses makes large cache hierarchies vulnerable to denial of service attacks.

comment:3 Changed 6 years ago by mnot@…

  • Milestone changed from unassigned to 13


Adjust p2 to reflect the text in p6, as the caching-specific text is clearly where cache implementers will have been looking, and realistically the text in p2 is likely to be a loose generalisation, whereas the text is p6 is a lot more specific.

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

See [1111]

comment:5 Changed 6 years ago by fielding@…

I am confused. Consensus is that p6 is wrong. Why have we changed p2 to be more like p6 when p6 (as written) is a known Denial of Service attack? Apache httpd never implemented what is in p6, and won't be implementing anything that allows arbitrary clients to cause cache invalidation.

comment:6 Changed 6 years ago by mnot@…

Roy, I think you're misunderstanding where we're at.

2616 and p6 both require implementations to check the URIs to disallow cross-site invalidations from Location and Content-Location. Furthermore, #235 (if we can agree on the definition of 'successful') will put control into the hands of the server, rather than the client making the request.

So, where's the denial of service here? Squid implements without any problem; at the very most -- even without the protections described above -- it's a loss of performance optimisation, not a DoS.

comment:7 Changed 6 years ago by mnot@…

  • Owner set to mnot@…

comment:8 Changed 6 years ago by mnot@…

  • Milestone changed from 13 to 14

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

  • Milestone changed from 14 to 15

comment:10 Changed 6 years ago by fielding@…

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

Never mind. My concern is being tracked in #235.

comment:11 Changed 6 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:12 Changed 6 years ago by mnot@…

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