W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

RE: NEW ISSUE: Methods and Caching

From: Brian Smith <brian@briansmith.org>
Date: Tue, 18 Nov 2008 16:50:29 -0600
To: <fielding@gbiv.com>, <henrik@henriknordstrom.net>
Cc: <mnot@mnot.net>, <ietf-http-wg@w3.org>
Message-ID: <01d601c949d0$0f3708e0$2da51aa0$@org>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:57 GMT