Re: CR148 analysis

<hat mode=not-chair">

Interesting.

There were those amongst us with the XMLP WG that at the time we were 
working on the SOAP Response
MEP wanted the request (HTTP GET) to be a "vrtual" SOAP envelope with no 
headers and no body and an
implicit "action" of "GET". the argument that some of us made at the time 
was that because SOAP was 
infoset based, that we could get away with that because we could establish 
what the infoset was for such
a message. There was some pushback that there would be subtle issues 
related to the infoset and that 
we would be better off if the request message of the SOAP Response MEP 
simply be an HTTP GET
sans SOAP envelope (physical or virtual).

So, technically, Mark is correct (in this member's opinion).

</hat>

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

xml-dist-app-request@w3.org wrote on 02/08/2007 11:17:10 PM:

> 
> There's no problem, per RFC 2616, with an HTTP GET request carrying an
> entity because the size of HTTP messages is self-descriptive
> independent of the request method.  But Content-Type is indeed an
> entity header, and so setting it to application/soap+xml - on any
> message - means that the sender intends the recipient to interpret the
> (null) entity as a SOAP envelope... which is prima facie incorrect as
> a zero length string is an invalid SOAP envelope.
> 
> Mark.
> 
> On 2/8/07, Jonathan Marsh <jonathan@wso2.com> wrote:
> >
> > Dear XMLP WG,
> >
> > Would you care to comment on this issue?  This is a case where we have 
a
> > "feature" with implementation support and obvious utility, yet it's 
not
> > clear whether it is in line with the intention of the SOAP Response 
MEP and
> > it's HTTP binding.
> >
> > http://www.w3.org/2002/ws/desc/5/cr-issues/#CR148
> >
> > Jonathan Marsh - http://www.wso2.com - 
http://auburnmarshes.spaces.live.com
> >
> >
> > > -----Original Message-----
> > > From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] 
On
> > > Behalf Of Jacek Kopecky
> > > Sent: Thursday, February 08, 2007 10:42 AM
> > > To: WS-Description WG
> > > Subject: CR148 analysis
> > >
> > >
> > > Hi all,
> > >
> > > it seems that in CR148, Canon and Axis2 have agreed to send
> > > content-type: application/soap+xml; action='...'
> > > in the GET request if using SOAP response MEP.
> > >
> > > I note that according to the HTTP RFC [1], content-type is an
> > > entity-header which appears with an entity body, or in the reply to 
HEAD
> > > where there is no entity body. GET requests don't transfer an 
entity,
> > > therefore they also don't have any entity headers.
> > >
> > > Additionally, the SOAP-Response MEP spec [2] says it is "a pattern 
for
> > > the exchange of a non-SOAP message acting as a request followed by a
> > > SOAP message acting as a response". I expect that a non-SOAP message
> > > should not be marked as application/soap+xml. There's a note just 
before
> > > 6.3.3 in the SOAP adjuncts that says "this MEP cannot be used in
> > > conjunction with features expressed as SOAP header blocks in the 
request
> > > because there is no SOAP envelope in which to carry them." I assume 
a
> > > similar intent also applies to the SOAP Action feature which is
> > > expressed as a parameter of the SOAP media type.
> > >
> > > While the behavior of the two implementations may not be harmful,
> > > I would say, from the two specs involved, that it's against the
> > > intention, even if I couldn't find a concrete MUST NOT there.
> > >
> > > I would suggest that our spec should be clarified to say that the 
{soap
> > > action} property is only used by messages that are, in fact, SOAP
> > > messages.
> > >
> > > Hope it helps,
> > > Jacek
> > >
> > > [1] http://www.faqs.org/rfcs/rfc2616.html
> > > [2] http://www.w3.org/TR/soap12-part2/#soapresmep
> >
> >
> >
> >
> 
> 
> -- 
> Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
> Coactus; Web-inspired integration strategies  http://www.coactus.com
>