- From: David Morris <dwm@xpasc.com>
- Date: Thu, 2 Sep 2010 13:49:01 -0700 (PDT)
- To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
On Thu, 2 Sep 2010, Darrel Miller wrote: > In the description of POST here [1], it starts with: > > "The POST method is used to request that the origin server accept the > representation enclosed in the request as data to be processed by the > target resource." > > This seems to infer that it is expected that a POST include a body. Is it > required to have a body? Is it unreasonable to expect a client to issue > > POST http://example.org/tokens > > ...and expect a token to be created, despite the fact that no representation > is passed to the origin server? Nothing is said in the description of POST re. creating anything. It says "processed by the target resource". I can't conceive of why an empty body would be an error. It is up to the processing resource to make that determnation, not the HTTP protocol. > > Taking this a step further, is the use of query string parameters instead of > a post body considered a valid request. Could a client make the following > request? > > POST http://mapservice.org/Waypoints?latitude=51&longiitude=114 Perhaps not common usage when combined with an empty body, but from a protocol perspective, the query string parameters are just part of the URL. I've worked with a number of platforms over the years which make it easy to just treat query string name value pairs and name value pairs in the POST body as a single name space such that the resource processing logic author need not care how the values were transported. In some cases, I had to look hard to determine how a value was transported. But I don't see any protocol issue with the above URL. > I realize this is not a common usage, but my question is whether this is > prohibited by the HTTP specification, whether it is discouraged due to > negative impacts, or whether it a reasonable usage that is just not clear > from the description of POST. > > Thanks for your time, > > Darrel Miller > > [1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-11#page-17 > > > >
Received on Thursday, 2 September 2010 20:49:41 UTC