RE: NEW ISSUE: Methods and Caching

Roy T. Fielding wrote:
> The fact that your experience would lead you to believe that GET is the
> only method worth caching is irrelevant.  It is a design choice based
> on the fact that HTTP is not a storage interface and cannot be presumed
> to act like one.  The only reason this is confusing in 2616 is because
> the section on caching does not reflect the WG opinions on how HTTP
> caching works.  Rather than simply state the content of the cache key,
> the description goes around in circles.  HTTP caching is far simpler
> when defined as a response cache.

Then how does caching work for POST? Why isn't OPTIONS cacheable? Why aren't
PUT and DELETE cacheable the same way as POST?

I would like to see per-method caching but is it something that will really
get deployed? AFAIK no implementations are doing it. Plus, I bet lots of
servers attach Cache-Control headers to POST responses accidentally.
Apache's mod_expires will add Cache-Control/Expires headers for every method
for all request URIs where it is active, so undoubtedly lots of Apache
instances are returning POST responses with Cache-Control even though they
don't want the response to be cached. 

Based on the current state of implementations, it is better to restrict
caching to GET/HEAD for now and add cacheability for other methods in a
future version of the protocol.

- Brian

Received on Tuesday, 18 November 2008 22:51:08 UTC