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. Regards Henrik
Received on Tuesday, 18 November 2008 17:52:51 UTC