W3C home > Mailing lists > Public > http-caching-historical@w3.org > January 1996

RE: GET, POST, and side-effects

From: Paul Leach <paulle@microsoft.com>
Date: Thu, 4 Jan 96 13:45:00 PST
To: http-caching@pa.dec.com, mogul@pa.dec.com
Message-Id: red-16-msg960104213957MTP[01.52.00]000000b0-5378
Just a simple example of a different kind of cachable POST, which 
generalizes to more practical ones.

Suppose I want to provide a "sine()" service -- you tell me an angle in 
degrees, and I tell you the sine of that angle.  I could implement this 
so that a POST to http://www.sine.com of an entity containing (e.g.) 
"x=0" would return an entity containing "y=0". It would be perfectly 
OK, for the sine service, to cache this result, and reply to the next 
POST to http://www.sine.com of the entity "x=0" with the "y=0" entity.

This property holds true even if sin(x) is generated dynamically every 
time, as opposed to being looked up. Sine is a function that is 
"reducible" (this term is from the IBM PL/I optimizing compiler): if 
you invoke it with the same arguments, it gives the same results.

In order for a proxy to take advantage of this, it needs some 
indication that its OK to cache the result. Expires: and Cache-Control 
aren't quite enough -- they would say that the URI returned in the  
Location: header could be used to as a cache key for the returned 
entity value, but not obviously that the same query would return the 
same result.

Note, finally, that it is not necessary for the same query to give the 
same result _forever_ -- only that it give the same result for as long 
as the Expires: and/or Cache-Control: headers say proxies are allowed 
to believe it does.
Received on Thursday, 4 January 1996 21:53:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC