This is still disorganized, in that the model issue is described elsewhere.
Jeff raised the issue of whether and how we could provide some mechanisms in HTTP/1.1 that would allow HTTP/1.1 caches to do something sensible with HTTP/1.2 (and later) protocols if new methods were introduced after HTTP/1.1. In other words, even though we do not now know what those new methods would be, can we figure out how to describe what they mean with respect to caches so that we can separate this from the rest of the semantics of the new methods?

This quickly led into a lengthy philosophical discussion of caching models, led by Larry Masinter. I'll try to summarize how far we got, although we did not reach any closure on this.

Larry described possible three ways to view an HTTP cache:

  1. a cache stores values and performs operations on these values based on the requests and responses it sees. For the purposes of the cache, one can describe each HTTP method as a transformation on the values of one or more resources.
  2. a cache stores responses, period.
  3. a cache stores the responses to specific requests. The cache must be cognizant of the potential interactions between various requests; for example, a PUT on a resource should somehow invalidate the cached result of a previous GET on the same resources, but a POST on that resource might not invalidate the result of the GET.
Nobody wanted to defend view (2); it was clearly insufficient.

Larry prefers view (3), mostly (if I recall right) because it seems to fit best with a simple model of content negotiation.

Jeff favors view (1), because it ultimately seems (to me) to allow a more straightforward description of what each method means to the cache. In particularly, view (3) seems to require describing O(N^2) interactions between the N methods.

The fact that we could reach agreement on a lot of other issues without having any kind of agreement on this particular debate suggests that either one's choice between views (1) and (3) does not have much effect on the solutions to those issues, or perhaps that the "proper" view is some hybrid.

Getting back to extensibility, if we followed view (1), we could perhaps describe the cache-related consequences of new (post-HTTP/1.1) methods by some generic request and response headers that the caches could obey without understanding the methods themselves. For example, these hypothetical headers could tell the cache to save (or not save) the response value, or to make stale ("invalidate") any previous cached values associated with the URL mentioned in the request, or one or more URIs mentioned in the response headers. It seems somewhat trickier to do a similar thing for extensibility if one follows view (3).

Paul Leach apparently agrees with Jeff Mogul on this.

K Claffy prefers method-based view because it seems to make cut-through (bypassing) easier in a cache hierarchy.

Shel adds:

We did mention that if requests on a URI invalidate the cached responses to other requests (different methods) on the same URI, (with possibly a couple of exceptions), then the N^2 problem goes away -- i.e. you assume a simpler model where the cache doesn't pretend to know the semantics of the methods. The "short cuts" we discussed were that GET and HEAD don't have to invalidate any other entries, and that the body of a PUT request might be used to service later GET requests.
but Jeff notes that assumes that a new method does not affect the cachability of a resource other than those mentioned in the request URL, any request URIs, any response URIs, any response Location: headers, etc. I.e., we would have to be careful about any new headers that could identify "cache consequences" of a new method.

We also discussed the possibility of a denial-of-service attack (or at least "denial of cache performance") if the protocol were to include mechanisms that allow one client or server to cause the invalidation of many cache entries.

http working group issues