|>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-BakerNot Speaking for anyone else.