W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2003

Re: idempotence of POST

From: David Morris <dwm@xpasc.com>
Date: Mon, 24 Nov 2003 17:37:55 -0800 (PST)
To: Mark Baker <distobj@acm.org>
Cc: Dave Oxley <david.oxley@workplace-systems.plc.uk>, <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.33.0311241723200.20363-100000@egate.xpasc.com>



On Mon, 24 Nov 2003, Mark Baker wrote:


> In my experience, an idempotent POST is most desirable in the situation
> where a response is not, or may not be, available.  So signally it in
> a response after the fact seems nonsensical.  But perhaps there are
> other use cases I'm not familiar with.

Actually, idempotence is of no interest if a prior response doesn't exist
.. or more precisely .. knowledge of a prior request doesn't exist. If the
user-agent has no such knowledge, then idempotence isn't an issue for GET
or POST.

The SAFE protocol proposal allowed a server to signal that a particular
POST was itempotent and could be re-issued w/o user prompting with no
risk of data distortion. It also logically means that a user-agent didn't
have to submit the POST request to the server if it had a valid cached
response.

Safe POST was the best alternative we could conceive of for allowing a
logical GET w/body which is a desirable feature. For example:
a. There is an expectation of a finite length for URLs ... allowing a body
would have resolved those issues
b. In some application interactions, such as login, it is quite
undesirable to have the credential data included in a URL ...
 i. They tend to be easy to compromise on the user's workstation through
    interfaces such as the broser location field.
 ii. Encoded URLs usually appear in server log data ... in order
    to preclude such exposure applications tend to use POST
    requests which may not be needed otherwise
Etc.

Dave Morris
Received on Monday, 24 November 2003 21:01:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:25 GMT