RE: [soapbuilders] mustUnderstand on client side

The basic SOAP processing model described in [1] doesn't know about
servers or clients but only "SOAP processors" which is the reason why
SOAP in general walks a fine line when talking about *generating* a
fault vs. *sending* a fault. The latter is only mentioned in the HTTP
binding and the RPC convention as these two talk about "requests" and
"responses". That is, SOAP distinguishes between generating a fault and
sending a fault message somewhere.

Within the context of a request/response model, I think the right thing
for an HTTP client that cannot accept/obey the SOAP message semantics is
to fault the processing or to suggest that the message is saved for
later processing by a more savvy processor. The latter is similar to
what clients do when receiving a response with an unknown media type.

It is important that a SOAP processor doesn't break the processing model
and merely ignores the SOAP rules just because it may not be in a
position where it can notify the sender about the fault.

Henrik

[1] http://www.w3.org/TR/SOAP/#_Toc478383491

Doug Davis wrote:
>
>I see 3 choices:
>  1 - ignore it
>  2 - fault back to the server
>  3 - fault back to the client
>
>While 2 is probably what "should" happen, I doubt many
>will be able to support this.  1 seems most likely, but
>scares me.  3 seems like a nice middle of the road solution.
>8-)
>
>Paul Kulchenko wrote:
>
>Since it's possible to return Header from server to client 
>also, what should client do if this header has mustUnderstand 
>attribute or wrong actor?

Received on Sunday, 22 April 2001 22:12:32 UTC