Несколько наших пользователей попросили нас включить данные относительно их учетной записи в заголовки HTTP отправленных нами запросов или даже ответы, полученные из нашего API. Каково общее соглашение о добавлении собственных HTTP-заголовков в терминах именования, формата... и т.д.
Кроме того, не стесняйтесь публиковать любое умное использование этих данных, которые вы наткнулись на Интернет; Мы пытаемся реализовать это, используя то, что лучше всего в качестве цели:)
Рекомендация - это : начинать свое имя с "X-". Например. X-Forwarded-For, X-Requested-With. Это также упоминается в о. раздел 5 RFC 2047.
Обновление 1: в июне 2011 года был опубликован первый черновик IETF, чтобы осудить рекомендацию использовать префикс "X-" для нестандартных заголовков. Причина в том, что когда нестандартные заголовки с префиксом "X-" становятся стандартными, удаление префикса "X-" нарушает обратную совместимость, заставляя прикладные протоколы поддерживать оба имени (например, x-gzip и gzip теперь эквивалентно). Итак, официальная рекомендация - просто назвать их разумно, без префикса [X- ".
Обновление 2: в июне 2012 года рекомендация об использовании префикса [X- "стала официальной как RFC 6648. Ниже приведены ссылки на релевантность:
3. Рекомендации для создателей новых параметров
...
- НЕ ДОЛЖЕН добавлять префикс их имен к "X-" или аналогичным конструкты.
4. Рекомендации для разработчиков протоколов
...
НЕ ДОЛЖЕН запрещать параметры с префиксом "X-" или аналогичным конструкции от регистрации.
НЕ ДОЛЖЕН оговариваться, что параметр с префиксом "X-" или подобные конструкции необходимо понимать как нестандартные.
НЕ ДОЛЖЕН оговариваться, что параметр без префикса "X-" или подобные конструкции необходимо понимать как стандартизированные.
Обратите внимание, что "НЕ ДОЛЖНО" ("не рекомендуется") не то же самое, что "НЕ ДОЛЖНО" ("запрещено"), см. также RFC 2119 для другой спецификации этих ключевых слов. Другими словами, вы можете продолжать использовать префиксные заголовки "X-", но это официально больше не рекомендуется, и вы можете определенно не документировать их, как если бы они были общедоступными стандартами.
Резюме:
Вопрос перечитывает. Фактический заданный вопрос не похож на префиксы поставщиков в свойствах CSS, где целесообразно проверять будущее и думать о поддержке поставщиков и официальных стандартах. Фактический заданный вопрос более сродни выбору имен параметров запроса URL. Никто не должен заботиться о том, кто они. Но совпадение имен с обычными - это совершенно правильная, и общая, и правильная вещь.
Обоснование:
Речь идет о соглашениях между разработчиками для пользовательских заголовков конкретных приложений - "данных, имеющих отношение к их учетной записи" - которые не имеют ничего общего с поставщиками, органами стандартов или протоколами, которые должны быть реализованы третьими сторонами, за исключением того, что разработчик, о котором идет речь просто нужно избегать заголовков, которые могут иметь другое предназначение для использования серверами, прокси или клиентами. По этой причине приведенные примеры "X-Gzip/Gzip" и "X-Forwarded-For/Forwarded-For" являются спорными. Возникает вопрос о соглашениях в контексте частного API, аналогичных соглашениям об именах параметров URL-запроса. Это вопрос предпочтения и расстояния между именами; опасения по поводу "X-ClientDataFoo", поддерживаемые любым прокси-сервером или поставщиком без "X", явно неуместны.
В префиксе "X-" нет ничего особенного или волшебного, но он помогает понять, что это настраиваемый заголовок. На самом деле, RFC-6648 и др. Помогают предотвратить использование префикса "X-" , поскольку - поскольку поставщики HTTP-клиентов и серверов отказываются от префикса - ваши приложения, частные API-интерфейсы, персональные данные, механизм передачи становится еще лучше изолированным от коллизий между именами и небольшим количеством официальных зарезервированных заголовков. Тем не менее, мои личные предпочтения и рекомендации - сделать шаг дальше и сделать, например, "X-ACME-ClientDataFoo" (если ваша компания-виджет "ACME" ).
IMHO спецификация IETF недостаточно специфична для ответа на вопрос OP, поскольку он не может отличить совершенно разные варианты использования: (A) поставщики, внедряющие новые глобально применимые функции, такие как "переадресованные", с одной стороны, vs. (B) разработчики приложений передают строки, зависящие от приложения, к клиенту и серверу. Спектр касается только первого, (A). Вопрос здесь в том, существуют ли соглашения для (B). Есть. Они включают группирование параметров в алфавитном порядке и разделение их от многих соответствующих стандартам заголовков типа (A). Использование префикса "X-" или "X-ACME-" является удобным и законным для (B) и не противоречит (A). Чем больше продавцов перестают использовать "X-" для (A), тем более четкими становятся (B).
Пример:
Google (которые несут немного веса в различных органах стандартизации) - на сегодняшний день, 20141102 в этом незначительном изменении моего ответа - в настоящее время используется "X-Mod-Pagespeed", чтобы указать версию своего модуля Apache, участвующего в преобразуя данный ответ. Кто-нибудь действительно предлагает, чтобы Google использовал "Mod-Pagespeed" без "X-" и/или попросил IETF благословить его использование?
Резюме:
Если вы используете пользовательские заголовки HTTP (как иногда подходящую альтернативу куки файлам) в своем приложении для передачи данных на ваш сервер, и эти заголовки явно не предназначены для использования вне контекста вашего приложения, между ними назначается "X-" или "X-FOO-" префикс - разумное и обычное соглашение.
Формат заголовков HTTP определен в спецификации HTTP. Я расскажу о HTTP 1.1, для которого спецификация RFC 2616. В разделе 4.2 "Заголовки сообщений" определена общая структура заголовка:
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
Это определение основывается на двух основных принципах, токенах и TEXT. Оба они определены в разделе 2.2 "Основные правила". Токен:
token = 1*<any CHAR except CTLs or separators>
В свою очередь, опираясь на CHAR, CTL и разделители:
CHAR = <any US-ASCII character (octets 0 - 127)>
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
ТЕКСТ:
TEXT = <any OCTET except CTLs,
but including LWS>
Где LWS - линейное пустое пространство, определение которого я не будет воспроизводиться, а OCTET:
OCTET = <any 8-bit sequence of data>
Существует примечание, сопровождающее определение:
The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].
Итак, два вывода. Во-первых, ясно, что имя заголовка должно быть составлено из подмножества символов ASCII - alphanumerics, некоторые знаки пунктуации, а не многое другое. Во-вторых, нет ничего в определении значения заголовка, которое ограничивает его ASCII или исключает 8-битные символы: он явно состоит из октетов, причем только контрольные символы запрещены (обратите внимание, что CR и LF считаются элементами управления). Кроме того, комментарий к выпуску TEXT подразумевает, что октеты должны интерпретироваться как ISO-8859-1, и что существует механизм кодирования (что ужасно, кстати) для представления символов вне этой кодировки.
Итак, для ответа на @BalusC, в частности, совершенно ясно, что согласно спецификации значения заголовка соответствуют ISO-8859-1. Я отправил высокомарочных 8859-1 символов (в частности, некоторые акцентированные гласные, как используется на французском языке) в заголовке Tomcat, и правильно их интерпретировал Firefox, поэтому в некоторой степени это работает как на практике, так и в теории (хотя это был заголовок Location, который содержит URL-адрес, и эти символы не являются законными по URL-адресам, поэтому это было фактически незаконным, но под другим правилом!).
Тем не менее, я бы не полагался на ISO-8859-1, работающий на всех серверах, прокси и клиентах, поэтому я бы придерживался ASCII в качестве защитного программирования.
Реестр имен полей заголовка определен в RFC3864, и ничего особенного с "X -".
Насколько я могу судить, для частных заголовков нет рекомендаций; в сомнении, избегайте их. Или посмотрите на HTTP Extension Framework (RFC 2774).
Было бы интересно узнать больше об использовании; почему информация не может быть добавлена в тело сообщения?
Изменение или, вернее, добавления дополнительных HTTP-заголовков - отличный инструмент для отладки кода, если ничего другого.
Когда URL-запрос возвращает перенаправление или изображение, нет html-страницы, чтобы временно записывать результаты отладочного кода, по крайней мере, в тот, который не отображается в браузере.
Один из подходов - записать данные в локальный файл журнала и просмотреть этот файл позже. Другим является временное добавление заголовков HTTP, отражающих отлаженные данные и переменные.
Я регулярно добавляю дополнительные HTTP-заголовки, такие как X-fubar-somevar: или X-testing-someresult: чтобы проверить все, и обнаружил много ошибок, которые в противном случае было бы очень сложно отследить.
RFC6648 рекомендует предположить, что ваш настраиваемый заголовок "может стать стандартизированным, общедоступным, широко развернутым или использоваться в нескольких реализациях". Поэтому он рекомендует не ставить перед ним префикс "X-" или аналогичными конструкциями.
Однако есть исключение "когда крайне маловероятно, что [ваш заголовок] когда-либо будет стандартизирован". Для таких заголовков "для конкретной реализации и частного использования" RFC говорит, что пространство имен, такое как префикс поставщика, является оправданным.