Share
I dette kapitlet ser vi inn i meldingene som utveksles i en HTTP-transaksjon. Vi lærer om meldingstyper, HTTP-overskrifter og statuskoder. Å forstå hva som er inne i en HTTP-melding, er viktig for utviklere som jobber på nettet. Ikke bare vil du bygge bedre applikasjoner ved å svare på de riktige typer meldinger, men du vil også kunne oppdage problemer og feilsøke problemer når webapplikasjoner ikke fungerer.
Tenk deg å gå opp til en fremmed i en flyplass og spør, "Vet du hvilken tid det er?" For at den fremmede skal svare med riktig tid, må noen ting være på plass. Først må den fremmede forstå spørsmålet ditt, fordi hvis han eller hun ikke kan engelsk, kan han eller hun ikke få svar. For det andre trenger den fremmede tilgang til et klokke eller en annen tidsbesparende enhet.
Denne flyplassanalogien ligner på hvordan HTTP fungerer. Du, klienten, trenger en ressurs fra en annen part (ressursen er informasjon om tidspunktet på dagen). Så, du gjør en forespørsel til den andre parten ved hjelp av et språk og vokabular du håper den andre parten vil forstå. Hvis den andre parten forstår forespørselen din og har ressursen tilgjengelig, kan den svare. Hvis den forstår forespørselen, men ikke har ressursen, kan den fortsatt svare og fortelle deg at den ikke vet. Hvis den andre parten ikke forstår hva du sier, får du kanskje ikke noe svar.
HTTP er en forespørsel og responsprotokoll. En klient sender en HTTP-forespørsel til en server ved hjelp av en forsiktig formatert melding som serveren vil forstå. En server svarer ved å sende en HTTP-respons at klienten vil forstå. Forespørselen og svaret er to forskjellige meldingstyper som utveksles i a enkelt HTTP-transaksjon. HTTP-standardene definerer hva som går inn i disse forespørsels- og svarmeldingene, slik at alle som snakker "HTTP", vil forstå hverandre og kunne bytte ressurser (eller når en ressurs ikke eksisterer, kan en server fortsatt svare og gi deg beskjed).
En nettleser vet hvordan du sender en HTTP-forespørsel ved å åpne en nettverkstilkobling til en servermaskin og sende en HTTP-melding som tekst. Det er ikke noe magisk om forespørselen - det er bare en kommando i ren ASCII-tekst og formatert i henhold til HTTP-spesifikasjonen. Ethvert program som kan sende data over et nettverk kan gjøre en HTTP-forespørsel. Du kan til og med lage en manuell forespørsel ved hjelp av et program som Telnet fra kommandolinjen. En vanlig Telnet-økt kobles over port 23, men som vi lærte i første kapittel, er standard nettverksport for HTTP port 80.
Følgende figur er et skjermbilde av en Telnet-økt som kobles til odetocode.com på port 80, foretar en HTTP-forespørsel, og mottar en HTTP-respons.
Gjør en HTTP-forespørsel Telnet-økten starter ved å skrive:
telnet www.odetocode.com 80
Vær oppmerksom på at Telnet-klienten ikke er installert som standard på Windows 7, Windows Server 2008 R2, Windows Vista eller Windows Server 2008. Du kan installere klienten ved å følge fremgangsmåten som er oppført på http://technet.microsoft.com/no -US / bibliotek / cc771275 (v = ws.10) ASPX.
Denne kommandoen forteller operativsystemet å starte Telnet-programmet, og forteller Telnet-programmet å koble til www.odetocode.com på port 80.
Når Telnet er tilkoblet, kan vi skrive ut en HTTP-forespørselsmelding. Den første linjen er opprettet ved å skrive følgende tekst og deretter trykke Tast inn:
GET / HTTP / 1.1
Denne informasjonen vil fortelle serveren vi ønsker å hente ressursen som ligger på "/" (dvs. roten ressurs eller hjemmesiden), og vi vil bruke HTTP 1.1-funksjoner. Neste linje vi skriver er:
host: www.odetocode.com
Denne vertsinformasjonen er en nødvendig del av informasjonen i en HTTP 1.1 forespørselsmelding. Den tekniske grunnen til å gjøre dette er å hjelpe servere som støtter flere nettsteder, det vil si både www.odetocode.com og www.odetofood.com kan hostes på samme server, og vertsinformasjonen i meldingen vil hjelpe webserveren direkte forespørsel til riktig webapplikasjon.
Etter å ha skrevet de to foregående linjene kan vi trykke Tast inn to ganger for å sende meldingen til serveren. Det du ser neste i Telnet-vinduet, er HTTP-responsen fra webserveren. Vi vil gå inn i flere detaljer senere, men svaret sier at ressursen vi vil ha (standard hjemmesiden til www.odetocode.com), har flyttet. Den har flyttet til stedet odetocode.com. Det er opp til klienten nå å analysere denne svarmeldingen og sende en forespørsel til odetocode.com i stedet for www.odetocode.com hvis den ønsker å hente hjemmesiden. Enhver nettleser vil automatisk gå til den nye plasseringen.
Disse typer "omdirigeringer" er vanlige, og i dette scenariet er årsaken til at alle forespørsler om ressurser fra OdeToCode går gjennom odetocode.com og ikke www.odetocode.com (dette er en søkemotoroptimalisering kjent som URL-kanonisering).
Nå som vi har sett en rå HTTP-forespørsel og -respons, la oss grave inn i bestemte deler.
De FÅ Ord skrevet inn i Telnet-økten er en av de primære HTTP-metoder. Hver forespørselsmelding må inneholde en av HTTP-metodene, og metoden forteller serveren hva forespørselen ønsker å gjøre. En HTTP FÅ ønsker å hente, hente og hente en ressurs. Du kan FÅ et bilde (GET /logo.png), eller FÅ en PDF-fil, (GET /documents/report.pdf), eller en annen gjenopprettelig ressurs serveren kan holde. En liste over vanlige HTTP-operatører vises i følgende tabell.
| Metode | Beskrivelse |
| FÅ | Hent en ressurs |
| SETTE | Lagre en ressurs |
| SLETT | Fjern en ressurs |
| POST | Oppdater en ressurs |
| HODE | Hent topptekstene for en ressurs |
Av disse fem metodene er bare to de viktigste arbeidshestene på nettet: FÅ og POST. En nettleser utsteder a FÅ Be om når den vil hente en ressurs, som en side, et bilde, en video eller et dokument. FÅ forespørsler er den vanligste typen forespørsel.
En nettleser sender en POST Be om når det er data som skal sendes til serveren. For eksempel, ved å klikke "Legg til i handlekurven" på et nettsted som amazon.com vil POST Informasjon til Amazon om hva vi vil kjøpe. POST forespørsler genereres vanligvis av a på en nettside, som skjemaet du fyller ut med elementer for adresse- og kredittkortinformasjon.
Det er en del av HTTP-spesifikasjonen som snakker om "sikre" HTTP-metoder. Sikker metode, Som navnet antyder, gjør ikke noe "usikkert" som å ødelegge en ressurs, send inn en kredittkorttransaksjon, eller kansellere en konto. De FÅ Metoden er en av de sikre metodene, siden den bare skal hente en ressurs og ikke endre ressursens tilstand. Sende en FÅ forespørsel om et JPG-bilde endrer ikke bildet, det henter bare bildet for visning. Kort sagt, det bør aldri være bivirkning for a FÅ be om.
En HTTP POST er ikke en sikker metode. EN POST endrer vanligvis noe på serveren - det oppdaterer en konto, sender inn en bestilling, eller gjør en annen spesiell operasjon. Nettlesere behandler vanligvis FÅ og POST annerledes siden FÅ er trygg og POST er usikre. Det er greit å oppdatere en nettside hentet av en FÅ forespørsel-nettleseren vil bare gjenopprette sist FÅ Be om og gjengi hva serveren sender tilbake. Men hvis siden vi ser på i en nettleser, er svaret på en HTTP POST forespørsel, vil nettleseren advare oss hvis vi prøver å oppdatere siden. Kanskje du har sett disse typer advarsler i nettleseren din.
Forfriskende en POST-forespørsel På grunn av advarsler som dette, prøver mange webapplikasjoner alltid at klienten ser resultatet av en FÅ be om. Etter at en bruker har klikket på en knapp til POST informasjon til en server (som å sende inn en bestilling), vil serveren behandle informasjonen og svare med en HTTP-omdirigering (som omadresseringen vi så i Telnet-vinduet) for å fortelle nettleseren FÅ en annen ressurs. Nettleseren vil utstede FÅ forespørsel, serveren vil svare med en "takk for bestillingen" ressurs, og da kan brukeren oppdatere eller skrive ut siden trygt så mange ganger som han eller hun ønsker. Dette er et vanlig webdesign mønster kjent som POST/ Omadresser /FÅ mønster.
Nå som vi vet litt mer om POST og FÅ, la oss snakke om noen vanlige scenarier og se når du skal bruke de forskjellige metodene.
La oss si at du har en side og vil at brukeren skal klikke på en lenke for å se den første artikkelen i denne serien. I dette tilfellet er en enkel hyperkobling alt du trenger.
Del I
Når en bruker klikker på hyperkoblingen i en nettleser, utsteder nettleseren a FÅ forespørsel til nettadressen som er angitt i href attributten til ankermerket. Forespørselen vil se slik ut:
FET http://odetocode.com/Articles/741.aspx HTTP / 1.1 Host: odetocode.com
Forestill deg nå at du har en side der brukeren må fylle ut informasjon for å opprette en konto. Fyll ut informasjon krever koder, og vi nest disse innspillene i a tag og fortell nettleseren hvor du skal sende inn informasjonen.
Når brukeren klikker på send-knappen, innser nettleseren at knappen er inne i et skjema. Skjemaet forteller nettleseren hvilken HTTP-metoden som skal brukes POST, og banen til POST er / Konto / opprette. Den faktiske HTTP-forespørselen nettleseren gjør vil se noe ut som dette.
POST http: // localhost: 1060 / konto / opprett HTTP / 1.1 Host: server.com firstName = Scott & lastName = Allen
Legg merke til at skjemainngangene er inkludert i HTTP-meldingen. Dette ligner veldig på hvordan parametere vises i en nettadresse, som vi så i forrige artikkel. Det er opp til webapplikasjonen som mottar denne forespørselen for å analysere disse verdiene og opprette brukerkontoen. Søknaden kan da svare på noen måter, men det finnes tre vanlige svar:
Accentsconagua
POST forespørsel, noe som kan føre til problemer hvis han eller hun oppdaterer siden - det kan prøve å registrere dem en gang til!FÅ Be om en side som forteller brukeren at kontoen er opprettet.Et tredje scenario er et søk scenario. I et søk scenario trenger du en for brukeren å skrive inn et søkeord. Det kan se ut som følgende.
Legg merke til at metoden på dette skjemaet er FÅ, ikke POST. Det er fordi et søk er en sikker henting operasjon, i motsetning til å opprette en konto eller bestille et fly til Belgia. Nettleseren vil samle inngangene i skjemaet og utstede a FÅ forespørsel til serveren:
GET http: // localhost: 1060 / search? Term = elsker HTTP / 1.1 Host: searchengine.com
Legg merke til i stedet for å legge inn verdiene i meldingsdelen, så går inngangene inn i forespørselsstrengdelen av nettadressen. Nettleseren sender en FÅ forespørsel etter / Søke? Term = kjærlighet. Siden søkeordet er i nettadressen, kan brukeren bokmerke URL-adressen eller kopiere lenken og sende den i en e-post. Brukeren kan også oppdatere siden så mange ganger som han eller hun ønsker, igjen fordi FÅ drift for søkeresultatene er en sikker operasjon som ikke vil ødelegge eller endre data.
Vi har snakket ganske mye om ressurser som fysiske ressurser på filsystemet til en server. Ofte, ressurser som PDF-filer, videofiler, bildefiler og skriptfiler gjøre finnes som fysiske filer på serveren. Webadressene som peker inne i mange moderne webapplikasjoner peker imidlertid ikke på filer. Teknologier som ASP.NET og Ruby on Rails vil fange opp forespørselen etter en ressurs og svare, men de ser det som passer. De kan lese en fil fra en database og returnere innholdet i HTTP-responsen for å få det til å virke som om ressursen egentlig eksisterte på selve serveren.
Et godt eksempel er POST Eksempel vi brukte tidligere som resulterte i en forespørsel til / Konto / opprette. Sjansen er at det ikke finnes noen ekte fil med navnet "create" i en "konto" -katalog. I stedet henter noe på webserveren denne forespørselen, leser og validerer brukerinformasjonen, og lager en post i databasen. De / Konto / opprette ressursen er virtuell og eksisterer ikke. Men jo mer du kan tenke på en virtuell ressurs som en reell ressurs, desto bedre vil din applikasjonsarkitektur og design overholde styrken til HTTP.
Så langt har vi sett en rå HTTP-forespørsel og snakket om de to populære HTTP-metodene-FÅ og POST. Men da Telnet-utgangen viste seg, er det mer til en HTTP-forespørselsmelding enn bare HTTP-metoden. En full HTTP-forespørselsmelding består av følgende deler:
[metode] [URL] [versjon] [headers] [body]
Meldingen er alltid i ASCII-tekst, og startlinjen inneholder alltid metoden, nettadressen og HTTP-versjonen (vanligvis 1.1, som har eksistert siden 1999). Det siste avsnittet, kroppsdelen, kan inneholde data som innloggingsparametrene for kontoen vi så tidligere. Når du laster opp en fil, kan kroppsdelen være ganske stor.
Den midterste delen, delen der vi så Vertskap: odetocode.com, inneholder en eller flere HTTP-overskrifter (husk, i HTTP 1.1 vert er et påkrevd overskrift). Overskrifter inneholder nyttig informasjon som kan hjelpe en serverprosess en forespørsel. For eksempel, i den siste artikkelen snakket vi om ressursrepresentasjoner og hvordan klienten og serveren kan forhandle om den beste representasjonen av en ressurs (innholdsforhandling). Hvis klienten ønsker å se en ressurs på fransk, kan den for eksempel inneholde en headeroppføring ( Accept-Language header) som ber om fransk innhold.
GET http://odetocode.com/Articles/741.aspx HTTP / 1.1 Host: odetocode.com Accept-Language: fr-FR
Det er mange overskrifter definert av HTTP-spesifikasjonen. Noen av topptekstene er generelle overskrifter som kan vises i enten en forespørsel eller en svarmelding. Et eksempel er Dato Overskrift. Klienten eller serveren kan inneholde en Dato Overskrift som angir når den opprettet meldingen.
GET http://odetocode.com/Articles/741.aspx HTTP / 1.1 Host: odetocode.com Accept-Language: fr-FR Dato: Fre, 9 Aug 2002 21:12:00 GMT
Alt annet enn vertsoverskriften er valgfritt, men når en overskrift vises, må den overholde standardene. For eksempel sier HTTP-spesifikasjonen at verdien av dataarkteksten må være i RFC822-format for datoer.
Noen av de mer populære forespørselshodene vises i følgende tabell.
| Overskrift | Beskrivelse |
| Referer | Når brukeren klikker på en kobling, kan klienten sende nettadressen til den henvisende siden i denne overskriften. |
| Bruker agent | Informasjon om brukeragenten (programvaren) som gjør forespørselen. Mange applikasjoner bruker informasjonen i denne overskriften, når den er til stede, for å finne ut hvilken nettleser som gjør forespørselen (Internet Explorer 6 versus Internet Explorer 9 versus Chrome, etc.). |
| Aksepterer | Beskriver media typer brukeragenten er villig til å akseptere. Denne overskriften brukes til innholdsforhandling. |
| Accept-Language | Beskriver de språkene brukeragenten foretrekker. |
| cookie | Inneholder informasjon om informasjonskapsler, som vi vil se på i et senere kapittel. Informasjon om informasjonskapsler hjelper vanligvis et server spor eller identifiserer en bruker. |
| If-Modified-Since | Vil inneholde en dato for når brukeragenten sist hentet (og lagret) ressursen. Bare serveren må sende hele ressursen tilbake hvis den er blitt endret siden den tiden. |
En full HTTP-forespørsel kan se ut som følgende.
GET http://odetocode.com/ HTTP / 1.1 Host: odetocode.com Tilkobling: Keep-alive Brukeragent: Mozilla / 5.0 (Windows NT 6.1; WOW64) Chrome / 16.0.912.75 Safari / 535.7 Godta: tekst / html, søknad / xhtml + xml, søknad / xml; q = 0,9, * / *; q = 0,8 Referer: http://www.google.com/url?&q=odetocode Godta-koding: gzip, deflate, sdch Accept-Language : en-US, en; q = 0,8 Godta-Charset: ISO-8859-1, utf-8; q = 0,7, *; q = 0,3
Som du ser, inneholder noen overskrifter flere verdier, som Aksepterer Overskrift. De Aksepterer header er oppført på MIME-typene som den liker å se, inkludert HTML, XHTML, XML og til slutt * / * (det betyr at jeg liker HTML det beste, men du kan sende meg noe (* / *) og jeg skal prøve å finne det ute).
Legg også merke til utseendet til "q"i noen av topptekstene q verdien er alltid et tall fra 0 til 1 og representerer kvalitetsverdi eller "relativ grad av preferanse" for en bestemt verdi. Standardinnstillingen er 1,0, og høyere tall indikerer en høyere preferanse.
En HTTP-respons har en lignende struktur som en HTTP-forespørsel. Delene av et svar er:
[versjon] [status] [grunn] [headers] [body]
Den fulle HTTP-responsen til den siste fulle forespørselen vi oppførte, kan se slik ut (med det meste av HTML utelatt for korthet).
HTTP / 1.1 200 OK Cache-Control: privat innholdstype: tekst / html; charset = utf-8 Server: Microsoft-IIS / 7.0 X-AspNet-Versjon: 2.0.50727 X-Powered-By: ASP.NET Dato: Lør, 14 Jan 2012 04:00:08 GMT Tilkobling: Lukk Innholdslengde: 17151.NET-relaterte artikler, kode og ressurser … innhold…
Åpningslinjen for en forespørsel starter med HTTP-versjonen, og deretter den all-viktige statuskoden og årsaken.
Statuskoden er et nummer som er definert av HTTP-spesifikasjonen, og alle tallene faller inn i en av fem kategorier.
| Område | Kategori |
| 100-199 | Informativ |
| 200-299 | Vellykket |
| 300-399 | omdirigering |
| 400-499 | Klientfeil |
| 500-599 | serverfeil |
Selv om vi ikke vil detaljere alle mulige HTTP-statuskoder, vil følgende tabell angi de vanligste kodene.
| Kode | Grunnen til | Beskrivelse |
| 200 | OK | Statuskoden alle ønsker å se. En 200 kode i svaret betyr at alt fungerte! |
| 301 | flyttet permanent | Resursen er flyttet til nettadressen som er angitt i plassering header og klienten trenger aldri å sjekke denne nettadressen igjen.Vi så et eksempel på dette tidligere da vi brukte Telnet og serveren omdirigert oss fra www.odetocode.com til odetocode.com for å gi søkemotorene en kanonisk URL. |
| 302 | Flyttet midlertidig | Resursen er flyttet til nettadressen som er angitt i plassering Overskrift. I fremtiden kan klienten fortsatt be om nettadressen fordi den er et midlertidig trekk.Denne typen svarkoden brukes vanligvis etter a POST operasjon for å flytte en klient til en ressurs det kan hente med FÅ (de POST/ Omadresser /FÅ mønster vi snakket om tidligere). |
| 304 | Ikke endret | Dette er serveren som forteller klienten at ressursen ikke har endret seg siden siste gang klienten hentet ressursen, slik at den bare kan bruke en lokalt cachert kopi. |
| 400 | Dårlig forespørsel | Serveren kunne ikke forstå forespørselen. Forespørselen brukte sannsynligvis feil syntaks. |
| 403 | Forbudt | Serveren nektet tilgang til ressursen. |
| 404 | Ikke funnet | En populær kode som betyr ressursen ble ikke funnet. |
| 500 | intern server feil | Serveren oppdaget en feil i behandlingen av forespørselen. Vanligvis skjer på grunn av programmeringsfeil i et webprogram. |
| 503 | Tjenesten er ikke tilgjengelig | Serveren vil for øyeblikket ikke betjene forespørselen. Denne statuskoden kan vises når en server er spjeldingsforespørsler fordi den er under tung belastning. |
Svarstatuskoder er en utrolig viktig del av HTTP-meldingen fordi de forteller klienten hva som skjedde (eller i tilfelle omdirigeringer, hvor du skal gå neste).
Husk at HTTP-statuskoden er en kode for å indikere hva som skjer på HTTP-nivå. Det reflekterer ikke nødvendigvis hva som skjedde i søknaden din. For eksempel, tenk en bruker sender et påloggingsskjema til serveren, men fyllte ikke ut etternavnet-feltet. Hvis søknaden krever et etternavn, vil det ikke opprette en konto for brukeren. Dette betyr ikke at du må returnere en HTTP-feilkode som indikerer feil. Du vil sikkert ha det motsatte som skjer - du vil lykkes med å returnere noe innhold til klienten med en 200 (OK) statuskode. Innholdet vil fortelle brukeren at etternavnet ikke ble oppgitt. Fra et søknadsperspektiv var forespørselen en feil, men fra et HTTP-perspektiv ble forespørselen behandlet. Dette er normalt i webapplikasjoner.
Et svar inkluderer headerinformasjon som gir en klientmetadata som den kan bruke til å behandle svaret. For eksempel vil innholdstypen bli spesifisert som en MIME-type, som vi snakket om i den siste artikkelen. I det følgende svaret kan vi se innholdstypen er HTML, og tegnsettet som brukes til å kode for typen, er UTF-8. Overskriftene kan også inneholde informasjon om serveren, som navnet på programvaren og versjonen.
HTTP / 1.1 200 OK Cache-Control: privat innholdstype: tekst / html; charset = utf-8 Server: Microsoft-IIS / 7.0 X-AspNet-Versjon: 2.0.50727 X-Powered-By: ASP.NET Dato: Lør, 14 Jan 2012 04:00:08 GMT Tilkobling: Lukk Innholdslengde: 17151.NET-relaterte artikler, kode og ressurser … innhold…
Response headers som vises vil ofte avhenge av typen svar. For eksempel må en omadresseringsrespons inneholde en plassering header som forteller kunden hvor du skal gå neste.
Det er en rekke overskrifter viet til caching og ytelsesoptimaliseringer. ETag, utløper, og Sist endret alle gir informasjon om cacheability av et svar. en ETag er en identifikator som vil endres når den underliggende ressursen endres, så sammenligner den ETags er en effektiv måte å vite om noe må oppdateres. en utløper header forteller en klient hvor lenge å cache en bestemt ressurs. Vi kommer tilbake og ser på caching mer detaljert senere.
I dette kapitlet har vi lært at HTTP-meldinger alltid kommer i par. Først er det forespørselen, og så er det svaret. Informasjonen i disse meldingene er alt i lesbar tekst, og det er mange verktøy du kan bruke til å inspisere HTTP-forespørsler som blir gjort på maskinen din. Fiddler er et slikt verktøy hvis du kjører Windows (http://fiddler2.com). Det er enkelt å bruke, og du kan se de røde HTTP-forespørslene som blir gjort, inkludert alle topptekstene.
Meldinger handler om å sikre at begge parter i en transaksjon forstår hva de mottar. Den første linjen i en HTTP-melding er alltid eksplisitt om hensikten. I en forespørselsmelding vises URL- og HTTP-metoden først for å identifisere hva som skal skje med en bestemt ressurs. I et svar angir statuskoden hvordan forespørselen ble behandlet. Vi har også overskrifter som beveger seg i begge retninger, som gir enda mer informasjon om forespørselen og svaret. I neste kapittel lærer vi litt mer om hvordan disse meldingene reiser over hele nettverket.
