Re: idempotence of POST

> 
> 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?