- From: Doug Bunting <db134722@iplanet.com>
- Date: Tue, 26 Nov 2002 14:20:01 -0800
- To: Mark Baker <distobj@acm.org>
- Cc: Ugo Corda <UCorda@SeeBeyond.com>, www-ws-arch@w3.org
- Message-id: <3DE3F391.6000107@iPlanet.com>
No, we're going to recognize that all POST operations are not necessarily not idempotent. GET is in reality used for requests that are both idempotent and able to be sent without additional information besides HTTP headers. POST is in reality used for requests that are not idempotent or require additional information or were set up against a random site developer's (possibly misguided) whim. That said, I'd agree knowing the HTTP method is enough to know whether the response is cacheable using existing proxies. I'm not entirely certain how an idempotent attribute independent of the method helps the requester. What would that software due with this proposed attribute? thanx, doug Mark Baker wrote: >Hi Ugo, > >On Tue, Nov 26, 2002 at 11:26:52AM -0800, Ugo Corda wrote: > > >>I have the impression that Hugo wanted to also address cases where POST is used instead of GET (because, for example, headers are to be specified), but still the operation is idempotent. So just looking at the method would not sufficient to tell whether the operation is idempotent or not. >> >> > >Looking at the method will *always* be enough to know whether it's >idempotent or not. POST is not idempotent, by definition. PUT is >idempotent, as is GET and DELETE, also by definition. They have >their own standalone meanings, and nothing in the body of the message >can change that. > >(uh oh, are we going to have to get into the "HTTP isn't a transport >protocol" issue again? 8-) > >MB > >
Received on Tuesday, 26 November 2002 17:20:50 UTC