[6628] in www-talk@info.cern.ch
Re: An alarming trend in METHOD=POST forms (an FYI)
daemon@ATHENA.MIT.EDU (Phillip M. Hallam-Baker)
Mon Nov 14 07:09:47 1994
Date: Mon, 14 Nov 1994 12:47:55 +0100
Errors-To: listmaster@www0.cern.ch
Reply-To: hallam@dxal18.cern.ch
From: hallam@dxal18.cern.ch (Phillip M. Hallam-Baker)
To: Multiple recipients of list <www-talk@www0.cern.ch>
In article <9289@cernvm.cern.ch> you write:
|>I think the guiding principle here is that GET must be idempotent.
|>That is, when you use GET,
|>
|> You don't change anything in thw webor anywhere else
|> You don't commit yourself to anything (except cost of access)
|> You always get the same logical resulf for the same URL
|>
|>These are really useful design criteria which allow one to
|>make important deductions. As an arbitrary example, you can
|>
|> Cache the result of a GET
|> Preemtively look-up the result of a GET on behalf of someone
|>
|>I said logical above because things like "the state of the coffee
|>pot" is a time-dependent thing though always logically the same.
One case in point I wrote a bit of code the other day that added a link
into a link database through a series of forms. Only there was a small snag,
if the form was reloaded the link was entered again!
This provides a bit of a problem, I want the behaviour to be such that a POST
performs an action but a GET merely reports the previous sucess code. Its
quite easy once you realise the problem but otherwise "you are toast".
Suprious GETs can occur very easily as a result of the history cache
being exhausted and a person using forward/backward too often...
--
Phillip M. Hallam-Baker
Not Speaking for anyone else.
