HTTP protokollen
Vel, i løpet av de siste to artikler om HTTP som jeg har skrevet, er det blitt klart at det er en god del til HTTP-protokollen. Det er absolutt det jeg vil kalle en "tett" protokollen, rett og slett fordi det er mye til det. Mye som DNS er en tett protokollen på grunn av sine mange ressurs poster og funksjonene de oppfylle. Du tenker kanskje at "hellig ku" er der ennå mer til HTTP!?. Faktisk er det, ville være svaret, og det er ganske ryddig hvis du spør meg. Å ha protokoller som HTTP utføre så mange forskjellige oppgaver via sin innebygde beregninger, for eksempel de vi allerede har dekket, er ingen liten prestasjon. Derfor min lue går bort til utviklerne av HTTP-protokollen, i alle sine revisjoner. De er de virkelige talenter uten tvil.
Med det blir sagt, akkurat hva annet er det å dekke. Vi må røre noen av de gjenværende delene av HTTP-protokollen en brikke av gangen. Også som lovet i del to, skal jeg raskt dekke bruken av en HTTP-proxy som Spike fullmektig. Dette utmerket verktøy ble skrevet av Dave AITeL, som også skjer for å være en av de premiere talenter i dag i en verden av nettverkssikkerhet.
Hva er statuskoder?
Som mange protokoller, fungerer HTTP på klient /server modell. Ved hjelp av denne modellen, er det logisk ville være behov for å formidle feiltilstander, som de er oppstått i løpet av økten mellom web klient og web server. Gir mening gjør det ikke? For hvis du ikke har slike statuskoder ting kan fort bli veldig rotete. De statuskoder som brukes av mange applikasjonslaget protokoller er brutt ned i fem hovedkategorier, og er som følger;
Statuskode serie 1xx
Statuskode serie 2xx
Statuskode serien 3xx
Status kode serie 4xx
Statuskode kode~~POS=HEADCOMP serie 5xx
Hver applikasjonslaget protokollen vanligvis har spesifikke feiltilstander tildelt kategoriene nevnt ovenfor. I vårt tilfelle er de som følger;
1xx serien
Kode 100 Fortsett
Kode 101 Bytte protokoller
2xx serien
Kode 200 OK < BR> Kode 201 Laget
Kode 202 Akseptert
Kode 203 ikke-autoritativ
det er ganske mange flere som dette går opp til 500-serien. De kan alle bli funnet på denne linken. Jeg håper du ikke cringe når du ser at det er den faktiske RFC for HTTP. Den definitive kilde for alle protokoller er alltid RFC for det. Fant det vil være alle nitty, sandete detaljer som jeg liker å lese.
klientforespørsler og kommandoer
Nå har vi dekket GET-forespørsel som vi så i pakken som inneholdt web-klienter be til webserveren, det er mange flere typer som vi kan se en webklient problem. La oss dekke dem! Følgende er en liste over potensielle web klient forespørsler eller handlinger til en webserver.
GET
web klient ber om en ressurs som er på webserveren
POST
Dette illustrerer at webklienten sender informasjon til webserveren og er ganske ofte brukt, da si, fylle ut et elektronisk skjema.
PUT
Dette skjer når en webklient sender en erstatning dokument til webserveren.
HEAD
Du vil se dette når webklienten ønsker litt informasjon om en ressurs på serveren og er ikke ber om ressursen selv.
SLETT
Vel dette er ganske enkel, og brukes til å slette et dokument fra webserveren.
TRACE
Dette vil normalt ikke se, men er brukes når webklienten ønsker fullmakter til å erklære seg. Det er ofte brukt for debugging formål.
Alternativer
Du vil se dette når webklienten ønsker å vite hva andre metoder kan brukes til et dokument på serveren.
CONNECT
Avrunding ut de ulike klient metoder er å koble. Dette brukes når en web klient ønsker å koble til en HTTPS-server via en proxy.
Det er ganske mange metoder som en web-klient kan bruke til å chatte med en webserver som vi nå kan se. Når det er sagt, vil du normalt bare se GET-forespørsel og noen ganger HEAD hvis alt du gjør er normal surfing. Alle disse er i bruk, men hvis du prøver å kanskje feilsøke en webapplikasjon.
Noen stjal min cookie!
Det var nok ikke den cookie monster heller. Det er ganske mange misoppfatninger om cookies, som jeg antydet tidligere i denne artikkelserien på HTTP. En av de største jeg finner er bare, hva er de og hva gjør de? Det lønner seg alltid å være så utdannet som mulig, og bruke det som min naturlig overgang måte kan diskutere cookies!
Akkurat det er en cookie anyways? Vel, enkelt sagt, de er en ren tekstfil som lagres på klientmaskinen av webserveren. Denne informasjonskapselen brukes til å lagre session variabler som brukernavn, passord, blant annen informasjon. Cookies seg selv er ikke en del av HTTP-protokollen i seg selv, men det er nå ganske mye betraktet synonymt med det. Noen nettsteder tvinge deg til å akseptere cookies for nettstedet til å fungere skikkelig. Så i noen tilfeller er det ikke lurt å nekte cookies helt som en del av sikkerhetsinnstillingene.
Det finnes to typer informasjonskapsler; økten cookie, som bare er gyldig for lengden på lesertilkobling til nettstedet, og den vedvarende cookie, som vil overleve utover økten avsluttes. Det er viktig å innse, som jeg nevnte tidligere at en cookie er ikke en kjørbar. Det blir sagt cookies selv bør ideelt sett være kryptert, slik som å oppheve tilfeldig disseksjon av dem.
Bruke Spike proxy
Jeg nevnte tidligere at en måte å fremme din kunnskap om HTTP er å bruke et verktøy som Spike fullmektig. Hva dette verktøyet vil tillate deg å gjøre er å fange opp web klientforespørsler, og endre dem. Du ønsker ikke å gjøre dette mot en ekte web server, ellers eierne kan få rasende med deg! Det jeg foreslår er at du bare laste ned en versjon av Apache, og installere det på en datamaskin i hjemmet. Vær klar over at du vil trenge en JRE på datamaskinen for å bruke Spike Proxy. Når dette er gjort er du fri til å nå påberope Spike Proxy, og begynner å endre dine HTTP-forespørsler for å se hvordan Apache web server vil reagere på det.
Avsluttende tanker
Å være involvert i datanettverk industrien, uansett form som kan ta, som betyr at du må hele tiden være å oppgradere dine ferdigheter. Enten det betyr å lære det nye Windows web server, eller videreutvikle din kunnskap om en spesifikk protokoll. Den underliggende tema er at du må sette av litt tid til å stadig oppsøke nye informasjonen for å lære. Bor fortsatt i denne bransjen lover ikke godt for ens levetid i det. Jeg håper at denne artikkelen serien var av interesse for deg. Som alltid jeg tar gjerne imot tilbakemeldinger, både gode og dårlige. Til neste gang!