RE: GET, POST, and side-effects

Larry Masinter writes:
 > 
 > FWIW, I am opposed to including an entity body in a 'GET' request,

for Jeff's reasons of downward compatibility, I agree.

   and
 > think POST-W-N-S-E is nonsense.

For reasons of downward compatibility, I agree it is apparently unusable.
And, following your reasoning below, it is not as flexible as it
should be anyway.

 Whether the results of a POST is
 > cachable might depend on the request!

And so, the server can insert appropriate Expires headers to indicate
just how cachable the response is.

 For example, you might POST
 > something which is syntactically invalid, and let the client cache the
 > error message telling you how it was wrong, but syntactically valid
 > POST requests would be sent along, have side effects, and thus not be
 > repeatable or cachable. The indication of the transaction status of a
 > request should be included in the response, not deduced from the
 > nature of the request, unless the response just doesn't say.
 > 

I agree, a response-based approach could certainly be more accurate
and flexible.  How exactly could we implement this?  Suppose that
instead of the HTML, browser, and request changes that I mentioned
about 5 minutes ago, that servers inserted the
Cache-control:no-side-effects header in appropriate *responses*.  This
then would be part of the cache's state for that particular
request/response pair, and could control the cache's behavior for
subsequent request of a similar nature. Yeah, I like it, and it
requires less infrastructure change as well.

Are we converging yet?

--Shel

Received on Friday, 5 January 1996 23:08:43 UTC