RE: NEW ISSUE: Methods and Caching

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

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

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

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.


Received on Tuesday, 18 November 2008 17:52:51 UTC