Subject: [core] What responses are cacheable (Re: When are two requests equivalent?)

From: Klaus Hartke <[email-masked]>
Date: Tue, 23 Nov 2010 17:46:03 +0100

Zach Shelby wrote:
> When we cache something, we are caching the
> representation of a resource identified by that URI.
> Thus it would make no sense to cache an error
> response.

Actually, it makes a lot of sense to cache error responses. Example:

C: GET coap://server/resource
S: 404 (max-age=3600s) "Not found."

If the server returns that the resource doesn't exist and that this
information will be fresh for the next 3600 seconds, it doesn't make
sense for the client to repeat its request. This is a perfect example
when a GET request can be avoided by using the cached response.

It also makes a lot of sense to cache error responses to other non-GET
requests. Example:

C: PUT coap://server/resource (content-type=0) "Hello World"
S: 405 (max-age=365d) "Method not allowed."

If the server returns that the resource doesn't support the requested
method and that this information will be fresh for the next 365 days,
it doesn't make sense for the client to repeat the request before the
time is up and expect a different result. ("Insanity: doing the same
thing over and over again and expecting different results." - Albert
Einstein)

Of course, it makes no sense to cache the 200 response to a PUT, POST
or DELETE request. And I'm not sure if it makes sense to validate that
a resource still doesn't exist or doesn't support a method using
Etags.

So regarding the cacheability of responses, I'd propose the following:

200
- in response to GET: cacheable; can be validated using Etag
- in response to PUT/POST/DELETE: not cacheable

4xx/5xx
- cacheable, not validatable

304
- used to signal that a cached 200 response is valid; updates freshness

Klaus