Jeg kan nu tilføje "RFC-forfatter" til visitkortet, idet RFC8941 er just blevet publiceret.
Eller rettere: Det har jeg fået email om, men ikke alle IETF's webservere har ikke hørt om det endnu.
Hvad er så "structured fields" ?
Jo, se...
I et kongerige langt mod nord (Sverige) skete det engang for mange (=5) år siden at vise mænd (og undertegnede) mødtes til HTTP Workshop.
Et af emnerne var at nogen, jeg husker ikke hvem, havde fået den idé at det var smart hvis man kunne fylde JSON i HTTP-headers for at gøre dem "mere udtryksfulde".
Selvom det fleste af de vise mænd og for den sags skyld også jeg, godt kunne se der var et behov, ville begejstringen for JSON ingen begyndelse tage.
For det første kan det slet ikke lade sig gøre.
JSON tillader ting som ikke er tilladt i HTTP headers, så det ville under alle omstændigheder ikke blive "JSON" men "JSON[fodnote]" der kunne blive tale om og dermed fordampede argumentet om at bruge "standard software", der ville blive brug for specielle JSON parsere og serializers.
Som om det ikke var problemer nok, er det forbavsende besværligt at lave en data-definition, et Schema, for JSON strukturer og hverken dengang eller nu er er nogen klar standard på dét felt.
Der var også mange andre ophævelser, helt ned til og med at '{' og '}', som JSON bruger meget, komprimerer negativt i den statiske Huffman kode i RFC7541 (HTTP/2's komprimering af HTTP headers.)
Men behovet var der som sagt, der var en grim tendens til at hver gang nogen definerede en ny HTTP-header skulle der skrives en specielt stykke kode til at parse/producere netop den header.
Behøver jeg nævne at der også var en der argumenterede at JSON var forkert, fordi XML var klart bedre ?
Der er altid en, er der ikke ?
Anyway, enighed om at Nogen™ burde gøre Noget® og nu videre til næste punkt på dagsordenen...
I toget på vej hjem fra Stockholm besluttede jeg mig for at se hvor stort problemet egentlig var når det kom til stykket, så jeg trawlede alle "Internet Standards Track" RFC'er om HTTP igennem og hev de headere de definerede ud, inklusive deres "ABNF" syntax hvor der var en og så begyndte jeg at refluxdestillere essensen ud af deres definitioner.
Det viste sig at der faktisk var en koncentreret lille essens med en lille men utroligt ildelugtende bærme, primært bestående af "Set-Cookie" og "Cookie".
Efter en smule debat på HTTPwg mailing listen, hvor parametrene og grænserne blev diskuteret, rekursion eller ej ? UniCode eller ej ? skrev Mark Nottingham og undertegnede det "Internet Draft", der efter fem år, 19 revisioner og, ironisk nok, tre måneders XML-wrangling, nu er officiel og allerede bruges i RFC8942.
Fordi formatet er baseret på destillatet af existerende headere kan rigtig mange existerende headers også bruge 8941 maskineriet:
o Accept - List
o Accept-Encoding - List
o Accept-Language - List
o Accept-Patch - List
o Accept-Ranges - List
o Access-Control-Allow-Credentials - Item
o Access-Control-Allow-Headers - List
o Access-Control-Allow-Methods - List
o Access-Control-Allow-Origin - Item
o Access-Control-Max-Age - Item
o Access-Control-Request-Headers - List
o Access-Control-Request-Method - Item
o Age - Item
o Allow - List
o ALPN - List
o Alt-Svc - Dictionary
o Alt-Used - Item
o Cache-Control - Dictionary
o Connection - List
o Content-Encoding - List
o Content-Language - List
o Content-Length - Item
o Content-Type - Item
o Expect - Item
o Expect-CT - Dictionary
o Forwarded - Dictionary
o Host - Item
o Keep-Alive - Dictionary
o Origin - Item
o Pragma - Dictionary
o Prefer - Dictionary
o Preference-Applied - Dictionary
o Retry-After - Item (see caveat below)
o Surrogate-Control - Dictionary
o TE - List
Der også en enkelt nyskabelse, som er helt og holden min: "Byte Sequences".
I stadig større grad er der brug for at flytte kryptorgrafisk skrammel i HTTP headers og det var helt klart ikke noget der var enighed om blandt dem der foreslår nye HTTP headers: Hex? Base64? Base85? og selvfølgelig mere end et selvopfundet format.
Og der var stadig folk der ville kunne transportere Unicode, specielt i fejlmeddelelser.
Kernighans udødelige kritik af Pascal var også in mente: "There is no escape": Uanset hvor godt vi gjorde det, ville der være folk der fik brug for at transportere noget der lå udenfor de fire kanter af vores specifikation, så der var brug for en escape-mechanism.
Mit forslag var base64 mellem to stjerner, hvilket undervejs i stedet blev til mellem to kolon:
:{base64}:
F.eks:
Example-Dict: en="Applepie", da=:w4ZibGV0w6ZydGU=:
Base64 blev valgt fordi det er den variant der komprimerer bedste med Huffman tabellen in RFC7541.
Undervejs skiftede vi også fra "Structured Headers" til "Structured Fields" fordi der, i princippet, også kan være "trailers" i HTTP.
I praksis er trailers ubrugelige med den nuværende definition, et problem HTTPwg nu har arbejde på i over tyve år uden at komme nærmere på en løsning.
Det sætter også de fem år Mark og jeg har brugt i perspektiv.
På en skala fra "Hunden skal vaskes, den lugter" til "Permanent fred i Mellemøsten" ligger RFC8941 helt klart i den lave ende, men jeg tror det har været besværet værd.
phk
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
