You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Andrea Smyth <an...@iona.com> on 2007/04/16 17:30:26 UTC
Client not decoding soap fault
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.
RE: Client not decoding soap fault
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> Sent: 16 April 2007 20:06
> To: cxf-dev@incubator.apache.org
> Subject: RE: Client not decoding soap fault
>
>
>
> for the default behaviour (which I think should be
> SYNC_WITH_TARGET, as a CXF client wouldn't necessary know a
> priori that the server-side is also CXF and thus supports
> this idea of variable sync points).
Slip of the mind/keyboard there, I meant to write that the default
should be the equivalent of SYNC_WITH_*TRANSPORT*, i.e. that the payload
has been written sucessfully to the wire.
/Eoghan
RE: Client not decoding soap fault
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Sortta reminds me a bit of the CORBA SyncScope policy whereby the client
app can control the sync point for oneways, and thus have confidence
that the oneway has been successfully delivered as far as the local
transport, or the server-side runtime, or even all the ways up to the
target (in which case the oneway is effectively treated as a twoway).
Sounds like we use we use an odd amalgam of different sync points,
depending on whether where the fault is thrown and whether addressing is
in use.
Now we could invent a new policy to allow this to be controlled
explicitly, but what's there currently (in the absence of addressing)
doesn't sound like a good candidate for the default behaviour (which I
think should be SYNC_WITH_TARGET, as a CXF client wouldn't necessary
know a priori that the server-side is also CXF and thus supports this
idea of variable sync points). Also it doesn't make a great deal of
sense to return a fault payload on the wire only for this to be ignored
for the client-side runtime ... better IMO to simply to log the issue on
the server-side by default.
Cheers,
Eoghan
> -----Original Message-----
> From: Andrea Smyth [mailto:andrea.smyth@iona.com]
> Sent: 16 April 2007 17:08
> To: cxf-dev@incubator.apache.org
> Subject: Re: Client not decoding soap fault
>
> Andrea Smyth wrote:
>
> > 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><soa
> >
> p:Fault><faultcode>soap:Server</faultcode><faultstring>FaultThrowingIn
> > terceptor
> > 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 addressing is used, and the fault throwing interceptor
> executes after the logical addressing interceptor, the client
> does not receive a Fault at all. The reason is that the
> partial response has already been sent (from within the
> logical addressing interceptor), so all faults occurring
> after that are practically ignored and the client has no idea
> that the actual invocation on the server never occurred.
> I don't believe this is correct either. At the very least it
> is not consistent with the non-addressing case where the
> client can surround the oneway invocation with a catch(Fault
> ...) clause.
> BTW an example of such an interceptor would be the logical RM
> interceptor, which executes after the logical addressing interceptor.
> Also, I am not quite sure how to interpret the following
> extract from the addressing spec:
> http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#msgaddrprops
>
> >>In a one-way interaction pattern a source sends a message
> to a destination without any further definition of the interaction.
> "Request-response" is a common interaction pattern that
> consists of an initial message sent by a source endpoint (the
> request) and a subsequent message sent from the destination
> of the request back to the source (the response). A response
> in this case can be either an application message, a fault,
> or any other message. Note, however, that reply messages may
> be sent as part of other message exchanges as well, and are
> not restricted to the usual single Request, single Response
> pattern, or to a particular WSDL transmission primitive or
> MEP. The contract between the interacting parties may specify
> that multiple or even a variable number of replies be delivered.<<
>
> I would tend to read it as: even if the operation is oneway,
> the contract between the interacting parties may mandate the
> use of RM, and as such require that e.g. non-existent
> sequence ids result in SoapFaults with prescribed fault code.
> The question is: does this go as far as mandating the sending
> of that fault back to the client, or is it sufficient to log
> such an error on the server side?
>
> Andrea.
>
> >
> > 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.
>
>
Re: Client not decoding soap fault
Posted by Andrea Smyth <an...@iona.com>.
Andrea Smyth wrote:
> 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 addressing is used, and the fault throwing interceptor executes after
the logical addressing interceptor, the client does not receive a Fault
at all. The reason is that the partial response has already been sent
(from within the logical addressing interceptor), so all faults
occurring after that are practically ignored and the client has no idea
that the actual invocation on the server never occurred.
I don't believe this is correct either. At the very least it is not
consistent with the non-addressing case where the client can surround
the oneway invocation with a catch(Fault ...) clause.
BTW an example of such an interceptor would be the logical RM
interceptor, which executes after the logical addressing interceptor.
Also, I am not quite sure how to interpret the following extract from
the addressing spec:
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#msgaddrprops
>>In a one-way interaction pattern a source sends a message to a
destination without any further definition of the interaction.
"Request-response" is a common interaction pattern that consists of an
initial message sent by a source endpoint (the request) and a subsequent
message sent from the destination of the request back to the source (the
response). A response in this case can be either an application message,
a fault, or any other message. Note, however, that reply messages may be
sent as part of other message exchanges as well, and are not restricted
to the usual single Request, single Response pattern, or to a particular
WSDL transmission primitive or MEP. The contract between the interacting
parties may specify that multiple or even a variable number of replies
be delivered.<<
I would tend to read it as: even if the operation is oneway, the
contract between the interacting parties may mandate the use of RM, and
as such require that e.g. non-existent sequence ids result in SoapFaults
with prescribed fault code. The question is: does this go as far as
mandating the sending of that fault back to the client, or is it
sufficient to log such an error on the server side?
Andrea.
>
> 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.