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

Re: idempotence of POST

From: Albert Lunde <Albert-Lunde@nwu.edu>
Date: Wed, 18 Sep 1996 21:50:21 -0500 (CDT)
Message-Id: <199609190250.AA151751421@merle.acns.nwu.edu>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1594
> In a discussion on html-wg@w3.org, the topic of GET vs. POST for
> sending form data was discussed. There are two issues:
> -  GET does not (at least in implementations) support a body
> -  POST requests are assumed to not be 'reload'able safely without
>        asking the user
> There are applications for requests that have a message body but are
> idempotent, e.g., a search with a complex form where the form data is
> too long to encode in a URL, or in which multipart/form-data is a more
> appropriate encapsulation.
> There are three suggested ways of accomplishing this:
> a) allow GET to take a body
> b) add a new method, GET-with-body (spelled how you like)
> c) allow the return value of POST to indicate that the request
>    can be repeated safely.
> (a) is an incompatible protocol change, at least for most
> implementations.
> (b) requires HTML forms that wish to request this action to
> say so directly, and so is also an incompatible change for HTML, if
> not for HTTP
> (c) is backward compatible.

(b) may be an advantage rather that a down-side: it lets servers 
announce in a very explict way that they can use the new method,
rather than trying some extension and having it fail.

I agree that (c) is backward compatible, in a sense. But you wouldn't
get this information in all cases unless we re-wrote the error
codes too, and idempotentence after failure might be as important
as after sucessess. Maybe another return header value?
Received on Wednesday, 18 September 1996 19:55:09 UTC

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