Re: wsa:To -> SOAP1.2's ImmediateDestination

On 23/08/2005, at 8:48 PM, Mark Baker wrote:

>> Consider the following scenario:
>>
>> SH1 -> H2 -> SH3 -> SH4
>>
>> where:
>> SH1 is a SOAP/HTTP node, the initial SOAP sender
>> H2 is a HTTP cache
>> SH3 is a SOAP/HTTP node, a SOAP intermediary
>> SH4 is a SOAP/HTTP node, the ultimate SOAP receiver
>>
>> Using the current HTTP binding, I'd expect the HTTP request URI for
>> SH1 -> H2 -> SH3 to be the HTTP URI for SH3 (*not* SH4). I'd expect
>> the HTTP request URI for SH3 -> SH4 to be the HTTP URI for SH4. I.e.
>> there would be two different HTTP request URIs for the single SOAP
>> message path. If WS-Addr were used then I'd expect the value of the
>> [destination] message addressing property to be the HTTP URI for SH4
>> so there'd be a clear difference between the value of [destination]
>> and the HTTP request URI at SH1.
>>
>
> Yes, I understand that to be your (and others) positions.  I believe
> that position is inconsistent with the HTTP specification, and
> possibly inconsistent with the SOAP specification (per the ambiguity
> over what ImmediateDestination means).
>
> My position, as you summized, is that the SH4 URI goes in the
> Request-URI, as that's the only interpretation consistent with HTTP
> semantics; the node identified by the Request-URI provides the
> response.
>

Mark,

How is that inconsistent with the HTTP specification / semantics?  
Irrespective of SOAP, there are many examples where applications have  
a concept of a message path that's greater than the end-to-end HTTP  
connection. E.g., Akamai and similar "reverse proxies" will act as  
the origin server -- i.e., the request-uri is addressed to them --  
but they will forward the request to another server based on internal  
configuration and/or message attributes.


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Wednesday, 24 August 2005 21:55:05 UTC