Re: idempotence of POST
Albert Lunde (Albert-Lunde@nwu.edu)
Wed, 18 Sep 1996 21:50:21 -0500 (CDT)
>
> 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?