Minor language corrections in the Swedish version.

sv/part1.md

@@ -6,9 +6,9 @@ sedemera gjordes om och breddades till ett fullt utvecklat dokument med alla
 detaljer och riktiga förklaringar.
 
 RFC 7540 är det officiella namnet på den slutliga http2-specifikationen och den
-blev publicerad den 15:e maj 2015: https://www.rfc-editor.org/rfc/rfc7540.txt
+publicerades den 15:e maj 2015: https://www.rfc-editor.org/rfc/rfc7540.txt
 
-Alla misstag i det är dokumentet är mina egna och resultatet av mina fel. Peka
+Alla misstag i det här dokumentet är mina egna och resultatet av mina fel. Peka
 gärna ut dem så åtgärdar vi dem till en kommande uppdatering.
 
 I det här dokumentet har jag försökt att konsekvent använda ordet "http2" för
@@ -18,7 +18,7 @@ ett bättre flöde i texten.
 
 ## 1.1 Författaren
 
-Mitt namn är Daniel Stenberg och jag jobbar för Mozilla. Jag har arbetat med
+Mitt namn är Daniel Stenberg. Jag har arbetat med
 open source och nätverk i över tjugo år i otaliga projekt. Möjligvis är jag
 mest känd för att jag är huvudutvecklaren av curl och libcurl. Jag har varit
 involverad i IETF och dess HTTPbis arbetsgrupp under flera år och där har jag

sv/part10.md

@@ -18,7 +18,7 @@ Skriv in “chrome://flags/#enable-spdy4" i din webbläsares adressfält och kli
 
 ## 10.2. Endast TLS
 
-Kom ihåg at Chrom bara implementerat http2 över TLS. Du kommer endast see
+Kom ihåg at Chrome bara implementerat http2 över TLS. Du kommer endast see
 http2 i aktion i Chrome när du går til https://-sajter som erbjuder http2-support.
 
 ## 10.3. Se HTTP/2-anvädning

sv/part11.md

