- From: Fisher Mark <FisherM@is3.indy.tce.com>
- Date: Thu Sep 19 07:12:31 1996
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Of the 4 suggested functions to be accomplished by POST (from the 8/15 HTTP
1.1 draft):
o Annotation of existing resources;
o Posting a message to a bulletin board, newsgroup, mailing list, or
similar group of articles;
o Providing a block of data, such as the result of submitting a form,
to a data-handling process;
o Extending a database through an append operation.
3 of them definitely relate to adding information to a resource (annotation,
message posting, database append). This is inconsistent with (c):
>c) allow the return value of POST to indicate that the request
> can be repeated safely.
Furthermore, in order for (c) to work correctly, clients will have to be
upgraded so that they know that POST can be repeated safely. As an example,
Netscape Navigator would continue to warn users about re-POSTing forms
without this upgrade.
As a final note, clients and servers both will need to be upgraded for i18n,
where this problem originated (submission of forms by non-ISO-8859-1
clients).
For these reasons I think that the goal of backwards compatibility should be
sacrificed in favor of the consistency of the definitions of GET and POST.
A GET-with-body (spelled however :)) would be more consistent with the
current definitions of GET and POST than allowing POST to be idempotent.
======================================================================
Mark Leighton Fisher Thomson Consumer Electronics
fisherm@indy.tce.com Indianapolis, IN
Received on Thursday, 19 September 1996 07:12:31 UTC