Re: HTTP 1.1 pipelining

Thank you Ian and sorry PUT! The real world can be harsh!
----- Original Message ----- 
From: "Ian Clelland" <>
To: <>
Cc: "A Bagi" <>
Sent: Saturday, May 29, 2004 7:56 AM
Subject: Re: HTTP 1.1 pipelining

> On Fri, May 28, 2004 at 09:14:54PM +0100, A Bagi wrote:
> >
> > Idempotence: the ability of a Document to be transmitted and accepted
> > than once with the same effect as being transmitted and accepted once.
> > 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
> <>

Received on Saturday, 29 May 2004 03:38:09 UTC