GET, POST, and side-effects

Jeff says:

   As Shel points out,
       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.

   In Roy's draft, section 14.2 says that GET and HEAD should not
   have side effects.  It also says that the protocol cannot enforce
   this, but (implicitly) that implementations of the protocol may
   assume that GET and HEAD are in fact side-effect-free.  I believe
   that this is a valuable concept, and I don't think we should give
   up our ability to make this assumption.

My point was that we can generalize this, while allowing the existing
behavior as a default.  It's safe to serve responses to GET and HEAD
out of a cache only because we assume they are side-effect-free.  We
don't make that assumption with other methods -- we assume they
actually have to do something at the origin server.  I'm claiming that
assumption is unnecessary if we adopt mandatory use of controls
already in the protocol to make this explicit, namely
Cache-control:no-cache, which on requests means "you can't give me the
answer to this out of a cache -- I want it from the origin server".
(we could call it something different - the meaning is what matters).

	...
   [Begin: thinking-out-loud portion of message]

   How might one make PUT idempotent?  Well, suppose that the client
   starts by doing a GET on an existing resource, and the server
   returns a cache-validator value for the resource.  Then the client
   issues one or more PUTs on the resource, handing back the
   cache-validator value it received from the server.  If the server
   only performs the PUT when the client's validator matches the
   one that it would provide if a GET were done on the resource,
   *and* (very important) the validator is constructed in a way
   that is guaranteed to change when the resource is modified, then
   we have an idempotent method.  No matter how many intervening
   PUTs have been done, this should not result in the same PUT
   being done twice.

But what happens if a PUT is done through an intermediary?
Are you saying that the PUT is only passed through if the proxy's
validator matches the request's validator?  I don't think that works.
If the cache has been updated since the client's original GET, or if
the client switched to using a proxy that had a version prior to the one
it GOT, the GOTten validator won't match the cache's validator.  In case
of either a match or non-match, the cache must pass the request through.

If we adopted the mandatory use of cache-control:no-cache on requests
to signify they must go through to the origin server, the omission of
that header would imply that if a cache contained a fresh copy of the
response, then the method would not have to be passed through.  I am
assuming here, in the case of POST, for instance, that the cache would
have to match the entity in the POST request to know if the
appropriate result was present in the cache (this could get messy, maybe
enough to render this whole discussion moot, but that's irrelevant for
the moment).  The lack of the proposed mandatory
cache-control:no-cache would signify/guarantee the lack of origin
server side effects.  With no explicit guarantee of
side-effect-lessness the request must be passed on to the origin
server. 

The point I was trying to make is that the important thing about GET
and HEAD, the ability to serve responses to them from a cache if the
cache contains a "fresh" copy of that response, is generalizable if we
want to, by making this behavior explicit in the protocol.
The difficulty we might get into with this is in specifying how a
cache should decide if a request doesn't have to be passed through.
(Note that it doesn't have to be perfect to be useful -- for instance
it could insist on bitwise equality of the entity, even though POSTs
from different browsers may have the fields in different orders, and
so the logically same request might not "match" in the cache).

Also, I'd like to suggest we stay away from the word "idempotence"
which has caused much trouble in the past in this group.


--Shel

Received on Thursday, 4 January 1996 05:08:54 UTC