Share
HTTP står för Hypertext Transfer Protocol. Det är ett statlöst, applikationslager protokoll för kommunikation mellan distribuerade system och ligger till grund för den moderna webben. Som webbutvecklare måste vi alla ha en stark förståelse för detta protokoll.
Låt oss granska detta kraftfulla protokoll genom en webbutvecklares lins. Vi tar itu med ämnet i två delar. I den här första inledningen kommer vi att täcka grunderna och skissera de olika förfrågnings- och svarhuvudena. I uppföljningsartikeln granskar vi specifika delar av HTTP - nämligen cachning, anslutningshantering och autentisering.
Även om jag ska nämna några detaljer relaterade till rubriker är det bäst att i stället kontakta RFC (RFC 2616) för djup täckning. Jag kommer att peka på specifika delar av RFC genom hela artikeln.
Om du har problem med ett HTTP-fel i WordPress som du behöver fixa kan du beställa en Express HTTP-felkorrigering på Envato Studio och få felet fixat på en dag för bara $ 50.
HTTP möjliggör kommunikation mellan olika värdar och klienter, och stöder en blandning av nätverkskonfigurationer.
För att göra det möjligt antar det mycket lite om ett visst system och håller inte tillstånd mellan olika meddelandeutbyten.
Detta gör HTTP a statslös protokoll. Kommunikationen sker vanligen över TCP / IP, men någon tillförlitlig transport kan användas. Standardporten för TCP / IP är 80, men andra portar kan också användas.
Anpassade rubriker kan också skapas och skickas av kunden.
Kommunikation mellan en värd och en klient sker via en förfrågan / svarspar. Klienten initierar ett HTTP-förfrågningsmeddelande, som servas genom ett HTTP-svarmeddelande i gengäld. Vi kommer att titta på detta grundläggande budskapspar i nästa avsnitt.
Den nuvarande versionen av protokollet är HTTP / 1,1, vilket lägger till några extra funktioner till den tidigare 1.0-versionen. Den viktigaste av dessa, enligt min mening, innefattar ihållande anslutningar, chunked överföringskodning och finkorniga cachinghuvuden. Vi kommer kortfattat att ta reda på dessa funktioner i den här artikeln; Fördjupad täckning kommer att tillhandahållas i del två.
Kärnan i webbkommunikation är begäran, som skickas via Uniform Resource Locators (URLs). Jag är säker på att du redan är bekant med webbadresser, men för fullständighetens skull kommer jag att inkludera den här. Webbadresser har en enkel struktur som består av följande komponenter:
Protokollet är typiskt http, men det kan också vara https för säker kommunikation. Standardporten är 80, men man kan uttryckas explicit, som illustreras i bilden ovan. Resursvägen är lokal väg till resursen på servern.
Det finns också webbfelsökningsproxys, som Fifflare på Windows och Charles Proxy för OSX.
URL-adresser avslöjar identiteten för den specifika värd som vi vill kommunicera med, men åtgärden som ska utföras på värden specificeras via HTTP-verb. Självklart finns det flera åtgärder som en klient vill att värden ska utföra. HTTP har formaliserats på några fånga de väsentliga som är universellt tillämpliga för alla typer av applikationer.
Dessa begäran verb är:
Ovanstående fyra verb är de mest populära, och de flesta verktyg och ramar exponerar uttryckligen dessa begäran verb. SÄTTA och RADERA betraktas ibland som specialiserade versioner av POSTA verb, och de kan vara förpackade som POSTA Förfrågningar med nyttolast som innehåller den exakta åtgärden: skapa, uppdatering eller radera.
Det finns några mindre använda verb som HTTP också stöder:
Accentsconagua
Via rubrikfält. Detta kan användas för diagnostiska ändamål.Med webbadresser och verb kan klienten initiera förfrågningar till servern. I gengäld svarar servern med statuskoder och meddelande nyttolast. Statuskoden är viktig och berättar klienten hur man tolkar serverns svar. HTTP-specifikationen definierar vissa talintervall för specifika typer av svar:
Alla HTTP / 1.1-klienter är skyldiga att acceptera
Transfer-Encodingrubrik.
Denna klass av koder introducerades i HTTP / 1.1 och är rent preliminärt. Servern kan skicka en Förvänta: 100-fortsätt meddelande, berätta för klienten om att fortsätta att skicka resten av begäran, eller ignorera om den redan har skickat den. HTTP / 1.0-klienter ska ignorera denna rubrik.
Detta berättar för kunden att förfrågan har bearbetats. Den vanligaste koden är 200 OK. För en SKAFFA SIG begäran skickar servern resursen i meddelandekroppen. Det finns andra mindre vanliga koder:
404 indikerar att resursen är ogiltig och inte finns på servern.
Detta kräver att kunden vidtar ytterligare åtgärder. Det vanligaste användningsfallet är att hoppa till en annan URL för att hämta resursen.
Plats Svarhuvudet innehåller den temporära URL: en.ETag (Enttity Tag) information som är en hash för innehållet. Servern jämför detta med sin egen beräknade ETag att kontrollera om ändringar.Dessa koder används när servern anser att kunden är fel, antingen genom att begära en ogiltig resurs eller gör en dålig begäran. Den mest populära koden i den här klassen är 404 Ej Hittad, som jag tror att alla kommer att identifiera med. 404 indikerar att resursen är ogiltig och inte finns på servern. De andra koderna i den här klassen är:
Tillstånd rubrik. Om klienten redan inkluderade Tillstånd rubrik, då var uppgifterna felaktiga.Denna klass av koder används för att ange ett serverfel när behandlingen behandlas. Den vanligaste felkoden är 500 Intern Serverfel. De andra i den här klassen är:
Hittills har vi sett det Webbadresser, verb och statuskoder utgöra de grundläggande delarna av ett HTTP-förfrågan / svarspar.
Låt oss nu titta på innehållet i dessa meddelanden. HTTP-specifikationen anger att en begäran eller ett svarmeddelande har följande generiska struktur:
meddelande =* ( ) CRLF [ ] = Request-Line | Status-Line = Fältnamn ':' Fält-värde
Det är obligatoriskt att placera en ny linje mellan meddelandehuvud och kropp. Meddelandet kan innehålla en eller flera rubriker, av vilka de i stor utsträckning klassificeras i:
Meddelandekroppen kan innehålla fullständiga entitetsdata, eller det kan vara piecemeal om den klumpiga kodningen (Överföring-kodning: chunked) är använd. Alla HTTP / 1.1-klienter är skyldiga att acceptera Transfer-Encoding rubrik.
Det finns några rubriker (allmänna rubriker) som delas av både förfrågnings- och svarmeddelanden:
general-header = Cache-Control | Anslutning | Datum | Pragma | Trailer | Transfer-Encoding | Uppgradera | Via | Varning
Vi har redan sett några av dessa rubriker, specifikt Via och Transfer-Encoding. Vi kommer att täcka Cache-Control och Förbindelse i del två.
Statuskoden är viktig och berättar klienten hur man tolkar serverns svar.
Via header används i ett TRACE-meddelande och uppdateras av alla intermittenta proxyer och gatewaysPragma anses vara en anpassad rubrik och kan användas för att inkludera implementeringsspecifika rubriker. Det vanligaste pragma-direktivet är Pragma: No-Cache, vilket verkligen är Cache-Control: no-cache under HTTP / 1.1. Detta kommer att beskrivas i del 2 i artikeln.Datum rubrikfält används för att stämpla förfrågan / svarmeddelandetuppgradering används för att byta protokoll och tillåta en smidig övergång till ett nyare protokoll.Transfer-Encoding brukar användas för att bryta svaret i mindre delar med Överföring-kodning: chunked värde. Detta är en ny rubrik i HTTP / 1.1 och möjliggör streaming av svar till klienten istället för en stor nyttolast.Anmälnings- och svarmeddelanden kan också innehålla enhetens rubriker för att ge meta-information om innehållet (t.ex. Meddelandeorgan eller Enhet). Dessa rubriker inkluderar:
entity-header = Tillåt | Content-Encoding | Innehållsspråk | Innehållslängd | Innehålls-plats | Innehåll-MD5 | Innehållsintervall | Innehållstyp | Löper ut | Senast ändrad
Alla Innehåll- prefixade rubriker ger information om strukturen, kodningen och storleken på meddelandekroppen. Vissa av dessa rubriker måste vara närvarande om enheten är en del av meddelandet.
De Utgår rubrik indikerar en tidsstämpel för vilken han eller hon upphör. Intressant, a "går aldrig ut" Enheten skickas med ett tidsstämpel om ett år till framtiden. De Senast ändrad rubrik anger den senaste ändringstidsstämpeln för enheten.
Anpassade rubriker kan också skapas och skickas av kunden; De kommer att behandlas som enhethuvuden med HTTP-protokollet.
Det här är verkligen en förlängningsmekanism, och vissa klient-server-implementeringar kan välja att kommunicera specifikt över dessa förlängningshuvuden. Även om HTTP stöder anpassade rubriker är det som söker efterfrågan och svarhuvudet, som vi täcker nästa.
Förfrågningsmeddelandet har samma generiska struktur som ovan, förutom förfrågningsraden som ser ut som:
Request-Line = Metod SP URI SP HTTP-Version CRLF Metod = "OPTIONS" | "HEAD" | "GET" | "POST" | "PUT" | "DELETE" | "SPÅR"
SP är mellanseparatorn mellan tokens. HTTP-version anges som "HTTP / 1,1" och sedan följt av en ny linje. Således kan ett typiskt förfrågningsmeddelande se ut:
GET / articles / http-basics HTTP / 1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Acceptera: text / html, application / xhtml + xml, application / xml; q = 0,9, * / *; q = 0,8
Observera förfrågningsraden följt av många begäranhuvuden. De Värd header är obligatoriskt för HTTP / 1.1-klienter. SKAFFA SIG Förfrågningar har inte ett meddelandeorgan, men POSTA Förfrågningar kan innehålla postdata i kroppen.
Förfrågningsrubrikerna fungerar som modifierare av begäran meddelande. Den fullständiga listan med kända begäranhuvuden är inte för lång och finns nedan. Okända rubriker behandlas som fält för enhetshuvud.
request-header = Acceptera | Acceptera-Charset | Accept-Encoding | Accept-Language | Auktorisation | Förvänta | Från | Värden | If-Match | Om-Modifierad-Sedan | If-None-Match | If-Range | Om-omodifierad-sedan | Max-framåt | Proxy-Authorization | Område | Referer | TE | User-Agent
De Acceptera prefixade rubriker anger de acceptabla medietyperna, språk och teckenuppsättningar på klienten. Från, Värd, referer och User-Agent Identifiera detaljer om den klient som initierade begäran. De Om- prefixade rubriker används för att göra en förfrågan mer villkorlig, och servern returnerar endast resursen om villkoret matchar. Annars returnerar den a 304 Ej modifierad. Villkoren kan baseras på en tidstämpel eller en ETag (en enhetens hash).
Svarformatet liknar begäran, med undantag för statusraden och rubrikerna. Statusraden har följande struktur:
Status-Line = HTTP-Version SP Status-kod SP Reason-Phrase CRLF
HTTP / 1,1 En typisk statusrad för ett lyckat svar kan se ut så här:
HTTP / 1.1 200 OK
Svarhuvudena är också ganska begränsade, och hela uppsättningen anges nedan:
response-header = Accept-Ranges | Ålder | ETag | Plats | Proxy-Authenticate | Försök igen efter Server | Vary | WWW-Authenticate
Ålder är tiden i sekunder sedan meddelandet genererades på servern.ETag är MD5-hash för enheten och brukade kontrollera efter ändringar.Plats används när en omdirigering skickas och innehåller den nya webbadressen.server identifierar servern som genererar meddelandet.Det har varit mycket teori fram till den här tiden, så jag kommer inte att skylla dig för dåsiga ögon. I nästa avsnitt kommer vi att bli mer praktiska och undersöka verktygen, ramarna och biblioteken.
Det finns ett antal verktyg för att övervaka HTTP-kommunikation. Här listar vi några av de mer populära verktygen.
Utan tvekan, den Chrome / Webkit inspektör är en favorit bland webbutvecklare:
Det finns också webbfelsökningsproxys, som Fifflare på Windows och Charles Proxy för OSX. Min kollega Rey Bango skrev en utmärkt artikel om detta ämne.
För kommandoraden har vi verktyg som curl, tcpdump och tshark för övervakning av HTTP-trafik.
Nu när vi har tittat på begäran / svarmeddelanden är det dags att vi lär oss hur bibliotek och ramar exponerar det i form av ett API. Vi ska använda ExpressJS för Node, Ruby on Rails, och jQuery Ajax som våra exempel.
Om du bygger webbservrar i NodeJS är chansen hög att du har ansett ExpressJS. ExpressJS var ursprungligen inspirerad av ett Ruby Web-ramverk, kallat Sinatra. Som förväntat påverkas API också lika.
Eftersom vi hanterar ett serverns ramverk, finns det två primära uppgifter när vi hanterar HTTP-meddelanden:
Förstå HTTP är avgörande för att ha ett rent, enkelt och RESTful gränssnitt mellan två ändpunkter.
ExpressJS ger ett enkelt API för att göra just det. Vi kommer inte att täcka detaljerna i API: n. Istället kommer vi att tillhandahålla länkar till den detaljerade dokumentationen om ExpressJS-guider. Metoderna i API är i de flesta fall självförklarande. Ett urval av API: n för begäran är nedan:
Värd rubrikfält.På väg ut till klienten tillhandahåller ExpressJS följande respons API:
Förfrågnings- och svarmeddelandena är mestadels desamma, förutom första raden och meddelandehuvuden.
I Rails tillhandahåller ActionController och ActionDispatch-modulerna API för hantering av förfrågan och svarmeddelanden.
ActionController tillhandahåller ett API på hög nivå för att läsa begäranadressen, göra utdata och omdirigera till en annan slutpunkt. En slutpunkt (aka-rutt) hanteras som en åtgärdsmetod. De flesta nödvändiga sammanhangsinformationen inom en åtgärdsmetod tillhandahålls via begäran, svar och params objekt.
ActionDispatch ger finkornad tillgång till begäran / svarmeddelanden, via ActionDispatch :: Request och ActionDispatch :: Response klasser. Det avslöjar en uppsättning av sökmetoder för att kontrollera typen av förfrågan (skaffa sig?(), posta?(), huvud?(), lokal?()). Förfrågningsrubriker kan nås direkt via request.headers () metod.
På svarsidan ger det metoder att ställa in småkakor(), plats = () och status = (). Om du känner dig äventyrlig kan du också ställa in kroppen = () och förbi Rails rendering system.
Eftersom jQuery är främst ett klientsidebibliotek, ger Ajax API ett motsats till ett serverns ramverk. Med andra ord tillåter du det läsa svarmeddelanden och ändra begära meddelanden. jQuery avslöjar ett enkelt API via jQuery.ajax (inställningar):
Genom att passera en inställningar objekt med beforeSend återuppringning, vi kan ändra begäran rubriker. Återuppringningen tar emot objektet jqXHR (jQuery XMLHttpRequest) som avslöjar en metod som kallas setRequestHeader () för att ställa in rubriker.
$ .ajax (url: 'http://www.articles.com/latest', typ: 'GET', föreSänd: funktion (jqXHR) jqXHR.setRequestHeader ('Accept-Language', 'en-US, en ');); jqXHR.getResponseHeader ().status ring tillbaka:$ .ajax (statusCode: 404: function () alert ("sidan hittades inte");); Så sammanfattar vi vår snabba rundtur i HTTP-protokollet.
Vi granskade URL-struktur, verb och statuskoder: de tre pelarna i HTTP-kommunikation.
Förfrågnings- och svarmeddelandena är mestadels desamma, förutom första raden och meddelandehuvuden. Slutligen har vi granskat hur du kan ändra begäran och svarhuvudet i webbramar och bibliotek.
Förstå HTTP är avgörande för att ha ett rent, enkelt och RESTful gränssnitt mellan två ändpunkter. I större skala hjälper det också till att utforma din nätverksinfrastruktur och ge en stor upplevelse till dina slutanvändare.
I del två ska vi granska anslutningshantering, autentisering och caching! Vi ses då.
