Subject: NEW ISSUE: Methods and Caching

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Nov 2008 19:11:43 -0800

RFC2616 does not clearly define what the relationship of the request  
method is to caching. In particular, does the method form part of the  
cache key?

If the method does not form part of the cache key, a cache can  
effectively only be used to satisfy GET and HEAD requests, but a non- 
GET/HEAD response could "populate" the cache if it had explicit expiry  
information; e.g., a POST response could be used to satisfy a future  
GET request (if the POST response were marked as explicitly cacheable).

If the method does form part of the cache key, any method (e.g.,  
OPTIONS, PROPFIND) could potentially be cached and returned in  
response to future requests.

Relevant text;

9.5 POST:
> Responses to this method are not cacheable, unless the response  
> includes appropriate Cache-Control or Expires header fields.

13.11 Write-Through Mandatory:
> All methods that might be expected to cause modifications to the  
> origin server's resources MUST be written through to the origin  
> server. This currently includes all methods except for GET and HEAD.  
> A cache MUST NOT reply to such a request from a client before having  
> transmitted the request to the inbound server, and having received a  
> corresponding response from the inbound server. This does not  
> prevent a proxy cache from sending a 100 (Continue) response before  
> the inbound server has sent its final reply.

IME current implementations do not cache any non-GET/HEAD responses,  
so either path is open.

Personally, my understanding has always been that methods do not form  
part of the cache key and this is also my preference; I'm concerned  
about the specification complexity making it part of the key would add  
(e.g., around variant selection, making the write-through requirement  
compatible with future cacheable methods), as well as getting  
implementation support and the likely proliferation of GET-copycat  
methods.

--
Mark Nottingham     http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 15 Nov 2008 13:36:15 -0800

#139; <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139>.

On 14/11/2008, at 7:11 PM, Mark Nottingham wrote:

> method is to caching. In particular, does the method form part of  
> the cache key?
>
> GET/HEAD response could "populate" the cache if it had explicit  
> expiry information; e.g., a POST response could be used to satisfy a  
> future GET request (if the POST response were marked as explicitly  
> cacheable).
>
>> server. This currently includes all methods except for GET and  
>> HEAD. A cache MUST NOT reply to such a request from a client before  
>> having transmitted the request to the inbound server, and having  
>> received a corresponding response from the inbound server. This  
>> does not prevent a proxy cache from sending a 100 (Continue)  
>> response before the inbound server has sent its final reply.
>
> Personally, my understanding has always been that methods do not  
> form part of the cache key and this is also my preference; I'm  
> concerned about the specification complexity making it part of the  
> key would add (e.g., around variant selection, making the write- 
> through requirement compatible with future cacheable methods), as  
> well as getting implementation support and the likely proliferation  
> of GET-copycat methods.
>
>
> --

---

From: Robert Siemer <[email-masked]>
Date: Sun, 16 Nov 2008 04:34:50 +0100

I think it is pretty clear, that the method is part of the cache key, 
otherwise a new completely unrelated method, which does always return 
the same response entity (and thus marked as cachable), will interfere 
with the next unrelated GET. That blocks new (and old) methods from 
defining sensible caching strategies.

Same people like to have a POST response cached for the next GET to 
come, but this effect can be achieved by better means:
Use a 303 "See Other". This 303 may get cached and the following GET, 
too.

This allows mixing "status-responses" and "entity-responses" on the 
discretion of the server, as HTTP does already.

Robert

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 17 Nov 2008 02:32:34 +0000

> defining sensible caching strategies.

I agreed with Mark and thought the opposite.  I've always imagined the
cache key is a function of the URL and headers enumerated by 'Vary'
only.  But...

It's a good question!  The answer may be that the question is
ill-formed for HTTP.

There *isn't* a flat cache key for cached entities, in the logic of
HTTP.  Think about the 'Vary' header, especially with cached responses
for the same URL having different 'Vary'.  Efficient but
non-conservative HTTP cache lookup is tree structured, as it
progressively refines the set depending on stored 'Vary' of different
cached responses.  The *set* is then transmitted in If-None-Match, or
considered for a time-based response.

