- From: Albert Lunde <Albert-Lunde@nwu.edu>
- Date: Wed, 18 Sep 1996 21:50:21 -0500 (CDT)
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> > 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