SPEAKER: La oss snakke om en annen protocol-- Hypertext Transfer Protocol, eller HTTP. Så vi har snakket om IP og TCP i tidligere videoer. Og de er protokoller som dikterer hvordan informasjon beveger seg fra maskin til maskin og fra program til program eller en tjeneste å betjene via internett, via Dette nettverk av rutere og maskiner. Men det er vanligvis ikke hele bildet, ikke sant? Vanligvis når vi sender informasjon, vil programmet itself-- når data er mottatt, si, for eksempel, i e-post via TCP port 25 eller nettside forespørsel via port 80, det er som regel et system av regler der å bearbeide det jeg nettopp har fått. Og HTTP er et eksempel av nettopp en slik protokoll. HTTP er den eneste applikasjonslaget protokollen at vi kommer til å snakke om. Men det er et annet sett av regler for hvordan informasjon skal overføres og behandlet via internett. Spesielt HTTP angir nøyaktig hvordan man må gjøre en forespørsel om en nettside, og nøyaktig hvordan en server, en maskin som er vert for websider, leverer denne informasjonen tilbake til kundene. Så denne protokollen ikke faktisk har noe å gjøre med hvordan informasjon beveger seg fra punkt A til punkt B. Det er virkelig det system av regler for-- det er i utgangspunktet reglene engasjement for å arbeide med en web-side, lik når noen bølgene sin hånd på deg, du skal vinke tilbake. Det er liksom en konvensjonelle menneskelige protokollen. HTTP-protokollen bare sier, hvis du ønsker å be om en web side, sørg for at format utseende som dette-- liksom som formatering et forretningsbrev, for eksempel. Og responsen vil likeledes komme i henhold til denne protokollen. Det er annet applikasjonslaget protokoller at vi ikke kommer til å snakke om i videoer. Men disse inkluderer ting som File Transfer Protocol, Simple Mail Transfer Protocol for sende e-post, Data Distribution Service, Remote Desktop Protokollen, RDP, som brukes hvis du ønsker å fjerntilgang datamaskinen fra en annen datamaskin, XMPP, som er hyppig kjent som Jabber eller chat, slik dette er protokollen for å bruke chat-tjenester. Og det er mange, mange, mange andre. Så hver gang du bruker en tjeneste, service venter informasjon skal received-- en forespørsel å være received-- i en veldig bestemt format og er nødvendig for å returnere informasjon tilbake i en meget bestemt format i tillegg. Så la oss gå tilbake til vår illustrasjon av oss som ønsker å snakke med internett. Så vi er glade, og vi ønsker å gå til cats.com, ikke sant? Så hvis vi bare snakker til cats.com, vi kan si noe sånt hei, kan jeg se hjemmesiden din? Og cats.com vil trolig svare, ja, sikkert. Vær så god. Så det er en menneskelig form av spørre-og-svar. Hva betyr det se ut i HTTP? Vel, det er faktisk slags overs ganske renslig til noe som dette. Vi kan kanskje si GET / HTTP / 1.1 fra verts cats.com. Så i utgangspunktet det jeg gjør her er ber om nettsiden www.cats.com/. Vi pleier å utelate slash i dag, men det ville bare mener cats.com sin hjemmeside. Oh, og forresten, jeg kommer å være ved hjelp av HTTP versjon 1.1 til å kommunisere med deg. Det er liksom analogt til si, som, forresten, Jeg kommer til å snakke på fransk, eller forresten, Jeg kommer til å være å snakke på engelsk. Det er bare det formatet av protokollen. Det er også 1,0, noe som er ikke brukte lenger. Så jeg snakker HTTP 1.1, og Jeg ønsker www.cats.com/. Vennligst få det for meg. Og så er det annen informasjon, også-- punktum, prikk, prikk der, som er informasjon om hvem du er så cats.com ville vite hvor du skal sende det. Men disse er de to slags kritiske deler helt i begynnelsen av en HTTP request-- akkurat som når du starter et bokstaven du si, kjære, blank. Dette er svært lik i ånden til det. Og hvis cats.com skal si, oh, sikker, her du går. De kan svare like dette-- Jeg er også svare. Jeg snakker også HTTP 1.1. Forespørselen er godkjent, 200 OK. Hva du er i ferd med å mottar er HTML og deretter prikk, prikk, prikk litt ekstra informasjon. Og helt på bunnen av forespørsel er faktisk HTML, kodespråket, den Innholdet i cats.com hjemmeside. Så HTTP / 1.1-- jeg erkjenner din forespørselen ble godtatt via HTTP 1.1. Din forespørsel ble godkjent. Jeg kan gi deg det du ønsker, 200 OK. Du er i ferd med å motta HTML. Og så her er HTML som du ba om. Men noen ganger våre forespørsler ikke alltid gå helt etter planen. Kan jeg få se cats.html side? Vel, hva om de sier, vi ikke har et cats.html side, som synes slags urealistisk fordi de er cats.com. Man skulle tro de ville ha cats.html. Men OK. Så dette er liksom den konvensjonell menneskelig samhandling Vi har nå hatt med cats.com. Hvordan oversette? Dette kan være noe kjent med deg. Vår forespørsel så nøyaktig det samme, bortsett fra i stedet for å få slash vi nå får cats.html. Så nå hva som i utgangspunktet hele denne Forespørselen sier er vennligst gi meg www.cats.com/cats.html. Så vert og midten del av det øverste linjen det indikerer nettopp hvilken side jeg ber om. Men cats.com i dette tilfellet ikke kommer å være i stand til å reagere positivt. De vet ikke vi snakker om. Og så dette er noe du kan ha sett before-- HTTP 1.1 404 Not Found. Jeg kunne ikke vite du ber om. Forresten, jeg skal gi deg tilbake noen HTML, og vanligvis som HTML er innholdet av noen 404-side. Og i tilfelle av cats.com, er det sannsynligvis noen søte katter i en kurv med en trist 404 ansikt ved siden av dem, fordi du kommer til å være trist når du ikke får side at du var ute etter. Det er slags grunnleggende om hva en protokollen, HTTP-protokollen forespørsler ser ut som. De er veldig lik hvordan vi ville gjøre en lignende interaksjon i bare menneskelige konvensjoner spør etter noe og få den tilbake eller skrive en brev og forventer et svar bokstav i et bestemt format. Det er ganske mye hva HTTP er bare canonicalizing for alle enheter som ønsker tilgang til websider, hyper overføringer. Slik at en linje av skjemaet, dette metode forespørsel target HTTP-versjonen, kalles en HTTP-forespørsel linje. Det er som regel det første som er overført som del av en HTTP-forespørsel eller hvis du ber om HTTP. Det er liksom som, som jeg sa, sier kjære, blank på toppen brevet. De vet at du er skrive dem et brev. Så dette er veldig lik å si, jeg vet at de gjør en HTTP-forespørsel og dette er bestemt format de spør etter. HTTP-versjonen er nok alltid skal være HTTP / 1/1. 1.0 også finnes, men er ikke virkelig brukes lenger. Med henblikk på CS50, GET er nok alltid hva du kommer til å være hjelp når du faktisk gjøre direkte HTTP-forespørsler. Men POST er et annet alternativ som vi er ikke kommer til å snakke om akkurat nå. Og så request-målet er hvilken side på vertens server du ønsker å få. Som jeg sa, dette vertsnavnet er en egen linje, vanligvis den andre linjen av den samlede forespørsel. Og så tatt sammen, verten navn og forespørselen målet angi en spesifikk ressurs søkes. I vår 404 eksempel en andre siden, jeg spurte igjen for www.cats.com, cats.com blir verten. Og i min forespørsel linje, Jeg sa /cats.html. Det var min forespørsel målet. Så samlet jeg ber om det innhold eller ressursen som ligger på www.cats.com/cats.html. Og så basert på om ressursen finnes og om serveren kan levere ressursen i henhold til kundens forespørsel, kan du få ulike statuskoder tilbake. Noen av disse statuskodene du har sett fordi de er en del av svaret. Noen av dem, 200 OK, er sannsynligvis ganske stille. Du har sikkert aldri sett en side svare 200 OK. Du bare få siden. Det er ikke som en 404-feil, som vanligvis er ganske klart. Du vanligvis ser at det står 404. Så la oss snakke om hva noen av disse statuskoder kan være. Igjen, når serveren reagerer på oss, de er kommer til å svare HTTP versjon status. Vanligvis HTTP / 1.1. Hva er disse statuskodene kommer til å bli? Vel, vi kan få en suksess. Så i suksessen kategori, vi kan få kode 200 med teksten OK. Hva betyr dette? Vel, alt er bra. Du har gjort en gyldig forespørsel. Her er et gyldig svar. Jeg var i stand til å levere nøyaktig hva du ville. Noen ganger kan du få andre ting at du ikke vil legge merke til med en gang men er noe feil. De er kalt omadresseringer. Det finnes to vanlige dem her. 301 Moved Permanently-- hva dette egentlig betyr er siden er nå på et nytt sted. Det vil leve der for alltid. Og de fleste nettlesere vil automatisk omdirigere deg. Slik at du aldri virkelig se en 301, heller, med mindre du er ved hjelp av en virkelig out-of-date nettleser, muligens, fordi 301 responsen er en del av dot, dot, dot av 301 svar. Den forteller deg også hvor den nye siden er. Og så de fleste nettlesere vil bare omdirigere deg der, forutsatt at du ønsker å gå dit. Noen ganger vil du også få 302 funnet. Og dette du faktisk kan fortsatt se innimellom. Noen ganger sidene flytter midlertidig. Så det kommer ikke til å bli bygget inn anmodningen forteller nettleseren å permanent endre helst det ser be om at du gjøre for å endre det til noe annet. Så du kan se 302 Funnet, som i utgangspunktet sier denne siden bor et annet sted. Men det er ikke til å leve det evig. Det vil etter hvert trolig gå tilbake til der du tror det er. Da får du ting som klient feil. Så disse er de du har sikkert sett, nå. Du har sannsynligvis ikke har sett de 200s eller 300s, men du er sannsynligvis kjent med 400s. Og det er det vi skal snakke omtrent i en andre, 500s også. Du kan se 401 Uautorisert. Vanligvis betyr dette at du er prøver å få tilgang til en side, men du har ikke logget inn. Så du prøver og gå til noen profil eller noe på Facebook eller du prøver og tilgang some-- du er på jobb. Du prøver å få tilgang til noe på arbeidsinternett, men du er ikke logget inn. Du kan ikke se på siden. Du kan få en 401 uautorisert, noe som betyr at vi trolig vil være i stand til å tilfredsstille denne forespørselen, men først må du logge inn for å gjøre det. Motsatt kan du få 403 Forbudt, noe som er det gjør egentlig ikke rolle om du er logget inn eller ikke. Denne forespørselen er ikke tillatt. Ressurs finnes på tjeneren. Men du har ikke lov til å få tilgang til det. Dette er vanligvis interne filer som bor på serveren for ulike årsaker men er ikke ment å være aksesseres fra omverdenen, og slik at de er forbudt. De bor der. Jeg sier ikke at jeg ikke kan finne det. Men jeg sier jeg ikke kan gi den til deg. Og det spiller ingen rolle om du er logget inn eller ikke. Og så selvfølgelig, svært vanlig 404 Not Found. Filen finnes ikke på serveren. Jeg ønsker å tilfredsstille forespørselen din, men jeg kan ikke. Du har også noen ganger se serveren feil, den vanligste vanligvis være 500 Internal Server Error, som faktisk ikke fortelle deg noe i det hele tatt om hva som har gått galt. Men det er faktisk ikke du gjør en feil i forespørselen. Det er faktisk den serveren sviktende å levere på forespørsel eller annen måte. Så 500 er den generelle respons. Du vil også se noe som Tjenesten er utilgjengelig, som jeg mener er kode 503. Og Gateway Timeout-- hvis du noen gang hatt en side bare sitte der lasting og lasting og laste og du vet aldri om det kommer til å last og så til slutt det bare says-- bare gir opp. Det er en 504 Gateway Timeout. Serveren ønsket å utføre din forespørsel, men noe gikk galt på serveren side-- ikke på din side-- til føre til at for å være et problem. Nå kan vi avslutte historien her, men hva jeg faktisk kommer til å gjøre nå er jeg kommer til å åpne opp min nettleser og vise deg hvordan du kan være i stand til å se noen av disse statuskoder selv om du ikke vanligvis ser dem. Og vi kommer til å gjøre det ved å ta En titt på noen utviklerverktøy. Greit Så her er jeg nå i min nettleservindu. Og jeg ønsker å lære litt mer om disse HTTP-forespørsler. Hvordan kan jeg know-- sikkert vi vite om en side goes-- når noe går galt, vi får en 404. Vi har alle sett det. Vi trenger ikke behov for å illustrere den. Men hva er noen andre? Og hvordan ville vi se disse forespørslene i aksjon? Så det første jeg kommer til å gjøre er å åpne opp utviklerverktøy. Så Utviklerverktøy er bygget inn i de fleste moderne nettlesere og tillate oss å se ting at vi ikke ellers see-- litt ekstra informasjon slags overføres under vår web forespørsler. Jeg bruker Google Chrome her. Og for å åpne utviklerverktøy i Chrome, du bare trykke F-12, og det kommer til å åpne det opp på siden. Når jeg skriver forespørselen, vil jeg zoome inn slik at vi kan se hva som skjer her. Men hva jeg skal gjøre i min nettleser bar er-- og jeg skal zoome inn over her-- Jeg vil gjøre en forespørsel til www.google.com. Vi har vel alle gjort denne forespørselen før. Jeg kommer til å treffe på Enter. Nå, over her i min Developer Verktøy, har jeg valgt kategorien Nettverk. Og du oppdager en masse ting her. Se på these-- 200 OK, 200 OK, noen av disse statuskoder som kommer opp. Jeg vet ikke hvorfor jeg får 302 Found. Jeg visste ikke at jeg ville se den. Men i utgangspunktet legge merke til at ganske mye, med tanke på min Google request-- Jeg gjorde en veldig enkel forespørsel om Googles side. Og i ferd med å levere min forespørsel, Google har tydeligvis gjort mye andre forespørsler på mine vegne. Men jeg har gjort en get forespørsel om Googles side og jeg får en masse 200 OKS. Jeg ser ikke 200 OK på skjermen min, men jeg får mange forespørsler som har blitt gjort. En mer at jeg er ganske sikker på kommer til å jobbe er-- for de av dere som er virkelig gamle skolen, du vet kanskje at Facebook var ikke alltid på Facebook.com. I sine tidlige dager var det på wwww.thefacebook.com. De tilsynelatende ikke kunne få tilgang til Facebook.com for ganske stund. Og så hva jeg forventer her er å få informasjon. Og vi får se om dette kokekar ut. Hva jeg forventer her er å få informasjon at Facebook har flyttet permanent fra thefacebook.com til Facebook.com. Så jeg forventer et sted nær toppen av mine forespørsler over i mine Utviklerverktøy å få en 301 varsling at Facebook har flyttet permanent. Igjen, jeg vil ikke se 301 på min nettleser skjermen. Og fordi det er en 301, det er en permanent overgang. Nettleseren min, er at det er en moderne nettleser, er trolig kommer til å omdirigere meg til Facebook.com uansett. Men la oss se hva som skjer. Og nå kommer jeg til å gå til thefacebook.com. Og ja, det er det rett på toppen. Det gikk unna, men det var der. La meg bla opp her. Akkurat her på toppen. Jeg gjorde en forespørsel til thefacebook.com, og jeg får et svar at denne siden er flyttet permanent. Og så 307 her er en intern viderekobling. Og så dette er hva som faktisk har flyttet meg til mye mer kjent www.facebook.com. Så disse svarkodene gjør fortsatt skje, selv om vi ikke ser dem. Jeg kommer ikke til å illustrere 401, 403, 404, fordi du har sikkert sett de på ulike punkter. Og 500, ville jeg bare være kind of-- vi ville få heldige hvis fikk en 500 fordi vi ikke vet hva serverne er for øyeblikket nede hvor som helst. Men disse kodene gjøre finnes, og det finnes en vei å få tilgang til dem, selv om vi ikke gjør det se dem på nært hold på våre systemer. Jeg er Doug Lloyd. Dette er CS50.