прочитать - подделка http заголовков




Пользовательские заголовки HTTP: соглашения об именах (4)

В июне 2012 года устаревшая рекомендация использовать префикс «X-» стала официальной как RFC 6648 . Ниже приводятся ссылки на актуальность:

3. Рекомендации для создателей новых параметров

...

  1. НЕ ДОЛЖНЫ приписывать имена параметров «X-» или аналогичным конструкциям.

4. Рекомендации для разработчиков протоколов

...

  1. НЕ ДОЛЖНЫ запрещать параметры с префиксом «X-» или аналогичными конструкциями от регистрации.

  2. НЕ ДОЛЖНО указывать, что параметр с префиксом «X-» или аналогичные конструкции следует понимать как нестандартные.

  3. НЕ ДОЛЖНО оговаривать, что параметр без префикса «X-» или аналогичных конструкций следует понимать как стандартизованный.

Обратите внимание, что «НЕ СЛЕДУЕТ» («обескуражен») - это не то же самое, что «НЕ ДОЛЖНО» («запрещено»), см. Также RFC 2119 для другой спецификации по этим ключевым словам. Другими словами, вы можете продолжать использовать префиксные заголовки «X-», но это не рекомендуется, и вы не можете документировать их, как если бы они были общедоступными.

В июне 2011 года был опубликован первый проект IETF, чтобы отклонить рекомендацию использовать префикс «X-» для нестандартных заголовков. Причина в том, что когда нестандартные заголовки с префиксом «X-» становятся стандартными, удаление префикса «X-» нарушает обратную совместимость, заставляя протоколы приложений поддерживать оба имени (например, x-gzip & gzip теперь эквивалентны). Итак, рекомендация состоит в том, чтобы просто назвать их разумно без префикса «X-».

Рекомендация заключалась в том, чтобы начать свое название с «X-». Например, X-Forwarded-For , X-Requested-With . Это также упоминается в разделе 5 раздела RFC 2047 .

Некоторые из наших пользователей попросили нас включить данные относительно их учетной записи в заголовки HTTP отправленных нами запросов или даже ответы, полученные из нашего API. Каково общее соглашение о добавлении пользовательских заголовков HTTP с точки зрения именования , формата ... и т. Д.

Кроме того, не стесняйтесь публиковать любое умное использование данных, которое вы наткнулись на Интернет; Мы пытаемся реализовать это, используя то, что лучше всего в качестве цели :)


Вопрос перечитывает. Фактический заданный вопрос не похож на префиксы поставщиков в свойствах 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) поставщики, внедряющие новые глобально применимые функции, такие как «Forwarded-For», с одной стороны, 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-» является разумным и общепринятым.


Реестр имени поля заголовка определен в RFC3864 , и нет ничего особенного в «X-».

Насколько я могу судить, для частных заголовков нет рекомендаций; в сомнении, избегайте их. Или посмотрите на HTTP Extension Framework ( RFC 2774 ).

Было бы интересно узнать больше об использовании; почему информация не может быть добавлена ​​в тело сообщения?


Формат заголовков 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 - линейное пустое пространство, определение которого i не будет воспроизводиться, а 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 в качестве защитного программирования.





http-headers