- 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
"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 UTC