RE: GET, POST, and side-effects

On Thu, 4 Jan 1996, Paul Leach wrote:

> I agree -- a POST in general has to go back to the origin server. 
> Although see my "sine server" for a case where it doesn't.

I must be truly dense ... why wouldn't the sine server be implemented
with GET?

POST has a long standing important semantic in terms of user expectations
and their interpretation by UAs. Netscape at least understands this
distinction.

method=POST of a form data prompts the user for confirmation that re-POST
is intended.  method=GET of a form does not.

It is quite reasonable to use method=GET for a form ... the discussion
was had ages ago and it distresses me that we are using this much
time to rehash the issue of GET vs. POST.

A GET is not required to return the same result each time.  The requirement
is that the GET REQUEST itself cause the repeated result to differ.
There is established tolerance for reference counts being updated or
as Jeff suggested a retrieval charge to be imposed perhaps.

Two POSTs in a row may return different results or have other sideeffects
(like getting two bags of HEX bolts). 

By choosing the FORM's method, the author is declaring the expected 
side-effects from FORM submission. A GET can easily be a complex data
base search so a FORM with METHOD=GET is quite rational.

With Shel's proposed default behavior, I guess expectations wouldn't 
break from a cachablility perspective, but the currently endorsed
browser behavior of advising users before resubmitting a POST 
would seem to be confused.

So I'm still trying to understand why the application would choose
POST and not GET. If the concern is transfer methodology, that is
send via URL or entity body, perhaps that should be addressed more
explicity by a new method or FORM attribute. As has already been pointed
out, managing the cache of POST requests is potentially more difficult.

Dave Morris

Received on Friday, 5 January 1996 05:48:15 UTC