Question

I’m connecting to web service using Axis 1.4. This service signals error by responding with SOAP envelope with error description and HTTP status code 202. The response looks like that:

<soap:Envelope>
<soap:Body>
 <TestResponse>
  <TestResult>wrong format</TestResult>
 </TestResponse>
</soap:Body>
</soap:Envelope>

The test response is described in WSDL:

  <s:element name="TestResponse">
    <s:complexType>
      <s:sequence>
        <s:element minOccurs="0" maxOccurs="1" name="TestResult" type="s:string"/>
      </s:sequence>
    </s:complexType>
  </s:element>

So, in my opinion everything is OK. The problem is, I don’t get that error message with Axis generated stub, receiving null instead. As I debugged, I’ve found the line in HTTPSender class line 705:

if ((returnCode > 199) && (returnCode < 300)) {
    if (returnCode == 202) {
        return inp;
    }
    // SOAP return is OK - so fall through
} 

It skips the code, that decodes SOAP envelope. So, finally, I’ve sent wrong request (it can be anything runtime, such as user password expired), I receive error description, but because I use Axis, I have no access to it and receive only null, which makes debugging very hard (the response I posted I’ve found using Wireshark).

My question is, is it bug or feature? Is the company that have made web service misusing HTTP status 202 or standard allows it and Axis is too primitive to support it? At best I would like to avoid coding communication manually using HttpClient from apache or anything similar….

Answer 1

That looks like a bug. The HTTP 202 Accepted status code is used to indicate that a request has been accepted, but further processing is required in order to complete it. The response should have a Location header representing a callback that can be made to the service, to check the request status, and an optional body with a descriptive message.

For a web service, I would expect that service implementors process the body response as long as its content matched the service contract (in this case the WSDL). But the implementors of Axis might have felt differently.

In any case, the vendor is incorrectly using 202 status codes to return errors, and that is a (big) part of the problem.