LC Comments: Web Method Feature

I have a couple of comments about the implementation of the Web Method
feature in the HTTP binding in the Part 2 Specification.

<Comment>
Part 2 Table 15 [1] in the HTTP binding specification states that the HTTP
Method is set "According to the webmeth:Method property (typically POST or
GET)." This implies that correct operation of the HTTP binding *requires*
the *use* of the Web Method feature rather than merely the provision of the
feature by implimentations of the binding. I take the MUST in [2] to be a
statement about the provision rather than the use of the Web Method feature.

IMO it should be possible to use either of the Request-Response or
SOAP-Response MEPs without knowledge of the Web Method feature and that in
such circumstances the HTTP Method used should be POST and GET respectively.
This latter is behaviour is in line with the norm described in the narrative
in the final paragraph of part 2 section 6.4.3 [3] but is not evident as
default behaviour in the HTTP binding description.

Suggested Remedy
----------------
In the first row of Part 2 Table 15 [1], replace "According to the
webmeth:Method property (typically POST or GET)." with

"When the webmeth:Method property is present in the Message Exchange
Context, HTTP Method is set according to the value of the webmeth:Method
property (typically POST or GET). Otherwise, the HTTP methods used is POST
if the message exchange pattern in use is the <a href="...">6.2
Request-Response Message Exchange Pattern</a> ie.
context:ExchangePatternName is set to
http://www.w3.org/2002/06/soap/mep/request-response/ or the GET if the
message exchange pattern is <a href="...">6.3 SOAP Response Message Exchange
Pattern</a> ie. context:ExchangePatternName is set to
http://www.w3.org/2002/06/soap/mep/SOAP-response/."

More compact wording to similar effect or tabular presentation would be
acceptable.
eg for the first row of Table 15:
============+=========================+=================================
HTTP Method	|webmeth:Method used      | Set according to webmeth:Method
            +-------------------------+---------------------------------
            |Request-Response MEP &   | HTTP POST
            |(webmeth:Method not-used)| 
            +-------------------------+---------------------------------
            |SOAP-Response MEP &      | HTTP GET
            |(webmeth:Method not-used)|
============+=========================+==================================
</Comment>

<Comment>
A related issue is that despite the sentence at [4], the paragraph at [3]
does not give full account of the usage of the Web Method feature in
combination with either the Request-Response or SOAP-Response MEPs for
example which if any of the following are allowed/disallowed:

a) MEP=Request-Response, webmeth:Method=GET
b) MEP=Request-Response, webmeth:Method=DELETE
c) MEP=SOAP-Response, webmeth:Method=POST
d) MEP=SOAP-Response, webmeth:Method=PUT
e) MEP=SOAP-Response, webmeth:Method=DELETE

Such "unusual" use is discouraged in [3] but to comply with [4] the spec
should be more explicit about the Web Method values that may be used with
particular MEPs, ie. PUT and POST with Request-Response and GET (any
others?) with SOAP-Response.

Preconditions about the 'legal' combinations of MEP and Method could be
expressed in the Web Method feature description.
</Comment>

Regards

Stuart Williams.
[speaking for himself only]
--
[1]
http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#tabreqstateinitfields

[2] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#http-suptfeatures

[3]
http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#webmethodstatemachine
"Applications SHOULD use GET as the value of webmeth:Method in conjunction
with the 6.3 SOAP Response Message Exchange Pattern to support information
retrievals which are safe, and for which no parameters other than a URI are
required; I.e. when performing retrievals which are idempotent, known to be
free of side effects, for which no SOAP request headers are required, and
for which security considerations do not conflict with the possibility that
cached results would be used. Except in unusual circumstances, other
operations SHOULD be performed using POST in conjunction with the 6.2
Request-Response Message Exchange Pattern. Other methods SHOULD not in
general be used. For example, use of PUT would suggest storing the SOAP
envelope Infoset as the created resource, as opposed to processing in the
manner required by the SOAP processing model."

[4] http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#bindfw
"In cases where multiple features are supported by a binding specification
the specifications for those features MUST provide any information necessary
for their successful use in combination; this binding framework does not
provide any explicit mechanism for ensuring such compatibility of multiple
features."

Received on Monday, 1 July 2002 07:40:13 UTC