Of course you are free to implement a flat cache if you want to be
conservative and not cache some cacheable things.  Nearly all HTTP
caches are conservative in this way, because it's easier to implement.

We all recognise that 'Vary' complicates things, but to _start_ the
cache lookup, do we start with key = URL only, or key = URL + method?

If someone defines a new method like say PATCH, clearly it must
invalidate the previously cached GET result for the same resource
somehow.

If the GET result uses _validated_ caching, i.e. ETags, then it's not
necessary for other methods to invalidate it automatically at
intermediaries, because the server will be consulted anyway by
following GETs.

On the other hand, if the GET result uses _time-based_ caching,
i.e. without validation required, then it _is_ necessary that other
methods like PATCH can invalidate it automatically at intermediaries.
(But then must it do the same for non-canonical URLs, such as "///" in
them, or %-encoded equivalents?)

Thus the "ideal" (non-conservative) choice of whether the initial
cache key depends on the request method _depends_ on the headers of
previously cached responses.  In other words, it's roughly analogous
to 'Vary: method', and it might not be a bad idea to define a
Cache-Control which means that - in requests, responses or both.

-- Jamie

---

From: Robert Siemer <[email-masked]>
Date: Mon, 17 Nov 2008 06:25:45 +0100

> cache lookup, do we start with key = URL only, or key = URL + method?

That's an implementation detail. Flat or not non-flat, part of the 
"initial" key or added later, the result is the same. It is important to 
understand that the method is part of the key. - Applications that would 
like to join the responses of method1+url1 and method2+url2 should 
redirect from the former to the latter (url1 and url2 can be the same).

> intermediaries, because the server will be consulted anyway by

The original question had nothing to do with invalidation, but the
scenario you mentioned has only _invalid_ responses (can be used only
once at response time), there is no need to invalidate later automatically
or manually or whatever. There is no real distinction between invalid and
has-to-be-validated cache entries.

> them, or %-encoded equivalents?)

Invalidation is a must, but is not a cure-all. An intermediary might not
see the invalidating request at all. If a URL equals another is defined
in RFCs, and "///" does not equal "/". 

> Cache-Control which means that - in requests, responses or both.

Initial or not, "Vary: method" is always "on" in HTTP.

Robert

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 17 Nov 2008 08:57:12 +0100

> method is to caching. In particular, does the method form part of the  

As already discussed extensively: no.

> GET request (if the POST response were marked as explicitly cacheable).

Yes.

> response to future requests.

Indeed.

My proposal is to make the URI-only GET/HEAD cache model more explicit,
so future protocol additions hopefully do not fall into the same trap of
inventing new GET-type methods like WebDAV did..

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 17 Nov 2008 08:59:13 +0100

> come, but this effect can be achieved by better means:

It's already defined so in HTTP/1.1 (and 1.0). Or do you propose
removing this feature from the specification os POST?

Regards
Henrik

---

From: [email-masked]
Date: Mon, 17 Nov 2008 09:37:01 +0100 (CET)

>> [...]

I think everyone agrees nowadays that side-effect free reading should be
done with GET. (If WebDAV comes up as a a bad example all the time in
these discussions, it is because it almost got things right. Other
protocols which nearly got everything-* wrong, will not be remembered).

I like Henriks approach because it keeps things easy to understand, which
is a prerequisite to easy to implement. And caches deployed on the net
with inconsistent behaviour in edge cases have always been a pain.

//Stefan

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 17 Nov 2008 10:00:33 -0600

> As already discussed extensively: no.

Where is the discussion?

> so future protocol additions hopefully do not fall into the same trap
> of inventing new GET-type methods like WebDAV did..

RFC 4918 says PROPFIND is cacheable. The only practical way PROPFIND can be
cacheable is if the method is part of the key. Otherwise the cached PROPFIND
responses would be returned by the cache for GET requests, which is clearly
wrong. 

