Client not decoding soap fault

[Andrea Smyth]

If a server-side in-interceptor throws a Fault when processing the 
inbound (soap) message for a oneway request, I can,  using the 
LoggingOutInterceptor,  see that a soap fault is sent back to the client:
INFO: Outbound message: <soap:Envelope 
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>FaultThrowingInterceptor 
interceptor failed to handle 
message.</faultstring></soap:Fault></soap:Body></soap:Envelope>

But the client does not decode the fault and simply throws a Fault (as 
opposed to a SoapFault) with code: "COULD_NOT_SEND", and message: "Could 
not send Message. (and a wrapped IOException: Server returned HTTP 
response code: 500 for URL: ...).

If the message is twoway, the client receives a SoapFault, with 
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server and the 
expected reason.

Is this intended behaviour? IMO it is not correct, considering that in 
the first case the correct fault code and faultstring is available it 
should as well be decoded so the client gets a idea of what went wrong 
on the server side. In particular, I think the soap fault should be 
decoded to correctly implement fault handling in addressing and rm, 
where server side interceptors may fail because of duplicate message 
ids, duplicate sequence ids, etc. which can occur in the context if both 
oneway and twoway requests.

Andrea.