Соответствующий код состояния HTTP для запроса с указанием недопустимого заголовка Content-Encoding?

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

Пример

Клиентские POST-данные JSON для ресурса REST и кодируют тело сущности с использованием кодирования gzip. Тем не менее, сервер может только декодировать коды DEFLATE, поскольку он не прошел класс gzip в серверной школе.

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

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

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

Update:

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

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

Ответ 1

Как я читаю, 415 Unsupported Media Type звучит как наиболее подходящий.

Из RFC 2616:

10.4.16 415 Неподдерживаемый тип носителя

Сервер отказывается обслуживать запрос, поскольку объект запроса находится в формате, не поддерживаемом запрошенным ресурсом для запрошенного метода.

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

Новая горячность, RFC 7231, даже явно говорит о ней:

6.5.13. 415 Неподдерживаемый тип носителя

Код статуса 415 (неподдерживаемый тип носителя) указывает, что сервер происхождения отказывается обслуживать запрос, потому что полезная нагрузка находится в формате, не поддерживаемом этим методом на целевом ресурсе.
Проблема с форматом может быть вызвана указанным запросом Content-Type или Content-Encoding или в результате проверки данные напрямую.

Ответ 2

Они должны сделать последний вопрос о том, кто хочет стать миллионером!

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

Мой первый инстинкт - 400 Bad Request - соответствующий ответ в этом случае.
405 Метод не разрешен неправильно, потому что он ссылается на HTTP-глагол, который не разрешен.
406 Не приемлемо выглядит так, как будто это может пообещать, но это означает, что сервер не может предоставить данные клиенту, который удовлетворяет заголовкам запроса Accept- *, которые он отправил. Это не похоже, что это подойдет вашему делу.
412 Предварительное условие Неудачно определено довольно неопределенно. Возможно, это было бы уместно, но я бы не стал спорить.
415 Неподдерживаемый тип носителя неверен, поскольку он не является типом данных, который отклоняется, это формат кодировки.

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

422 Unprocessable Entity описывает ответ, который должен быть возвращен, если запрос был правильно сформирован, но если он был семантически некорректным. Это похоже на хорошую подгонку, но это расширение WebDAV для HTTP, а не стандартное.

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

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

10.4.7 406 Не приемлемо

Ресурс, указанный в запросе, способен генерировать объекты ответа, которые не обладают характеристиками контента в соответствии с принимаемыми заголовками, отправленными в запросе.

Если это не был запрос HEAD, ответ СЛЕДУЕТ включать объект содержащий список доступных характеристик объекта и местоположений (ов) из которого пользователь или пользовательский агент может выбрать наиболее подходящий. Формат сущности определяется типом носителя, указанным в Поле заголовка Content-Type. В зависимости от формата и возможности пользовательского агента, выбор наиболее подходящих выбор МОЖЕТ быть выполнен автоматически. Однако эта спецификация не определяет какой-либо стандарт для такого автоматического выбора.
  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.
Если ответ может быть неприемлемым, пользовательский агент СЛЕДУЕТ временно прекратить получение большего количества данных и запросить у пользователя решение о дальнейшем действия.

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

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

Клиент: Дайте мне страницу GZIPPED.
Сервер: Извините, не могу. Я могу ОТКАЗАТЬ пакет для вас. Здесь упакована страница DEFLATE. Это хорошо для вас?
Клиент: Welllll... Я действительно не хотел DEFLATE, но я могу декодировать его в порядке, поэтому я возьму его.

(или)

Клиент. Думаю, мне придется это сделать с моим пользователем. Оставайтесь на линии.