W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2007

Re: [SPAM] Re: CR148 analysis

From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
Date: Fri, 09 Feb 2007 16:30:46 +0100
To: Christopher B Ferris <chrisfer@us.ibm.com>
Cc: Mark Baker <distobj@acm.org>, Jacek Kopecky <jacek.kopecky@deri.org>, Jonathan Marsh <jonathan@wso2.com>, WS-Description WG <www-ws-desc@w3.org>, xml-dist-app@w3.org
Message-id: <45CC93A6.9030902@crf.canon.fr>

+1 to Jacek's suggestion + we should not even use Content-Type with 
SOAP-Reponse (for the inbound message).

Chris, your XML is ill-formed. ;-)

JJ.

Christopher B Ferris wrote:
>
> <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
> >
Received on Friday, 9 February 2007 15:31:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:23 GMT