Установить более одного HTTP-заголовка с тем же именем?

Question

Насколько я знаю, в спецификации HTTP разрешено устанавливать более одного заголовка HTTP с одинаковым именем.Есть ли вариант использования для этого (от клиента к серверу и наоборот)?

HTTP 1.1 Раздел 4.2 :

Несколько полей заголовка сообщения содно и то же имя поля МОЖЕТ присутствовать в сообщении тогда и только тогда, когда все значение поля для этого поля заголовка определено как список, разделенный запятыми [т.е. # (значения)].ДОЛЖНО быть возможно объединить несколько полей заголовка в одну пару «field-name: field-value», не изменяя семантику сообщения, добавляя каждое последующее значение поля к первому, каждое из которых разделяется запятой.Порядок, в котором принимаются поля заголовка с одинаковым именем поля, поэтому важен для интерпретации объединенного значения поля, и, следовательно, прокси-сервер НЕ ДОЛЖЕН изменять порядок этих значений поля при пересылке сообщения.

Если я не ошибаюсь, ни в одном случае не требуется несколько заголовков с одинаковым именем.

Answer 1

Обычно используется для Set-Cookie:.Многие серверы устанавливают более одного файла cookie.

Конечно, вы всегда можете установить их все в одном заголовке.

На самом деле, я думаю, вы не можете установитьнесколько файлов cookie в одном заголовке.Так что это необходимый вариант использования.

Спецификация Cookie действительно утверждает, что вы можете объединять несколько файлов cookie в один заголовок так же, как можно объединять другие заголовки (через запятую), но это также указывает на то, что несоответствующие синтаксисы (такие как параметр Expires, который имеет , s в своем значении) по-прежнему распространены и должны решаться реализациями.

Итак, если выиспользуйте Expires params в ваших Set-Cookie заголовках, и вы не хотите, чтобы срок действия всех ваших файлов cookie истекал одновременно, вам, вероятно, нужно использовать несколько заголовков.

Answer 2

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

Answer 3

Это разрешено только для заголовков, использующих очень специфический формат, см. RFC 2616, раздел 4.2 .

Answer 4

Если вы ищете варианты использования, возможно, Accept будет правильным.

• Принять: приложение / JSON
• Примите: application / xml

Answer 5

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

Допустим, у нас есть заголовок, чейзначение может быть записано в списке через запятую.

Entries-In-Order: Jane,John,Charlie

Это значение заголовка , допустимое по своему определению, и сервер или клиент знает его .И затем мы можем отделить его как

Entries-In-Order: Jane,John
Entries-In-Order: Charlie

Но любые заголовки, не понимающие значение, разделенное запятыми, не могут быть записаны в нескольких.

Who-Are-Responsible: John, Jane or maybe Charlie?

Если, по определению, сервер иликлиент может обработать всю строку (John,Jane,maybe Charlie?) как одно значение, запись его в виде нескольких заголовков не будет работать должным образом.

My-Dummy-Header: John
My-Dummy-header: Jane or maybe Charlie?

Answer 6

Старая тема, но я изучал эту же проблему. В любом случае, заголовки Accept и Accept-Encoding являются типичными примерами, в которых используются несколько значений, разделенных запятыми. Даже если это заголовок, специфичный для запроса, спецификации не различают запрос и ответ на этом уровне. Проверьте один из этой страницы. Спецификация говорит, что если у вас есть запятые в качестве символа в значении заголовка, вы не можете использовать несколько заголовков с тем же именем, если только вы не устраните неоднозначность использования запятой.