RE: GET, POST, and side-effects

----------
Shel responds to what Paul says:
]
] Paul Leach writes:
]  > 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.
]  >
]
] This isn't the property that matters here.  If in addition to
] returning the sine, that same angle of apple pie were ordered for you
] in response to each POST, then it would be important for the POST
] request to make it all the way to the origin server each time.

In which case, it isn't a "sine server" at all, but a 
"sine-and-apple-pie" server, and the sine-and-apple-pie function is 
_not_ reducible.  I think I used "result" in an ambiguous way in my 
original post -- I meant it in the sense of the total effect of the 
function, not the narrower sense of the resulting entity.

I agree that the POSTs to the sine-and-apple-pie server need to make it 
to the origin server each time.

  The
] property that matters here is whether a POST (or any method) is
] capable of generating side effects at the origin server.

We agree 100% on this.

 Right now
] this is hard-wired into the method definitions -- we assume GET and
] HEAD have no side effects, and everything else does.  Therefore GET
] and HEAD can be answered by a cache, but nothing else can.  This can
] be generalized as I described earlier.
]
]  > 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.
]  >
]
] Expires and Cache-Control on responses only describe the cachability
] ("freshness period") of the result, not the side-effectfulness of the
] request.

We agree again.  That's why I said Expires: and Cache-Control aren't 
enough for this case.

These are separable.  (As an aside, Location in and of
] itself can't be used as a cache key, because of spoofing
] possibilities, but we'll discuss that another time).

(I understand about Location: -- just trying to be brief...)

  What is needed
] is a way to clearly indicate in a *request* (not in responses) that
] the request may be served from a cache, or must go through to the
] origin server.  (See my earlier posts).

This I disagree about.  It seems clear to me that only the server knows 
whether the POST will have side effects, and that identical requests 
return identical results. It seems easy enough to have the server 
indicate that on the response to a POST, and I don't see how the client 
could know.

Paul

Received on Friday, 5 January 1996 00:48:48 UTC