- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Mon, 1 Jul 2002 12:43:40 +0100
- To: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
FYI... I have just sent in the attached as Last Call commentary. Regards Stuart Williams -----Original Message----- From: Williams, Stuart Sent: 01 July 2002 12:38 To: 'xmlp-comments@w3.org' Subject: 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:44:02 UTC