[Web-SIG] Form field dictionaries
Simon Willison
cs1spw at bath.ac.uk
Fri Oct 24 22:44:57 EDT 2003
Gregory (Grisha) Trubetskoy wrote:
> For everyone's amusement, here is last two out of the three paragraphs of
> this section:
>
> In particular, the convention has been established that the GET and
> HEAD methods SHOULD NOT have the significance of taking an action
> other than retrieval. These methods ought to be considered "safe".
> This allows user agents to represent other methods, such as POST, PUT
> and DELETE, in a special way, so that the user is made aware of the
> fact that a possibly unsafe action is being requested.
>
> Naturally, it is not possible to ensure that the server does not
> generate side-effects as a result of performing a GET request; in
> fact, some dynamic resources consider that a feature. The important
> distinction here is that the user did not request the side-effects,
> so therefore cannot be held accountable for them.
>
> At first I thought this was completely wacky and didn't belong in an RFC
> at all. But having read it a couple of times, I'm thinking that they are
> referring here to *browser implementations*, not web apps, so I don't
> think it's relevant to our discussion.
I understand it to be a recommendation to developers of server side
applications. It's saying "don't write apps that do something other than
just blindly serve up content on a GET or HEAD" - in other words, only
modify data stored on the server (the classic example being altering
data in a database) in a POST or PUT request. Obviously this doesn't
mean you shouldn't do anything dynamic on GETs, it just means that a
user GETing a resource shouldn't result in a permanent change to the
state maintained by the server.
--
Simon Willison
Web development weblog: http://simon.incutio.com/
More information about the Web-SIG
mailing list