Re: CR148 analysis

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 <[email protected]> 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: [email protected] [mailto:[email protected]] 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