#http #http-headers #http-accept-language #http-accept-header
#http #http-заголовки #http-accept-language #http-accept-header
Вопрос:
Мое чтение RFC 2616 не ответило на мой вопрос:
Как сервер должен интерпретировать несколько заголовков Accept, Accept-Encoding, Accept-Language и т. Д.?
Конечно, это, как правило, должно быть редким явлением, но я далек от того, чтобы предполагать, что каждый HTTP-клиент действительно делает то, что должен.
Представьте, что HTTP-запрос включает в себя следующее:
Accept-Language: en
Accept-Language: pt
Должен ли сервер:
- Объединить результаты, чтобы эффективно
Accept-Language: en, pt? - Соблюдайте только первый (
en)? - Соблюдайте только последний (
pt)? - Бросьте шипение (возможно, верните статус 400?)
Вариант # 1 кажется мне наиболее естественным и, скорее всего, будет тем, что имеет в виду клиент, и с наименьшей вероятностью полностью нарушит ожидания, даже если это не то, что имеет в виду клиент.
Но существует ли какое-либо фактическое правило (в идеале указанное в RFC) для того, как справляться с этими ситуациями?
Ответ №1:
1) Вы смотрите на устаревший RFC. RFC 2616 устарел два года назад.
2) Тем не менее, ответ таков: 1); см. https://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.3.2.2.p.3 : «Получатель МОЖЕТ объединить несколько полей заголовка с одним и тем же именем поля в одну пару «имя поля: значение поля» без изменения семантики сообщения, добавляя каждое последующее значение поля к объединенному значению поля в порядок, разделенный запятой. (…)»
Комментарии:
1. Давайте также добавим, что это не верно для всех заголовков. Например, заголовок Content-Length должен быть уникальным.
2. Это верно в том смысле, что получателю разрешено рекомбинировать их через запятую. Это просто означает, что мусор был отправлен и преобразован в другой вид мусора.