Спеціальні заголовки HTTP: іменування умов

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

Крім того, сміливо публікуйте будь-яке розумне використання цих, про які ви натрапили в Інтернеті; Ми намагаємось реалізувати це, використовуючи те, що найкраще в якості цілі :)

Ця рекомендація буде була почати своє ім'я з «Х-». Наприклад 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. Рекомендації для творців нових параметрів

...

3. НЕ БУДЕ ПРЕФІКСУвати свої назви параметрів "X-" або подібними конструкціями.

4. Рекомендації для конструкторів протоколів

...

4. НЕ БУДЕ забороняти реєструвати параметри з префіксом "X-" або подібними конструкціями.

5. НЕ МОЖЕ НЕ встановлювати, що параметр з префіксом "X-" або подібними конструкціями потрібно розуміти як нестандартний

6. НЕ МОЖЕ НЕ встановлювати, що параметр без префікса "X-" або подібні конструкції потрібно розуміти як стандартизований.

Зауважте, що "ПОТРІБНО НЕ" ("відмовлятись") не те саме, що "ПОВИНЕН НЕ" ("заборонено"), див. Також RFC 2119 для іншої характеристики цих ключових слів. Іншими словами, ви можете продовжувати використовувати заголовки "X-", але це офіційно більше не рекомендується, і ви, безумовно, не можете їх документувати так, ніби вони є державним стандартом.

Підсумок :

• офіційна рекомендація - просто назвати їх розумно, без префікса "X-"
• ви можете продовжувати використовувати заголовки "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 недостатньо специфічна, щоб відповісти на питання ОП, оскільки не вдається розрізнити абсолютно різні випадки використання: (A) постачальники, що впроваджують нові глобально застосовні функції, такі як "Forwarded-For", з одного боку, проти (B) розробники додатків, що передають спеціальні рядки для клієнта та сервера. Спекуляція стосується лише колишнього, (A). Тут питання полягає в тому, чи існують конвенції для (B). Існує. Вони передбачають групування параметрів за алфавітом та відокремлення їх від багатьох заголовків типу A (відповідних стандартам). Використання префікса "X-" або "X-ACME-" є зручним і законним для (B) і не суперечить (A). Чим більше продавці перестануть використовувати "X-" для (A), тим чіткіше виразними стануть (B).

Приклад:
Google (які мають невелику вагу в різних органах зі стандартів) - станом на сьогодні 20141102 у цьому невеликому редагуванні моєї відповіді - наразі використовує "X-Mod-Pagespeed", щоб вказати версію свого модуля Apache бере участь у перетворенні заданої відповіді. Хтось дійсно пропонує, що Google повинен використовувати "Mod-Pagespeed" без "X-" та / або просити IETF благословити його використання?

Підсумок:
Якщо ви використовуєте власні заголовки HTTP (як іноді відповідну альтернативу файлам cookie) у вашій програмі для передачі даних на / з вашого сервера, і ці заголовки, явно, НЕ призначені ніколи використовуватись поза контекстом вашого додаток, розміщення їх іменами з префіксом "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 - буквено-цифрових знаків, деяких пунктуацій, не багато іншого. По-друге, у визначенні значення заголовка немає нічого, що обмежує його на ASCII або виключає 8-бітові символи: воно явно складається з октетів, лише заборонені символи управління (зауважте, що CR та LF вважаються елементами управління). Крім того, коментар до виробництва TEXT передбачає, що октети слід інтерпретувати як такі, що знаходяться в ISO-8859-1, і що існує механізм кодування (який, до речі, жахливо) для представлення символів поза цим кодуванням.

Отже, щоб реагувати на @BalusC, зокрема, цілком зрозуміло, що згідно зі специфікацією, значення заголовків знаходяться в ISO-8859-1. Я надсилав символи високого рівня 8859-1 (зокрема, деякі голосні наголошені, як це використовується французькою мовою), в заголовку з Tomcat, і їх інтерпретував Firefox правильно, так що певною мірою це працює як на практиці, так і в теорії (хоча це був заголовок Location, який містить URL-адресу, і ці символи не є законними в URL-адресах, тому це було фактично незаконно, але за іншим правилом!).

Втім, я не покладаюся на ISO-8859-1, що працює на всіх серверах, проксі-серверах та клієнтах, тому я б дотримувався ASCII як питання оборонного програмування.

RFC6648 рекомендує припустити, що ваш власний заголовок "може стати стандартизованим, загальнодоступним, широко розгорнутим або придатним для використання в декількох реалізаціях". Тому він рекомендує не префіксувати його "X-" або подібними конструкціями.

Однак є виняток, "коли вкрай малоймовірно, що [ваш заголовок] коли-небудь стандартизується". Для таких заголовків, що стосуються конкретної реалізації та приватного використання, RFC каже, що обґрунтований простір імен, такий як префікс постачальника.

Змінення або, правильніше, додавання додаткових заголовків HTTP - це чудовий інструмент налагодження коду, якщо нічого іншого.

Коли запит URL повертає переспрямування або зображення, немає HTML-сторінки "сторінки", щоб тимчасово записати результати налагоджувального коду до - принаймні, не такого, який видно у браузері.

Один із підходів - записати дані в локальний файл журналу та переглянути цей файл пізніше. Інша полягає у тимчасовому додаванні заголовків HTTP, що відображають дані та змінні, що піддаються налагодженню.

Я регулярно додаю додаткові заголовки HTTP, як-от X-fubar-somevar: або X-testing-someresult: щоб перевірити речі - і знайшов багато помилок, які інакше було б важко відстежити.

Реєстр імен поля заголовка визначений в RFC3864 , і немає нічого особливого з "X-".

Наскільки я можу сказати, для приватних заголовків немає вказівок; сумнівайтеся, уникайте їх. Або подивіться на HTTP Extension Framework ( RFC 2774 ).

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