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

Re: HTTP working group status & issues (please reply)

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Fri, 27 Sep 1996 13:04:29 -0500 (EST)
To: yjj@rad.balink.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <01I9Z2ZTE0WY0089K5@SCI.WFBR.EDU>
"Y. John Jiang" <yjj@rad.balink.com> wrote:
>On Sep 27,  1:10pm, Maurizio Codogno wrote:
>> Subject: Re: HTTP working group status & issues (please reply)
>>
>> % - GET-with-body or idempotent-POST
>> %   Discussed on the working group; there seems to be enough
>> %   demand, but not a lot of clarity on the solution.
>> %   *** I'd like a brief note from you about your opinion,
>> %       especially if you haven't responded on this before.
>>
>> I personally don't like very much an idempotent-POST: if I have an
>> incremental database, POSTing twice should result in two record added.
>
>Agree.  POST is intended to have something posted/added to the
>server content.  A cache should never intercept such a request
>and acts on behalf of the server.  If POST is used to give fairly
>static responses, it's rather a misuse of the method, and the
>protocol should not be modified to accomodate the misuse.

	POST originally became widely used in conjunction with the
development of FORMs, and its intent in that case was to provide a
means of passing a greater amount of data associated with filling
out the FORM than is feasible by appending it as a ?searchpart to
the URI designated as the FORM's ACTION.  This does not necessarily
add server content in the sense you mean.  A script may simply parse
the submitted content, as it would the ?searchpart if the METHOD had
been GET, and not retain that content, nor change any other.  I
suspect this is still the predominant use of POST, and will remain
so for some time to come.  That is, in many cases, the POST *is*
idempotent, despite the present requirement to assume that it is
not.  The proposal is not simply to treat POST as idempotent, but
to provide a means of indicated when it is, rather than *always*
require the, often false, assumption that it is not.

	This ability would be extremely useful for clients seeking
to implement aspects of the recently approved i18n RFC (not yet
edited and assigned an RFC number, but on its way 8-).

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
Received on Friday, 27 September 1996 10:12:20 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:14 EDT