You are proposing that 9(1) only GET and HEAD are cacheable, and in
particular (2) POST and PROPFIND are never cacheable even with Cache-Control
headers in the responses, and (3) that there will never be another cacheable
method in HTTP. Off the top of my head, I can't think of any problems with
that proposal as long as caches aren't caching PROPFIND already.

- Brian

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 17 Nov 2008 10:03:14 -0600

> removing this feature from the specification os POST?

I searched through RFC 2616 for a long time trying to find this. Where is it specified that a cached POST response can be returned for a subsequent GET request?

- Brian

---

From: Werner Baumann <[email-masked]>
Date: Mon, 17 Nov 2008 19:33:06 +0100

> responses would be returned by the cache for GET requests, which is clearly
RFC 4918 says:
"Some PROPFIND results MAY be cached, with care, as there is no cache 
validation mechanism for most properties."

Additionally the response to a PROPFIND request is highly client 
defined. With three levels of DEPTH and about 10 properties defined in 
RFC 4918, there are about 3000 different possible responses for the same 
state of the same resource. And clients are free to create any number of 
custom properties. Nothing an intermediary cache would like to cache.

Apart from the method the intermediary cache would have to include the 
DEPTH header and a list of requested properties into the key. And what 
would be the cache hit rate?

Werner

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Nov 2008 16:22:13 -0600

AIUI it's implied by the combination of POST being explicitly  
cacheable, but being required to be written through. Freshness can't  
be used, and validation is fraught with difficulty.

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.

On 17/11/2008, at 10:03 AM, Brian Smith wrote:

> I searched through RFC 2616 for a long time trying to find this.  
> Where is it specified that a cached POST response can be returned  
> for a subsequent GET request?
>
> - Brian
>
>

---

From: Robert Siemer <[email-masked]>
Date: Tue, 18 Nov 2008 06:54:20 +0100

> be used, and validation is fraught with difficulty.

You read that it is implied that POST responses can be used for GET, I 
read that POSTs don't have to be written through.

R

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 18 Nov 2008 06:39:40 -0600

Mark Nottingham wrote:
> cacheable, but being required to be written through.

It looks like something that was just overlooked to me. It almost never
makes sense for the response to a POST to be returned for a GET request to
the same request URI. It would be more useful for PUT (e.g. an AtomPub
server could return a new representation of the entry in its response to a
PUT).

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.

> 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.")

- Brian

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 18 Nov 2008 06:55:15 -0600

Werner Baumann wrote:
> RFC 4918, there are about 3000 different possible responses for the
> same state of the same resource. And clients are free to create any
> number of custom properties. Nothing an intermediary cache would like
> to cache.
> 

For other depths, a cacheable propfind should include a "Vary: *" and
validators (ETag and/or Last-Modified). "Vary: *" is needed since the
response depends on the request body. Then the cache can cache the response
just as it would for any other use of "Vary: *", by passing through the
PROPFIND as a conditional request.

Additionally, if a WebDAV server doesn't support infinite-depth request,
then it can return a 403 with a long expiration time and "Vary: Depth". The
cache can cache all of these very effectively.

For any given WebDAV client, there are not many different types of PROPFIND
queries done on a resource. And, often there are repeated PROPFIND queries
done on the same resource, so it makes sense to support caching with
revalidation.

- Brian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Nov 2008 22:21:49 +0100

Werner Baumann wrote:
> ...
> ...

It could be quite good, depending on what clients do; such as refreshing 
a collection view over and over again (think explorer-like clients).

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 18 Nov 2008 16:28:31 +0100

> server could return a new representation of the entry in its response to a

The classic example of where a cacheable response to POST makes sense is
the guestbook example (or unmoderated blog comments for those needing a
more modern example, basically the same thing in a different era) where
the visitor POSTs an addition to the page currently viewed, or "separate
entity that accepts annotations" as it's expressed in the RFC. The
response given to the POST is the new representation of the page. Both
GET and POST uses the same URL in this example.

So you have the sequence

  GET /page

  200 OK, max-age=X

[user fills in comment form]

  POST /page

  200 OK, max-age=X

where the 200 OK response to POST is in all regards identical to that of
a GET following the POST.

