HTTP/1.1 er en succes

I lidt over fire år har en arbejdsgruppe i IETF arbejdet på at renskrive specifikationen af HTTP protokollen. Renskrive, helst ikke noget med at tilføje noget nyt. Det er planen at de allersidste detaljer skal være på plad i slutningen at marts.

Det er let at forestille sig formanden for arbejdsgruppen sidde med armene over hovedet og råbe "Mission Accomplished", trille tommelfingre i fem minutter og endelig gå til af kedsomhed. Og hvad er mere nærliggende end at tænke på HTTP/2.0, for nu skal der ske noget nyt!

Google er tilsyneladende allerede langt foran med deres SPDY protokol. Men jeg kan rigtig godt lide HTTP, så måske skulle man lige læne sig tilbage og overveje hvorfor HTTP er så let at arbejde med.

  • Det er let observere hvad der sker mellem en klient og en server. Fat i tcpdump og i værste fald skal man lige adskille de forskellige tcp streams. Der er ikke nogen protokol-specifik multipleksing man lige skal parse.

  • I praksis er kryptering en helt separat protokol. Ikke noget med først lidt ukrypteret trafik og så lidt TLS forhandling. Ofte kan man let slå kryptering fra hvis man skal teste noget i et lukket miljø.

  • Meget lidt protoko-tilstand man skal huske på hvad enten man debugger eller implementerer protokollen.

  • Det er overkommeligt at implementere en simpel server eller klient selv eller i det mindste at forstå en simpel implementation.

Det er faktisk nærved at være min favoritprotokol.

Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Troels Arvin

Hvis HTTP kun er nærved at være din favoritprotokol, hvilken er så favoritprotokollen?

HTTP er glimrende. Eneste irriterende element, jeg lige komme på, er dens tidsstempelformat som jeg synes godt kunne tage at være lidt simplere at parse. Og mht. HTTP-klient-implementationerne kunne jeg godt ønske mig bedre muligheder for at tilpasse login-prompts samt en måde at logge ud uden at skulle lukke hele browseren (jeg taler her om kode 401-agtig autentificering).

  • 2
  • 0
Mikkel Høgh

Nu beskæftiger jeg mig primært websites og -apps, og for mig at se, er ting som SPDY og Websockets tegn på at HTTP ikke længere er tidssvarende (I hvert fald ikke inden for det område).

Efterspørgslen efter mere dynamik og stadig hurtigere responstider belyser ulemperne ved HTTP. En (stort set) stateless protokol, giver en frygtelig masse arbejde på serveren for hver forespørgsel. Hvem spørger? Hvad ved vi om ham? Har han adgang til det? Skal han have særbehandling? Kryptering gør så denne proces endnu langsommere, omend det kan delvist afhjælpes ved brug af keep-alive.

På mange måder tror jeg at HTTP vil blive lidt som en gammeldags skruetrækker. Der er ikke mange håndværkere som ikke har adskillige af disse – men i deres daglige arbejde, bruger de stort set kun de elektiske skruemaskiner. Selvom disse er dyrere, mere komplicerede, har flere fejlmuligheder, skal have deres batterier ladt op, osv. osv.

  • 1
  • 0
Baldur Norddahl

Jeg er ikke helt med på HTTP-protokollens lyksaligheder. Den er fyldt med hacks. En af de værste er 100-continue - en timeout bestemmer om klienten sender en fil eller bare headers. I forsættelse heraf er basic/digest-auth totalt klodset: man sender potentielt en masse data, for at få at vide at det skal du altså sende igen, denne gang med auth detaljer.

Total mangel på mulighed for at push'e noget til klienten medfører work-arounds, som at holde et request kørerende indtil der er data at sende. Dette kombineret med mangel på kontrol over antal tilladte forbindelser, som derfor er sat til 2 i de fleste browsere, medfører reducering eller blokkering af anden trafik. Derfor skal man huske at gøre den slags på et alternativt domæne: hack.

Det virker suboptimalt at cookiedata sendes over med hvert request. Stateless er godt, men serveren kunne jo bare spørge efter det, når det skal bruges.

  • 2
  • 0
Peter Makholm

Jeg er meget enig i dit indlæg på HTTPbis listen. Tidsplanen der er lagt frem siger enten SPDY eller ændringer der reelt bare er search and replace af den nuværende specifikation (erstat "Content-Type:" med "CT:").

Og mest af alt lugter det af førstnævnte model.

Jeg er bare ikke mand nok til at brage ind og delurke på HTTPbis listen og give min holdning til kende, specielt ikke uden at bruge noget mere tid på det. Det kunne sikkert være sjovt at deltag, men med mindre min chef kommer og siger at jeg skal sætte rigeligt af min tid af til det (inklusiv rejsetid), så tror jeg ikke jeg har muligheden.

  • 0
  • 0
Peter Makholm

Jeg er ikke helt med på HTTP-protokollens lyksaligheder. Den er fyldt med hacks. En af de værste er 100-continue - en timeout bestemmer om klienten sender en fil eller bare headers.

Expect og status '100 Continue' er noget jeg først har set glæden af efter jeg har arbejdet med store, betingede PUT requests. At vores kodebase så ikke rigtigt wrapper rundt om Apaches request-håndtering på en måde så vi kan gøre nytte af det er en anden sag...

  • 0
  • 0
Baldur Norddahl

Ja, men læs lige specifikationen:

Because of the presence of older implementations, the protocol allows
ambiguous situations in which a client may send "Expect: 100-
continue" without receiving either a 417 (Expectation Failed) status
or a 100 (Continue) status. Therefore, when a client sends this
header field to an origin server (possibly via a proxy) from which it
has never seen a 100 (Continue) status, the client SHOULD NOT wait
for an indefinite period before sending the request body.

Så hvis serveren er lidt langsom, så kan klienten finde på at sende det hele. Medmindre klienten altså husker noget om serverens tidligere opførsel (stateless?). En antagelse der ikke nødvendigvis holder, for en server kan godt hoste to web applikationer, hvoraf kun den ene implementerer expect/continue korrekt.

Bevares, det fungerer da det meste at tiden. Men elegant synes jeg ikke det er. Det er kun på overfladen at protokollen er enkel. Hvis man vil have alle detaljerne med er det noget rod.

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