Axis 1.4 не декодирует конверт SOAP, когда HTTP-статус 202 - ошибка или функция? - PullRequest
Новая
       44

Axis 1.4 не декодирует конверт SOAP, когда HTTP-статус 202 - ошибка или функция?

1 голос
/ 22 февраля 2012

Я подключаюсь к веб-сервису через Axis 1.4. Эта служба сообщает об ошибке, отправляя конверт SOAP с описанием ошибки и кодом состояния HTTP 202. Ответ выглядит так: 

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

Ответ теста описан в 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>

Так что, на мой взгляд, все в порядке. Проблема в том, что я не получаю это сообщение об ошибке с сгенерированной заглушкой Axis, получая вместо этого null. Когда я отлаживал, я нашел строку в HTTPSender строке класса 705: 

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

Он пропускает код, который декодирует конверт SOAP. Итак, наконец, я отправил неправильный запрос (это может быть что угодно во время выполнения, например, истек срок действия пароля пользователя), я получаю описание ошибки, но поскольку я использую Axis, у меня нет доступа к нему и я получаю только null, что делает очень трудная отладка (ответ, который я отправил, нашел с помощью Wireshark).

У меня вопрос, это ошибка или особенность? Компания, которая сделала веб-сервис неправильно использующим статус HTTP 202 или стандарт, разрешает это, а Axis слишком примитивен, чтобы поддерживать его? В лучшем случае я хотел бы избежать кодирования связи вручную, используя HttpClient от apache или чего-либо подобного ....

1 Ответ

1 голос
/ 22 февраля 2012

Это похоже на ошибку. Код состояния HTTP 202 «Принят» используется для указания того, что запрос принят, но для его завершения требуется дополнительная обработка. Ответ должен иметь заголовок Location, представляющий обратный вызов, который может быть сделан службе, для проверки состояния запроса, и необязательное тело с описательным сообщением.

Для веб-службы я ожидаю, что разработчики службы обрабатывают ответ тела, пока его содержимое соответствует контракту на обслуживание (в данном случае WSDL). Но разработчики Axis могли бы чувствовать себя иначе.

В любом случае поставщик неправильно использует 202 кода состояния для возврата ошибок, и это (большая) часть проблемы.

...