axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject Re: [Axis2]Incorrect handling of SOAP Faults
Date Wed, 27 Jun 2007 04:31:44 GMT
Hi all!

Comments inline.

Eran Chinthaka wrote:
>> * 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


>> * 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message