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

Re: NEW ISSUE: Methods and Caching

From: Werner Baumann <werner.baumann@onlinehome.de>
Date: Tue, 18 Nov 2008 19:10:40 +0100
Message-ID: <49230520.9040405@onlinehome.de>
CC: ietf-http-wg@w3.org


Brian Smith wrote:
> I interpreted the combination of the write-through requirement and POST
> being cacheable like this: if the response to the POST indicates that a
> cached response can be returned without validation, then write-through isn't
> required as long as that response is fresh--in other words, it is a way of
> indicating that write-through isn't required. This makes sense because there
> are a lot of cases where people use POST as a query mechanism (e.g. due to
> real or imagined limitations on request URI length). It also explains why
> POST is cacheable but PUT isn't; PUT is explicitly defined to modify a
> resource, whereas POST isn't.
> 
>> Note that PROPFIND is in the same boat as POST; it's defined as being
>> cacheable, but since write-through isn't explicitly relaxed for it,
>> this isn't terribly useful.
> 
> PROPFIND is explicitly defined as being safe, so write-through isn't
> required. (Write through is required only for "methods that might be
> expected to cause modifications to the origin server's resources.")
> 
POST and PUT are intended to send information from the client to the 
origin server and must always be send to the server and must not be 
answered by intermediaries from the cache. Just some POST requests that 
contain only query strings are not reason enough to require 
intermediaries to interpret the request body.
What may be cached by intermediaries is the response to a POST (see 
posting of Henrik).

When talking about caching it would be useful to differentiate in two 
dimensions:
- cashing by intermediaries or caching by user agents
- direction and kind of information flow

As I see it there are three very different cases for information flow:

1. Distributing content from an origin server to many clients (typical GET):
- caching by intermediaries is very important and effective
- caching by user agents is important except they can access an
   intermediary cache over a LAN connection.

2. Distributing content from an origin server to many clients where the 
content of the response is highly client defined (GET with query string 
and PROPFIND):
- caching by intermediaries is not important. The effect will vary
   and will be zero in many cases (responses to a GET with query string
   are often marked "No-Cache" or "private")
- caching by user agents is important

3. Sending information from different clients to an origin server.
- caching by intermediaries is either impossible or unimportant
- caching by user agents can be very important but mostly fails
   because of lack of a cache validation mechanism.

When talking about (new) cache requirements that affect intermediaries 
it is important to not impose any negative effects on the most important 
case 1.

Werner
Received on Tuesday, 18 November 2008 18:11:28 GMT

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