Как веб-сервер должен обрабатывать запрос http, если файл, отправленный клиентом, содержит данные в неправильном формате? - PullRequest
0 голосов
/ 09 ноября 2011

У нас есть веб-сервер, который выставил API, где клиент может загрузить файл. Этот файл читается на сервере, и происходит определенная обработка, и генерируется HTTP-ответ с кодом состояния 200. Однако иногда файл с данными в неправильном формате принимается сервером. Как следует обращаться с этим делом? Разрешить возникновение исключения или возвратить 400 неверных запросов?

РЕДАКТИРОВАТЬ -

Выдает исключение эквивалентно возвращению 500 кодов состояния? Должно ли это быть использовано в этом случае?

1 Ответ

1 голос
/ 09 ноября 2011

По моему мнению, не следует использовать коды не-200, чтобы сообщать клиенту о проблемах уровня приложения, эти коды зарезервированы исключительно для функций уровня HTTP.

Имеет смысл просто вернуть код 200 ипоместите код ошибки / сообщение на уровне приложения / что угодно в теле ответа HTTP

Однако , существует по крайней мере один протокол, который использует 500 кодов для сообщения о сбоях на уровне приложения: SOAP.Например, вот глава HTTP-ответа, содержащая сообщение об ошибке SOAP:

HTTP/1.1 500 Internal Server Error
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Body>
    <env:Fault>
     <env:Code>
       <env:Value>env:Sender</env:Value>
       <env:Subcode>
        <env:Value>rpc:BadArguments</env:Value>
       </env:Subcode>
     </env:Code>

Но, в любом случае, вы видите, что возвращается не только 500 кодов HTTP-ошибок, но и данные прикладного уровня (SOAP), включенные в подробныеинформация о том, что произошло.

В конечном счете, вам решать, будете ли вы использовать что-то кроме 200 для своего протокола.Ваши требования к клиенту решат, достаточен ли код ошибки 500 для их полного сообщения об ошибке и ее причинах.Если этого достаточно, вам больше ничего не нужно.Если это не так, придумайте свой протокол или, лучше, используйте существующий, например, SOAP или REST.

...