W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

Re: Issue 133, and permitting no body

From: Jacek Kopecky <jacek@systinet.com>
Date: Wed, 30 Jan 2002 20:51:44 +0100 (CET)
To: Mark Baker <distobj@acm.org>
cc: <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0201302044020.23272-100000@mail.idoox.com>
 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 
 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 
 Do you have any use case for Body-less messages that is 
independent of HTTP?
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:45 UTC