nvpapworth 0 Posted March 2, 2012 Report Share Posted March 2, 2012 I'm relatively new to SOAP, so please forgive any lack of knowledge I should have... We have a server application with a SOAP interface, and the SOAP operation response data contains an element which is a complex type, which looks something like : <myResult code="123" description="invalid parameter NAME"> When (for any reason) the server fails to process, or reject a request, at the SOAP level, which results in a Fault element to be in the response, the client would also like to receive an appropriate application response data element like in <myResult> above. My question is this, when a response is sent (presumably with an HTTP response code of 500) containing a Fault element, is it allowed/recommended to ALSO include application level response data ? The Fault can/does contain enough information, basically the same information. For example, is this kind of response allowed, a basic Fault with a <myResult> element added : <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Server Error</faultstring> <detail> ... </detail> </SOAP-ENV:Fault> <myResult code="123" description="invalid parameter NAME"> </SOAP-ENV:Body></SOAP-ENV:Envelope> As background we are using gSOAP, and when a SOAP error occurs, a callback function is called, and the Fault element populated. What we may need to implement is something that grabs the <faultcode> and <faultstring> and puts this into the <myResult> element attributes, but I'm not sure if this is "allowed" or recommended... Quote Link to post Share on other sites
boen_robot 107 Posted March 2, 2012 Report Share Posted March 2, 2012 I'm not sure if it's allowed, but I'd assume it's not reccomended, as it's not a good idea to do that in general.It might be wise to split the functionality of this function into two functions - the error prone one, and the one that gets "just enough data", thus allowing consumers to uniformly handle this and any other error prone functions. Quote Link to post Share on other sites
nvpapworth 0 Posted March 2, 2012 Author Report Share Posted March 2, 2012 Thanks for that. It's a bizarre environment. The actual SOAP client application is bypassing the WSDL itself, and using an HTTP client to send generated SOAP envelope/body elements. Which means that, for example, in the WSDL it can say a parameter is 5-10 digits. But they can send 20 if they want and the server gets it. If they were using a proper client and WSDL I assume the client wouldn't even send it (and would generate a local error/fault). It's these kind of errors I need to trap. Just plain wrong in my opinion. Then they want an application error saying "parameter XXX is too long". gSOAP in this case is picking this up perfectly and sending a <Fault> back ! From what information I could find on <Fault> I didn't see anything that said anywhere that if included if must be the only thing in the <body> etc., which I was hoping to find. Quote Link to post Share on other sites
boen_robot 107 Posted March 2, 2012 Report Share Posted March 2, 2012 From the SOAP 1.2 spec on the Fault element: To be recognized as carrying SOAP error information, a SOAP message MUST contain a single SOAP Fault element information item as the only child element information item of the SOAP Body .So... if the SOAP client is SOAP 1.2 compatible, it shouldn't recognize a fault with an actual content. Quote Link to post Share on other sites
nvpapworth 0 Posted March 2, 2012 Author Report Share Posted March 2, 2012 Ah that's perfect. That's what I was hoping was in the specs somewhere, but I missed it. And that probably is why we couldn't find a way to do it, it's not valid ! Many thanks for your valuable time. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.