Share
HTTP står for Hypertext Transfer Protocol. Det er en statsløs, applikasjonslagprotokoll for kommunikasjon mellom distribuerte systemer, og er grunnlaget for den moderne web. Som webutvikler må vi alle ha en sterk forståelse av denne protokollen.
La oss se gjennom denne kraftige protokollen gjennom linsen til en webutvikler. Vi tar tak i emnet i to deler. I denne første oppføringen vil vi dekke grunnleggende og skissere de ulike forespørslene og svarhodene. I oppfølgingsartikkelen vurderer vi bestemte deler av HTTP - nemlig caching, tilkoblingshåndtering og autentisering.
Selv om jeg skal nevne noen detaljer relatert til overskrifter, er det best å i stedet konsultere RFC (RFC 2616) for grundig dekning. Jeg vil peke på bestemte deler av RFC gjennom hele artikkelen.
Hvis du har problemer med en HTTP-feil i WordPress som du trenger fast, kan du bestille en Express HTTP-feilrettelse på Envato Studio, og få feilen løst på en dag for bare $ 50.
HTTP tillater kommunikasjon mellom en rekke verter og klienter, og støtter en blanding av nettverkskonfigurasjoner.
For å gjøre dette mulig, antar det lite om et bestemt system, og holder ikke tilstand mellom forskjellige meldingsutvekslinger.
Dette gjør HTTP a statsløs protokoll. Kommunikasjonen foregår vanligvis over TCP / IP, men noen pålitelig transport kan brukes. Standardporten for TCP / IP er 80, men andre porter kan også brukes.
Tilpassede overskrifter kan også opprettes og sendes av klienten.
Kommunikasjon mellom en vert og en klient skjer via en forespørsel / svarspar. Klienten initierer en HTTP-forespørselsmelding, som blir betjent gjennom en HTTP-svarmelding i retur. Vi vil se på dette grunnleggende meldingsparet i neste avsnitt.
Den nåværende versjonen av protokollen er HTTP / 1.1, som legger til noen ekstra funksjoner til den forrige 1.0-versjonen. Den viktigste av disse, etter min mening, inkluderer vedvarende forbindelser, chunked overføringskoding og finkornede caching-hoder. Vi vil kort berøre disse funksjonene i denne artikkelen; Dyp dekning vil bli gitt i del to.
I hjertet av webkommunikasjon er forespørselsmeldingen, som sendes via Uniform Resource Locators (URLs). Jeg er sikker på at du allerede er kjent med nettadresser, men for fullstendighet skyld, vil jeg inkludere det her. Nettadresser har en enkel struktur som består av følgende komponenter:
Protokollen er typisk http, men det kan også være https for sikker kommunikasjon. Standardporten er 80, men man kan angi eksplisitt, som illustrert i bildet ovenfor. Resursveien er lokal sti til ressursen på serveren.
Det er også web feilsøking proxies, som Fiddler på Windows og Charles Proxy for OSX.
Nettadresser avslører identiteten til den aktuelle verten som vi vil kommunisere med, men handlingen som skal utføres på verten, er spesifisert via HTTP-verb. Selvfølgelig er det flere handlinger som en klient vil at verten skal utføre. HTTP har formalisert noen få som fanger de essensielle som er universelt gjeldende for alle typer applikasjoner.
Disse forespørgsordene er:
De ovennevnte fire verbene er de mest populære, og de fleste verktøy og rammebetingelser ekspliserer eksplisitt disse forespørselsverker. SETTE og SLETT Noen ganger betraktes spesialiserte versjoner av POST verb, og de kan være pakket som POST forespørsler med nyttelast som inneholder den nøyaktige handlingen: skape, Oppdater eller slette.
Det er noen mindre brukte verb som HTTP også støtter:
Accentsconagua
via toppfelt. Dette kan brukes til diagnostiske formål.Med nettadresser og verb kan klienten starte forespørsler til serveren. Til gengitt reagerer serveren med statuskoder og meldings nyttelaster. Statuskoden er viktig og forteller kunden hvordan man tolker serverresponsen. HTTP-spesifikasjonen definerer bestemte nummerintervaller for bestemte typer svar:
Alle HTTP / 1.1 klienter er pålagt å akseptere
Transfer-EncodingOverskrift.
Denne klassen av koder ble introdusert i HTTP / 1.1 og er rent foreløpig. Serveren kan sende en Forvent: 100-fortsett melding, og forteller klienten å fortsette å sende resten av forespørselen, eller ignorere om den allerede har sendt den. HTTP / 1.0-klienter er ment å ignorere denne overskriften.
Dette forteller klienten at forespørselen ble behandlet. Den vanligste koden er 200 OK. For en FÅ forespørsel, sender serveren ressursen i meldingslegemet. Det finnes andre mindre brukte koder:
404 indikerer at ressursen er ugyldig og ikke eksisterer på serveren.
Dette krever at klienten tar ytterligere tiltak. Det vanligste brukssaken er å hoppe til en annen nettadresse for å hente ressursen.
plassering svarhodet inneholder den midlertidige nettadressen.ETag (Enttity Tag) informasjon som er en hash av innholdet. Serveren sammenligner dette med sin egen beregne ETag for å sjekke om endringer.Disse kodene brukes når serveren mener at klienten er feil, enten ved å be om en ugyldig ressurs eller å lage en dårlig forespørsel. Den mest populære koden i denne klassen er 404 ikke funnet, som jeg tror alle vil identifisere med. 404 indikerer at ressursen er ugyldig og ikke eksisterer på serveren. De andre kodene i denne klassen inkluderer:
Autorisasjon Overskrift. Hvis klienten allerede inkluderte Autorisasjon header, så var legitimasjonene feil.Denne klassen av koder brukes til å indikere en serverfeil under behandling av forespørselen. Den vanligste feilkoden er 500 intern serverfeil. De andre i denne klassen er:
Så langt har vi sett det Nettadresser, verb og statuskoder utgjør de grunnleggende delene av en HTTP-forespørsel / responspar.
La oss nå se på innholdet i disse meldingene. HTTP-spesifikasjonen angir at en forespørsel eller svarmelding har følgende generiske struktur:
melding =* ( ) CRLF [ ] = Request-Line | Status-Linje = Feltnavn ':' Feltverdi
Det er obligatorisk å plassere en ny linje mellom meldingshoder og kropp. Meldingen kan inneholde en eller flere overskrifter, som i stor grad er klassifisert i:
Meldingslegemet kan inneholde de komplette enhetdataene, eller det kan være i stykker hvis den klumpete kodingen (Overførings-koding: chunked) benyttes. Alle HTTP / 1.1 klienter er pålagt å akseptere Transfer-Encoding Overskrift.
Det er noen overskrifter (generelle overskrifter) som deles av både forespørsel og svarmeldinger:
generell header = Cache-Control | Tilkobling | Dato | Pragma | Trailer | Transfer-Encoding | Oppgrader | Via | Advarsel
Vi har allerede sett noen av disse overskriftene, spesielt via og Transfer-Encoding. Vi vil dekke Cache-Control og Forbindelse i del to.
Statuskoden er viktig og forteller kunden hvordan man tolker serverresponsen.
via header brukes i en TRACE melding og oppdateres av alle intermitterende proxyer og gatewaysPragma anses som en egendefinert header og kan brukes til å inkludere implementeringsspesifikke overskrifter. Det mest brukte pragma-direktivet er Pragma: no-cache, som egentlig er Cache-Control: no-cache under HTTP / 1.1. Dette vil bli dekket i del 2 av artikkelen.Dato Overskriftsfelt brukes til å tidsstempelere forespørselen / svarmeldingenOppgradering brukes til å bytte protokoller og tillate en jevn overgang til en nyere protokoll.Transfer-Encoding Brukes vanligvis til å bryte svaret i mindre deler med Overførings-koding: chunked verdi. Dette er en ny overskrift i HTTP / 1.1 og gir mulighet for streaming av svar til klienten i stedet for en stor nyttelast.Forespørsels- og svarmeldinger kan også inkludere ethetsoverskrifter for å gi meta-informasjon om innholdet (f.eks. Meldingsorgan eller Enhet). Disse overskriftene inkluderer:
entity-header = Tillat | Content-Encoding | Innholdsspråk | Innholdslengde | Innhold-plassering | Innhold-MD5 | Innholdsintervall | Innholdstype | Utløper | Sist endret
Alle Innhold- Prefixed headers gir informasjon om strukturen, kodingen og størrelsen på meldingslegemet. Noen av disse overskriftene må være til stede dersom enheten er en del av meldingen.
De utløper Overskrift indikerer en tidsstempel for hvor han entitet utløper. Interessant, a "aldri utløper" Enheten sendes med en tidsstempel på ett år inn i fremtiden. De Sist endret Overskrift indikerer siste modifikasjonstidsstempel for enheten.
Tilpassede overskrifter kan også opprettes og sendes av klienten; De blir behandlet som enhetsoverskrifter av HTTP-protokollen.
Dette er virkelig en utvidelsesmekanisme, og enkelte klient-server-implementeringer kan velge å kommunisere spesielt over disse utvidelsesoverskriftene. Selv om HTTP støtter egendefinerte overskrifter, er det det som virkelig ser etter, forespørsels- og svarhodene, som vi dekker neste.
Forespørselsmeldingen har samme generiske struktur som ovenfor, unntatt forespørselslinjen som ser ut som:
Request-Line = Metode SP URI SP HTTP-Versjon CRLF Method = "OPTIONS" | "HEAD" | "GET" | "POST" | "PUT" | "SLETT" | "TRACE"
SP er mellomromsseparatoren mellom tokens. HTTP-versjon er spesifisert som "HTTP / 1.1" og deretter etterfulgt av en ny linje. En typisk forespørselsmelding kan således se ut som:
GET / articles / http-basics HTTP / 1.1 Host: www.articles.com Connection: keep-alive Cache-Control: ikke-cache Pragma: no-cache Godta: tekst / html, application / xhtml + xml, application / xml; q = 0,9, * / *; q = 0,8
Merk forespørselen linje etterfulgt av mange forespørsel overskrifter. De Vert header er obligatorisk for HTTP / 1.1 klienter. FÅ forespørsler har ikke et meldingsorgan, men POST forespørsler kan inneholde postdata i kroppen.
Forespørselshodene fungerer som modifikatorer av forespørselsmeldingen. Den komplette listen over kjente forespørselsoverskrifter er ikke for lang, og er gitt nedenfor. Ukjente overskrifter behandles som enhetshovedfelter.
request-header = Accept | Godta-Charset | Godta-Koding | Godta-Språk | Autorisasjon | Forvent | Fra | Vert | If-Match | Hvis-Modifisert-Siden | Hvis-Ingen-Match | If-Range | Hvis-umodifisert-Siden | Max-Forward | Proxy-Authorization | Område | Referer | TE | Bruker agent
De Aksepterer Prefixed headers angir akseptable medietyper, språk og tegnsett på klienten. Fra, Vert, Referer og Bruker agent identifisere detaljer om klienten som initierte forespørselen. De Hvis- Prefixed headers brukes til å gjøre en forespørsel mer betinget, og serveren returnerer kun ressursen hvis tilstanden samsvarer. Ellers returnerer den a 304 ikke endret. Tilstanden kan være basert på en tidsstempel eller ETag (en hash av enheten).
Svarformatet ligner på forespørselen, unntatt statuslinjen og overskriftene. Statuslinjen har følgende struktur:
Status-Line = HTTP-versjon SP Status-kode SP Reason-Phrase CRLF
HTTP / 1.1 En typisk statuslinje for et vellykket svar kan se slik ut:
HTTP / 1.1 200 OK
Svarhodene er også ganske begrensede, og hele settet er gitt nedenfor:
response-header = Accept-Ranges | Alder | ETag | Beliggenhet | Proxy-Authenticate | Prøv igjen etter Server | Vary | WWW-Verifisere
Alder er tiden i sekunder siden meldingen ble generert på serveren.ETag er MD5-hash for enheten og pleide å sjekke om endringer.plassering brukes når du sender en omdirigering og inneholder den nye nettadressen.Server identifiserer serveren som genererer meldingen.Det har vært mye teori opp til dette punktet, så jeg vil ikke klandre deg for døsige øyne. I de neste avsnittene vil vi bli mer praktiske og ta en oversikt over verktøyene, rammene og bibliotekene.
Det finnes en rekke verktøy tilgjengelig for å overvåke HTTP-kommunikasjon. Her viser vi noen av de mer populære verktøyene.
Utvilsomt, den Chrome / Webkit inspektør er en favoritt blant webutviklere:
Det er også web feilsøking proxies, som Fiddler på Windows og Charles Proxy for OSX. Min kollega, Rey Bango, skrev en utmerket artikkel om dette emnet.
For kommandolinjen har vi verktøy som curl, tcpdump og tshark for overvåking av HTTP-trafikk.
Nå som vi har sett på forespørsel / svarmeldinger, er det på tide at vi lærer hvordan biblioteker og rammebetingelser avslører det i form av en API. Vi skal bruke ExpressJS for Node, Ruby on Rails, og jQuery Ajax som våre eksempler.
Hvis du bygger webservere i NodeJS, er det stor risiko for at du har vurdert ExpressJS. ExpressJS ble opprinnelig inspirert av et Ruby Web-rammeverk, kalt Sinatra. Som forventet er API også like påvirket.
Fordi vi arbeider med et server-side rammeverk, er det to primære oppgaver når det gjelder å håndtere HTTP-meldinger:
Forstå HTTP er avgjørende for å ha et rent, enkelt og RESTful grensesnitt mellom to endepunkter.
ExpressJS gir en enkel API for å gjøre nettopp det. Vi vil ikke dekke detaljene i APIen. I stedet vil vi gi koblinger til den detaljerte dokumentasjonen om ExpressJS-guider. Metodene i API-en er selvforklarende i de fleste tilfeller. Et utvalg av forespørselsrelatert API er under:
Vert toppfelt.På vei ut til klienten gir ExpressJS følgende respons-API:
Forespørsels- og svarmeldingene er stort sett de samme, med unntak av første linje og meldingshoder.
I Rails gir ActionController og ActionDispatch-modulene APIen for håndtering av forespørsel og responsmeldinger.
ActionController gir et høyt nivå API for å lese forespørselsadressen, gjengi utdata og omdirigere til et annet sluttpunkt. Et sluttpunkt (aka rute) håndteres som en handlingsmetode. De fleste av de nødvendige kontekstinformasjonene i en handling-metode er gitt via be om, respons og params objekter.
ActionDispatch gir finkornet tilgang til forespørsel / responsmeldinger, via ActionDispatch :: Request og ActionDispatch :: Response klasser. Den avslører et sett med spørringsmetoder for å kontrollere typen forespørsel (få?(), post?(), hode?(), lokalt? ()). Forespørselheiser kan nås direkte via request.headers () metode.
På responssiden gir det metoder for å sette kapsler (), plassering = () og status = (). Hvis du føler deg eventyrlystne, kan du også sette legemet = () og omgå Rails rendering systemet.
Fordi jQuery primært er et klientsidebibliotek, gir Ajax API det motsatte av et server-side rammeverk. Med andre ord, det tillater deg å lese svarmeldinger og modifisere be om meldinger. jQuery avslører en enkel API via jQuery.ajax (innstillinger):
Ved å passere en innstillinger objekt med beforeSend tilbakeringing, vi kan endre forespørselhodene. Tilbakeringingen mottar objektet jqXHR (jQuery XMLHttpRequest) som avslører en metode som kalles setRequestHeader () å sette overskrifter.
$ .ajax (url: 'http://www.articles.com/latest', type: 'GET', førSend: funksjon (jqXHR) jqXHR.setRequestHeader ('Accepts-Language', 'en-US, en ');); jqXHR.getResponseHeader ().status Ring tilbake:$ .ajax (statusCode: 404: function () alert ("siden ikke funnet");); Så oppsummerer vi vår hurtige gjennomgang av HTTP-protokollen.
Vi har gjennomgått nettadressestruktur, verb og statuskoder: de tre pilarene til HTTP-kommunikasjon.
Forespørsels- og svarmeldingene er stort sett de samme, med unntak av første linje og meldingshoder. Endelig har vi gjennomgått hvordan du kan endre forespørselen og svarhodene i webrammer og biblioteker.
Forstå HTTP er avgjørende for å ha et rent, enkelt og RESTful grensesnitt mellom to endepunkter. I større målestokk bidrar det også til å utforme nettverksinfrastrukturen og gi en god opplevelse til sluttbrukerne dine.
I del to, vi vurderer tilkoblingshåndtering, autentisering og caching! Ser deg da.
