- From: Laird Nelson <ljnelson@yahoo.com>
- Date: Mon, 27 Aug 2001 12:37:05 -0700 (PDT)
- To: xml-dist-app@w3c.org
--- "Jones, Matthew" <MJones@NetSilicon.com> wrote: > It never seemed to me that post was particularly for updating an > object. > Perhaps that is implied by a content type of multipart file upload, > but for > url form encoded I wouldn't infer > update-this-resource-please-oriented. Why not? Thus speaketh the RFC: "The POST method is used to request that the destination server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: * Annotation of existing resources; * Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; * Providing a block of data, such as the result of submitting a form [3], to a data-handling process; * Extending a database through an append operation." > Many search requests and other requests (ie stock price) use post. I > always > inferred that post was supposed to be more general than get. That's certainly how it's *now* used (i.e. for both update and retrieval purposes), largely because, as you quite rightly point out, there's no commonly imposed limit on the payload of a POST request. But I think that the RFC shows that that's not what it was intended for (although it certainly seems to serve that purpose quite well). Whether SOAP decides to follow HTTP's existing practices or its intended design is probably not that big an issue, but it should probably do one or the other knowing what it's *not* doing. :-) Cheers, Laird ===== -- ljnelson94@alumni.amherst.edu ljnelson@yahoo.com Good, cheap, fast: pick two. __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
Received on Monday, 27 August 2001 15:37:06 UTC