Re: Caching data returned from POST, and conditional POST

David W. Morris writes:
	...

   There is an
 > essential difference between GET and POST ... GET is not supposed to
 > cause state changes in the server which would cause the response to 
 > a subsequent GET to be different.  POST may make such changes.
 > 

I've been thinking about this some, having made a number of similar
statements myself.  I'm now having doubts.

Suppose we didn't make any presumption about POST normally side effecting
servers and GET not being able to.  How would we get the right
behavior and what would be gained?

There's an antique version of form submission that uses GET with stuff
crammed into the URL, that *can* cause server side effects.
It's just a convention that GET doesn't cause side effects.  There's
also (in practice) a distinction between those POSTs that have server
side effects, and those that are really just search forms or similarly
non-side-effectful requests.  So we can have GETs that cause side
effects, and POSTs that don't.

Given the possible existence of cache-control: no-cache in requests
I think it might be possible to do away with the need for a
presumption about which methods can be served from cache and which can't.
To get the default behavior we expect, the default GET would not have
a cache-control:no-cache, but the default POST would.

The problem with this in the world as we find it is that the
information available from the HTML is insufficient to tell, for a
given GET or POST request, whether or not it is going to have side
effects.

If there were a way to control this from HTML (or other content-types)
then we could get better caching of search results, for instance.

--Shel Kaphan

Received on Thursday, 4 January 1996 02:27:35 UTC