[Web-SIG] Form field dictionaries

[Simon Willison]

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/