HTTP er ikke "one size fits all"

Allan Ebdrup har et problem. Heldigvis har han også fundet en løsning der bruger PATCH udvidelsen til HTTP. Men er det en god løsning? Baldur Norddahl mener det ikke fordi det giver "problemer med gamle browsere og proxy servere".

Men i dag bliver HTTP brugt til meget andet end bare hypertekst fremvist i en browser. HTTP er blevet en generisk protokol som vi rækker ud efter hver gang vi har behov for at implementere en request/response baseret protokol. Dermed bliver HTTP brugt flere steder hvor generiske browsere og generiske proxy-servere ikke længere er relevante.

Selv arbejder jeg meget med WebDAV der definerer 7 nye HTTP metoder. Målgruppen er helt klart ikke webbrowsere men klienter der specifikt er skrevet til at bruge denne ekstra funktionalitet. Ved at anvende SSL omgår vi desuden problemet med systemadministratore der tror de skal pille i vores trafik med en ikke-autoriseret proxy.

Det stiller selvfølgelig nogle krav til vores valg af komponenter. Vi kan ikke anvende et HTTP-library der ikke lader os sætte metoden og vi kan slet ikke anvende en generisk reverse proxy der forsøger at omskrive URL'er. Det første kunne vi løse ved at pakke alt ind i POST requests (unødvendigt overhead), men det andet problem kan bare ikke løses generisk.

Det kræver selvfølgelig at vi som udviklere kender vores domæne og ved hvilke omgivelser vores kode kommer til at køre under. Men gør alle ikke-trivielle udviklingsopgaver i grunden ikke det?

I øjeblikekt er vores største problem med generisk proxy-implementationer at Expect-headeren radikalt ændre på semantikken for HTTP. Det er et problem der kan være ikke-trivielt at rette. At tilføje en ny metode til noget software der hardkoder listen af metoder er nærmest trivielt.

Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Christian Schmidt

Dermed bliver HTTP brugt flere steder hvor generiske browsere og generiske proxy-servere ikke længere er relevante.
[...]
Det kræver selvfølgelig at vi som udviklere kender vores domæne og ved hvilke omgivelser vores kode kommer til at køre under. Men gør alle ikke-trivielle udviklingsopgaver i grunden ikke det?

Det afhænger af din evne til at spå om fremtiden. På kort sigt kender man dem ofte, men hvis man strikker sin egen semantik sammen oven på HTTP, så gør man muligvis nogle ting sværere for sit fremtidige jeg, især hvis man ikke har kontrol over det miljø, som koden skal køre i (hvilket dit SSL-workaround antyder, at du ikke har?).

Der kan være flere årsager til at introducere en (reverse-)proxy-server i et driftsmiljø udover til at performanceoptimere almindelig websurf, fx load-balancering eller firewalling/logning af udgående trafik.

  • 1
  • 0
Peter Makholm

Nu anser jeg ikke SSL som et workaround for fejlopsatte systemer. Det er kun ekstra bonus ved at vi generelt forsøger at undgå at manden i midten har adgang til indholdet. En reverse-proxy opfatter jeg som en del at mit system. Derfor er det selvfølgelig mig der definerer hvilke krav den skal opfylde. Blandt andet terminerer vi netop SSL i en reverse-proxy.

Det der skaber problemer er hvis man vælger at bruge komponenter der er designet til at alt HTTP-trafik er almindelig statisk websurf og jeg opponerer netop imod at alt HTTP-trafik skal opfattes og behandles som var det statisk websurf.

  • 0
  • 0
Jacob Christian Munch-Andersen

HTTP er ikke "one size fits all"

Men det bliver brugt sådan, og WebDAV er da egentlig et symptomatisk eksempel. Man opnår ikke kompatibilitet med HTTP klienter, man opnår blot at protokollen nødvendigvis må bygge oven på det patchwork af hovsaløsninger som vi kalder HTTP.

Der forekommer at herske et ubehageligt standarder for standardernes skyld syndrom. Uanset at en protokol eller et filformat ikke har behov for at være kompatibelt med noget som helst andet, og i øvrigt heller ikke bliver det af den grund, så pakker man det egentlige format ind i et eller flere mere eller mindre egnede standardformater.

Ikke at det nødvendigvis er forkert. Hvis man har værktøjer som gør det særligt nemt at arbejde med netop sådan et format, og prisen i millisekunder og bytes ikke betyder noget særligt kan det være et fint nok valg.

Jeg får bare sådan en grim mavefornemmelse hvis jeg hører en udvikler sige at han har brugt XML som om det er noget at være stolt af, snarere end en tør teknikalitet.

  • 1
  • 0
Baldur Norddahl

