Re: Issue 133, and permitting no body

 Mark,
 I'm not sure what you mean by "web architecture", because I 
thought we have yet to see that. 8-)
 Anyway, from SOAP-centric point of view, a transport binding 
specifies means of getting SOAP messages from one node to 
another.
 I think that your proposal (of making the Body optional) should 
come from a use case independent of any particular protocol 
binding, not from some unusual but possible use of GET method in 
HTTP.
 Do you have any use case for Body-less messages that is 
independent of HTTP?
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Wed, 30 Jan 2002, Mark Baker wrote:

 > Hi all,
 > 
 > I had a thought recently, about an extension to our SOAP/HTTP binding
 > to support the GET method.  I'm *not* suggesting we incorporate this
 > into the spec, only that we consider its needs going forward, as it
 > requires a change to the current envelope schema.
 > 
 > AFAIK, no use of HTTP GET today includes a body, though RFC 2616 doesn't
 > preclude one from being used.  But, it defines no behaviour for what the
 > body should mean, except implicitly in the definition of GET that it
 > can't change the meaning of the GET (i.e. can't use the body to change
 > what the Request-URI identifies).
 > 
 > So, if we used the GET body to carry header information, specifically
 > SOAP headers, we could use GET in a web architecture friendly manner.
 > What that means is that a GET binding could permit an envelope in a GET
 > body, but that envelope would have to be all headers, no body.  However,
 > currently, the envelope schema requires that there be at least one body.
 > 
 > Would we consider making this change to the envelope to support GET in
 > the future?
 > 
 > Note that this may help address issue 133.
 > 
 > MB
 >

Received on Wednesday, 30 January 2002 14:51:47 UTC