RE: [i95, i22] - Proposal for clarifying use of SOAPAction

We are currently using SOAPAction in what I thought was its definition and
will continue to do so since we currently have no interop issues. However,
for the future there will be interop issues so this has to be resolved. We
certainly don't want to go with tying a service to a url 1-2-1.

Philip Painter
Technology Consultant
Compaq Computer Limited
Warrington UK
Philip.Painter@compaq.com
Desk: +44 (0)1925 841233
Mobile: +44 (0)7790666784



-----Original Message-----
From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
Sent: 04 May 2001 01:05
To: 'Daniel Barclay'
Cc: xml-dist-app@w3.org
Subject: RE: [i95, i22] - Proposal for clarifying use of SOAPAction



>> An HTTP client MUST use this header field when issuing a SOAP HTTP
>                      ^^^
>"Use" is ambiguous.  (It might imply reading an existing header, not 
>providing the header.)   Use a more specific word: "provide," "attach,"
>"generate," etc.

"generate" is good

>> ...
>> The value of the SOAPAction header field is a URI-reference 
>as defined 
>> by RFC 2396. The URI can be either absolute or relative. If the 
>> SOAPAction URI is a relative URI, it is interpreted relative to the 
>> Request-URI.
>
>Should that URI-reference really be resolved?  
>(I'm not clear on the intent, whether the URI-reference should 
>really be resolved with the request-URI, or whether both are 
>available for deciding how to dispatch the request.

Whether it is expanded or not is up to the server - all this says is
that the base URI is the request URI so that we know what relative URIs
means in this place. The absolutization mechanism is the one described
in RFC 2396 and which you give examples of below.

The same is the case for most other URIs in HTTP header fields btw.

>Will the SOAP/XMLP processor otherwise have access to the URI to which 
>the HTTP POST request was sent?   Should it be using that URI for 
>anything?  

As is indicated in the text it may use it.

Thanks!

Henrik

Received on Friday, 4 May 2001 10:01:49 UTC