Note that the POST request as such can never be satisfied from cache. A
repeated POST with the same form content will not yield the same result
even if the response is cacheable.

This only applies when the response to POST has explicit expiry
information as the response to POST has the duality of either being a
status message indicating the result of the action OR the modified
resource, both using the 200 OK status code. There was a discussion some
time ago about adding a new status code to separate the two cases to
make this property of POST more explicit, but iirc the conclusion were
that 200 OK is actually fine for both cases. But this property of POST
do need a better explanation.

PUT on the other hand is not really meant to perform any server-side
processing of the resource, only storing it "as-is" and adding relevant
meta data such as ETag (which returned in the response) and Content-Type
if not supplied by the client (not returned in the response). For all
practical purposes (i.e. continued authoring of the resource) the client
SHOULD be able to use the resource it sent in the PUT request as it's
current representation of the resource, even if it may differ slightly
from what the server actually stored. Because of this the response to
PUT is always a status message. There has been discussions about
extending PUT to allow it to return a modified representation, and any
such negotiated extension would place those responses in the same family
as POST above, returning a representation that is a valid representation
as if the request had been a GET request immediately after the PUT.

Regards
Henrik

---

From: Yves Lafon <[email-masked]>
Date: Tue, 18 Nov 2008 10:40:30 -0500 (EST)

> a GET following the POST.

How about

GET /page

200 OK

POST /page

303 Location: /page

GET /page

Of course it requires another round trip, but it's far more clear.

> even if the response is cacheable.

I've always read cachable POST as "if I have the same URI+payload, then
the server told me I can serve from the cache", now having the "let's 
cache POST responses for other methods would require explicit signalling. 
The 303 on the same page + cache info + etag might signal that, but 
currently that's stretching the meaning of methods a lot.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Werner Baumann <[email-masked]>
Date: Tue, 18 Nov 2008 18:32:19 +0100

> a collection view over and over again (think explorer-like clients).
Conditional PROPFIND would be very useful for user agents (i.e. WebDAV 
clients). But the problem is RFC 4918, which does not define anything 
like a cache validation mechanism for properties (and not for 
collections). I don't think this missing functionality can be added by 
some extension, but it would require a revision of RFC 4918.

I doubt that it would be very useful for intermediaries. WebDAV access 
is usually restricted to a comparably small set of users.

Werner

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Nov 2008 18:41:37 +0100

Werner Baumann wrote:
> 
> 
> Julian Reschke wrote:
>> Werner Baumann wrote:
>>> ...
>>> Apart from the method the intermediary cache would have to include 
>>> the DEPTH header and a list of requested properties into the key. And 
>>> what would be the cache hit rate?
>>> ...
>>
>> It could be quite good, depending on what clients do; such as 
>> refreshing a collection view over and over again (think explorer-like 
>> clients).
>>

I also believe that it would be both tricky and a lot of work to add all 
the additional infrastructure for validators.

Thus,
<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-01.html> 
-- which essentially makes PROPFIND results GETtable.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 18 Nov 2008 18:52:00 +0100

On tis, 2008-11-18 at 10:40 -0500, Yves Lafon wrote:

> the server told me I can serve from the cache"

This is not allowed. There is both a MUST and a MUST NOT in
"Write-Through Mandatory" which forbids this. In the base HTTP/1.1
specifications only GET/HEAD may be served from cache.

> now having the "let's 

I wouldn't agree it's stretching. It's very natural when you have a
cache which solely exists for GET/HEAD requests with write-through for
every other base method.

Extension methods MAY define their own cache rules, but only applies to
caches implementing the same. PROPFIND has already been mentioned in
this discussion and as a note can be mentioned that a cache which only
implements the base HTTP/1.1 specifications will invalidate any cached
objects on the URI when seeing a PROPFIND request for that URI.

But yes, it's easy to misread the intentions of RFC2616 unless it's read
in full several times to piece all the pieces together, and I even read
it exactly the same way as you initially but with a big reservation "is
this really what it means, it doesn't make much sense to do so.". The
primary aim of this working group is to revise the specs making them
easier to follow and remove any inconsistency or major ambiguity.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 18 Nov 2008 18:52:32 +0100

