- From: Ian Clelland <ian@veryfresh.com>
- Date: Fri, 28 May 2004 23:59:32 -0700
- To: www-talk@w3.org
On Fri, May 28, 2004 at 09:14:54PM +0100, A Bagi wrote: > > Idempotence: the ability of a Document to be transmitted and accepted more > than once with the same effect as being transmitted and accepted once. This > somehow does not mean no side-effects (web applications, GET)! > Only idempotent requests can be pipelined, such as GET and HEAD requests > with maximum scucess. POST and PUT are dodgy business!! > Ahmed Bagi > Manchester If we're going by the way that things are *supposed* to be, then PUT isn't dodgy at all -- you should be able to submit the same PUT request a hundred times, and have the outcome be the same as submitting it just once. From the RFC: 9.1.2 Idempotent Methods Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent. Of course, in the real world, things may not be this clean. But, for that matter, neither are GET requests -- web applications routinely take parameters from URLs and do horrible, non-idempotent things with them. So from that perspective, GET is kind of dodgy too. Heck, even HEAD would have side effects in half of the server-side scripts that I've seen. I don't think it makes sense to leave poor PUT out of a pipelining application just because some developers might be abusing the HTTP protocol. There are already worse offences out there, that will break things much harder, than a non-idempotent PUT or two. Ian Clelland <ian@veryfresh.com>
Received on Saturday, 29 May 2004 03:00:15 UTC