HTTP Transfer-Encoding и запросы
Спецификация HTTP гласит, что заголовок Transfer-Encoding разрешен для запросов, но какой код ошибки должен ответить сервер, если он не понимает, что задано Transfer-Encoding.
Насколько я знаю, стандарт HTTP не охватывает эту возможность, но, возможно, я просто упустил это из виду.
6 ответов
Неизвестная кодировка передачи должна вызвать ошибку HTTP 501 "НЕ РЕАЛИЗОВАНО". Это то, что делает Apache, по крайней мере.
Также см. http://argray.com/unixfaq/httpd_error_codes.shtml
Изменить: указатель на соответствующий раздел RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Я согласен с тем, что ответ на этот вопрос неочевиден, и он был включен в список рассылки HTTP WG.
ОБНОВЛЕНИЕ: Бьерн Х. справедливо указывает:
Раздел 3.6 RFC 2616:
Сервер, который получает тело объекта с кодировкой передачи, которую он не понимает, ДОЛЖЕН вернуть 501 (не реализовано) и закрыть
подключение.Так что это уже решено.
В основном личное мнение.
Я всегда думал, что ошибки 5хх были фактическими ошибками программирования, как будто что-то упало. Если сервер не понимает запрос, я бы сказал, что ошибка 4xx - лучший ответ, поскольку проблема заключается в том, что запрос не является неудачным процессом на сервере. Я не уверен, какой 4xx, но есть несколько, поэтому выбор не должен быть трудным.
Запрос с недействительным Transfer-Encoding для версии HTTP искажен. Поэтому сервер должен ответить 400 Bad Request,
Возможно, непонимание кусочного кодирования должно быть 500 Внутренняя ошибка сервера, а не 501, потому что RFC-2616 говорит, что сервер ДОЛЖЕН понимать это.
Однако, если сервер решает не принимать запросы с кусочными телами и хочет обвинить клиента в этом, один из способов сделать это по закону будет 411 Требуемая длина - поскольку нельзя использовать Content-Length и Transfer-Encoding при в то же время, и это не практично, чтобы отправить запрос без так или иначе.
RFC немного неясно, но ИМХО это должно быть 406 неприемлемо.