> Where is the discussion?

On this list somewhere..

> responses would be returned by the cache for GET requests, which is clearly

So nice of RFC4918, and works fine in context of a WabDAV client, but
not in general HTTP terms.

> that proposal as long as caches aren't caching PROPFIND already.

I don't propose dropping the cacheability properties of POST->GET, but
other than that yes.

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 18 Nov 2008 18:53:52 +0100

> I searched through RFC 2616 for a long time trying to find this. Where is it specified that a cached POST response can be returned for a subsequent GET request?

The implicit fact that HTTP cache is primarily for GET/HEAD resource
response entities, and the last sentence in the definition of POST which
means to refer to the case where POST returns the modified resource
entity as such and not just a status report about the action taken.

This was discussed in earlier on this list I think... probably in 2007
or maye as early as 2006. But for some reason I can't find a reference
to it now. Then partially referenced in the "requested variant"
discussion.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Nov 2008 19:03:40 +0100

> objects on the URI when seeing a PROPFIND request for that URI.

The method registry we're building 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-method-registrations-00.html>) 
will tell implementers that PROPFIND is safe -- that should be 
sufficient for not requiring invalidate, right?

BR, Julian

---

From: Werner Baumann <[email-masked]>
Date: Tue, 18 Nov 2008 19:10:40 +0100

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Nov 2008 10:36:04 -0800

No. Although there are a number of aspects here that aren't clearly  
specified, 2616 does clearly state that POST must be written through.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Nov 2008 10:40:53 -0800

[ trimming the CC: list ]

Well, we need to look at how all of the requirements are specified,  
and how they fit together. Currently, this entire area is very fuzzy,  
especially reqarding extension methods, so we need to sort it out.

As I said before, I think this could go either way, but personally I'm  
leaning towards NOT putting the method in the key cache key, for two  
reasons;

1) Major shared cache implementers interpret it this way (see Henrik's  
mail, for example).

2) Allowing non-GET methods to be cacheable will IMO encourage the  
development of GET-like extension methods. This will result in a lot  
of data and metadata that isn't "on the Web" (i.e., you can't just  
dereference a link to obtain it; now you need to know the correct  
method as well).

#1 may be a stronger reason to go this way as per our charter, but I  
think in the long run #2 is a stronger motivation.

On 18/11/2008, at 10:03 AM, Julian Reschke wrote:

> The method registry we're building (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-method-registrations-00.html 
> >) will tell implementers that PROPFIND is safe -- that should be

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 18 Nov 2008 13:49:47 -0600

Here's my proposal:

* Replace the first line of Part 6, section 3.1:

     - A correct cache MUST respond to a request
     - with the most up-to-date 

     + For methods other than GET and HEAD, a cache
     + MUST forward the request to the origin server
     + and MUST return the origin server's response.
     + For GET and HEAD requests, a cache MUST 
     + response with the most up-to-date
     
* Insert the following paragraph at the beginning of part 6, section 6
(Response Cacheability):

     + Responses for methods other than HEAD and GET
     + MUST NOT be cached.

* Remove part 6, section 13 (Write-Through Mandatory).

* Remove all the "responses to this method are not cacheable" statements
from part 2.

* Remove the statement about the cacheability of POST in part 2, section
8.5.

* Issue an errata or some other update of RFC 4918 that says that PROPFIND
responses are not cacheable.

Justification:

* This is the simplest thing that could possibly work.

* Nobody is caching anything other than GET and HEAD responses anyway.

* Section 13 is redundant with the other parts, and it has misleading
statements. For example, according to section 13, a cache cannot return a
5xx response if it cannot communicate with the server. 

- Brian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 18 Nov 2008 13:01:42 -0800

> As already discussed extensively: no.

