Protobuf má registrované typy obsahu. Rozšířené x-protobuf je zastaralý alias

Binární přenos je bez popisu jen sloupec bajtů. Aby z něj příjemce něco měl, musí mu odesílatel říct, co drží v ruce, a k tomu slouží typ obsahu v hlavičce Content-Type. Protocol Buffers, zkráceně protobuf, jsou přitom od roku 2008 jedním z nejběžnějších způsobů, jak strukturovaná data mezi programy přenést, a vlastní zápis v rejstříku typů obsahu dlouho neměly. Napravuje to RFC 9996, které nese datum červenec 2026 a v seznamu čerstvě vydaných dokumentů se u RFC Editoru objevilo 30. července.

Dva typy a dva volitelné parametry

Zapsané jsou application/protobuf pro binární podobu a application/protobuf+json pro takzvané ProtoJSON, tedy protobufové schéma promítnuté do JSONu. U druhého z nich je parametr charset povinný a musí být utf-8.

Oba typy berou dva volitelné parametry, a oba jsou zatím prázdné rukávy. Parametr encoding nabývá hodnot binary a json, jenže každý z těch dvou typů dnes připouští právě jednu z nich, takže se dá jen zopakovat, co už plyne z názvu; křížová kombinace se musí považovat za chybu. Parametr version se týká verze zápisu na drátě, ne jazyka schématu, výchozí hodnota je 1 a žádná jiná dnes neexistuje. Dokument obojí popisuje jako zásobu na budoucí rozšíření a k verzi přidává jednu tvrdou větu: klient musí odmítnout data s verzí, kterou nezná.

Vedle toho jsou jmenovitě uvedené tři zastaralé aliasy: application/x-protobuf, application/x-protobuffer a application/x-protobuf+json. Dokument je zapsaný jako informativní, tedy nikoli jako norma, a stojí za ním editor Murray Kucherawy spolu s Warrenem Kumarim a Robem Sloanem z Googlu. Správcem obou zápisů je IETF, kontaktní adresa vede na protobufový tým Googlu.

Rejstřík má zápis dřív než dokument

Kdo si rejstřík typů médií otevře, najde u obou položek datum 21. listopadu 2025 a odkaz na šestou revizi konceptu, ne na hotové RFC. To není nesrovnalost: IANA zapisuje na základě schváleného textu a číslo dokumentu doplní, až vyjde. Prakticky to znamená, že application/protobuf je oficiální o osm měsíců déle, než by se z data RFC zdálo.

Cestu k vydání jde dohledat do dne. První soukromý koncept draft-murray-dispatch-mime-protobuf je z 25. dubna 2025, pracovní skupina DISPATCH si ho převzala 30. května 2025 a poslední, sedmá revize je z 1. prosince 2025. Od prvního zápisu k vydanému RFC uplynulo patnáct měsíců, z toho posledních osm mezi poslední revizí a vydáním.

Co dnes posílají skutečné protokoly

Osmnáct let bez zápisu neznamená, že by si protobuf typ obsahu nevzal. Vzal si ho po svém, tedy s předponou x-, kterou konvence vyhrazuje pro neregistrované věci, a stihl se s ním dostat do specifikací, které se dnes berou jako závazné.

Specifikace Prometheus Remote-Write 1.0 vyjmenovává hlavičky, které odesílatel poslat musí, a je mezi nimi Content-Type: application/x-protobuf vedle Content-Encoding: snappy a vlastní hlavičky s číslem verze protokolu. Stejně tvrdě je to napsané v OTLP 1.11.0, protokolu projektu OpenTelemetry: klient i server musí u binární zprávy nastavit Content-Type: application/x-protobuf, a to v požadavku i v odpovědi.

U JSONové varianty se ty dva texty rozcházejí o něco zajímavěji. OTLP přikazuje pro JSONem zakódovaný protobuf hlavičku application/json, kdežto RFC 9996 chce v takovém případě application/protobuf+json. Není to hnidopišství, jak je vidět z dalšího oddílu.

Proč prohlížeči na příponě +json záleží

Bezpečnostní úvahy zabírají v desetistránkovém dokumentu nejvíc místa a všechny míří na jedno: co se stane, když si prohlížeč přenášená data splete s něčím spustitelným.

Přípona +json podle RFC 6839 říká, že obsah je čisté JSON. Prohlížeč pak umí nasadit ochrany, které mají zabránit tomu, aby cizí stránka data vytáhla přes vložený skript. Kdo pošle ProtoJSON pod obecným typem, tuhle informaci prohlížeči nedá. Dokument proto říká, že pro JSONovou serializaci se musí použít application/protobuf+json, a doporučuje u JSONu vždy vyplnit i znakovou sadu, protože záměna kódování je sama o sobě známý útok.

U binární podoby je rada jiná: kdykoli to jde, zakódovat obsah do base64, aby se nedal přečíst jako aktivní obsah, a řídit se pokyny RFC 9205 proti odhadování typu podle obsahu. K tomu dokument připomíná dvě věci, které se na protobuf snadno navěsí mylně. Sám o sobě neposkytuje žádné zabezpečení, soukromí, integritu ani kompresi. A ověření platnosti UTF-8 u textových polí je volitelné, takže se text může muset zkontrolovat ručně.

Verze schématu není verze drátu

Poslední věc, kterou dokument narovnává, je pojmenování verzí. Protobuf má za sebou proto2, proto3 a takzvané edice 2023 a 2024, přičemž ta poslední je v době psaní aktuální. Všechny se ale týkají jazyka pro popis schématu, ne zápisu na drátě: serializovaný objekt vzniklý pod kteroukoli z nich je slučitelný s kteroukoli jinou.

Slučitelnost bajtů přitom není totéž co slučitelnost významů a dokument to říká na vlastním příkladu. V proto2 se neznámá hodnota výčtu považovala za neplatnou, v proto3 se zachová. Data projdou, výsledek je jiný.

Co se tím mění

Prakticky nic nepřestane fungovat. Zastaralý alias je pořád alias, servery i knihovny, které posílají application/x-protobuf, budou posílat totéž i zítra a nikdo je nenutí přepisovat.

Podle nás je užitečnější ta druhá polovina dokumentu než samotný zápis do rejstříku. Registrace uklidila stůl a dala nové kódy do rukou tomu, kdo něco píše od nuly. Rozdíl mezi application/json a application/protobuf+json je ale konkrétní bezpečnostní pokyn a týká se toho, co běží dnes, včetně telemetrie posílané do prohlížeče. Právě u něj bude zajímavé, jak dlouho potrvá, než se do zavedených specifikací promítne.

Zdroje: RFC 9996 Media Types for Protocol Buffers, rejstřík typů médií IANA, historie konceptu v datatrackeru IETF, Prometheus Remote-Write 1.0 a OTLP 1.11.0.