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