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

Ticket #225 (closed design: fixed)

Opened 4 years ago

Last modified 3 years ago

PUT side effect: invalidation or just stale?

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

Description

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

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

Same problem for DELETE

comment:2 Changed 4 years ago by fielding@gbiv.com

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

  • Milestone changed from unassigned to 13

Resolution:

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 3 years ago by julian.reschke@gmx.de

See [1111]

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

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

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

  • Owner set to mnot@pobox.com

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

  • Milestone changed from 13 to 14

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

  • Milestone changed from 14 to 15

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

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

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

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

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:12 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.