Hvad gør du når din direktør stolt kommer og fortæller om årets kontrakt med en støre dansk bank, lad os kalde dem Danske Bank? I bankverden tillader man ikke krypteret trafik som IT afdelingen ikke har styr på, så alt HTTP går igennem en proxy inklusiv HTTPS. SSL bliver dekrypteret på proxien og derefter rekrypteret med et self signed certifikat. Samme self signed certifikat er installeret på brugernes computer, så derfor fungerer det "usynligt". Løsningen er iøvrigt et standard produkt hos Cisco.

Evil? Måske, men bankens formål er at alt trafik skal scannes for malware, virus og decideret hacking. Det dur ikke hvis bad guys bare kan pakke deres ting ind i SSL.

Evil? Måske, men har du stadig et job når direktøren må indse at banken under ingen omstændigheder ændrer på deres setup, og jeres løsning by design ikke fungerer?

  • 1
  • 3
Adam Tulinius

Du har lige sagt at banken selv står for at dekryptere, og re-kryptere skidtet som Peter sender dem. Hvor er problemet? Så længe Cisco-produktet ikke blokerer for ekstra http-verbs er det vel irrelevant..

Desuden synes jeg godt nok det er synd og skam hvis Peter skal selvcensurere sin blog, og kun omtale ting der kan sættes i drift hos DB. Mest af alt lyder det som om du er lidt bitter over at måtte bokse med den slags. ;-)

  • 4
  • 0
Baldur Norddahl

Allan Ebdrup har et problem. Heldigvis har han også fundet en løsning der bruger PATCH udvidelsen til HTTP. Men er det en god løsning? Baldur Norddahl mener det ikke fordi det giver "problemer med gamle browsere og proxy servere".

Jeg kan ikke lade være med at sammenligne RFC 5789 der genopfinder PATCH metoden med RFC 6455 der definerer WebSocket.

PATCH RFC dokumentet er 10 sider langt. Ordet "proxy" nævnes ikke en eneste gang og ej hellere behandles andre problemer med gammelt software. Det nævnes at man kan bruge OPTIONS til at afgøre om en server har PATCH support og det er det.

WebSocket RFC dokumentet er 69 sider langt. Hvis de var gået ligeså let til værks som PATCH RFC'en, kunne de såmænd have nøjedes med 10 sider. I stedet så behandles kompatibilitetsproblemet hele vejen igennem dokumentet. "Proxy" nævnes 17 gange og faktisk er hele protokollen defineret ud fra at det skal fungere med gamle og defekte proxier. Man er gået så langt, så at indholdet skal XOR krypteres for at undgå at visse sjældne gamle og defekt implementeret proxier kan få protokollen galt i halsen.

  • 2
  • 1
Baldur Norddahl

Du har lige sagt at banken selv står for at dekryptere, og re-kryptere skidtet som Peter sender dem. Hvor er problemet? Så længe Cisco-produktet ikke blokerer for ekstra http-verbs er det vel irrelevant..

Ok, det kom måske ikke med over fra den forrige tråd. Problemet er at proxien kløjes i de nye ukendte HTTP metoder. Hacket består i at bruge SSL, så at proxien ikke kan "se" at der bruges alternative HTTP metoder. Problemet er bare at vi kan formode at der er stort sammenfald imellem arbejdspladser hvor man vælger at gøre brug af en HTTP proxy og arbejdspladser hvor man vælger at gøre brug af en SSL dekrypterende HTTP proxy. Derfor er hacket værdiløst.

  • 2
  • 1
Adam Tulinius

WebSocket RFC dokumentet er 69 sider langt. Hvis de var gået ligeså let til værks som PATCH RFC'en, kunne de såmænd have nøjedes med 10 sider. I stedet så behandles kompatibilitetsproblemet hele vejen igennem dokumentet. "Proxy" nævnes 17 gange og faktisk er hele protokollen defineret ud fra at det skal fungere med gamle og defekte proxier. Man er gået så langt, så at indholdet skal XOR krypteres for at undgå at visse sjældne gamle og defekt implementeret proxier kan få protokollen galt i halsen.

I en verden hvor enterprise webbrowsere som IE6 alligevel ikke understøttes, har jeg stor forståelse for at man er ligeglad med tilsvarende enterprise proxy-løsninger, og undrer mig over at WebSocket RFCen går så langt som du påstår. Legacy cruft er en belastning i længden, og det er da meget muligt at WebSockets virker gennem normale proxy-servere, men det har også kompliceret implementationen af WebSockets. Hvor gammelt skrammel skal man (blive ved med at) understøtte?

Desuden er det meget fint at WebSocket RFCen omhandler normale proxy-servere, men måske skulle man også have løst problemet med reverse proxies. Eksempel; hvornår fik nginx websocket-support? Inden for det sidste halve år? Hvad med Apache httpd?