As designed, yes.  The http-caching discussion had the same problem -- a
small group went off and thought they could redesign HTTP caching on the
basis of their experience with file and CPU caches.  They were wrong.
When the discussion came up about HTTP having an entity-storage cache or
a response cache, the result was always that the method was part of the
cache key (a response cache).  It had to be because HTTP is intended to
usable as a generic interface protocol for non-Web information systems
that may have their own sets of methods.

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.

>> expiry

No.  Those WebDAV discussions had nothing to do with caching or, for
that matter, reasonable design.  They are new methods for the sole
purpose of removing a single round-trip when interacting with a new
resource, which was proven back then to be a false design assumption
and defined anyway because of sheer pig-headed MS.

There is no danger of per-method caching suddenly causing people
to prefer other methods over GET.  Links are valuable because of the
identifier, not because people have to do GET on the identifier, and
the deployment problem alone is more than sufficient to encourage
people to use GET for retrieval when the URI is the target.
PROPFIND is stupid because it hides the identifier (and thus all
the other methods that might be applied on an identifier have to
be duplicated, not just GET).

....Roy

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 18 Nov 2008 22:09:07 +0100

> sufficient for not requiring invalidate, right?

The issue with this is that the implementer must care to look up the
PROPFIND method and special-case it in the implementation.

The default for anything non-GET/HEAD is invalidate, and there is no way
that's going to change. The opposite would be very dangerous to any new
method added.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 18 Nov 2008 22:14:43 +0100

> think in the long run #2 is a stronger motivation.

Yes. #2 is the important one imho.

In our implementation we actually do keep the method as an internal part
of the cache key, but that's for other reasons, and if I were to
reimplement the cache today the method would not be part of the key
getting rid of a lot of special cases..

Regards
Henrik

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 18 Nov 2008 16:50:29 -0600

> 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

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 19 Nov 2008 20:00:02 +1300

I'd also propose clearing up nomenclature relating to "cachability".  
The same word used is used for 2 completely different meanings, being

a) response permitted to be stored into a cache
b) request permitted to be responded to by a cache

GET/HEAD responses can be stored in and GET/HEAD requests can be 
responded to by a cache.  POST responses can be stored into a cache, but 
POST requests cannot be responded to by a cache.

I think the misuse of the word "cacheable" is causing additional confusion.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Nov 2008 23:02:21 -0800

Yes, I'm working on a proposal for this now; stay tuned.

Cheers,

On 18/11/2008, at 11:00 PM, Adrien de Croy wrote:

>
> I'd also propose clearing up nomenclature relating to  
> "cachability".  The same word used is used for 2 completely  
> different meanings, being
>
> responded to by a cache.  POST responses can be stored into a cache,  
> but POST requests cannot be responded to by a cache.
>
>> and how they fit together. Currently, this entire area is very  
>> fuzzy, especially reqarding extension methods, so we need to sort  
>> it out.
>>
>> As I said before, I think this could go either way, but personally  
>> I'm leaning towards NOT putting the method in the key cache key,  
>> for two reasons;
>>
>> 1) Major shared cache implementers interpret it this way (see  
>> Henrik's mail, for example).
>>
>> development of GET-like extension methods. This will result in a  
>> lot of data and metadata that isn't "on the Web" (i.e., you can't  
>> just dereference a link to obtain it; now you need to know the  
>> correct method as well).
>>
>>
>> #1 may be a stronger reason to go this way as per our charter, but  
>> I think in the long run #2 is a stronger motivation.
>>
>>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Nov 2008 08:08:43 +0100

> PROPFIND method and special-case it in the implementation.

Yes. But at least there'll be a single place to lookup that information.

> that's going to change. The opposite would be very dangerous to any new

I disagree with the "very" dangerous. Only one cache will see the method 
invocation, so other caches will not be invalidated either way.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 19 Nov 2008 10:28:59 +0100

> invocation, so other caches will not be invalidated either way.

Agreed. Only dangerous.

But it's also those caches being the most important, as it's the caches
the same user is most likely to hit.

Regards
Henrik

---

From: Yves Lafon <[email-masked]>
Date: Wed, 19 Nov 2008 05:32:09 -0500 (EST)

