RE: mustUnderstand on client side

Hi Daniel,

> -----Original Message-----
> From: Daniel Barclay [mailto:Daniel.Barclay@digitalfocus.com]
> Sent: 03 May 2001 16:06
> To: xml-dist-app@w3.org
> Subject: Re: mustUnderstand on client side
> 
> 
> Henrik Frystyk Nielsen wrote:
> > 
> ...
> > We all know that HTTP defines a request/response model and when SOAP is
> > used in combination with HTTP, it can take advantage of that message
> > pattern. The HTTP model means that if the request fails, we know what to
> > do with the fault - send it back to the client.
> > 
> > If the client fails the response either by not understanding it or for
> > some other reason, there is no mechanism in HTTP to alert the server. 
> 
> Could that be handled by saying that when using the HTTP binding, the 
> client must perform another HTTP request and post the fault message?
> 
> Obviously there's the correlation/causality issue to address.  
> 
> Could that issue be handled by requiring the use of the HTTP 
> keep-alive option?  

I also have a notion that I haven't worked up much yet that the
causality/correlation thing could trigger the use of mechanisms like
cookies. Taking the abstract model notion of causality/correlation in an
XMLP/SOAP implementation at an HTTP client, an XMLP application sending a
message as a direct consequence of a message it previously received in via
an HTTP POST response, could use the Correlation.MessageRef parameter (see
abstract model) which would trigger the inclusion of any cookie received
with the earlier message.

This is just an embryonic thought. I have thought about how this would
operate through intermediaries and a whole raft of stuff. to be useful it
would probably also require an HTTP binding to take a view on the use of
cookies in SOAP.

Anyway, just a thought.

> Daniel
> -- 
> Daniel Barclay
> Digital Focus
> Daniel.Barclay@digitalfocus.com

Regards

Stuart

Received on Thursday, 3 May 2001 13:15:21 UTC