RE: GET, POST, and side-effects

Paul Leach writes:
 > 
 > ----------
 > ] From: Shel Kaphan  <sjk@amazon.com>
	...
 > ]
 > ] It's mostly a thought experiment.  Due primarily to URL length
 > ] limitations, POST is often used where GET would semantically be sufficient.
 > 
 > I'd always assumed that they were always the same semantically, and 
 > that POST was invented primarily because of the length issue. So I must 
 > be confused. When can't
 > 	GET foo?x=y&a=b
 > be just as well implemented as:
 > 	POST foo
 > 	x=y&a=b
 > except for the length issue?
 > 
 > Paul
 > 

The GET can always be implemented as a POST -- you just get less
effective service from any caches in the chain.  But the POST couldn't
always be implemented as a GET (assuming a cachable response), since
the POST might have side effects that might be omitted if a GET were
handled entirely by a proxy cache.

You may get different answers from different people, but here's how I
look at it: as soon as someone decided it was OK for caches to respond
to GETs without communicating with the origin server, but that POSTs
had to be forwarded to the origin server, a semantic difference
appeared.  That decision meant that there was an assumption that GET
would not have side effects on the origin server, but that POST might.
We're about to create a middle ground by annotating certain POST
request/responses as being without side effects, and therefore OK for
a cache to respond to without contacting the origin server.

--Shel

Received on Saturday, 6 January 1996 00:43:01 UTC