Share
HTTP er protokollen som gjør at vi kan kjøpe mikrobølgeovner fra Amazon.com, gjenforene med en gammel venn i en Facebook-chat, og se morsomme kattevideoer på YouTube. HTTP er protokollen bak World Wide Web. Det tillater en webserver fra et datasenter i USA å sende informasjon til en internettkafé i Australia, hvor en ung student kan lese en nettside som beskriver Ming-dynastiet i Kina.
I denne boken ser vi på HTTP fra et programvares utviklerperspektiv. Å ha en solid forståelse av HTTP kan hjelpe deg med å skrive bedre webapplikasjoner og webtjenester. Det kan også hjelpe deg med å feilsøke applikasjoner og tjenester når ting går galt. Vi vil dekke alle grunnleggende, inkludert ressurser, meldinger, tilkoblinger og sikkerhet som det gjelder HTTP.
Vi starter med å se på ressurser.
Kanskje den mest kjente delen av nettet er HTTP-adressen. Når jeg vil finne en oppskrift på en tallerken med brokkoli, som nesten aldri er, kan jeg åpne nettleseren min og skrive inn http://food.com i adressefeltet for å gå til food.com nettsiden og søke etter oppskrifter. Min nettleser forstår denne syntaksen og vet at den må lage en HTTP-forespørsel til en server som heter food.com. Vi snakker senere om hva det betyr å "lage en HTTP-forespørsel" og alle nettverksdetaljer som er involvert. For nå vil vi bare fokusere på adressen: http://food.com.
Adressen http://food.com er det vi kaller en URL-en enhetlig ressurs locator. Den representerer en bestemt ressurs på nettet. I dette tilfellet er ressursen hjemmesiden til food.com nettsiden. Ressurser er ting jeg vil samhandle med på nettet. Bilder, sider, filer og videoer er alle ressurser.
Det er milliarder, om ikke billioner, av steder å gå på Internett, med andre ord, det er trillioner ressurser. Hver ressurs vil ha en nettadresse jeg kan bruke til å finne den. http://news.google.com er et annet sted enn http://news.yahoo.com. Dette er to forskjellige navn, to forskjellige selskaper, to forskjellige nettsteder, og derfor to forskjellige nettadresser. Selvfølgelig vil det også være forskjellige nettadresser på samme nettside. http://food.com/recipe/broccoli-salad-10733/ er nettadressen for en side med en brokkoli salatrecept, mens http://food.com/recipe/grilled-cauliflower-19710/ er fortsatt på food.com, men er en annen ressurs som beskriver en blomkål oppskrift.
Vi kan bryte den siste nettadressen i tre deler:
Accentsconagua
http, delen før : //, er det vi kaller URL-skjema. Ordningen beskriver hvordan for å få tilgang til en bestemt ressurs, og i dette tilfellet forteller det nettleseren å bruke hypertekstoverføringsprotokollen. Senere ser vi også på et annet system, HTTPS, som er den sikre HTTP-protokollen. Du kan også komme inn i andre ordninger, for eksempel FTP for filoverføringsprotokollen, og mailto for e-postadresser. Alt etter : // vil være spesifikk for en bestemt ordning. Så, en juridisk HTTP-nettadresse er kanskje ikke en juridisk post til URL-de to er ikke egentlig utvekslingsbare (noe som gir mening fordi de beskriver forskjellige typer ressurser).
food.com er den vert. Dette vertsnavnet forteller nettleseren navnet på datamaskinen som er vert for ressursen. Datamaskinen vil bruke Domain Name System (DNS) til å oversette food.com inn i en nettverksadresse, og da vil den vite nøyaktig hvor du skal sende forespørselen for ressursen. Du kan også angi vertdelen av en nettadresse med en IP-adresse./ Oppskrift / grillet-blomkål-19710 / er den URL-banen. Food.com-verten bør gjenkjenne den spesifikke ressursen som blir forespurt av denne banen og svare på riktig måte.Noen ganger vil en URL peke til en fil på vertsfilsystemet eller harddisken. For eksempel URL-adressen http://food.com/logo.jpg kan peke på et bilde som egentlig eksisterer på food.com-serveren. Imidlertid kan ressurser også være dynamiske. URL-adressen http://food.com/recipes/brocolli sannsynligvis refererer ikke til en ekte fil på food.com-serveren. I stedet kjører en slags applikasjon på food.com-verten som vil ta denne forespørselen og bygge en ressurs ved hjelp av innhold fra en database. Programmet kan bygges ved hjelp av ASP.NET, PHP, Perl, Ruby on Rails eller en annen webteknologi som vet hvordan du svarer på innkommende forespørsler ved å lage HTML for en nettleser å vise.
Faktisk prøver disse dager mange nettsteder å unngå å ha noen form for ekte filnavn i deres nettadresse. For det første er filnavn vanligvis knyttet til en bestemt teknologi, for eksempel .aspx for Microsofts ASP.NET-teknologi. Mange nettadresser vil overleve teknologien som brukes til å være vert for og betjene dem. For det andre vil mange nettsteder legge inn søkeord i en nettadresse (som å ha / Oppskrift / brokkoli / i nettadressen for en brokkolioppskrift). Å ha disse søkeordene i nettadressen er en form for søkemotoroptimalisering (SEO) som vil rangere ressursen høyere i søkemotorresultater. Beskrivende søkeord, ikke filnavn, er viktige for nettadresser i disse dager.
Noen ressurser vil også føre til at nettleseren laster ned flere ressurser. Food.com hjemmeside vil inneholde bilder, JavaScript-filer, CSS og andre ressurser som vil kombinere for å presentere "home page" of food.com.
food.com hjemmeside Nå som vi vet om nettadresseplaner, verter og baner, la oss også se på en nettadresse med et portnummer:
http://food.com:80/recipes/broccoli/
Tallet 80 representerer portnummer verten bruker for å lytte etter HTTP-forespørsler. Standardportnummeret for HTTP er port 80, så du ser vanligvis dette portnummeret utelatt fra en nettadresse. Du trenger bare å spesifisere et portnummer hvis serveren lytter på en annen port enn port 80, som vanligvis bare skjer i testing, feilsøking eller utviklingsmiljøer. La oss se på en annen nettadresse.
http://www.bing.com/search?q=broccoli
Alt etter ? (spørsmålet) er kjent som spørsmål. Spørringen, også kalt spørringsstreng, inneholder informasjon for destinasjonssiden for å bruke eller tolke. Det er ingen formell standard for hvordan spørringsstrengen skal se ut som det er teknisk opp til applikasjonen for å tolke verdiene den finner, men du vil se at flertallet av spørringsstrenger som brukes til å passere navnverdierpar i skjemaet name1 = verdi1 & navn2 = value2.
For eksempel:
http://foo.com?first=Scott&last=Allen
Det er to navnverdier i dette eksemplet. Det første paret har navnet "først" og verdien "Scott". Det andre paret har navnet "sist" med verdien "Allen". I vår tidligere nettadresse (http://www.bing.com/search?q=broccoli), vil Bing-søkemotoren se navnet "q" knyttet til verdien "brokkoli". Det viser seg at Bing-motoren ser etter en "q" -verdi som skal brukes som søkeord. Vi kan tenke på nettadressen som nettadressen for ressursen som representerer Bing-søkeresultatene for brokkoli.
Endelig en nettadresse:
http://server.com?recipe=broccoli#ingredients
Delen etter # -tegnet er kjent som fragment. Fragmentet er annerledes enn de andre stykkene vi har sett på så langt, fordi i motsetning til URL-banen og spørringsstrengen, blir ikke fragmentet behandlet av serveren. Fragmentet brukes kun på klienten, og det identifiserer en bestemt del av en ressurs. Spesifikt er fragmentet vanligvis brukt til å identifisere et bestemt HTML-element på en side av elementets ID.
Nettlesere vil typisk justere startvisningen på en nettside slik at toppen av elementet identifisert av fragmentet er øverst på skjermen. Som et eksempel, URL-adressen http://odetocode.com/Blogs/scott/archive/2011/11/29/programming-windows-8-the-sublime-to-the-strange.aspx#feedback har fragmentverdien "tilbakemelding". Hvis du følger nettadressen, skal nettleseren din bla nedover siden for å vise tilbakemeldingsdelen av et bestemt blogginnlegg på bloggen min. Nettleseren din hentet hele ressursen (blogginnlegget), men fokuserte oppmerksomheten til et bestemt område - tilbakemeldingsdelen. Du kan forestille deg at HTML for blogginnlegget ser ut som følgende (med alt tekstinnhold utelatt):
......
Klienten sørger for at elementet med "tilbakemelding" ID er øverst.
Hvis vi legger sammen alt vi har lært så langt, vet vi at en URL er brutt inn i følgende stykker:
: // : / ? #
Alle programvareutviklere som jobber med nettet, bør være oppmerksomme på tegnkodingsproblemer med nettadresser. De offisielle dokumentene som beskriver nettadresser, går i store lengder for å gjøre nettadresser så brukbare og interoperable som mulig. En nettadresse skal være så lett å kommunisere via e-post som det skal skrives ut på et støtfangerklistremerke og festes til en 2001 Ford Windstar. Av denne grunn definerer Internett-standardene usikre tegn for nettadresser. Romtegnet er for eksempel betraktet som usikkert fordi mellomromstegn kan feilaktig vises eller forsvinne når en nettadresse er i trykt form (er det ett mellomrom eller to mellomrom på visittkortet ditt?).
Andre usikre tegn inkluderer talltegnet (#) fordi det brukes til å avgrense et fragment, og hylle (^) fordi det ikke alltid overføres korrekt gjennom alle nettverksenheter. Faktisk definerer RFC 3986 ("loven" for nettadresser) de sikre tegnene for nettadresser som de alfanumeriske tegnene i US-ASCII, pluss noen spesialtegn som tykktarmen (:) og skråstreket (/).
Heldigvis kan du fremdeles sende usikre tegn i en nettadresse, men alle usikre tegn må være prosentkodede (aka URL-kodet). % 20 er kodingen for et mellomromstegn (hvor 20 er den heksadesimale verdien for US-ASCII-romkarakteren).
For eksempel, la oss si at du ønsket å opprette nettadressen for en fil med navnet "^ min CV.txt" på someserver.com. Den juridiske, kodede nettadressen vil se ut som:
http://someserver.com/%5Emy%20resume.txt
Både ^ og mellomrom har blitt prosentkodede. De fleste webapplikasjonsrammer vil gi en API for enkel URL-koding. På serversiden bør du kjøre dynamisk opprettede nettadresser via en kodings-API, bare hvis en av de usikre tegnene vises i nettadressen.
Så langt har vi fokusert på nettadresser og forenklet alt annet. Men hva betyr det når vi skriver inn en nettadresse i nettleseren? Vanligvis betyr det at vi ønsker å hente eller se litt ressurs. Det er en enorm mengde materiale å se på nettet, og senere ser vi også hvordan HTTP også gjør det mulig for oss å opprette, slette og oppdatere ressurser. For nå holder vi fokus på gjenfinning.
Vi har ikke vært veldig spesifikke om hvilke typer ressurser vi vil hente. Det finnes tusenvis av ressurstyper på webbilder, hypertekstdokumenter, XML-dokumenter, video, lyd, kjørbare applikasjoner, Microsoft Word-dokumenter og utallige flere.
For at en vert skal kunne betjene en ressurs, og for at en klient skal kunne vise en ressurs riktig, må de involverte partene være spesifikke og presise om ressursens type. Er ressursen et bilde? Er ressursen en film? Vi vil ikke at våre nettlesere skal prøve å gjengi et PNG-bilde som tekst, og vi vil ikke at de skal prøve å tolke hypertekst som et bilde.
Når en vert svarer på en HTTP-forespørsel, returnerer den en ressurs og spesifiserer også innholdstype (også kjent som media type) av ressursen. Vi får se detaljene for hvordan innholdstypen vises i en HTTP-melding i neste kapittel.
For å angi innholdstypene, er HTTP avhengig av MU-standardene (Multipurpose Internet Mail Extensions). Selv om MIME ble opprinnelig utformet for e-postkommunikasjon, bruker HTTP MIME-standarder til samme formål, som er å merke innholdet på en slik måte at klienten vil vite hva innholdet inneholder.
For eksempel, når en klient ber om en HTML-nettside, kan verten svare på HTTP-forespørselen med noen HTML som den merker som "text / html"."tekst"del er den primære medietypen, og"html"er medietypen. Når du svarer på forespørselen om et bilde, merker verten ressursen med en innholdstype"image / jpeg"for JPG-filer,"image / gif"for GIF-filer, eller"image / png"for PNG-filer. Disse innholdstypene er standard MIME-typer og er bokstavelig talt hva som vil vises i HTTP-responsen.
Du kan tro at en nettleser vil stole på filtypen for å bestemme innholdstypen for en innkommende ressurs. For eksempel, hvis nettleseren min ber om "frog.jpg", bør den behandle ressursen som en JPG-fil, men behandle "frog.gif" som en GIF-fil. For de fleste nettlesere er filtypen det siste stedet det skal gå for å bestemme den faktiske innholdstypen.
Filutvidelser kan være misvisende, og bare fordi vi ba om en JPG-fil betyr ikke at serveren må svare med data som er kodet i JPG-format. Microsoft dokumenterer Internet Explorer (IE) som først ser på innholdstypen angitt av verten. Hvis verten ikke gir en innholdstype, vil IE skanne de første 200 bytes av svaret som prøver å gjette innholdstypen. Endelig, hvis IE ikke finner en innholdstype og ikke kan gjette innholdstypen, vil den falle tilbake på filtypen som brukes i forespørselen for ressursen. Dette er en grunn til at innholdstypen er viktig, men det er langt fra den eneste grunnen.
Selv om vi pleier å tenke på HTTP som noe som brukes til å betjene nettsider, viser det seg at HTTP-spesifikasjonen beskriver en fleksibel, generell protokoll for å flytte informasjon om høy troskap. En del av jobben med å flytte informasjon rundt, sørger for at alle involverte parter vet hvordan de skal tolke informasjonen, og det er derfor innstillingene for medietypen er viktige.
Men medietyper er ikke bare for verter. Klienter kan spille en rolle i hvilken medietype en vert returnerer ved å delta i en forhandling av innholdstype.
En ressurs identifisert av en enkelt nettadresse kan ha flere representasjoner. Ta for eksempel brokkolioppskriften vi nevnte tidligere. Enkel oppskrift kan ha representasjoner på forskjellige språk (engelsk, fransk og tysk). Oppskriften kan til og med ha representasjoner i forskjellige formater (HTML, PDF og ren tekst). Det er samme ressurs og samme oppskrift, men forskjellige representasjoner.
Det åpenbare spørsmålet er: Hvilken representasjon skal serveren velge? Svaret er i innholdsforhandlingsmekanismen beskrevet av HTTP-spesifikasjonen. Når en klient gjør en HTTP-forespørsel til en nettadresse, kan klienten spesifisere medietyper som den vil akseptere. Medietyper er ikke bare for verten å merke utgående ressurser, men også for klienter å spesifisere medietypen de vil konsumere.
Klienten spesifiserer hva den vil akseptere i meldingen for utgående forespørsel. Igjen, vi vil se detaljer om denne meldingen i neste økt, men forestill deg en forespørsel til http://food.com/ sier at det vil akseptere en representasjon på tysk. Det er opp til serveren å prøve å oppfylle forespørselen. Verten kan sende en tekstressurs som fremdeles er på engelsk, som sannsynligvis vil skuffe en tysktalende bruker, men det er derfor vi kaller det innholdsforhandling og ikke innholds-ultimatum.
Nettlesere er sofistikerte stykker programvare som kan håndtere mange forskjellige typer ressursrepresentasjoner. Innholdsforhandlinger er noe en bruker sannsynligvis aldri bryr seg om, men for programvareutviklere (spesielt webtjenesteutviklere) er innholdsforhandlinger en del av det som gjør HTTP stor. Et stykke kode skrevet i JavaScript kan gjøre en forespørsel til serveren og be om en JSON-representasjon. Et stykke kode skrevet i C ++ kan gjøre en forespørsel til serveren og be om en XML-representasjon. I begge tilfeller, hvis verten kan tilfredsstille forespørselen, kommer informasjonen til klienten i et ideelt format for analyse og forbruk.
På dette punktet har vi kommet så langt vi kan gå uten å komme inn i de nitty-gritty detaljene av hva en HTTP-melding ser ut. Vi har lært om nettadresser, URL-koding og innholdstyper. Det er på tide å se hva disse innholdstypespesifikasjonene ser ut som de reiser over ledningen.
