Incorrect hadling of SOAPFaults
-------------------------------
Key: AXIS2-2933
URL: https://issues.apache.org/jira/browse/AXIS2-2933
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Reporter: Thilina Gunarathne
Priority: Critical
As per the discussion in the following thread...
http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200706.mbox/[EMAIL
PROTECTED]
Proposed resolution is to introduce SenderFault & ReceiverFault classes and use
them properly...
Following is a extract from the conversation...
>> * Further debugging showed me Axis2 defaults to FaultCode Sender if
>> the faultcode is null and if the there isn't a SOAPEnvelope (line 484-
>> MessageContextBuilder), which is the exact case when throwing an
>> exception from the messageReceiver...
>
> Yes this I did intentionally. The reason is that if there is no fault
> code, what will be the default fault code? When I was writing this code
> I searched this in SOAP 1.2 spec[1] and WS-I BP also but couldn't find one.
> So I assumed whatever the service implementation is always correct and
> it is client that is always wrong if there is a problem :). Well you
> have to make either the sender or receiver guilty if you have to guess
> at one point. So I selected to make sender guilty.
I'm not sure it's a huge deal, but I think this was the wrong decision.
The Sender fault code indicates to the sender that there's a good chance
that if they were to fix some problem in their message and try again,
the request might succeed. In the case of a random fault thrown by some
component in the Axis2 processing chain, I don't think we have any such
knowledge. There are really two issues here - one is that we SHOULD
make it easier to be more clear about whether a fault is due to sender
error or a server problem. The second is what we should do when we
really have no idea. I think this is exactly equivalent to what Tomcat
or Apache have to do when a generic exception is caught - the answer
there is typically an HTTP 500 "General Server Error" or the like. The
SOAP equivalent is not a Sender fault, but a Receiver one, so I think
that should be our default.
As for the issue of ease-of-use, perhaps we should consider extending
AxisFault with a "SenderFault" class (which would set the fault code
explicitly to Sender), and then custom exceptions which had to do with
bad data could extend or throw that? I.e.
class MyMessageReceiver {
public invokeBusinessLogic() {
if (value > max) throw new SenderFault("Out of range!");
if (somethingElseBad) throw new AxisFault("Failed");
}
}
>> * Then in the AxisServlet (line 385) when using SOAP12 we are setting
>> the response http status code to BAD_REQUEST(400) if the FaultCode is
>> sender which was the result of the SOAPFault with http-400...
>
> According to RFC2616 HTTP 400 is the correct HTTP status code if the
> fault is with the client. Also according to SOAP 1.2 HTTP binding[2]
> status code should be 400 when the fault code is Sender
+1
>> * Axis2 client does not process the body of the message if the http
>> status code is 400...
>
> I think this can be a bug in Axis2 code as status code 400 doesn't mean
> it should not process this.
+1, we should definitely be looking for SOAP faults unless there's a
known code like 404. But we need to make sure we handle HTML responses
from servers too if at all possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
