GET and side-effects

Jeffrey Mogul writes:
	...
 > 
 > My vote is for "no GET/HEAD side effects except for retrieval charges."
 > 
 > -Jeff

I generally agree with what you said, but let me point out two things:

Thing 1. since forms can be submitted through the use of GET, it is
hard to legislate the no-side-effects rule.  I believe it is for this
reason that as a heuristic, caches typically do not cache the output
of GETs on URLs with '?' in them.  Note that with the scheme I
suggest, it would be possible (at least theoretically, if this
mechanism were exposed at the HTML level) to distinguish those GETs
that could cause side effects from those that couldn't, and thereby
improve caching of GETs with URLs containing '?', that might cause
side effects.  Either that or we have to do some fancy legislation
about forms submitted through GET being somehow fundamentally
different than those submitted through POST, which I think is skating
on thin ice.

Thing 2.  I don't especially care about the business with GETs.  What
I am interested in is being able to serve responses to
non-side-effecting POSTs from a cache.  This seems like a big win to
me.  Right now, the only way you might even get close to this is with a
"conditional POST", which isn't even really defined yet, and I'm not
even sure how Netscape or any caches treat it anyway. And that still
involves a trip all the way to the origin server and back, even if the
results aren't passed back.


Re: Cache-control:reload:  much better terminology!

--Shel

Received on Thursday, 4 January 1996 19:34:44 UTC