RFC8941 - Structured Fields

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

Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Emil Kampp

Jeg kunne godt se, hvordan man kunne strukturere det til at forbedre og tilføje til et request når det sendes rundt imellem services i en service orienteret arkitektur.

  • 5
  • 0
#2 Stig Christensen

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".

Mener du her, at cookie headeren var defineret på forskellige måder?

Jeg tænker, det er jo ofte en header, hvori man gemmer vilkårlig tekst, og så er det jo oplagt at bruge byte sekvensen.

Hvordan vil det gå med implementeringerne, bliver det bare hurtigt accepteret og udbredt?

  • 2
  • 0
#3 Jesper S. Møller

Solidt arbejde at finde en fælles struktur, der retrofitter så lang en liste af kendte felter, det vil helt sikkert kunne hjælpe til at stramme parsning og serialisering gevaldigt op.

Men det er god nok en meget åben informationsmodel, der tillades i det generelle tilfælde. Har I gjort jer tanker om hvordan en RFC ville kunne specificere anvendelsen i praksis, hvor jeg antager at man tager udgangspunkt i RFCens produktioner, med uden at skulle gen-specificere den konkrete syntaks?

  • 7
  • 0
#4 Poul-Henning Kamp Blogger

Mener du her, at cookie headeren var defineret på forskellige måder?

Cookie og Set-Cookie er begge defineret så hvis der er flere headers, er de separate entiteter.

Alle andre HTTP headers er defineret så hvis der er flere headers, kan de samles til en med et komma imellem.

Derudover er selve syntaxen af headerne heller ikke "kanonisk" i forhold til det normale HTTP header design-mønster.

  • 2
  • 0
#10 Poul-Henning Kamp Blogger

Har du et eksempel på en konkret use-case hvor structured fields, gør implementeringen nemmere/renere?

Egentlig kun listen i blogindlægget af existerende felter som er "structured" selvom de ikke er defineret som sådan i deres respektive RFC'er.

Jeg kender til ca. en håndfuld "Internet Drafts" der bruger RFC8941 til at definere deres felter, men hvor mange af dem der nogensinde når RFC status er tvivlsomt.

  • 1
  • 0
#15 Casper Bang

XML eller JSON, jeg forstår stadig ikke behovet for at gøre det nemt for mennesker. Det er computere der dekomprimerer indhold og for et Huffman træ spiller localization i forhold til entropi vel en ret stor rolle? Altså, key1,key2, key3; value1,value2,value3 er at foretrække frem for key1;value1,key2;value2,key3;value3?

  • 0
  • 0
Log ind eller Opret konto for at kommentere