- From: Shel Kaphan <sjk@amazon.com>
- Date: Fri, 5 Jan 1996 16:24:26 -0800
- To: Paul Leach <paulle@microsoft.com>
- Cc: http-caching@pa.dec.com
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