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

Question

Я подключаюсь к веб-сервису с помощью 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> 

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

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

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

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

Answer 1

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

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

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