RE: NEW ISSUE: Methods and Caching

On Tue, 18 Nov 2008, Henrik Nordstrom wrote:

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

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.

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

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

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

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

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

         ~~Yves

Received on Wednesday, 19 November 2008 10:32:22 UTC