Og igen -- Danske Bank eksemplet er lidt fjollet. Diverse web-teknologier bevæger sig meget stærkt for tiden. Personlig synes jeg det er fedt, men det er selvfølgelig ikke noget man skal gøre brug af hvis kunden tilhører bank-sektoren, som jo nok sætter verdensrekord inden for emnet "gammel software i produktion", men jeg synes nu heller ikke Peter giver udtryk for at man bare skal skrive software først, og så bagefter undersøge hvad kunden rent faktisk vil/kan have i drift.

  • 0
  • 0
Baldur Norddahl

Desuden er det meget fint at WebSocket RFCen omhandler normale proxy-servere, men måske skulle man også have løst problemet med reverse proxies.

WebSocket virker faktisk ikke igennem normale proxy-servere. De har blot brug en hel masse kræfter på at analysere problemet og sikre at det er ok. XOR tricket er for at man ikke skal kunne hacke de gamle proxier, men ikke for at få protokollen til at fungere.

I praksis bruger man fallback til en anden metode hvis der ikke er support. De har sørget for at browseren pålideligt kan detekte dette, mere end bare at henvise til OPTIONS.

I den anden tråd bliver der påpeget at man kan bruge biblioteker der laver fallback i forbindelse med alternative HTTP metoder. Forskellen er at fallback ved REST er præcis ligeså god som den oprindelige metode, så derfor er det bare ekstra arbejde ikke altid at køre med fallback metoden.

I tilfældet WebSocket så er fallback mulighederne IKKE ligeså gode som websocket. Her er fallback ægte nødløsninger. Så der er god grund til at implementere flere metoder.

  • 1
  • 0
Peter Makholm

WebSocket RFC dokumentet er 69 sider langt. Hvis de var gået ligeså let til værks som PATCH RFC'en, kunne de såmænd have nøjedes med 10 sider. I stedet så behandles kompatibilitetsproblemet hele vejen igennem dokumentet.

WebSockets er lidt noget andet fordi det netop ikke er en request/reply-protokol men et forsøg på at pakke tovejs-kommunikation ind i noget der ligner HTTP tilpas meget. Derfor er WebSockets væsenforskelligt fra de udvidelser til HTTP der stadigvæk opfylder det grundlæggende design-koncept med at HTTP består at et request og et reply.

Efter min mening er der WebSockets derfor nærmere at sammenligne med "TCP over DNS" end med udvidelser til HTTP som PATCH-rfc'en eller WebDAV.

Derudover vil jeg da gerne gentage at jeg ikke mener at PATCH er en overvældende gennemarbejdet udvidelse. Basalt set siger den "boilerplate. Her er en ny metoder. Der er en content-type som vi ikke specificerer nærmere. Boilerplate".

Skal vi diskutere kvaliteten og behovet for HTTP-udvidelser vil jeg derfor hellere tage udgangspunkt i WebDAV og de udvidelser der er baseret på WebDAV (Delta-V, SEARCH eller CalDAV for nu at tage vidt forskellige typer udvidelser)

  • 2
  • 0
Morten Brørup

Hvis du er i tvivl, så læs om HTTP 2.0 - her tilføjer man mux/demux af multiple datastrømme, endda med indbyrdes prioritering. Det er et forsøg på at genopfinde det hjul, der allerede findes i diverse QoS-standarder (fx DiffServ), og med vold og magt mase det ind i en protokol, som alle elsker.

Jeg er fuldsændig enig i Jacob Christian Munch-Andersens pointe om "standard for standardens skyld", og hans XML-eksempel er meget tydeligt: XML var engang det store buzzword, så hvis man kunne pakke data ind i XML, var man dygtig (og ingen stillede spørgsmålet, om det var relevant at tilføje det ekstra overhead, som XML giver).

I "gamle dage" fungerede selve operativsystemet som multiplekser/demultiplekser for netværkskommunikation, idet man benyttede forskellige TCP-porte til forskellige formål. Og man benyttede diverse prioritetsbits (TOS, DSCP, VLAN Prio, etc.) til den indbyrdes prioritering af datastrømmene.

Så kom en periode, hvor diverse firewall-administratorer blokerede for alt andet end web-portene (80 og 443). Det affødte, at programmørerne begyndte at benytte web-portene til deres trafik, så den kunne komme igennem firewallen alligevel.

De fleste webservere fik derfor indbygget en demultiplekser, så de kunne overtage den rolle, som operativsystemet tidligere havde på TCP-portniveau. Læs evt. også om HTTP CONNECT-metoden - ren demultipleks.

Nu er det bare ved at tage fuldstændig overhånd med HTTP. Både TCP og DiffServ er "not invented here", så selvfølgelig skal HTTP 2.0 også have en datastrøm-multipleksfunktion og en prioriteringsfunktion.

HTTP er et buzzword. Skal vi spille buzzword bingo? Jeg kan også sige REST og JSON, så er jeg allerede to point foran.

  • 5
  • 1
Jesper Lund
  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize