HTTP hlavičky a záhadný prefix X-

Protokol HTTP je definován celou řadou různých standardů. Například RFC 2068 z roku 1997 již nenápadně v poznámce naráží na kompatibilitu s ohledem na X- prefix. Konkrétně v sekci 3.5 zmiňuje:

For compatibility with previous implementations of HTTP, applications should consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.

Je třeba dodat, že zde prefix nehraje roli v klíči, jako spíše v hodnotě. Proč tomu tak je zjistíme dále pohledem do historie. Zmínka o vlastních hlavičkách je i v RFC 2047 z listopadu 1996. RFC se věnuje MIME a rozšířením hlaviček zpráv. Konkrétně zde Keith Moore zmiňuje:

An 'encoded-word' may also appear in any user-defined ("X-") message or body part header field.

Čili už se nebavíme jen o hodnotách ale vyloženě klíči. Samotná poznámka je navíc jen potvrzení stavu světa než oficiální deklarace. Už tento dokument je totiž pouhou aktualizací jiných RFC, ve kterých se X- prefix běžně zmiňuje. Speciální pozornost je X- hlavičkám věnována též v RFC 2045 sekci 6.3 a v best practices RFC 2048. V té době se též doporučuje používat X- prefix pro některé hodnoty media types, které nejsou standardizovány.

Jinými slovy v dřevních dobách internetu si čas od času někdo vymyslel vlastní HTTP hlavičku a tu následně používal pro své účely. Aby ji odlišil od těch standardizovaných, použil po vzoru některých RFC prefix X-. Jenomže někteří průkopníci byli úspěšní a jejich nestandardní hlavička se stala standardem. A to je docela problém. V době, kdy se něco prohlásí za standard už je to zcela běžná věc. Používají-li klienti určité X- hlavičky několik let, není možné vydáním standardu přikázat jejich hromadnou změnu. A tak se kvůli zpětné kompatibilitě přijmou buď dvě verze a nebo vzejde ve standard ošklivá HTTP hlavička s X- prefixem. Řada takových HTTP hlaviček byla standardizována mezi roky 1997 až 2011.

V roce 2012 byl vydán RFC 6648, který nese označení „Deprecating the "X-" Prefix and Similar Constructs in Application Protocols“. Vysvětluje proč. Zde se mimo jiné dozvíme, že X- prefix je historicky vázán už na FTP protokol a zmínky se nacházejí v RFC 691 z roku 1975.

I suggest that parameters be allowed to be more than one letter, and that an initial letter X be used for really local idiosyncracies.

Nakonec tento nápad pro „lokální výstřednosti“ přežil přes 45 let a dnes se vývojáři hádají, zda X- prefix používat pro názvy HTTP hlaviček v REST API. Prefix našel uplatnění v rámci FTP komunikace, v rámci e-mailové komunikace a protekl až do HTTP RFCéček, která jsem zmínil na začátku článku. Konečně v roce 2012 se RFC 6648 věnuje analýze, kde popisuje problémy X- prefixu.

Závěr

Pokusím se interpretovat závěry tak, jak je popisuje RFC a to s ohledem na vývojáře webových aplikací (tedy ne aplikačních protokolů). Při návrhu HTTP hlaviček by měl vývojář vzít na vědomí, že jakákoliv HTTP hlavička může vzejít ve standard. Vývojář by měl preferovat pro daný účel standardní hlavičky a teprve pokud vhodnou nenajde, měl by zvolit vlastní výstižný název pro HTTP hlavičku. Vývojář by neměl používat X- prefix. Klíčové je spojení „BY NEMĚL“, protože RFC výslovně pracují například s pojmy „MŮŽE“ a „NESMÍ“.

Konec analýzy ještě zmiňuje výjimky, kdy může X- prefix být ospravedlnitelný. Jsou to situace, kdy je přijetí HTTP hlavičky s daným klíčem extrémně nepravděpodobné. Například X-Kavarna se standardem zřejmě nestane. Pro takové případy je nicméně lepší vybrat výstižnější název nebo prefix nahradit smysluplnějším, například App-Kavarna. Použití může dávat smysl i tam, kde by měl X zvláštní sémantický význam nebo důraz. Například pro zvýšení priority vůči jiné standardní hlavičce (což je samo o sobě spekulativní). Standard nicméně doporučuje i v těchto případech zvolit vhodnější synonymum. Poslední případ zahrnují scénáře, kde je cílem mít co nejkratší délku hlavičky a X má opět specifický význam.

Shrnuto a podtrženo slovy 10 let starých RFC vývojáři = BY NEMĚLI = X- prefix používat.

Dodatek

Standard je zastaralý. Vývojáři a tvůrci protokolů ho zřejmě nečetli nebo několik let ignorovali, což vyústilo ve vznik celé řady ustálených HTTP hlaviček s X- prefixem. Ty jsou v dnešní době natolik rozšířené, že jejich přijetí jako standard je spíše pravděpodobné a zbavit se X- prefixu by nedávalo příliš smysl. Příkladem jsou v dnešní době například X-Rate-Limit hlavičky. Přestože při návrhu API by ve jménu standardu bylo lepší použít Rate-Limit, prakticky nikdo to nedělá. Je pravděpodobnější, že jako standard bude přijatý klíč X-Rate-Limit nežli Rate-Limit. Tedy možná. Zmapování situace se totiž věnoval Roberto Polli a později s ním i Alejandro Martinez Ruiz z Red Hatu. Současný návrh, který se táhne bezmála 2 roky navrhuje názvy klíčů bez prefixu X-.

Za mě souhlasím se závěry RFC 6648, avšak u letitých ustálených HTTP hlaviček používám nepsanou normu (X-Rate-Limit, X-Correlation-ID, X-Request-ID…) a další. Chcete-li mít vše exaktní a neprůstřelné, správně je varianta bez X-.

Tak či onak bych doporučoval energii věnovat především otázce, jak HTTP hlavičky správně zdokumentovat. Zda totiž přijmu request hlavičku s prefixem nebo bez něj už je mi koneckonců jedno. Důležité je, aby konzument API věděl co má poslat. A zrovna tato informace ve většině dokumentací k REST API chybí.