axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <g...@thoughtcraft.com>
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

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

Thanks,
--Glen

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message