@@ -10,7 +10,7 @@ webbsajter och vi tänker fortsätta med det för http2 också.
 curl använder det separata biblioteket [nghttp2](https://nghttp2.org/) för all
 funktionalitet i http2-lagret. curl kräver nghttp2 1.0 eller senare.
 
-Notera att just nu skippas curl på linux inte alltid med http2-support
+Notera att just nu skeppas curl på linux inte alltid med http2-support
 påslaget.
 
 ## 11.1. HTTP 1.x-liknande

sv/part2.md

@@ -8,7 +8,7 @@ saker att köra över HTTP hellre än att bygga något som är helt nytt och ege
 ## 2.1 HTTP 1.1 är stort
 
 När HTTP skapades och slängdes ut i världen ansågs det antagligen vara ett
-ganska enkelt och rakt-fram protokoll, men tiden har bevisat att detta inte är
+ganska enkelt och rättframt protokoll, men tiden har bevisat att detta inte är
 sant. HTTP 1.0 är RFC 1945 som är en 60 sidors specifikation släppt 1996. RFC
 2616, som beskriver HTTP 1.1, släpptes bara tre år senare 1999, och växte
 avsevärt till sina 176 sidor. Trots att den redan växt så, delade IETF senare
@@ -24,7 +24,7 @@ senare utökningar har lett till ett ekosystem av programvara där nästan ingen
 implementation någonsin implementerar allting - och det är inte ens möjligt
 att riktigt säga vad "allting" är. Det ledde till en situation där funktioner
 i protokollet som utnyttjades väldigt lite ofta inte alls implementerades - i
-början - och de fall när någon faktiskt implementerade dem såg de väldigt
+början - och i de fall när någon faktiskt implementerade dem såg de väldigt
 liten användning.
 
 Senare skapade detta interoperabilitetsproblem när klienter och servrar väl
@@ -50,7 +50,7 @@ avsnitten belyser några av de existerande bristerna.
 När man tittar på trenden för några av de mest populära sajterna på webben
 idag och vad det krävs för att ladda ner deras framsidor, så ser man ett
 tydligt mönster. Genom åren har mängden data som behöver laddas ner gradvis
-ökat till och förbi 2.1MB. Vad som är än viktigare i det här sammanhanget är
+ökat till och över 2,1 MB. Något som är än viktigare i det här sammanhanget är
 att i genomsnitt så behövs det över ett hundra enskilda objekt för att visa
 varje sida.
 
@@ -70,7 +70,7 @@ HTTP 1.1 är väldigt känsligt för fördröjningar (latency), delvis för att
 Pipelining fortfarande är fyllt med problem och är avslaget per default hos en
 stor andel av användarna.
 
-Medan vi sett en rejäl ökning i tillgänglig bandbredd hos människor över de
+Medan vi sett en rejäl ökning i tillgänglig bandbredd för användare över de
 senaste åren, så har vi inte sett samma förbättring i att minska
 fördröjningar. Länkar med stora fördröjningar, som många nuvarande mobila
 teknologier, gör det riktigt svårt att få en bra och snabb upplevelse av
@@ -96,7 +96,7 @@ rätt kö, och ibland kan du till och med starta en ny, egen kö, men hur du än
 gör så kan du inte undvika att ta ett beslut och när det väl är taget kan du
 inte byta kö.
 
-Skapa nya köer är också belagt med prestanda- och resurs-förluster så det
+Skapa nya köer är också belagt med prestanda- och resursförluster så det
 skalar inte upp bra till mer än ett ganska lågt antal köer. Det finns helt
 enkelt ingen perfekt lösning för detta.
 

sv/part3.md

@@ -52,7 +52,7 @@ logiskt resonemang bakom.
 
 Från början sade HTTP 1.1-specifikationen att en klient endast var tillåten
 att använda maximalt två TCP-koppel till varje host. Så, för att inte bryta
-mot specen uppfann smarta sajter nya host namn och - voilá - så kunde du få
+mot specen uppfann smarta sajter nya hostnamn och - voilá - så kunde du få
 många fler koppel till din sajt och minska sidladdningstider.
 
 Över tid har den gränsen tagits bort och dagens klienter använder lätt 6-8
@@ -61,17 +61,17 @@ fortsätter att använda den här tekniken för att öka antalet koppel. Med ett
 ständigt ökande antal objekt (som jag visade tidigare) så måste ett än större
 antal koppel användas för att få HTTP att prestera bra och göra din sajt
 snabb. Det är inte ovanligt att enskilda sajter använder långt över 50 eller
-upp och förbi 100 koppel tack vare den här tekniken. Färsk statistik från
+upp till och över 100 koppel tack vare den här tekniken. Färsk statistik från
 httparchive.org visar att av de 300 000 mest populära URLerna i världen så
 behövs i genomsnitt 40(!) TCP-koppel för att visa sajten, och trendkurvan
 säger att det fortsätter växa.
 
 En annan anledning att också lägga bilder och liknande resurser på ett separat
 hostnamn som inte använder cookies, är att storleken på cookies idag kan bli
-betydande. Genom att använda cookie-lösa bild-värdar så kan du ibland öka
+betydande. Genom att använda cookie-lösa bildvärdar så kan man ibland öka
 prestandan enbart genom att HTTP-förfrågningarna blir så mycket mindre!
 
-Bilden nedan visar paket-spårning och hur det ser ut när en webbläsare besöker
+Bilden nedan visar paketspårning och hur det ser ut när en webbläsare besöker
 en av Sveriges toppsajter, och hur förfrågningarna är distribuerade över flera
 olika hostnamn.
 

sv/part4.md

@@ -17,8 +17,8 @@ practices", HTTP och mängder med protokollvarianter som aldrig kom någon vart.
 
 Inom IETF formas arbetetsgrupper (working groups) med ett avgränsat
 arbetsområde som jobbar mot ett mål. De etablerar en stadga med ett antal
-riktlinjer och begränsningar för vad de ska åstadkomma. Alla som vill är
-tillåtna att delta i diskussionerna och utvecklingen. Alla som deltar och
+riktlinjer och begränsningar för vad de ska åstadkomma. Alla som vill får
+lov att delta i diskussionerna och utvecklingen. Alla som deltar och
 säger något har samma vikt och chans att påverka utgången, och alla är där som
 enskilda individer. Det läggs väldigt liten vikt vid vilka företag individerna
 jobbar för.
@@ -52,7 +52,7 @@ som i fallet för HTTP 1.1.
 [SPDY](https://en.wikipedia.org/wiki/SPDY) är ett protokoll som utvecklades och
 togs fram av Google. De utvecklade det visserligen öppet och bjöd in alla som
 ville att delta, men det var tydligt att de utnyttjade sin situation med att
-kontrollera både en populär webbläsare och ett signifikant server-bestånd med
+kontrollera både en populär webbläsare och ett signifikant serverbestånd med
 välanvända tjänster.
 
 När HTTPbis-arbetsgruppen bestämde att det var dags att börja jobba på http2

sv/part5.md

@@ -6,33 +6,33 @@ satte sig för att göra?
 De var faktiskt ganska strikta och satte ett antal begränsningar för gruppens
 möjligheter att förnya protokollet.
 
-- Det måste behålla HTTP:s paradigmer. Det måste fortfarande ett protokoll där
-  klienten skickar förfrågningar till en server över TCP.
+- Det måste behålla HTTP:s paradigmer. Det måste fortfarande vara ett protokoll
+  där klienten skickar förfrågningar till en server över TCP.
 
-- http://- och https://-URLer kan inte ändras. Det kan inte göras ett nytt
+- http://- och https://-URLer får inte ändras. Det får inte göras ett nytt
   schema. Mängden innehåll som redan använder sådana URLer är helt enkelt för
   stor för att tro att de kan ändras.
 
 - HTTP1-servrar och klienter kommer finnas kvar i decennier, vi måste kunna
   erbjuda proxys för http2-servrar.
 
-- Därför måste proxys kunna mappa http2-funktioner till HTTP 1.1-klienter, ett
-  till ett.
+- Därför måste proxys kunna översätta http2-funktioner till HTTP 1.1-klienter,
+  en till en.
 
 - Ta bort eller minska antalet valbara delar i protokollet. Det var inte
   riktigt ett krav men mer som ett mantra som följde med från SPDY och
   Google-teamet. Genom att se till att allting var obligatoriskt så finns det
   inte något sätt som man kan undvika att implementera allt nu och sedan
   upptäcka problemen i framtiden.
 
-- Ingen mera fraktionsdel i versionsnumret. Det beslöts att klienter och
+- Ingen mera decimaldel i versionsnumret. Det beslöts att klienter och
   servrar är antingen kompatibla med http2 eller så är de det inte. Om det
   kommer ett behov att utöka protokollet eller ändra saker så kommer http3 att
   skapas. Det finns inte något "minor version" i http2.
 
 ## 5.1. http2 för existerande URI-scheman
 
-Som tidigare nämnts så kan inte existerande URI-scheman ändras, så http2 var
+Som tidigare nämnts så får inte existerande URI-scheman ändras, så http2 var
 tvunget att göras med de redan existerande. Eftersom de används för HTTP 1.x
 idag så behövde vi förstås ett sätt att uppgradera protokollet till http2
 eller på något vis be servern använda http2 istället för äldre protokoll.
@@ -67,7 +67,7 @@ mellan-boxar att blanda sig i och förstöra trafik när det faktiskt är något
 annat protokoll som pratas där.
 
 Obligatorisk TLS är ett ämne som orsakat mycket handviftande och upprörda
-röster på mailinglistor och möten - är det bra eller är det ondska? Det är ett
+röster på mailinglistor och möten - är det gott eller är det ont? Det är ett
 infekterat ämne - var medveten om detta när du kastar den här frågan i
 ansiktet på en HTTPbis-deltagare!
 
@@ -82,7 +82,7 @@ finns krav på vilka chiffer som måste användas.
 
 Next Protocol Negotiation (NPN), är tillägget som användes i SPDY för att
 förhandla med TLS-servrar. Eftersom det inte var en riktig standard så togs
-det till IETF och igenom och det som kom ut blev ALPN: Application Layer
+det till och igenom IETF och det som kom ut blev ALPN: Application Layer
 Protocol Negotiation. ALPN är det som nu lyfts upp för att användas i http2,
 medan SPDY-klienter och -servrar fortsätter använda NPN.
 
@@ -92,7 +92,7 @@ servrar är gjorda att använda båda dessa tillägg när de förhandlar
 http2. Vidare, eftersom NPN används för SPDY och många servrar ju stöder både
 SPDY och http2 så är det vettigt att stödja både NPN och ALPN på sådana servrar.
 
-ALPN skiljer sig i huvudsak från NPN genom vet det är som bestämmer vilket
+ALPN skiljer sig i huvudsak från NPN genom vem det är som bestämmer vilket
 protokoll som pratas. Med ALPN är det klienten som ger servern en lista med
 protokoll i den ordningen den föredrar att använda dem, och servern väljer det
 protokoll den vill ha, medan för NPN så är det klienten som gör det slutliga
@@ -102,9 +102,9 @@ valet.
 
 Som tidigare nämnts i förbifarten, för klartext-HTTP 1.1 så är mekanismen att
 förhandla http2 att fråga servern med en Upgrade:-header. Om servern då pratar
-http2 svarar den med en "101 Byter" status och från då och framöver pratar den
-istället http2 på det kopplet. Du inser förstås att den
-uppgraderingsproceduren kostar en hel nätverks fram-och-tillbaka-tur men en
+http2 svarar den med en "101 Byter" status och från det och framöver pratar den
+istället http2 på det kopplet. Man inser förstås att den
+uppgraderingsproceduren kostar en hel fram-och-tillbaka-tur i nätverket men en
 fördel är att ett http2-koppel bör vara möjligt att hålla levande och
 återanvända i mycket högre grad än HTTP1-koppel generellt är.
 

sv/part6.md

@@ -36,14 +36,14 @@ liknande.
 
 <img style="float: right;" src="https://raw.githubusercontent.com/bagder/http2-explained/master/images/frame-layout.png" />
 
-http2 skickar binära paket ("frames"). Det finns olika paket-typer som kan
+http2 skickar binära paket ("frames"). Det finns olika pakettyper som kan
 skickas och de har allihop samma upplägg:
 
-Längd, typ, flaggor, ström-id och paket-data ("payload").
+Längd, typ, flaggor, ström-id och paketdata ("payload").
 
-Det finns tio olika paket-typer definierade i http2-specen och de två kanske
+Det finns tio olika pakettyper definierade i http2-specen och de två kanske
 mest fundamentala som direkt mappar HTTP 1.1-funktioner är DATA och
-HEADERS. Jag kommer beskriva några av paket-typerna i närmare detaljer nedan.
+HEADERS. Jag kommer beskriva några av pakettyperna i närmare detaljer nedan.
 
 ## 6.3. Multiplexade strömmar
 
@@ -56,7 +56,7 @@ Ett enda http2-koppel kan överföra många samtidiga strömmar mellan
 ändpunkterna genom att skicka paket från olika strömmar över kopplet. Strömmar
 kan etableras och användas ensidigt eller delas av både klienten och servern
 och de kan stängas av endera sidan. Ordningen som paketen skickas inom
-strömmen behålls, så mottagaren tar emot de i samma ordning som de skickades.
+strömmen behålls, så mottagaren tar emot dem i samma ordning som de skickades.
 
 Multiplexande strömmar betyder att paket från många strömmar blandas och
 skickas över samma koppel. Två (eller fler) individuella tåg med data trycks
@@ -77,11 +77,11 @@ resursbrist tvingar servern att välja vilka strömmar som ska skickas först.
 
 Genom att använda ett PRIORITY-paket kan en klient också berätta för servern
 vilken annan ström den beror på. Detta möjliggör för en klient att bygga ett
-"träd" med prioriteter där flera "barn-strömmar" kan bero att
+"träd" med prioriteter där flera "barn-strömmar" kan bero på att
 "föräldra-strömmar" först avslutas.
 
 Prioritetsvikter och beroenden kan ändras dynamiskt under körning, vilket bör
-tillåta webbläsare att se till att när användare scrollar ner en sida full med
+göra att webbläsare kan se till att när användare scrollar ner en sida full med
 bilder så kan den berätta vilka bilder som är viktigast, eller om du byter
 tabbar så kan den prioritera en ny uppsättning strömmar som då plötsligt
 kommer i fokus.
@@ -91,10 +91,10 @@ kommer i fokus.
 HTTP är ett state-löst protokoll. I korthet betyder det att varje förfrågan
 måste ta med sig precis så mycket detaljer som servern behöver för att serva
 den frågan utan att servern ska behöva mellanlagra info eller meta-data från
-tidigare förfrågningar. Eftersom http2 inte ändra några sådana paradigmer så
-måste det också fungera så.
+tidigare förfrågningar. Eftersom http2 inte får ändra några sådana paradigmer
+så måste det också fungera så.
 
-Detta gör HTTP repetativt. När en klient frågar efter många resurser från
+Detta gör HTTP repetitivt. När en klient frågar efter många resurser från
 samma server, typ bilder på en webbsida, så kommer det göras en lång serie med
 förfrågningar som ser nästan identiska ut. En serie med nästan identiska
 någonting ber om komprimering.
@@ -122,8 +122,8 @@ Att komprimera dynamiskt innehåll för ett protokoll utan att bli sårbar för
 dessa attacker kräver lite omtanke och försiktiga övervägningnar. Det är vad
 HTTPbis-teamet försökte sig på.
 
-In kommer då [HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt), Header-
-komprimering för http2, vilket – som namnet lämpligt indikerar - är ett
+In kommer då [HPACK](https://www.rfc-editor.org/rfc/rfc7541.txt),
+Header-komprimering för http2, vilket – som namnet lämpligt indikerar - är ett
 komprimeringsformat speciellt framtaget för http2-headers och det är strikt
 talat specificerat i en egen specifikation. Det nya formatet, tillsammans med
 andra motåtgärder, som en bit som ber mellanhänder att inte komprimera en viss
@@ -147,7 +147,7 @@ det kommer till priset av att du måste förhandla upp ett nytt TCP-koppel igen.
 
 En bättre lösning skulle vara att bara stoppa meddelandet och skicka ett
 nytt. Det kan göras med http2:s RST_STREAM-paket som därmed hjälper till att
-undvika slösa på bandbredd och onödiga nedrivningar av koppel.
+undvika att slösa på bandbredd och onödiga nedrivningar av koppel.
 
 ## 6.7. Server push
 
@@ -163,9 +163,9 @@ pushad ström med RST_STREAM ifall den inte vill ha den.
 
 ## 6.8. Flödeskontroll
 
-Varje individuell ström över http2 har sin eget annonserade flödesfönster som
+Varje individuell ström över http2 har sitt eget annonserade flödesfönster som
 den andra sidan är tillåten att sända data för. Det är väldigt likt hur SSH
-fungerar i stil och koncept, om du råkar veta hur det fungerar.
+fungerar i stil och koncept, om du råkar känna till hur det fungerar.
 
 För varje ström måste båda sidor berätta för den andra hur mycket utrymme det
 finns att lagra inkommande data i, och den andra änden har bara tillåtelse att