Re: Optional SOAP response; the transfer binding view

Mark Baker writes;

> 1) if a server/resource wants to interpret a message with no entity in
> some particular way, it should be allowed to ("The actual function
> performed by the POST method is determined by the server")
> 2) an HTTP message is self-descriptive with respect to message size,
> so there should be no issue with actually sending POST messages with
> no entity
> 
> It's a similar argument to the HTTP FAQ about why HTTP doesn't
> preclude GET requests from including an entity.

I never said POST without an entity didn't make sense in principle.  As I 
said in my earlier note, the HTTP RFC says:

"The POST method is used to request that the origin server accept the 
entity enclosed in the request as a new subordinate of the resource 
identified by the Request-URI in the Request-Line."

If the purpose is to accept the entity, then that comes pretty close to 
implying that the POST has no work to do if there is no entity.  So, I'm 
saying that it could have made sense, but the spec appears to rule it out.

No need to pursue this on my account, I just found it surprising.

> > Someone who knows more of the details will have to remind me how this
> > squares with application/x-www-form-urlencoded.
> 
> Not quite sure what you mean by that.

As I understand it, application/x-www-form-urlencoded is usually done with 
a POST with no entity.  If you take the above interpretation that the 
whole purpose of POST is to process the entity, then that's a bit 
surprising. As I say: it all makes perfect sense in principle, I was just 
surprised to see RFC 2616 referring so specifically to the entity as 
opposed to operating more broadly on information provided with the POST 
(such as the Request URI).

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Friday, 13 January 2006 22:24:44 UTC