> cache which solely exists for GET/HEAD requests with write-through for

Well, if you have:
GET /foo
->
200 OK
CT: text/plain
CC: max-age=86400
1

POST /foo
->
200 OK
CT: text/html
CC: max-age=3600

<html><body><p>Value incremented!</p></body></html>

What will the cache do?
There is no Vary on the first GET, as the GET always return the text 
version, and the POST just return HTML saying it successfully done its 
action. Clearly, the POST-driven invalidation of the cache entry kicks in 
and forbid to return "1", but if a subsequent GET was returning the HTML, 
it would be really bad.

There is no way to disambiguate the response of a POST as being the same 
as what a GET would do, unless the server gives extra informations, a 
mechanism not defined in 2616. The best way seems to be POST->303 with 
almost empty body on same Location -> GET and retrieve the body, then 
cache.

> objects on the URI when seeing a PROPFIND request for that URI.

Yes and that's safe, if you don't know that PROPFIND may be cachable, then 
do not cache it.

> easier to follow and remove any inconsistency or major ambiguity.

Agreed that there is an ambiguity there, as people have different reading 
of it :)

         ~~Yves

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 19 Nov 2008 12:46:19 +0100

> almost empty body on same Location -> GET and retrieve the body, then 

That piece of extra information is the explicit expiry information.
There is nothing ambiguous about that, ignoring broken servers who send
explicit expiry information on responses where they did not intend to..

Regards
Henrik

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 19 Nov 2008 12:15:46 +0000

>      + Responses for methods other than HEAD and GET

Provided we understand that at some point, we _might_ define
cachability of some other methods when the response contains a
"Cache-Control" header, maybe with a yet to be defined token.

There is no harm in other method responses being cachable if the
server says they are, especially if an Etag is used so the origin
server is always consulted for accuracy.

-- Jamie

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 19 Nov 2008 14:35:14 +0100

> server is always consulted for accuracy.

etag values in requests refer to the "selected representation", not the
method specific response.

Basing the selected representation on the method used does not make much
sense imho. 

ETag headers in responses also refer to the selected representation the
response either contains or relates to, and is meant to be able to use
as validator cross methods for the same URI.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Nov 2008 15:18:06 +0100

> method specific response.

Yes, and we will need to define what the selected representation is.

> Basing the selected representation on the method used does not make much

Sure. That would break for instance conditional headers on WebDAV 
requests, such as LOCK.

> as validator cross methods for the same URI.

I may agree with this, but we certainly need to do better stating it.

BR, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 19 Nov 2008 12:58:15 -0800

On Nov 18, 2008, at 2:50 PM, Brian Smith wrote:

> Then how does caching work for POST?

The same way it has been defined in HTTP/1.1 since my first proposal.
If the response is cacheable under the same URI, then it will be a 200
response with a Content-Location that says it is the same as the
request URI.  If it is cacheable under a different URI, then 303 is
the preferred response in order to fill all caches in the chain
without bypassing authority checks.

> Why isn't OPTIONS cacheable?

For the same reason that it is specified not to contain a body.
It was a disagreement among the previous editors.

> Why aren't

They are if you read the individual response codes and field  
definitions.

> don't want the response to be cached.

That is not a problem.

> future version of the protocol.

No.  The right thing to do is to remove the artificial restrictions
that were made in the absence of any implementations and let the
messages be self-descriptive.

....Roy

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 19 Nov 2008 18:14:04 -0600

Roy T. Fielding wrote:
> request URI.

Let me make sure I understand your response:

(1) When a cache receives a POST request, it MUST always forward to the
origin server, even if it already has a previous matching response in its
cache. It MUST NOT return a cached response for any POST request. This is
stated in section 13.11.

(2) A POST response MAY be cached only if: (a) has appropriate Cache-Control
or Expires fields, AND (b) it has a Content-Location header that resolves to
the Request URI. All other POST responses MUST NOT be cached. The
Cache-Control/Expires requirement is in section 9.5. 

