[
https://issues.apache.org/jira/browse/AXIS2-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deepal Jayasinghe reassigned AXIS2-2933:
----------------------------------------
Assignee: Glen Daniels
> 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
> Assignee: Glen Daniels
> 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]
