Вопрос по http-headers, http-status-codes, http – Подходящий код состояния HTTP для запроса с указанием недопустимого заголовка Content-Encoding?

27

Какой код состояния должен быть возвращен, если клиент отправляет HTTP-запрос и указывает заголовок Content-Encoding, который не может быть декодирован сервером?

Example

Клиент помещает данные JSON в ресурс REST и кодирует тело объекта, используя кодировку gzip. Однако сервер может декодировать только кодировки DEFLATE, потому что он не прошел класс gzip в школе серверов.

Какой код ответа HTTP должен быть возвращен? я бы сказал415 Unsupported Media Type но проблема не в Content-Type объекта, а в кодировании тела поддерживаемого объекта.

Что более уместно: 415? 400? Возможно пользовательский код ответа?

Addendum: Я, конечно, тщательно проверил rfc2616. Если ответ есть, мне могут понадобиться новые корректирующие очки, но я не верю, что это так.

Update:

Это не имеет ничего общего с отправкой ответа, который может быть неприемлемым для клиента. Проблема заключается в том, что клиент отправляет серверу то, что может или не может быть допустимым типом носителя в кодировке, которую сервер не может понять (согласноContent-Encoding заголовок клиента упакован с сообщением запроса).

Это крайний случай, и он не будет встречаться при работе с пользовательскими агентами браузера, но может возникать в API-интерфейсах REST, принимающих тела объектов для создания / изменения ресурсов.

Ваш Ответ

2   ответа
11

кто хочет стать миллионером!

Ну, браузер сделал запрос, что сервер не может обслуживать, потому что информация, предоставленная клиентом, находится в формате, который не может быть обработан сервером. Однако это не ошибка сервера за то, что он не поддерживает данные, предоставленные клиентом, это ошибка клиента за то, что он не прослушивает заголовки сервера Acccept- * и предоставляет данные в неподходящей кодировке. Это сделало бы это ошибкой клиента (код ошибки серии 400).

My first instinct is 400 Bad Request is the appropriate response in this case. 405 Method Not Allowed isn't right because it refers to the HTTP verb being one that isn't allowed. 406 Not Acceptable looks like it might have promise, but it refers to the server being unable to provide data to the client that satisfies the Accept-* request headers that it sent. This doesn't seem like it would fit your case. 412 Precondition Failed is rather vaguely defined. It might be appropriate, but I wouldn't bet on it. 415 Unsupported Media Type isn't right because it's not the data type that's being rejected, it's the encoding format.

После этого мы попадаем в область нестандартных кодов ответов.

422 Unprocessable Entity describes a response that should be returned if the request was well-formed but if it was semantically incorrect in some way. This seems like a good fit, but it's a WebDAV extension to HTTP and not standard.

Учитывая вышеизложенное, я лично выбрал 400 Bad Request. Если у какого-либо другого HTTP-эксперта есть лучший кандидат, я бы его послушал. ;)

UPDATEЯ ранее ссылался на статусы HTTP со своей страницы в Википедии. Хотя представленная информация кажется точной, она также не является полной. Глядя на спецификации отW3C дает намного больше информации о HTTP 406, и это наводит меня на мысль, что 406 может быть правильным кодом в конце концов.

10.4.7 406 Not Acceptable

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

  Note: HTTP/1.1 servers are allowed to return responses which are
  not acceptable according to the accept headers sent in the
  request. In some cases, this may even be preferable to sending a
  406 response. User agents are encouraged to inspect the headers of
  an incoming response to determine if it is acceptable.

If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.

Хотя в нем явно упоминается заголовок Content-Type, в формулировке упоминается «характеристики объекта», которые вы можете прочитать как охватывающие такие вещи, как GZIP или сжатие DEFLATE.

Стоит отметить, что в спецификации говорится, что может быть целесообразно просто отправить данные как есть вместе с заголовками, чтобы сообщить клиенту, в каком формате он находится и в какой кодировке он используется, и просто оставить его для клиента. отсоритровать. Таким образом, если клиент отправляет заголовок, указывающий, что он принимает сжатие GZIP, но сервер может генерировать ответ только с помощью DEFLATE, тогда отправка этого сообщения вместе с заголовками, сообщающими, что это DEFLATE, должна выполняться (в зависимости от контекста).

Client: Give me a GZIPPED page. Server: Sorry, no can do. I can DEFLATE pack it for you. Here's the DEFLATE packed page. Is that okay for you? Client: Welllll... I didn't really want DEFLATE, but I can decode it okay so I'll take it.

(или же)

Client: I think I'll have to clear that with my user. Hold on.
Что ж,400 Bad Request предполагается, что он содержит синтаксические ошибки в запросе, а не общий сбой запроса (или, по крайней мере, так я прочитал определение) ...
Вы правы насчет 405, 406, 412 и 415 (обратите внимание, что 412 четко определено для применения к полям условного заголовка). 422is стандартный код ответа (в противном случае он не будет в реестре), но также не применяется. Так что 400 (потенциально с диагностикой в полезной нагрузке) должны делать.
На самом деле .... чтение спецификаций на W3C приводит к некоторым интересным взаимодействиям, которые предполагают, что 406 может быть правильным ответом в конце концов. Или даже просто отправив данные в любом случае (предыдущий источник по кодам статуса HTTP был Википедия). Обновляю свой ответ сейчас.
@ircmaxell Достаточно верно. Тем не менее, ни один из других кодов действительно не подходит, и вы должны что-то отправить ...
Проблема с 406 состоит в том, что он говорит, что сервер не можетgenerate a response чтоclient готов принять. Это в основном противоположность проблемы, о которой спрашивает ОП; в этом случае сервер не может даже декодировать запрос, чтобы выяснить, что дать клиенту. Разговор будет больше похож на то, как клиент говорит «Вот это запрос GZIP», и вопрос в том, как правильно сказать клиенту, что сервер должен сказать «WTF?». Я ничего не могу сделать с этим & quot; (и, в идеале, используйте только "УДАЛИТЬ", пожалуйста ").
45

415 Unsupported Media Type звучит как самый подходящий.

Из RFC 2616:

10.4.16 415 Unsupported Media Type

The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.

Да, текстовая часть гласит «тип носителя» скорее, чем «кодирование», но фактическое описание не включает никакого упоминания об этом различии.

Новая жара,RFC 7231, даже явно об этом:

6.5.13. 415 Unsupported Media Type

The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated
Content-Type or Content-Encoding
, or as a result of inspecting the
data directly.

@GarethOakley правильно, как указано вrfc2616 #14.11.
Это, без сомнения, правильный ответ - и это в RFC2616:"If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type)."
@Miquella: хотя стоит RFC 2616, она того стоит. Да здравствует RFC 723 [0-5]. :)

Похожие вопросы