>> Greit.
Så la oss dykke inn i noen tekniske opplysninger.
Forhåpentligvis med noen hva med en softball spørsmål.
HTTP, er målet for i dag rett og slett ikke gi oss en mental
modell for de typer av søknader
og prosjekter vi er kommer til å gjennomføre.
På onsdag, vil vi overgangen i mer dybde til ting som MVC
og spesielt til Laravel og i ORM
som vi vil snakke med en database.
Men for i dag, la oss sette iscenesette for disse samtalene.
HTTP er hva?
Hypertext Transfer Protocol?
OK hva betyr det?
Yeah.
[Hørbar Remark]
OK. Lukk.
Det er den andre.
Ikke HT - det er at HTML.
HTTP er den som gjør hva?
>> Er at tjenesten som som overfører tekst tilbake
og tilbake mellom servere?
>> Ja akkurat.
Det er serveren.
Så egentlig er det protokollen.
Det er sett av konvensjoner som benyttes
å overføre informasjon tilbake og tilbake mellom klient og server.
Og at informasjon vanligvis tar form av HTML,
Hypertext Markup Language, som er de åpne kodene og nære koder.
Så hvis du har noen klient her representert til venstre
og noen server representert her til høyre.
Pilene går frem og tilbake
mellom dem representerer at språket HTTP.
Og hvis kjent med 50 for eksempel i fjor eller et par
år siden du kanskje husker at vi beskrev det
som en protokoll i den forstand at når jeg først møter noen,
Jeg kan utvide min hånd og si, hei og du kan si -
>> Hei.
>> Hei. Og nå, den slags transaksjon mellom klient
og server er fullført.
OK.
Så HTTP er bare en sett av konvensjoner.
Og blant disse konvensjonene er å sende visse meldinger.
Så for eksempel, La oss åpne Chrome.
Og for kurset, kan du sikkert bruke de fleste hvilken som helst nettleser,
men Chrome har en tendens til å være kanskje den mest populære i disse dager.
Fordi den har en hel pakke med verktøy bygget i.
La oss gå videre og Inspiser Element.
La meg gå til kategorien Network og la meg gå til noe
som http://www.cs164.net og trykk Enter
etter første treffer Record incase vi blir omdirigert.
Og nå skal vi å se en hel haug
rader i denne tabellen.
Hva gjør hver enkelt av disse radene representerer
når du besøker en nettside?
Yeah?
[Hørbar Remark]
Nettopp. Alle filene Jeg valgte nettopp er vist
som en enkelt rad i det lille bordet der,
men vent filer.
Jeg bare ba om en slik fil, ikke sant,
formodentlig index.html eller index.php.
De kan være lenker, ikke sant?
Sikkert er det bilde tags innsiden av det,
det er lenke koder for CSS, det er skriptkodene
for Javascript og en hel haug med andre koder
som faktisk kan trekke
i flere filer slags rekursivt.
Og så det er hva vi ser.
Hvis vi blar opp nå til toppen av disse,
legge merke til at vi først se en det er faktisk litt nysgjerrig.
Det sier vår hjemmeside flyttet midlertidig,
statuskode slik å snakke er 302.
Det er en annen lignende en, 301 som har flyttet permanent.
Og hvis du flytter midlertidig eller permanent hva betyr det?
Hva bør øynene være på jakt etter i orden
å svare på hvor vi flytte til?
Den nåværende og lengde.
OK. Så kunne sikkert antyde hvor vi endte opp.
Og tilsynelatende jeg endte opp på canvas.harvard.edu / noe
som er mye hardere å huske.
Men mer teknisk, jeg vil å diagnostisere en redirect problemet.
Jeg ønsker å forstå hvor jeg er å gå fra punkt A til punkt B
til et punkt prikk, prikk, dot canvas.harvard.edu
i dette mer uforståelige grensesnittet til overskrifter.
Hvordan kan jeg svare på et spørsmål om skjemaet til der jeg flytte?
Beliggenhet. OK.
Så hvis jeg ruller ned her til de Response hoder,
Legg merke til at dette er de overskrifter og la meg endre det.
Dette er liksom en pen trykt versjon fra Chrome.
La oss klikke vis kilde.
Dette er den rå teksten Apache webserver.
Og jeg vet at ved skotter på denne linjen her.
Og Apache er bare gratis og open-source programvare.
Det er sannsynligvis den mest populære web-server programvare der ute.
Det er et resultat av den håndtrykk kommer tilbake til meg.
Og hvis jeg liksom ser på hva som var inne i hånden
eller den virtuelle innhylle at representerer pakkene,
går på tvers av tråden inne
av det er disse flere linjer med tekst.
Og fordi nettlesere selv snakke HTTP,
de er forhåndsprogrammerte av Google og Microsoft
og andre selskaper å se etter denne linjen.
Og når den ser plassering: hva gjør den med nettadressen
etter kolon formodentlig?
Det går til det.
Og vi kan se dette på en rekke måter.
Faktisk en veldig hendig verktøy spesielt på Linux
og Mac OS er hvis jeg åpner et terminalvindu her
og jeg krølle og jeg gjør-jeg og deretter lim denne webadressen der.
Det er en god vane å bruke sitater
fordi hvis du noen gang har spørsmålstegn
eller andre funky tegn, du faktisk kan sortere
av forvirre kommandolinjen.
Men hvis du sitere adressen der, nå får vi se nøyaktig alt
av overskriftene som kom tilbake.
Og i dette tilfellet, faktisk Jeg gjorde feil en.
Jeg gjorde Canvas URL.
La oss gjøre http://www.cs164.net.
Enter. Det er akkurat de samme overskriftene.
Og hvis jeg ønsker å se neste hva som kommer tilbake,
Jeg kan bare gjøre dette manuelt.
Så curl er bare slags rask og skitne diagnostisk verktøy her,
curl-I, og nå som URL igjen og disse er alle overskrifter
som nå kommer tilbake fra canvas.harvard.edu.
Hva mer informasjon sender de oss?
Det er litt avskåret.
La meg flytte dette over.
Så en av disse linjene er interessant.
Så innhold lengde, er at hvor mange byte var inne
av den virtuelle konvolutt som kom tilbake.
Innholdstype det er HTML, det kan være noe annerledes
hvis det er en PNG eller en GIF eller JPEG.
Faktisk, generelt sett, hva er denne strengen som kalles?
Det er disse unike strengene i verden
som unikt beskrive ulike datatyper.
Dette er en såkalt MIME-type, M-I-M-E-type.
Så verden har standardisert
som. png Jeg tror er "image / jpeg".
Verden har standardisert som i HTML-filen er text / html.
Verden har standardisert at en mp4, er filmfil video/mp4.
Så disse er unike symboler som nettlesere vanligvis bruker
å avgjøre om du vil spille det som en film, for å vise det
som et bilde, for å gjengi den som HTML eller lignende.
Hva serveren gjør - instructure selskapet bak Canvas
tilsynelatende bruke?
Så Apache også, så de bruker det samme verktøyet, og vi kan se
som via denne linjen her.
Som en side, har de faktisk gjort noe som er smart
at ikke alle nettsteder gjør.
Svært ofte nettsteder spytte ut,
ikke bare at de er kjører Apache, men også
at de kjører Apache versjon 2.1.3.
Men disse gutta har vært smart og deaktivert versjonsnummeret.
Hvorfor er det smart?
Yeah.
>> Kanskje fordi visse versjon kan bli oppdaget
og har særlig sårbarheter
[Uhørbart] opplagt.
>> Nettopp.
Det er en potensiell sikkerhetstrussel.
Hvis du er i hovedsak kringkasting verden, hey,
vi kjører denne versjonen.
Hei vi kjører denne versjonen.
Det er ikke så vanskelig med Google eller med bare krølle selv å rote
rundt tilfeldige IP-adresser
og finne folk som kjører buggy programvare og deretter angripe dem
etter hva dokumentert betyr at det er.
Nå, hvorfor er det fortsatt sier Apache?
Uten tvil, er den slags umotivert informasjon.
Vel, gjør det enkelt å Apache slå av versjonsnummer
men ikke deres slags bak kulissene merkevarebygging på denne måten.
Og dette er hvordan Google og andre selskapene vet hva web-servere
folk kjører fordi de er bare å fortelle hele verden
hver gang du besøker dem.
Så cookies vil komme tilbake også.
Men du husker kanskje at cookies er liksom store unike numre
som er typisk liker en hånd stempel på brukeren.
Dens en liten fil eller del av data plantet i nettleseren
å huske hvem brukeren er.
Status 200 er bra.
X-Canvas-Meta, så det som er alt dette?
Vel, lang historie kort, verden har også lov til verden
å komme opp med vilkårlig, HTTP overskrifter og hvis du prefiks dem
med X, som bare betyr at de er tilpasset.
Og det er en fin måte selv for diagnoseformål
hvis du utvikler en web-basert applikasjon
og du vil være i stand
å se bak kulissene deg vet hva sikkerhets end server spytte
ut dette svaret, eller hva Versjonsnummeret blir kjørt
på denne serveren.
Eller hva er den interne IP-adresse,
noen ting der du kanskje ønsker noen interne glimt
på noe som er skjer, kan du spytte
ut din egen vilkårlig HTTP-hoder på den måten.
Men historien begynte med åpne opp kurset hjemmeside.
Og vi så på alle disse rader i kategorien Nettverk.
Den første var for det meste interesse at omdirigert oss
til den neste, og så fikk vi tilbake til dette svaret her.
Så, hvor er canvas.harvard.edu?
La oss presse litt videre og sortere
av å følge disse brødsmuler.
Canvas.harvard.edu er tilsynelatende eid av Harvard.
De skapte dette sub-domene kalt canvas.harvard.edu.
Hvordan ville jeg finne ut hvor
i verden canvas.harvard.edu liv?
Eller kanskje mer spesifikt hva er dens IP-adresse?
Hvordan kan vi finne det ut?
Yeah?
[Hørbar Remark]
Absolutt.
Så det er faktisk svare til et par spørsmål der.
Den første slike enkle verktøy ville være noe som kalles nslookup
selv om det heter andre ting.
Nameserver Oppslag og Jeg kan skrive inn noe
som canvas.harvard.edu.
Enter. Og dette kommer til å gi meg tilbake tilsynelatende en hel haug
av svarene.
Men innbytteren kan ikke fornuftig av dette.
Så tilsynelatende,
canvas.harvard.edu er en kanonisk navn
for dette fryktelig ser ting,
Harvard-vanity.instructure.com.
Så, hva er det som skjer her?
Mens i mellomtiden, hvis vi fortsetter å lese,
Harvard-vanity.instructure.com har en kanonisk navn
av noe enda mer kryptisk,
Harvard-170 noe -Oss-øst-1.elb.amazon.aws.
Dessuten løser den tingen
til tilsynelatende tre forskjellige IP-adresser.
Så hva i all verden ikke alle av disse betyr?
Yeah?
[Hørbar Remark]
OK. Bra. Og la meg finpusse én ting som du sa,
det er egentlig ikke en Content Delivery Network.
Fordi det er typisk at betyr at det er statisk innhold
og fordi de fleste av de Nettstedet er dynamisk drevet,
Jeg ville ikke beskrive dette som en CDN
men det er Amazon vert servere.
Amazon tilbyr en tjeneste som heter Amazon Elastic Compute Cloud,
EC2 for korte.
Og disse er bare web servere ofte kjører Apache
eller andre biter av programvare at du kan leie i hovedsak
ved å betale Amazon noen få kroner eller noen få dollar per time
og faktisk du kjører din kode på sine servere.
Og de midler som de gjør dette er at de gir en kryptisk
ser domenenavn som dette som igjen resulterer i en
eller flere IP-adresser som disse tre her.
Og i sin tur, du kan opprette aliaser
som er mye mer menneskevennlig
for at ellers helt unmemorable Amazon adresse.
Og i dette tilfellet Selskapet instructure besluttet
for å lage en noe mer minneverdig adresse,
Harvard-vanity.instructure.com
men det ville være en fryktelig slags ting for oss
å besøke for kurs nettsteder.
Så Harvard i sin tur skapt et annet alias som er mer
bare canvas.harvard.edu.
Og alle disse teknikkene er utnytte noe som kalles DNS,
Domain Name System.
Så lenge systemet administrator har tilgang
til Harvard eller instructure sin DNS-servere,
du kan lage disse aliaser.
Og hvis dere, for dine prosjekter,
bestemmer seg for å kjøpe et domene navn for fem dollar,
10 dollar eller noe sånt.
Og selv betale for en web-vert
eller bare bruke en fritt tilgjengelig web vert, og du vil ha det
å faktisk leve ikke på noe random.com
men på ditt eget domene nevne at du kjøpte for fem
eller 10 dollar disse er de typer konfigurasjonsdetaljer
at vi vil utforske mot slutten av semesteret.
Hvis og når det gjelder tid å sende noe offentlig
slik at den kan leve i en mer interessant URL.
La meg ta en liten pause Fordi dere er liksom
av unødvendig bunching opp i det.
Ønsker du å klønete bare slags komme inn og sitte
i ryggen eller i midten?
Burde jeg ikke trekke merke til deg?
Kom inn
Det er sannsynligvis mer ubehagelig der.
[Pause]
OK.
OK. Velkommen.
OK.
Så hvor kommer som nå forlater oss?
Så en eller annen måte er vi andre og vi vil krysse denne broen hvis
og når den tid kommer i form
DNS hvordan du ville faktisk konfigurere alt dette.
Noen hvordan eller andre, dette HTTP-forespørsel,
denne første håndtrykk når en server hos en
av disse IP-adresser.
På denne serveren er noe kalles en web server.
Ingen overraskelse.
Men det som virkelig teknisk er en web server?
Du liksom ta uttrykket for gitt, men hva er det?
Hva er en web server?
Yeah?
[Hørbar Remark]
OK. Så, det er bare en datamaskin med minne og innganger.
Du vet det kan ha så
sånn bilde tidligere selv skjønt dette er en lite
retro og mer av en desktop eller tower datamaskin.
Ja, det er bare en datamaskin.
Men teknisk sett, en web-server er ikke en datamaskin per si.
Vi som slags mennesker har lang smeltet sammen webservere
og e-postservere som fysiske enheter.
Men en webserver virkelig er et dataprogram.
Det er et stykke programvare kjører på en fysisk datamaskin.
Og derfor kan du ha en e-post-server og en web-server
og et diagram server og noen antall andre servere
eller mer riktig tjenester som kjører på toppen
av en bestemt datamaskin og alle disse tjenester kan leve
på samme IP-adresse derfor.
Så, hvordan - hvis du har du har flere tjenester
eller servere som kjører på samme datamaskin, hvordan når nuller
og de kommer i på dem via internett,
ikke datamaskinen vite om å svare som en e-postserver
med en web-side, med en prat?
Yeah.
[Hørbar Remark]
Bra. Nettopp.
Så en web server lytter på det som kalles en port.
Og hvis du har tatt CS143 Nettverk, kan du vite
at disse portene forholder til protokoller som TCP
som du sannsynligvis på minst hørt om eller UDP.
Og disse porter eller portnumre er bare unike identifikatorer
som identifiserer en tjeneste.
Så 80 er web, 25 er e-post, 23 er Telnet, er 22 SSH
og det er dusinvis eller hundrevis
av andre som selv om det er bare noen få svært populære.
Og dette er en vei for en datamaskin med en IP-adresse
å sortere av multiplex blant forskjellige typer av forespørsel
og reagere deretter.
Så hva betyr dette egentlig?
Så vi trenger ikke en nettleser.
Vi trenger ikke curl til faktisk snakke til en webserver.
Vi må bare forstå hva protokollen er og hvordan det fungerer
og jeg antydet dette for et øyeblikk siden.
Telnet er liksom en old school program.
Tilbake i min dag, brukte vi å bruke den til å sjekke e-post
men det var helt usikkert.
Det er bare et verktøy via der du kan sende tekstkommandoer
til en annen datamaskin.
Og tilbake i dag,
disse tekstkommandoer ofte inkludert ditt brukernavn
og ditt passord med ingen form for kryptering.
Hvis du er kjent med SSH,
SSH er ganske mye Telnet men med kryptering.
Så det er litt av en forenkling.
Men jeg kan late som en menneske med en terminal vindu
og dette gamle skoleprogram Telnet til å være en nettleser.
Jeg kan skrive inn noe som telnet www.cs164.net
og dessverre hvis jeg bare trykke Enter, dens prøver
men ingenting ser ut å skje.
Og det er på grunn av retten, verden besluttet år siden
at Telnet er standardporten er 23
som jeg kort hentydet til øyeblikk siden.
Men jeg ønsker ikke Telnet per si.
Jeg ønsker å bruke Telnet denne typen av tekstlig program for å late
å være en nettleser i Chrome og IE og andre nettlesere
som standard har vært vanskelig kodet av Google og Microsoft
å snakke ikke til 23, men til 80 eller kanskje 443
for SSL-baserte nettsteder.
Og nå, merker jeg prøve, og jeg koble til webserveren.
Jeg kommer nå, gå videre og si noe sånt som hei.
Og tydeligvis dette har nettopp flyttet permanent.
Jeg sender noen falsk kommando
og dens sende meg tilbake til denne adressen her.
Så, la oss faktisk gjør dette litt annerledes.
La oss faktisk se si, GET/HTTP/1.1.
Så hva gjør jeg?
Dette er kommandoen.
Dette er liksom min håndtrykk, så å si.
Hva er det frem slash sannsynligvis indikere?
Hjemmekatalogen.
Så hjemmekatalogen her er det bare betyr -
vel la oss kalle det roten av nettstedet.
Uansett standardfilen er, kanskje det er index.html,
kanskje det er index.php
og HTTP/1.1 er i hovedsak den nyeste versjonen av HTTP.
Så jeg later til å være en nettleser som er ganske aktuell
slik at den svarer det meg som jeg håper.
Og jeg går videre og trykk Enter to ganger
fordi måten ting fungerer er at når du ser en blank linje,
gjør en web server deretter svare.
Men dessverre Dette er en dårlig forespørsel.
Nettleseren sendte en forespørsel
at denne serveren kunne ikke forstå.
Nå er dette er en mye vanskeligere å diagnostisere.
Men det viser seg at cs164.net bruker Apache.
Og ikke mye vi kan finne ut.
Men det er også å bruke noe kalt virtuell hosting
hvor du kan bli kjent.
Kanskje vagt fra dine CS50 dager
eller hvis du har skrevet kommersielle nettsteder før,
hva er en virtuell host eller vhost?
Yeah.
[Hørbar Remark]
OK. Nettopp.
Så det er flere lag med multiplekses her så å si.
Når du får en forespørsel på noen server
på en bestemt IP-adresse, du minimalt behov for at portnummer
slik at serveren vet dette er en e-post, er det en web forespørsel,
en chat-melding eller hva ikke.
Men hvis når du finne ut, OK, dens port 80.
Det er åpenbart forespørsel for en web-side.
Men ville det ikke vært fint
hvis en enkelt server kunne faktisk støtter flere
nettsteder, food.com og bar.com og bass.com
slik at de ikke trenger en fysisk server eller en enkelt stykke
av programvare for hvert faen nettsted i verden.
Så verden oppfunnet virtuelle hosting som lar deg
å sette flere domenenavn på samme IP-adresse.
Men fangsten er tilkoblingen Jeg har nettopp gjort ved hjelp av Telnet,
spesifisere port 80 til www.cs164.net jeg gjorde ingen omtale
av domenenavnet at jeg var interessert
i utover kommandolinjen.
Og dessverre, og dette er en liten ikke-åpenbare.
Så snart jeg trykker Enter,
hovedsak Telnet presumptuously er konvertering
www.cs164.net for meg til en IP-adresse
og så bare sende min rå GET-forespørsel til serveren.
Slik at forestillingen om at det var www.cs164.net helt tapt,
høyre.
Telnet er ikke en nettleser hvorfor skulle det bry å sende
mer informasjon til serveren?
Det er ikke så smart.
Så jeg bla har minne serveren
som ikke bare ønsker jeg å få hjemmesiden,
Jeg ønsker også å spesifisere en rekke cs164.net.
Og HTTP header så å tale er akkurat det, Host:.
Nå, når jeg trykker på Enter, jeg få tilbake den samme redirect
som jeg så i Chrome, og at jeg så i curl, men jeg tør si nå,
vi gjør dette bare omtrent så lavt nivå
som er teknisk mulig
ved hjelp av disse mer uforståelige kommandoer.
Nå, hvorfor er dette nyttig?
Så, dette er ikke den normale vei for å besøke en nettside
men nesten enhver tid, du nødt til å diagnostisere noen problem
med web-basert applikasjon som innebærer en server eller brikke
av programvare eller nylig opprettet virtuell vert
eller nylig kjøpt domenenavnet.
Dette er akkurat de verktøyene at du vet Tim og Rob og jeg
og andre ville bruke bare for å prøve å finne
ut hva som går galt, ikke sant?
Case in point når du kommer et domenenavn, du liksom ha
å knytte en IP ta med det.
Og du gjør dette vanligvis via web-basert grensesnitt på GoDaddy
eller namecheap.com eller hvor du kjøpte domenenavnet.
Så forskjellige nettsteder har ulike verktøy
men det er i hovedsak på en Excel-tabell med kolonner
for vertsnavn og kolonner
for IP-adressene noe sånt.
Men det er et problem fordi når du blir bedt om
å knytte en IP-adresse med et vertsnavn, blir du bedt om
for sin TTL som står for - du tok 143.
Jeg hører det over her.
Time To Live.
En TTL betyr hvor mange sekunder bør denne oppføringen bli husket
for og av husket, Jeg mener bufret.
Så, lang historie kort, også innen DNS verden
det er hele denne oppfatningen av caching.
Og dette er et tema vi vil utforske i kurset også
på en programvarenivå der caching er ofte en virkelig
god ting.
Og hva mener vi med caching en nettside for eksempel
eller caching en DNS rekord, en IP-adresse?
Hva betyr det for cache?
Yeah.
[Hørbar Remark]
Ja, akkurat bare å holde rundt en kopi slik at
hvis det ikke endrer eller ærlig selv om endrer seg,
lar ikke merke i minst noen få sekunder kanskje enda noen
minutter eller verre for en time eller to.
Og i et nettsted, kan du har sett dette før,
noen ganger hvis du er ved hjelp av en nettside,
ikke så mye de største nettsteder.
Du har en tendens til å få dette detalj akkurat som Facebook
og Gmail og lignende.
Men hvis du bruker en annen nettside som bruker mye
av teknologiene vi vil bruke i klassen,
det er ofte en design beslutning å avgjøre hvorvidt
å cache noe, og hvis så, hvor lenge å cache noe.
Og hvis du noen gang har vært på en nettside
der for eksempel du treffer Lagre og så laste siden på nytt
og deretter hva du postet er ikke der.
Men så kanskje du reload igjen og det ser ut.
Og faktisk, har jeg faktisk sett symptom selv
med Facebook gang på en stund
der hvis du har lastet din News Feed,
noen ganger noe er der, noen ganger er det forsvinner
og ting ikke egentlig synes konsekvent.
Og det er ofte resultatet av bare caching problemer.
På en forespørsel, er du treffer én server.
På en annen forespørsel, er du treffer en annen server
og deres cacher, deres kopier
av websider kanskje ikke være helt synkron
etter noen få sekunder eller minutter
slik at du ser annerledes statene i verden.
Samme skjer med DNS.
Hvis du bestemmer deg for at du eier food.com
og hvis du har vært vert det på GoDaddy,
en ganske populær web hosting selskapet blant annet
og du bestemmer deg for, nei, jeg gjør ikke det virkelig liker deres politikk,
Jeg vet egentlig ikke liker deres priser, deres tjenester.
Jeg ønsker å bytte til en annen web hosting selskapet alle sammen.
Hva gjør du da?
Vel, du vil bare endre IP-adressen til food.com å peke
på noen andres server som du kommer til å starte penger til.
Men fordi hele DNS server-systemet bruker cacher,
hva kan dette bety for brukerne
hvis du plutselig flytter ditt nettsted herfra
til over her, annerledes IP-adresse.
OK.
For noen som ikke er null av minutter eller sekunder,
brukerne kan ende opp med å gå her for eksempel, eller her
fordi deres operativsystem, sin nettleser, deres ISP,
deres hjem ruteren har kanskje bufret den gamle IP-adressen
på hvilket tidspunkt, dens veldig vanskelig å figur
ut nøyaktig hva som går galt.
Så hvordan kan du begynne å jage ned enda problemer sånn?
Bare ved å følge disse brødsmuler
og forståelse til syvende og sist hva er HTTP
og hva betyr det å sende en forespørsel og hva gjør verktøy
som nslookup faktisk gjøre for deg.
Og så hvordan kan du utføre noen av disse lavt nivå kommandoer
og bare finne ut hva faktisk går galt.
Så du vet hvem du skal ringe, som å sende ut en e-post til eller hva
å endre på din egen server.
Og som en side, Jeg tipper de fleste
av dere her har brukt CS50 Appliance, hvis du tok CS50.
Selv om du ikke har mange
av har du sannsynligvis brukt Apache enten på din egen Mac
eller PC eller Linux-bokser.
Akkurat som en side, hvis jeg gjør åpne et terminalvindu her
på den nyeste CS50 Appliance og jeg blir rot med Sudu su
og så går jeg inn denne katalogen
her etc / httpd / conf.d /.
Dette er en vanlig plasser for web server -
for Apache web-servere for å lagre konfigurasjonsfilene.
Conf.d betyr bare konfigurasjon katalog med en hel haug
av filer, og hvis jeg skal åpne opptil med vi eksempelvis
apparatet 50, vil du faktisk se hvordan virtuell hosting
i CS50 Appliance har vært arbeider alle disse tid.
Hvis det har gått en stund tilbakekalling
at du kan sette de fleste hvilken som helst nettside inne
av din vhost katalog i Appliance.
Hvordan det faktisk fungerer?
Vel merke til, er dette en litt uforståelige, og du kan sortere
av grok deg gjennom dette ved hjelp av dokumentasjonen.
Men i hovedsak de sannsynligvis den mest nyttige linjen
å se opp - se på dette.
Denne linjen her i hovedsak forteller webserveren til å se
i John Harvards vhost katalog
for den nederste tilfelle versjon uansett servernavn
eller domenenavn var faktisk besøkte.
Og vi vil ikke nødvendigvis gå inn med denne graden av fiksing og triksing.
Men når du bruker Apache, du er de
som i siste instans har Kontroll over disse detaljene.
OK. Så, fra nå, kan vi nå ta HTTP for gitt, ikke sant?
OK.
Så hvorfor kan ikke vi gjøre dette, spesielt hvis noen
av dere føler noe en fange publikum, hvorfor ikke vi gå videre
og ta en to minutters pause,
når vi kommer tilbake vil vi dykke litt inn i MVC og vi vil
på en lapp på - av et problem som vi vil da løse på onsdag
med et verktøy kalt Laravel.
Så, la oss ta en par minutter.