W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: idempotence of POST

From: Daniel DuBois <dan@spyglass.com>
Date: Thu, 19 Sep 1996 02:06:23 -0500
Message-Id: <>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1597
>Sorry - I don't have an idea to contribute for syntax either.

Seems we come back to this topic fairly often.  If we wrote it, will they come?

Idempotent: yes
Idempotent: no

9.1.2 Idempotent Methods

Methods may 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 are assumed to have this property by default.  If a particular
response has a Idempotent header field, the default idempotent nature of
that method for that Request-URI is over-ridden.  User agents SHOULD
remember the idempotent nature of requests they make if they have any
automatic retry facilities that make the handling of idempotence an issue.
14.24 Idempotent

The Idempotent response header field is used to indicate to user agents the
idempotent nature of an individual method/request-URI pair.

      Idempotent = "Idempotent" ":" idempotent-nature
      idempotent-nature = "yes" | "no"

An example of the field is:

       Idempotent: yes

Typically in HTTP/1.2, GET, HEAD, PUT and DELETE are the only methods
assumed to be idempotent (See 9.1.2).  However, some web servers may attach
special significance to methods that are normally idempotent, and can use
the Idempotent header field with a "no" value to warn the user of the
presence of abnormal implications of repeated requests for that resource.
Similiarly, a particular server may attach no special significance to a
request made with a method that is normally not idempotent.

    Note:  In particular, an example of this would be one of the numerous
    web indexing search services that uses the POST method to handle large
    amounts of query data that might not be desirable to have embedded in a
    URL for a GET requests.  Usually that search request on that resource
    can be made numerous times without any implications to the user, and a
    user agent that recognizes this idempotence need not bother the user
    with confirmation prompts for those subsequent additional requests.

Daniel DuBois, Traveling Coderman         
Received on Thursday, 19 September 1996 00:11:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:20 UTC