(3) When a cache receives a GET (or HEAD) request, it MAY return a
previously cached POST response that was a cached using the criteria in (2)
above, or it MAY return a previously cached GET (or HEAD) response. This
isn't stated anywhere in RFC 2616.

Is my understanding correct?

Can (2) and (3) be generalized: Any response to any method can be cached and
returned in subsequent GET and HEAD requests, as long as the response
includes Expires/Cache-Control and a Content-Location that resolves to the
Request URI? For example, a PROPFIND response that meets those conditions
could be returned for subsequent GET and HEAD responses on the request URI. 

What about the case where the method is not GET, HEAD, or POST, the
Content-Location isn't the same as the request URI, or Content-Location is
missing)? For example, can we cache PROPFIND or SEARCH responses and return
them for subsequent PROPFIND and SEARCH requests? What are the requirements
for caching extension methods--the method MUST be "safe" and the response
MUST include a Cache-Control/Expires header? Any other requirements?

> They are if you read the individual response codes and field

The non-cacheability of PUT and DELETE is stated the same way as the
non-cacheability of OPTIONS: "Responses to this method are not cacheable."
Granted, it isn't using MUST NOT language, but the statement is pretty clear
in forbidding the caching of any of those methods (AFAICT, for no good
reason).

> messages be self-descriptive.

It would be smart to at least warn cache implementers about the problems of
caching anything other than GET and HEAD, and to warn origin server
implementers to be (more) careful with their Cache-Control/Expires headers.

Regards,
Brian

---

From: [email-masked]
Date: Thu, 20 Nov 2008 10:19:12 +0100 (CET)

Let me try to rephrase it to see if I understood:

A 200 response to *any* method (given headers like Content-* don't
indicate otherwise), can be returned on a subsequent GET/HEAD by
a cache (ignoring validation handling for now).

So, the cache is caching resource representations, not responses to
specific request types. There is no cached response for a POST, separate
to a cached response to a GET and to a PATCH and so forth. Instead the
cache is holding at most *one* entry per URI.

Unsafe methods like POST clear the cache for the request URI, before any
processing is done. Which enforces a cache miss and a forwarding of the
request to the server (or up the cache chain).

Would that describe the principal operation of a HTTP cache (ignoring
all the fine details of cache-control and so forth)?

//Stefan

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 20 Nov 2008 10:47:35 +0100

> without bypassing authority checks.

Where is the Content-Location requirement? Can't seem to find such
requirement, only a general recommendation to always send a
Content-Location, and cache rules on invalidation when there is a
Content-Location.

The cache note in POST says

   Responses to this method are not cacheable, unless the response
   includes appropriate Cache-Control or Expires header fields. However,
   the 303 (See Other) response can be used to direct the user agent to
   retrieve a cacheable resource.

And there from what I can tell is no requirement anywhere that cacheable
responses MUST have a Content-Location. But yes, there is a requirement
that servers SHOULD provide a Content-Location on any response where
there is a matching unique resource-URI, but at the same time it's a
little ambiguent by having a overlapping MAY requirement which kind of
indicates Content-Location is not needed if it's the same as the
requested URI.

> They are if you read the individual response codes and field  

Can you elaborate?

> > don't want the response to be cached.

How so?

When is a server unintentionally stating that a temporary status
response is cacheable not a problem?

Unless you mean it's not a problem in or due to the specifications, just
a broken server.

> messages be self-descriptive.

Agreed.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 20 Nov 2008 10:55:17 +0100

> cache is holding at most *one* entry per URI.

per Content-Location URI, when Content-Location is given.

For any given Request-URI there MAY be many variants, each of which MAY
have a unique Content-Location, and servers SHOULD provide this (unique
locations) if they can.

Some methods or responses return the complete representaion, some only
partial headers and/or partial body.

Yes.

> all the fine details of cache-control and so forth)?

In my view yes.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 20 Nov 2008 11:06:35 +0100

> isn't stated anywhere in RFC 2616.

Almost.

The POST invalidates any prior responses, and the cache which have seen
the POST passing by MUST NOT return a previsouly cached GET (or HEAD)
response.

Regards
Henrik