Izdali smo novu knjigu, Marketing sadržaja društvenih medija: Kako ući u glave svojih pratilaca i natjerati ih da se zaljube u vaš brend.
HTTP je ono što omogućava prijenos podataka. Prvobitno je kreiran za slanje i primanje dokumenata koji sadrže veze u sebi za prelazak na resurse trećih strana.
Skraćenica glasi “HyperText Transfer Protocol”, što u prijevodu znači “protokol za prijenos”. HTTP pripada grupi slojeva aplikacije na osnovu specifičnosti koje koristi OSI.
Da bismo bolje razumjeli šta HTTP znači, pogledajmo jednostavnu analogiju. Zamislimo da komunicirate sa strancem na društvenoj mreži. On vam pošalje poruku na engleskom, vi je primite. Ali ne možete razumjeti sadržaj jer ne govorite dobro jezik. Za dešifriranje poruke koristite rječnik. Pošto ste shvatili suštinu, strancu odgovarate na ruskom i šaljete odgovor. Stranac dobija odgovor i uz pomoć prevodioca dešifruje poruku. Da bi se cijeli mehanizam pojednostavio, Internet protokoli HTTP obavljaju funkciju prevoditelja. Uz njihovu pomoć, pretraživač može prevesti šifrirani sadržaj web stranica i prikazati njihov sadržaj.
Čemu služi HTTP?
HTTP protokol se koristi za razmjenu informacija korištenjem klijent-server modela. Klijent sastavlja i prenosi zahtjev serveru, zatim ga server obrađuje i analizira, nakon čega se kreira odgovor i šalje korisniku. Na kraju ovog procesa, klijent izdaje novu naredbu i sve se ponavlja.
Dakle, HTTP protokol omogućava razmjenu informacija između različitih korisničkih aplikacija i posebnih web servera, kao i povezivanje s web resursima (obično pretraživačima). Danas opisani protokol osigurava rad cijele mreže. HTTP protokol za prijenos podataka se također koristi za prijenos informacija preko drugih protokola nižeg nivoa, na primjer, WebDAV ili SOAP. U ovom slučaju, protokol je prevozno sredstvo. Mnogi programi se također oslanjaju na HTTP kao primarni alat za razmjenu informacija. Podaci se prikazuju u različitim formatima, na primjer, JSON ili XML.
HTTP je protokol za razmjenu informacija preko IP/TCP veze. Obično server koristi TCP port 80 u tu svrhu. Ako port nije naveden, klijentski softver će prema zadanim postavkama koristiti TCP tip porta 80. U nekim slučajevima mogu se koristiti i drugi portovi.
HTTP protokol koristi simetričnu šemu šifriranja i koristi simetrične kriptosisteme. Simetrični kriptosistemi uključuju korištenje istog ključa za šifriranje i dešifriranje informacija.
Koja je razlika između HTTP-a i HTTPS-a
Razlika se može otkriti čak i dekodiranjem skraćenica. HTTPS je skraćenica od Hypertext Transfer Protocol Security. Dakle, HTTP je nezavisan protokol, a HTTPS je ekstenzija koja ga štiti. HTTP prenosi informacije nezaštićene, dok HTTPS pruža kriptografsku zaštitu. Ovo posebno važi za resurse sa odgovornim ovlašćenjem. To mogu biti društvene mreže ili stranice platnog sistema.
Koje su opasnosti od prenošenja nezaštićenih podataka? Program presretača može ih prenijeti napadačima u bilo kojem trenutku. HTTPS ima složenu tehničku organizaciju, koja vam omogućava da pouzdano zaštitite informacije i eliminišete mogućnost neovlašćenog pristupa njima. Razlika je u portovima. HTTPS obično radi na portu 443.
Dakle, HTTP se koristi za prijenos podataka, a HTTPS omogućava siguran prijenos podataka korištenjem enkripcije i autorizacije na resursima s visokim nivoom sigurnosti.
Dodatna funkcionalnost
HTTP je bogat funkcionalnošću i kompatibilan je s raznim ekstenzijama. Specifikacija 1.1 koja se danas koristi omogućava da se zaglavlje Upgrade koristi za prebacivanje i rad kroz druge protokole prilikom razmjene podataka. Da bi to učinio, korisnik mora poslati zahtjev serveru sa ovim zaglavljem. Ako server treba da se prebaci na određenu razmjenu koristeći drugi protokol, on vraća zahtjev klijentu, koji prikazuje status “426 Upgrade Required”.
Ova funkcija je posebno relevantna za razmjenu informacija putem WebSocket-a (ima specifikaciju RFC 6455, koja vam omogućava razmjenu podataka u bilo koje vrijeme, bez nepotrebnih HTTP zahtjeva). Za migraciju na WebSocket, jedan korisnik šalje zahtjev sa zaglavljem za nadogradnju i vrijednošću “websocket”. Zatim, server odgovara sa "101 Switching Protocols." Nakon ovog trenutka počinje prijenos informacija putem WebSocketa.
Svrha protokola
Protokol za prijenos hiperteksta (HTTP) je protokol visokog nivoa (naime, na nivou aplikacije) koji obezbeđuje potrebne brzine prenosa podataka potrebne za distribuirane hipermedijske informacione sisteme. HTTP se koristi u projektu World Wide Web od 1990. godine.
Praktični informacioni sistemi zahtevaju više od primitivnog pronalaženja, modifikacije i beleženja podataka. HTTP/1.0 pruža otvoreni skup metoda koje se mogu koristiti za specificiranje svrhe zahtjeva. Oni su izgrađeni na referencirajućoj disciplini, gdje se univerzalni identifikator resursa (URI), u obliku lokacije (URL) ili imena (URN), koristi za označavanje resursa na koji treba primijeniti dati metod. Format poruke je sličan Internet pošti ili višenamjenskim ekstenzijama Internet pošte (MIME).
HTTP/1.0 se takođe koristi za komunikaciju između različitih korisničkih pretraživača i gateway-a koji daju hipermedijski pristup postojećim Internet protokolima kao što su SMTP, NNTP, FTP, Gopher i WAIS. HTTP/1.0 je dizajniran da omogući takvim gatewayima da prenose podatke preko proxy servera bez ikakvih gubitaka koristeći ove ranije protokole.
Opća struktura
HTTP je baziran na paradigmi zahtjeva/odgovora. Program koji traži (obično se zove klijent) uspostavlja vezu sa uslužnim programom primaoca (obično se zove server) i šalje zahtev serveru u sledećem obliku: metoda zahteva, URI, verzija protokola, nakon čega sledi poruka nalik MIME koji sadrži informacije o kontroli zahtjeva, informacije o klijentu i možda tijelo poruke. Server odgovara porukom koja sadrži statusni niz (uključujući verziju protokola i statusni kod uspjeha ili greške), nakon čega slijedi poruka nalik MIME koja uključuje informacije o serveru, metainformacije o sadržaju odgovora i možda odgovor samo telo. Treba napomenuti da jedan program može biti i klijent i server u isto vrijeme. Upotreba ovih termina u ovom tekstu odnosi se samo na ulogu koju program obavlja tokom te posebne komunikacijske sesije, a ne na opšte funkcije programa.
Na Internetu se komunikacija obično zasniva na TCP/IP protokolima. Za WWW, podrazumevani broj porta je TCP 80, ali se mogu koristiti i drugi brojevi portova - to ne isključuje mogućnost korišćenja HTTP-a kao protokola najvišeg nivoa.
Za većinu aplikacija, sesiju otvara klijent za svaki zahtjev i zatvara server nakon što je odgovor na zahtjev završen. Međutim, to nije karakteristika protokola. I klijent i server moraju biti u mogućnosti da zatvore komunikacijsku sesiju, na primjer, kao rezultat neke radnje korisnika. U svakom slučaju, prekid veze iniciran od strane bilo koje strane prekida trenutni zahtjev, bez obzira na njegov status.
Opšti koncepti
Zahtjev je poruka koju klijent šalje serveru.
Prvi red ove poruke uključuje metodu koja će se primijeniti na traženi resurs, identifikator resursa i verziju protokola za korištenje. Za kompatibilnost sa HTTP/0.9 protokolom, postoje dva formata HTTP zahtjeva:
Upit = Jednostavan upit | Full-Request Simple-Request = "GET" SP Requested-URI CRLF Full-Request = Line-Status *(General-Header | Request-Header | Content-Header) CRLF [Request-Contents]
Ako HTTP/1.0 server primi Simple-Request, mora odgovoriti sa HTTP/0.9 Simple-Response. HTTP/1.0 klijent sposoban da obradi Full-Response nikada ne bi trebao slati Simple-Request.
Status linije
Red statusa počinje linijom s imenom metode, nakon čega slijedi URI zahtjeva i verzija protokola koja se koristi. Statusna linija završava CRLF znakovima. Linijski elementi su odvojeni razmacima (SP). Znakovi LF i CR nisu dozvoljeni u statusnoj liniji, sa izuzetkom završne CRLF sekvence.
String-Status = Metoda SP zahtjeva URI SP Verzija-HTTP CRLF
Treba napomenuti da je razlika između statusne linije punog zahtjeva i statusne linije jednostavnog zahtjeva prisutnost polja HTTP-verzija.
Metoda
Polje Metod specificira metodu koja se treba primijeniti na resurs identificiran URI-jem zahtjeva. Nazivi metoda razlikuju velika i mala slova. Postojeća lista metoda se može proširiti.
Metod = "GET" | "HEAD" | "PUT" | "POST" | "IZBRIŠI" | "LINK" | "UNLINK" | dodatna-metoda
Lista metoda dozvoljenih od strane određenog resursa može se navesti u polju Naslov-Sadržaj u “Points”. Međutim, klijent je uvijek informiran od servera putem statusnog koda odgovora da li je data metoda dozvoljena za navedeni resurs, budući da se valjanost različitih metoda može dinamički mijenjati. Ako je data metoda poznata serveru, ali nije dozvoljena za navedeni resurs, server MORA vratiti statusni kod "405 Method Not Allowed" i statusni kod "501 Not Implemented" ako metoda nije poznata ili ne podržava dati server. Uobičajene metode HTTP/1.0 opisane su u nastavku.
GET
Metoda GET se koristi za dohvaćanje bilo koje informacije koju identifikuje URI zahtjeva. Ako se URI zahtjeva odnosi na proces koji proizvodi podatke, odgovor će biti podaci generirani tim procesom, a ne sam procesni kod (osim ako nije izlaz procesa).
Metoda GET se mijenja u "uvjetni GET" ako poruka zahtjeva uključuje polje zaglavlja "If-Modified-Since". Kao odgovor na uslovni GET, tijelo traženog resursa se prenosi samo ako je izmijenjeno od datuma navedenog u zaglavlju "If-Modified-Since". Algoritam za određivanje ovoga uključuje sljedeće slučajeve:
- Ako je statusni kod odgovora na zahtjev drugačiji od "200 OK", ili je datum naveden u polju zaglavlja "If-Modified-Since" netačan, odgovor će biti identičan odgovoru na normalan GET zahtjev.
- Ako se resurs promijenio od navedenog datuma, odgovor će također biti identičan odgovoru na običan GET zahtjev.
- Ako resurs nije izmijenjen od navedenog datuma, server će vratiti statusni kod "304 Nije modificirano".
Upotreba uvjetne GET metode ima za cilj rasterećenje mreže, jer vam omogućava da izbjegnete prijenos suvišnih informacija preko mreže.
HEAD
Metoda HEAD je slična GET metodi, osim što server ne vraća tijelo odgovora u odgovoru. Meta informacije sadržane u HTTP zaglavljima odgovora na HEAD zahtjev moraju biti identične informacijama sadržanim u HTTP zaglavljima odgovora na GET zahtjev. Ova metoda se može koristiti za dobivanje metainformacija o resursu bez prijenosa samog resursa preko mreže. Metoda "Uslovna HEAD", slična uslovnom GET-u, je nedefinisana.
POŠTA
POST metoda se koristi za traženje od servera da prihvati informacije uključene u zahtjev kao podređene resursu navedenom u statusnoj liniji u polju URI zahtjeva. POST metoda je dizajnirana da omogući korištenje jedne uobičajene metode za sljedeće funkcije:
- Sažetak postojećih resursa
- Dodavanje poruka u novinske grupe, mailing liste ili slične grupe članaka
- Isporuka blokova podataka procesima koji obrađuju podatke
- Proširivanje baza podataka kroz operaciju dodavanja
Stvarnu funkciju koju obavlja POST metoda određuje server i obično ovisi o URI-ju zahtjeva. Informacije koje se dodaju tretiraju se kao podređene navedenom URI-ju u istom smislu kao što je datoteka podređena direktoriju u kojem se nalazi, novi članak je podređen novinskoj grupi u koju je dodan, unos je podređen direktoriju u kojem se nalazi. bazu podataka.
Klijent može predložiti URI za identifikaciju novog resursa uključivanjem "URI" zaglavlja u zahtjev. Međutim, server bi ovaj URI trebao tretirati samo kao savjet i može pohraniti tijelo zahtjeva pod drugim URI-jem ili bez URI-ja.
Ako je novi resurs kreiran kao rezultat obrade POST zahtjeva, odgovor bi trebao imati statusni kod "201 Created" i sadržavati URI novog resursa.
STAVITI
Metoda PUT zahtijeva od servera da pohrani tijelo zahtjeva pod URI jednak URI-ju zahtjeva. Ako se URI zahtjeva odnosi na već postojeći resurs, tijelo zahtjeva treba tretirati kao modificiranu verziju tog resursa. Ako resurs na koji upućuje URI zahtjeva ne postoji, a dati URI se može smatrati opisom za novi resurs, server može kreirati resurs sa datim URI-jem. Ako je kreiran novi resurs, server mora obavijestiti klijenta koji je zatražio odgovor putem statusnog koda “201 Kreirano”. Ako je postojeći resurs izmijenjen, mora se poslati odgovor "200 OK" da obavijesti klijenta da je operacija bila uspješna. Ako se resurs sa navedenim URI-jem ne može kreirati ili modificirati, mora se poslati odgovarajuća poruka o grešci.
Osnovna razlika između POST i PUT metoda je različito značenje polja Request URI. Za metodu POST, ovaj URI specificira resurs koji će upravljati informacijama sadržanim u tijelu zahtjeva kao dodatak. Resurs bi mogao biti proces obrade podataka, pristupnik nekom drugom protokolu ili poseban resurs koji dozvoljava bilješke. Nasuprot tome, URI za PUT zahtjev identifikuje informacije sadržane u sadržaju zahtjeva. Korisnik PUT zahteva tačno zna koji URI namerava da koristi, a primalac zahteva ne bi trebalo da pokušava da primeni zahtev na neki drugi resurs.
IZBRIŠI
Metoda DELETE se koristi za brisanje resursa identificiranih URI-jem zahtjeva. Rezultati ove metode na serveru mogu se promijeniti ljudskom intervencijom (ili nekim drugim načinom). U principu, klijent nikada ne može biti siguran da je operacija brisanja završena, čak i ako statusni kod poslat od servera ukazuje da je akcija bila uspješna. Međutim, server ne bi trebao prijaviti uspjeh sve dok, u vrijeme odgovora, ne želi izbrisati dotični resurs ili ga premjestiti u neko nedostupno područje.
VEZA
LINK metoda uspostavlja odnose između postojećeg resursa navedenog u URI-ju zahtjeva i drugih postojećih resursa. Razlika između metode LINK i drugih metoda koje omogućavaju uspostavljanje veza između dokumenata je u tome što metoda LINK ne dozvoljava prosljeđivanje tijela zahtjeva u zahtjevu i što se kao rezultat ove metode ne kreiraju novi resursi.
UNLINK
Metoda UNLINK uklanja jednu ili više veza veza za resurs naveden u URI-ju zahtjeva. Ovi odnosi se mogu uspostaviti pomoću metode LINK ili neke druge metode koja podržava zaglavlje "Link". Uklanjanje veze do resursa ne znači da resurs prestaje postojati ili postaje nedostupan za buduće reference.
Polja zaglavlja zahtjeva
Polja zaglavlja zahtjeva omogućavaju klijentu da prosledi dodatne informacije serveru o zahtevu i samom klijentu.
Zaglavlje zahtjeva = Prihvati | Prihvati-Charset | Accept-Encoding | Accept-Language | Autorizacija | Od | If-Modified-Since | Pragma | Referrer | Korisnički agent | extension-header
Dodatno, dodatna zaglavlja se mogu definirati kroz mehanizam proširenja; aplikacije koje ih ne prepoznaju moraju tretirati ova zaglavlja kao sadržaj zaglavlja.
Neka od polja zaglavlja zahtjeva će biti razmotrena u nastavku.
Od
Ako je polje Od prisutno, ono mora sadržavati punu adresu e-pošte korisnika koji kontrolira agentski program koji postavlja zahtjeve. Ova adresa mora biti navedena u formatu definisanom u RFC 822. Format ovog polja je: Od = "Od" ":" specifikacija adrese. Na primjer:
Ovo polje se može koristiti za funkcije prijave, kao i za identifikaciju izvora netačnih ili neželjenih zahtjeva. Ne treba ga koristiti kao neklasifikovani oblik kontrole pristupa. Tumačenje ovog polja je da se zahtjev koji se obrađuje vrši u ime datog korisnika, koji prihvata odgovornost za korišteni metod. Posebno, robotski agenti bi trebali koristiti ovo zaglavlje kako bi se osoba odgovorna za robota mogla kontaktirati ako se pojave problemi. Internet adresa pošte navedena u ovom polju ne mora se podudarati sa adresom hosta sa kojeg je ovaj zahtjev poslan. Kad god je to moguće, adresa treba da bude pristupačna Internet adresa, bez obzira da li je to zapravo Internet adresa e-pošte ili Internet E-mail adresa adrese iz drugih sistema pošte.
Napomena: Klijent ne bi trebao koristiti polje zaglavlja From bez dozvole korisnika, jer to može biti u sukobu s njegovim privatnim interesima ili sa njegovim lokalnim sigurnosnim sistemom. Izričito se preporučuje da se korisniku da mogućnost da onemogući, omogući ili izmijeni ovo polje u bilo kojem trenutku prije nego što podnese zahtjev.
If-Modified-Since
Polje zaglavlja If-Modified-Since se koristi sa metodom GET kako bi se učinilo uslovnim: ako se traženi resurs nije promijenio u vremenu navedenom u ovom polju, server neće vratiti kopiju tog resursa; umjesto toga, bit će vraćen odgovor "304 Nije modificirano" bez tijela odgovora.
If-Modified-Since = "If-Modified-Since" ":" HTTP datum
Primjer korištenja zaglavlja:
Svrha ove funkcije je da omogući efikasno ažuriranje informacija lokalne keš memorije uz minimum prenetih informacija. Isti rezultat se može postići korištenjem metode HEAD praćeno GET-om ako je server naznačio da se sadržaj dokumenta promijenio.
Korisnički agent
Polje zaglavlja User-Agent sadrži informacije o korisničkom agentu koji je poslao zahtjev. Ovo polje se koristi za statistiku, praćenje grešaka u protokolu i automatsko prepoznavanje korisničkog agenta. Iako nije obavezno, korisnički agenti bi uvijek trebali uključiti ovo polje u svoje zahtjeve. Polje može sadržavati više nizova koji predstavljaju naziv softverskog proizvoda, opcionalnu kosu crtu koja označava verziju proizvoda i druge softverske proizvode koji su važan dio korisničkog agenta. Po konvenciji, proizvodi su navedeni u opadajućem redoslijedu prema njihovoj važnosti za identifikaciju aplikacije.
Korisnički agent = "Korisnički agent" ":" 1*(proizvod) proizvod = string ["/" verzija proizvoda] verzija proizvoda = string
Korisnički agent: CERN-LineMode/2.15 libwww/2.17b3
Red koji opisuje naziv proizvoda trebao bi biti kratak i precizan - korištenje ovog naslova za oglašavanje bilo koje druge, irelevantne informacije nije dozvoljeno i smatrat će se neusklađenom s protokolom. Iako bilo koji niz može biti prisutan u polju verzije proizvoda, niz bi se trebao koristiti samo za označavanje verzije proizvoda. Polje User-Agent može uključivati dodatne informacije u komentarima koje nisu dio njegove vrijednosti.
Struktura odgovora
Nakon prijema i tumačenja zahtjeva, server šalje odgovor u skladu sa sljedećim obrascem:
Odgovor = Jednostavan odgovor | Jednostavan odgovor punog odgovora = [Sadržaj odgovora] Puni odgovor = Status linije *(Zajedničko zaglavlje | Zaglavlje odgovora | Zaglavlje sadržaja) CRLF [Sadržaj odgovora]
Jednostavan odgovor treba poslati samo kao odgovor na HTTP/0.9 Simple-Request, ili ako server podržava samo ograničeni HTTP/0.9 protokol. Ako klijent pošalje HTTP/1.0 Full-Request i primi odgovor koji ne počinje statusnom linijom, mora pretpostaviti da je odgovor servera jednostavan odgovor i obraditi ga u skladu s tim. Treba napomenuti da se jednostavan odgovor sastoji samo od traženih informacija (bez zaglavlja) i tok podataka se zaustavlja u trenutku kada server zatvori komunikacijsku sesiju.
Status linije
Prvi red punog zahtjeva je statusni red, koji se sastoji od verzije protokola praćene numeričkim statusnim kodom i pripadajućom tekstualnom rečenicom. Svi elementi Line-Status su razdvojeni razmacima. CR i LF znakovi nisu dozvoljeni, s izuzetkom CRLF sekvence na kraju.
Linija-Status=Verzija-HTTP SP Status-Kod SP Objašnjenje fraze.
Budući da statusna linija uvijek počinje verzijom protokola "HTTP/" 1*DIGIT "." 1*DIGIT (npr. HTTP/1.0), postojanje ovog izraza se smatra osnovnim za određivanje da li je odgovor jednostavan ili potpuni odgovor. Iako format jednostavnog odgovora ne sprječava pojavljivanje takve linije (što bi dovelo do pogrešnog tumačenja poruke odgovora kao punog odgovora), vjerovatnoća takve pojave je blizu nule.
Statusni kod i objašnjenje za njega
Element Status Code je trocifreni cijeli kod koji identificira rezultat pokušaja tumačenja i zadovoljenja zahtjeva. Sljedeća fraza objašnjenja namijenjena je kratkom tekstualnom opisu statusnog koda. Statusni kod je namijenjen da ga koristi mašina, dok je izraz objašnjenja namijenjen osobi. Od klijenta se ne traži da pregleda i prikaže frazu objašnjenja.
Prva cifra statusnog koda je namijenjena da odredi klasu odgovora. Zadnje dvije cifre ne igraju nikakvu kategorizirajuću ulogu. Postoji 5 značenja za prvu cifru:
- 1xx: Informativno - Ne koristi se, ali je rezervirano za buduću upotrebu
- 2xx: Uspjeh - Zahtjev je u potpunosti primljen, shvaćen i prihvaćen za obradu.
- 3xx: Preusmjeravanje - Klijent bi trebao poduzeti daljnje radnje kako bi uspješno dovršio zahtjev. Klijent ponekad može izvršiti potrebnu dodatnu radnju bez interakcije korisnika, ali se snažno preporučuje da se to dogodi samo u slučajevima kada je metoda korištena u zahtjevu indiferentna (GET ili HEAD).
- 4xx: Greška klijenta - Zahtjev koji sadrži nevažeću sintaksu ne može biti uspješno dovršen. 4xx klasa je namijenjena da opiše slučajeve u kojima je napravljena greška na strani klijenta. Ako klijent još nije dovršio zahtjev kada dobije odgovor sa statusnim kodom - 4xx, mora odmah prekinuti prijenos podataka na server. Ova vrsta statusnog koda je primjenjiva za sve metode korištene u zahtjevu.
- 5xx: Greška servera - Server nije mogao dati odgovor na ispravno dostavljen zahtjev. U ovim slučajevima
server ili zna da je napravio grešku ili nije u stanju obraditi zahtjev. Sa izuzetkom odgovora na HEAD zahtjeve, server šalje opis stanja greške i da li je stanje privremeno ili trajno u Response-Content. Ova vrsta statusnog koda je primjenjiva za sve metode korištene u zahtjevu.
Pojedinačna značenja statusnih kodova i odgovarajućih izraza objašnjenja su data u nastavku. Ove izraze za objašnjenje se samo preporučuju – mogu se zamijeniti bilo kojim drugim frazama koje zadržavaju svoje značenje i koje su dozvoljene protokolom.
Status-Code = "200" ; OK | "201" ; Created | "202" ; Prihvaćeno | "203" ; Privremene informacije | "204" ; Nema sadržaja | "300" ; Višestruki izbori | "301" ; Trajno preseljeno | "302" ; Privremeno preseljeno | "303" ; Metoda | "304" ; Nije modificirano | "400" ; Loš zahtjev | "401" ; Neovlašteno | "402" ; Obavezno plaćanje | "403" ; Zabranjeno | "404" ; Nije pronađeno | "405" ; Metoda nije dozvoljena | "406" ; Ništa prihvatljivo | "407" ; Proxy autentikacija je potrebna | "408" ; Request Timeout | "409" ; Konflikt | "410" ; Gone | "500" ; Interna greška servera | "501" ; Nije implementirano | "502" ; Bad Gateway | "503" ; Usluga nedostupna | "504" ; Gateway Timeout | Šifra ekstenzije Šifra proširenja = 3DIGIT Objašnjenje fraze = niz *(SP niz)
HTTP aplikacije nisu obavezne da razumiju sve statusne kodove, iako je takvo razumijevanje očigledno poželjno. Međutim, od aplikacija se traži da budu u stanju prepoznati klase statusnih kodova (identificiranih prvom cifrom) i tretirati sve statusne kodove odgovora kao da su ekvivalentne statusnom kodu x00.
Polja odgovora zaglavlja
Polja zaglavlja odgovora dozvoljavaju serveru da prosledi dodatne informacije o odgovoru koje se ne mogu uključiti u statusnu liniju. Ova polja zaglavlja nisu namijenjena za prenošenje informacija o sadržaju odgovora poslanog kao odgovor na zahtjev, ali mogu sadržavati informacije o samom serveru.
Response-Header= Javno | Ponovni pokušaj nakon | Server | WWW-Autentikacija | extension-header
Iako se dodatna polja zaglavlja odgovora mogu implementirati kroz mehanizam proširenja, aplikacije koje ne prepoznaju ova polja moraju ih tretirati kao polja sadržaja zaglavlja. Potpuni opis ovih polja može se naći u specifikaciji CERN HTTP protokola.
Opći koncepti
Full-Request i Full-Response mogu se koristiti za prenošenje nekih informacija u zasebnim zahtjevima i odgovorima. Ove informacije su sadržaj zahtjeva ili sadržaj odgovora, odnosno zaglavlje sadržaja.
Polja naslov-sadržaj
Polja sadržaja zaglavlja sadrže opcione meta-informacije o sadržaju zahtjeva ili sadržaju odgovora. Ako tijelo odgovarajuće poruke (zahtjev ili odgovor) nije prisutno, onda Content-Header sadrži informacije o traženom resursu.
Neka od polja zaglavlja sadržaja opisana su u nastavku.
Dopustiti
Polje zaglavlja Dozvoli je lista metoda koje podržava resurs identificiran URI-jem zahtjeva. Svrha ovog polja je da tačno informiše primaoca o važećim metodama povezanim sa resursom; ovo polje mora biti prisutno u odgovoru sa statusnim kodom “405 Metoda nije dozvoljena”.
Dozvoli = "Dozvoli" ":" 1#metod
Primjer upotrebe:
Dozvoli: GET, HEAD, PUT
Naravno, klijent može isprobati i druge metode. Međutim, preporučuje se da se pridržavate metoda navedenih u ovom polju. Ovo polje nema zadanu vrijednost; ako se ostavi nedefinisan, skup dozvoljenih metoda određuje server u vreme svakog zahteva.
Content-Length
Polje Content-Length specificira veličinu tijela poruke koju server šalje kao odgovor na zahtjev ili, u slučaju HEAD zahtjeva, veličinu tijela poruke koje će biti poslano kao odgovor na GET zahtjev.
Content-Length = "Content-Length" ":" 1*DIGIT
Na primjer:
Dužina sadržaja: 3495
Iako nije obavezno, aplikacije se snažno ohrabruju da koriste ovo polje za analizu veličine poruke koja se prenosi, bez obzira na vrstu informacija koje sadrži. Za polje Content-Length valjana je svaka vrijednost cijelog broja veća od nule.
Content-Type
Polje zaglavlja Content-Type identifikuje tip informacija u tijelu poruke koje se šalju strani primaocu ili, u slučaju HEAD metode, tip informacije (medija) koji bi se poslao da se koristi GET metoda.
Content-Type = "Content-Type" ":" tip okruženja
Tipovi medija su definisani zasebno.
primjer:
Content-Type: text/html; charset=ISO-8859-4
Polje Content-Type nema zadanu vrijednost.
Zadnja izmjena
Polje zaglavlja sadrži datum i vrijeme kada strana pošiljateljica vjeruje da je resurs posljednji put izmijenjen. Semantika ovog polja definirana je terminima koji opisuju kako bi ga primalac trebao tumačiti: ako primalac ima kopiju resursa koja je starija od datuma koji je prošao u polju Last-Modified, tada se kopija treba smatrati zastarjelom .
Last-Modified = "Last-Modified" ":" HTTP datum
Primjer upotrebe:
Tačno značenje ovog polja zaglavlja ovisi o implementaciji strane pošiljatelja i prirodi samog resursa. Za datoteke, ovo bi jednostavno moglo biti vrijeme posljednje izmjene. Za pristupnike baze podataka, ovo može biti vrijeme kada su podaci u bazi podataka posljednji put ažurirani. U svakom slučaju, primalac treba da brine samo o rezultatu – šta je u datom polju – a ne o tome kako je rezultat dobijen.
Telo poruke
Tijelo poruke se odnosi na sadržaj zahtjeva ili sadržaj odgovora. Tijelo poruke, ako postoji, šalje se u HTTP/1.0 zahtjevu ili odgovoru u formatu i kodiranju specificiranom u poljima sadržaja zaglavlja.
Telo poruke = *OCTET (gdje je OCTET bilo koji 8-bitni znak)
Tijelo poruke je uključeno u zahtjev samo ako metoda zahtjeva podrazumijeva njegovo prisustvo. Za HTTP/1.0 specifikaciju, ove metode su POST i PUT. Općenito, prisustvo tijela poruke je naznačeno prisustvom polja zaglavlja sadržaja kao što su Content-Length i/ili Content-Transfer-Encoding u poslanom zahtjevu.
Za poruke odgovora, prisustvo tijela poruke u odgovoru ovisi o metodi korištenoj u zahtjevu i statusnom kodu. Svi odgovori na HEAD zahtjeve ne smiju sadržavati tijelo poruke, iako prisustvo nekih polja zaglavlja poruke može ukazivati na moguće prisustvo jednog. Shodno tome, odgovori "204 bez sadržaja", "304 nije modificirano" i "406 nije prihvatljivo" također ne bi trebali uključivati tijelo poruke.
Dobro loše
HTTP protokol za prijenos hiperteksta (RFC 1945, 2068) dizajniran je za prijenos hipertekstualnih dokumenata sa servera na klijenta. HTTP protokol je protokol sloja aplikacije. Prema RFC-u, njegov transportni protokol mora biti protokol orijentiran na vezu koji pouzdano prenosi podatke i ne čuva granice između poruka. U praksi, u velikoj većini slučajeva, transportni protokol za HTTP je TCP, pri čemu HTTP server (Web server) čeka na vezu sa strane klijenta, standardno na TCP portu 80, a HTTP klijent (Web pretraživač) pokreće vezu.
U Web terminima, sve čemu korisnik može pristupiti - dokumentima, slikama, programima - naziva se resursima. Svaki resurs ima jedinstvenu adresu za Web, nazvanu univerzalni identifikator resursa (URI - Universal Resource Identifier). U najopćenitijem slučaju, URI izgleda ovako:
protokol://user:password@host:port/path/file?paremeters#fragment
Pojedinačna URI polja imaju sljedeće značenje:
protokol - aplikacijski protokol preko kojeg se pristupa resursu;
korisnik - korisnik u čije ime se pristupa resursu ili sam korisnik kao resursu;
lozinka - korisnička lozinka za autentifikaciju prilikom pristupanja resursu;
host - IP adresa ili naziv servera na kojem se nalazi resurs;
port - broj porta na kojem server radi, pružajući pristup resursu;
path - putanja do datoteke koja sadrži resurs;
datoteka - datoteka koja sadrži resurs;
parametri - parametri za obradu od strane programa resursa;
fragment - tačka u datoteci počevši od koje treba prikazati resurs.
Interakcija između klijenta i web servera se odvija razmjenom poruka. HTTP poruke se dijele na zahtjeve klijenta prema serveru i odgovore servera klijentu.
Poruke zahtjeva i odgovora imaju zajednički format. Obje vrste poruka izgledaju ovako: prvo postoji početna linija, zatim možda jedno ili više polja zaglavlja, koja se nazivaju i zaglavlja, zatim prazan red (tj. red koji se sastoji od znakova CR i LF), koji označava kraj polja zaglavlja, a zatim eventualno tijelo poruke:
startna linija
polje zaglavlja 1
polje zaglavlja 2
polje zaglavlja N
tijelo poruke
Formati početnih linija klijenta i servera se razlikuju i o njima će se govoriti u nastavku. Postoje četiri vrste naslova:
opšta zaglavlja, koja mogu biti prisutna i u zahtjevu i u odgovoru;
zaglavlja zahtjeva, koja mogu biti prisutna samo u zahtjevu;
zaglavlja odgovora, koja mogu biti prisutna samo u odgovoru;
zaglavlja entiteta, koja se odnose na tijelo poruke i opisuju njen sadržaj.
Svako zaglavlje se sastoji od naslova, znaka dvotočka ":" i vrijednosti. Najvažniji naslovi prikazani su u tabeli. 1.
|
Tabela 1 |
|
|
Zaglavlja HTTP protokola |
|
|
Naslov |
Svrha |
|
Zaglavlja objekata |
|
|
Navodi metode koje podržava server |
|
|
Content-Encoding |
Način na koji je tijelo poruke kodirano, na primjer za smanjenje veličine |
|
Dužina poruke u bajtovima |
|
|
Vrsta sadržaja i eventualno neki parametri |
|
|
Jedinstvena oznaka resursa na serveru koja vam omogućava da uporedite resurse |
|
|
Datum i vrijeme kada će se resurs na serveru promijeniti i treba ga ponovo preuzeti |
|
|
Datum i vrijeme posljednje izmjene sadržaja |
|
|
Zaglavlja odgovora |
|
|
Broj sekundi nakon kojih se zahtjev mora ponoviti da bi se dobio novi sadržaj |
|
|
URI resursa za pristup za dobivanje sadržaja |
|
|
Datum i vrijeme ili broj sekundi nakon kojih se zahtjev mora ponoviti da bi se dobio uspješan odgovor |
|
|
Naziv serverskog softvera koji je poslao odgovor |
|
|
Zaglavlja zahtjeva |
|
|
Vrste sadržaja koje klijent "razumije" i može reproducirati |
|
|
Kodiranja znakova u kojima klijent može prihvatiti tekstualni sadržaj |
|
|
Način na koji server može kodirati poruku |
|
|
Host i broj porta sa kojeg se traži dokument |
|
|
If-Modified-Since Ako-Neizmijenjeno-Od |
Zaglavlja zahtjeva za uvjetni pristup resursima |
|
Zatražite dio dokumenta |
|
|
Naziv klijentskog softvera |
|
|
General Headings |
|
|
Označava server da zatvori ili zadrži sesiju |
|
|
Datum i vrijeme kada je poruka generirana |
|
Detaljan opis HTTP/1.0 zaglavlja može se naći u RFC 2068.
Tijelo poruke sadrži stvarne informacije koje se prenose – korisni teret poruke. Tijelo poruke je niz okteta (bajtova). Tijelo poruke može se kodirati, na primjer, kako bi se smanjila količina prenesenih informacija, a način kodiranja je naznačen u zaglavlju objekta Content-Encoding.
Poruka zahtjeva od klijenta do servera sastoji se od linije zahtjeva, zaglavlja (općenito, zahtjevi, objekt) i moguće tijela poruke. Redak zahtjeva počinje metodom, praćen identifikatorom traženog resursa, verzijom protokola i krajnjim znakovima na kraju reda:
<Метод> <Идентификатор> <Версия HTTP>
Metoda specificira naredbu HTTP protokola za primjenu na traženi resurs. Na primjer, GET metoda ukazuje da klijent želi dohvatiti sadržaj resursa. Identifikator identifikuje resurs koji se traži. HTTP verzija je označena linijom poput ove:
HTTP/<версия>.<подверсия>
RFC 2068 uvodi HTTP/1.1 protokol.
Pogledajmo glavne metode HTTP protokola.
Metoda OPTIONS zahtijeva informacije o opcijama povezivanja (npr. metode, tipovi dokumenata, kodiranja) koje poslužitelj podržava za traženi resurs. Ova metoda omogućava klijentu da specificira opcije i/ili zahtjeve povezane sa resursom ili mogućnostima servera bez izvođenja bilo kakvih radnji na resursu ili izazivanja njegovog učitavanja.
Ako odgovor servera nije poruka o grešci, tada zaglavlja objekta sadrže informacije koje se mogu smatrati opcijama povezivanja. Na primjer, zaglavlje Dozvoli navodi sve metode koje podržava server za dati resurs.
Ako je traženi identifikator resursa zvjezdica (“*”), tada je OPTIONS zahtjev namijenjen adresiranju poslužitelja u cjelini.
Ako traženi ID resursa nije zvjezdica, tada se zahtjev OPTIONS primjenjuje na opcije koje su dostupne prilikom povezivanja na navedeni resurs.
Metoda GET vam omogućava da dobijete bilo koju informaciju u vezi sa traženim resursom. U većini slučajeva, ako traženi ID resursa ukazuje na dokument (npr. HTML dokument, tekstualni dokument, grafika, video), server vraća sadržaj tog dokumenta (sadržaj datoteke). Ako je traženi resurs aplikacija (program) koja generiše neke podatke tokom svog rada, onda se ti podaci vraćaju u tijelu odgovorne poruke, a ne binarna slika izvršne datoteke. Ovo se koristi, na primjer, prilikom kreiranja CGI aplikacija. Ako identifikator traženog resursa ukazuje na direktorij (direktorij, mapu), tada, ovisno o postavkama servera, ili sadržaj direktorija (lista datoteka) ili sadržaj jedne od datoteka koja se nalazi u ovom direktoriju (obično index.html ili Default.htm). Kada se od vas zatraži ime fascikle, može, ali ne mora biti označeno sa "/" na kraju. Ako ovaj znak nije prisutan na kraju identifikatora resursa, server izdaje jedan od odgovora za preusmjeravanje (sa statusnim kodovima 301 ili 302).
Jedna varijacija GET metode je "uvjetni GET", u kojem poruka zahtjeva uključuje zaglavlja zahtjeva ako-promijenjeno-od, ako-nepromijenjeno-od, ako-podudaranje, ako-nepodudaranje ili ako-raspon. Uslovna metoda GET zahtijeva prijenos objekta samo ako zadovoljava uvjete opisane u datim zaglavljima. Na primjer, ako je zaglavlje If-Modified-Since prisutno, sadržaj traženog resursa će se dohvatiti samo ako se nije promijenio od trenutka u vremenu navedenom kao vrijednost ovog zaglavlja. Uslovna GET metoda je namijenjena da smanji nepotrebno opterećenje mreže, jer izbjegava ponovno učitavanje podataka koje je klijent već spremio.
Postoji i "djelimični GET" u kojem poruka zahtjeva uključuje zaglavlje zahtjeva za opseg. Djelomični GET zahtijeva da se prenese samo dio objekta. Djelomična GET metoda je dizajnirana da smanji nepotrebno opterećenje mreže zahtijevajući samo dio objekta kada je drugi dio već preuzeo klijent. Vrijednost zaglavlja Range je niz "bytes=" iza kojeg slijedi raspon bajtova koji treba preuzeti. Bajtovi se numerišu počevši od 0. Početni i završni bajtovi opsega su razdvojeni znakom “–”. I početni i završni bajt u rasponu mogu nedostajati. Ako trebate dobiti nekoliko raspona, oni su navedeni odvojeni zarezima. Ako se neki od navedenih raspona ukrste, server ih spaja. Poruka odgovora za djelomični GET zahtjev mora sadržavati zaglavlje Content-Range koje specificira raspon koji treba proslijediti. Ako server šalje više raspona koji se ne preklapaju, zaglavlje Content-Type uzima posebnu vrijednost "multypart/byteranges". Tijelo poruke je podijeljeno na dijelove odvojene separatorom koji je generirao server i prosljeđuje se kao parametar zaglavlja tipa sadržaja. Svaki pojedinačni dio sadrži vlastita zaglavlja Content-Type i Content-Range, s praznim redom ispred sadržaja raspona.
HEAD metoda je identična GET, osim što server ne vraća tijelo poruke u odgovoru. Informacije sadržane u HTTP zaglavljima odgovora na HEAD zahtjev identične su informacijama koje su date kao odgovor na GET zahtjev za isti resurs. Ova metoda se može koristiti za dobivanje informacija o objektu zahtjeva bez direktnog prosljeđivanja tijela objekta. HEAD metoda se može koristiti za testiranje hipertekstualnih veza.
POST metoda se koristi za zahtjev u kojem adresirani server prihvata podatke uključene u tijelo poruke zahtjeva (objekt) i šalje ih aplikaciji koja je navedena kao traženi resurs na obradu. POST je dizajniran za implementaciju sljedećih funkcija na opći način:
bilješke o postojećim resursima;
postavljanje poruke na sistem oglasne ploče (BBS), novinske grupe, mailing liste ili slične grupe članaka;
prijenos bloka podataka, na primjer rezultata unosa u formu, u proces obrade;
izvršavanje upita prema bazama podataka (DB);
Zapravo, funkcija koju izvodi POST metoda je određena aplikacijom na koju ukazuje traženi ID resursa. Uz GET metodu, POST metoda se koristi prilikom kreiranja CGI aplikacija. Pregledač može izdati zahtjeve POST metodom prilikom slanja obrazaca. Da biste to učinili, element FORM HTML dokumenta koji sadrži obrazac mora imati atribut metode s vrijednošću POST.
Aplikacija koju je pokrenuo POST može izvršiti radnju na serveru i kao rezultat toga neće vratiti nikakav sadržaj. U zavisnosti od toga da li odgovor uključuje tijelo poruke koje opisuje rezultat ili ne, statusni kod u odgovoru može biti ili 200 (OK) ili 204 (Nema sadržaja).
Ako je resurs na poslužitelju kreiran, odgovor sadrži statusni kod 201 (Kreirano) i uključuje zaglavlje odgovora Lokacija.
Tijelo poruke koja se šalje u PUT zahtjevu je pohranjena na serveru, a identifikator traženog resursa će biti identifikator pohranjenog dokumenta. Ako traženi identifikator resursa ukazuje na već postojeći resurs, tada se objekt uključen u tijelo poruke tretira kao modificirana verzija resursa koji se nalazi na poslužitelju. Ako je kreiran novi resurs, server obavještava korisničkog agenta odgovarajućim statusnim kodom 201 (Kreirano).
Razlika između POST i PUT metoda je različita vrijednost ID-a traženog resursa. URI u POST zahtjevu identificira resurs koji obrađuje objekt uključen u tijelo poruke. Ovaj resurs može biti aplikacija koja prima podatke. Nasuprot tome, URI u PUT zahtjevu identifikuje entitet uključen u zahtjev kao tijelo poruke, to jest, korisnički agent dodjeljuje dati URI uključenom resursu.
Metoda DELETE zahtijeva od servera da izbriše resurs koji ima traženi ID. Zahtjev s ovom metodom server može odbiti ako korisnik nema prava da izbriše traženi resurs.
Metoda TRACE se koristi za vraćanje poslanog zahtjeva na razini HTTP protokola. Primalac zahtjeva (web server) šalje primljenu poruku nazad klijentu kao tijelo odgovorne poruke sa statusnim kodom 200 (OK). TRACE zahtjev ne smije sadržavati tijelo poruke.
TRACE omogućava klijentu da vidi šta server prima na drugom kraju i koristi ove podatke za testiranje ili dijagnostiku.
Ako je zahtjev uspješan, odgovor sadrži cijelu poruku zahtjeva u tijelu poruke odgovora, a zaglavlje objekta Content-Type je "message/http".
Detaljne informacije o metodama HTTP/1.1 protokola mogu se naći u RFC 2068.
Nakon što primi i protumači poruku zahtjeva, server odgovara porukom HTTP odgovora.
Prva linija odgovora je Statusna linija. Sastoji se od verzije protokola, numeričkog statusnog koda, izraza za objašnjenje, odvojenih razmacima i znakova na kraju reda:
<Версия HTTP> <Код состояния> <Поясняющая фраза>
Verzija protokola ima isto značenje kao u zahtjevu.
Element Status-Code je cjelobrojni trocifreni (trocifreni) kod za rezultat razumijevanja i zadovoljavanja zahtjeva. Fraza razloga je kratak tekstualni opis statusnog koda. Statusni kod je namijenjen za obradu od strane softvera, a izraz objašnjenja namijenjen je korisnicima.
Prva cifra statusnog koda određuje klasu odgovora. Posljednje dvije cifre nemaju posebnu ulogu u klasifikaciji. Postoji 5 značenja za prvu cifru:
1xx: Informacijski kodovi – zahtjev primljen, obrada se nastavlja.
2xx: Uspješni kodovi - akcija je uspješno primljena, shvaćena i obrađena.
3xx: Kodovi za preusmjeravanje - moraju se poduzeti daljnje radnje da se zahtjev završi.
4xx: Kodovi grešaka klijenta - zahtjev ima sintaksičku grešku ili se ne može dovršiti.
5xx: Serverski kodovi grešaka - Server nije u mogućnosti da dovrši važeći zahtjev.
Fraze objašnjenja za svaki statusni kod su navedene u RFC 2068 i preporučuju se, ali se mogu zamijeniti ekvivalentnim bez ograničenja protokola. Na primjer, u lokaliziranim verzijama HTTP servera na ruskom jeziku, ove fraze su zamijenjene ruskim. U tabeli 2 prikazuje kodove odgovora HTTP servera.
|
tabela 2 |
||
|
HTTP serverski kodovi odgovora |
||
|
Objašnjavajuća fraza prema | ||
|
1xx: Informacijski kodovi |
||
|
Nastavi |
||
|
2xx: uspješni kodovi |
||
|
Nema sadržaja |
||
|
Resetujte sadržaj |
||
|
Djelomični sadržaj |
Djelomičan sadržaj |
|
|
3xx: Kodovi za preusmjeravanje |
||
|
Premješteno privremeno |
Privremeno preseljena |
|
|
Nije izmijenjeno |
||
|
4xx: Klijentovi kodovi grešaka |
||
|
Loš zahtjev |
||
|
Neovlašteno |
||
|
Nije pronađeno |
||
|
Metoda nije dozvoljena |
Metoda nije dozvoljena |
|
|
Request Timeout |
Zahtjev je istekao |
|
|
Sukob |
||
|
Obavezna dužina |
Potrebna dužina |
|
|
Entitet zahtjeva je prevelik |
Objekt zahtjeva je prevelik |
|
|
Kraj stola. 2 |
||
|
Objašnjavajuća fraza prema |
Ekvivalentni izraz za objašnjenje na ruskom |
|
|
5xx: Serverski kodovi grešaka |
||
|
Interna greška servera |
Interna greška servera |
|
|
Nije implementirano |
Nije implementirano |
|
|
usluga nedostupna |
Usluga je nedostupna |
|
|
HTTP verzija nije podržana |
Nije podržana HTTP verzija |
|
Detaljne informacije o kodovima odgovora i zaglavljima koji prate ove odgovore mogu se naći u RFC 2068.
Statusnu liniju prate zaglavlja (općenito, odgovor i objekt) i eventualno tijelo poruke.
Jedna od najvažnijih funkcija Web servera je da obezbedi pristup delu lokalnog sistema datoteka. Da biste to učinili, u postavkama servera je naveden određeni direktorij, koji je osnovni direktorij za ovaj web server. Da biste objavili dokument, odnosno da biste ga učinili dostupnim korisnicima koji “posjećuju” ovaj server (povezujući se na njega preko HTTP-a), potrebno je da kopirate ovaj dokument u korijenski direktorij web servera ili u jedan od njegovih poddirektorija. Prilikom povezivanja putem HTTP-a na serveru se kreira proces s korisničkim pravima, koji u pravilu ne postoji, već je posebno kreiran za pregled resursa servera. Konfigurisanjem prava i dozvola datog korisnika, možete kontrolisati pristup Web resursima.
Pozdrav, dragi čitaoci blog stranice. Prilikom proučavanja mehanizma odgovornog za ispravno funkcioniranje Interneta, nema bijega od potrebe da se vrijeme posveti njegovim glavnim aspektima, koji, bez sumnje, uključuju HTTP protokol za prijenos podataka i njegovu sigurnu verziju HTTPS.
Osnova za rad ovog alata, koji korisnikovom pretraživaču omogućava otvaranje potrebnih datoteka i dokumenata za dobivanje informacija, je tehnologija „klijent-server“, o čijim će detaljima biti riječi u ovom članku u nastavku.
Naravno, oni koji žele da se istinski posvete radu sa računarskim mrežama i razvoju mrežnih programa treba da maksimalno prouče ovo pitanje kako bi stekli odgovarajuće kvalifikacije. Ali ovo nam ne treba.
Glavna stvar je razumjeti šta je HTTP općenito i koje su glavne karakteristike HTTPS-a, kao i razumjeti osnovne principe koji su ugrađeni u njih. Takvo znanje će biti korisno, između ostalog, za optimizaciju i promociju vaše web stranice, o tome ćete dobiti bezuvjetnu potvrdu iz ovog i sljedećih članaka na ovu temu.
Šta je HTTP i kako funkcioniše?
Da bi dobio željeni dokument na Internetu, korisnik samo treba da unese željeni URL u traku za pretragu pretraživača (više o URL strukturi), koja samo sadrži naziv HTTP (ili HTTPS) protokola.
3. HTTP/Verzija— prikazana je trenutna modifikacija protokola. Trenutno je HTTP 1.1 (možete pročitati njegovu specifikaciju). Međutim, sljedeća verzija protokola 2.0 već postoji u obliku nacrta, koji je zasnovan na .
Donja linija predstavlja Host header kao dio HTTP zahtjeva koji pretraživač šalje serveru u skladu sa IP-om primljenim od DNS-a. čemu ovo služi? Za identifikaciju željene stranice, budući da web serveri obično hostuju više od jednog resursa.
Pogledajmo jasan primjer kako bismo učvrstili ono što smo naučili. Recimo da je pretraživač dobio “zadatak” od korisnika da prikaže stranicu sa sljedećom adresom:
Http://subscribe.ru/group/
Zatim se HTTP zahtjev pomoću metode GET može sastaviti na sljedeći način (u ovom slučaju obično nema tijela poruke):
GET /group/ HTTP/1.1 Host: subscribe.ru
Radi jasnoće, dao sam samo vrlo jednostavan primjer, uključujući jedno zaglavlje Host-a; u stvari, može ih biti nekoliko. Ali to nije sve. Na kraju krajeva, potpuna komunikacija zahtijeva dijalog, koji se uspostavlja nakon što server odgovori na zahtjev pretraživača. Početna linija odgovora se također može prikazati shematski:
HTTP/verzija status koda objašnjenje
Pogledajmo sada ukratko sastav odgovora servera:
1. HTTP verzija naznačeno po analogiji sa zahtjevom.
2. Statusni kod(Status Code) - tri broja koja obavještavaju o statusu dokumenta koji traži pretraživač. Na primjer, 200 - OK, stranica postoji i biće prikazana u pretraživaču, 301 - izvršeno je preusmjeravanje na drugi URL, - nema web stranice na toj adresi (možda je obrisana ili je korisnik napravio grešku kada je unos URL-a).
3. Objašnjenje(Reason Phrase) - tekst dodatka kodu odgovora. U nekim slučajevima, objašnjenje se može razlikovati od standarda ili u potpunosti izostati. To je također zbog konfiguracije softvera koji se nalazi na serveru.
Pravi primjer? Molim te. Pokušajmo dobiti odgovor servera na zahtjev koji sam dao kao primjer iznad (url “http://subscribe.ru/group/”). To će izgledati ovako (početni red zaglavlja):
HTTP/1.1 200 OK Server: nginx Datum: Sub, 10 Jun 2017 06:36:38 GMT Tip sadržaja: text/html; charset=utf-8 Veza: Keep-alive Content-Language: ru Set-Cookie: Pretplatite se::Viziter=UQkivlk7k3YO3DgjAxM2Ag==; expires=Čet, 31-Dec-37 23:55:55 GMT; domain=subscribe.ru; path=/ P3P: policyref="/w3c/p3p.xml", CP="NOI PSA NAŠA BUS UNI"
U ovom slučaju ne postoji objašnjenje i tijelo poruke koje, kada se koristi GET metod, može sadržavati, na primjer, HTML kod traženog dokumenta (web stranice). Ovisno o vrsti klijentske aplikacije, ovi odjeljci mogu biti prisutni.
Dakle, hajde da ukratko sumiramo gore navedeno. Ukoliko korisnik unese URL stranice koju traži, s namjerom da preuzme njen sadržaj za pregled, pretraživač šalje GET zahtjev željenom serveru i dobija odgovor. Kao rezultat ove komunikacije, ili će (pod povoljnim okolnostima) sadržaj traženog dokumenta biti prikazan, ili neće.
U svakom slučaju, sadržaj HTTP odgovora servera (uključujući statusni kod) može pružiti korisne informacije vezane za traženi dokument.
Da bi se gornje informacije bez napora uklopile u slagalicu, nedostaje konkretan primjer. Pogledaćemo to koristeći jedan od (ovaj web pretraživač je moj radni alat) koji se zove HTTP zaglavlja.
Pogodan je jer daje potpunu sliku interakcije klijent-server, pružajući sadržaj u „jednoj boci“ HTTP zahtjev (zahtjev) i odgovor (odgovor). Pogledajte dokument koji je ovaj dodatak napravio kada slijedite vezu s jedne stranice mog bloga na drugu:
Ovdje se na samom vrhu nalazi metoda GET, pomoću koje pretraživač pristupa serveru, kao i status stranice, označen statusnim kodom 200 OK, čime je jasno da je server prenio sve podatke u vezi sa traženim web stranicu.
Također od interesa HTTP zaglavlja, prikazan ispod. Na primjer, stavka "Preporučilac" pruža informacije u obliku URL-a sa kojeg je izvršen prijelaz.
Naslov "korisnički agent" odražava upravo klijentsku aplikaciju koja je poslala zahtjev web serveru. U ovom slučaju, ovo je pretraživač, ali mogu postojati i drugi (mobilni uređaji, roboti za pretraživanje, itd.). Podaci predstavljeni u korisničkom agentu neophodni su da serverski softver identifikuje aplikaciju koja šalje zahtev.
Samo botovi pretraživača, koji skeniraju stranice web stranice kako bi dobili informacije koje utiču na rangiranje, za nas su od primarnog interesa, jer upravo oni odlučuju o sudbini određene stranice u smislu efikasnosti njene promocije.
Zato se u sljedećoj publikaciji planiram detaljnije zadržati na tome kako pregledati HTTP zaglavlja i provjeriti kodove odgovora servera posebno za zahtjev robota, što je izuzetno važno za webmastere u svjetlu optimizacije SEO resursa. Stoga se pretplatite da biste pravovremeno primali najnoviji članak.
Šta je posebno u vezi sa sigurnim HTTPS protokolom?
Siguran sam da su svi korisnici interneta, bez izuzetka, uključujući i početnike, upoznati sa postojanjem posebnog protokola pod nazivom HTTPS (Hypertext Transfer Protocol Secure), koji služi za zaštitu ličnih podataka na servisima na kojima se koristi njihov prijenos (sistemi plaćanja, online trgovine, veliki specijalizovani portali, itd.) d.).
Ako unesete adresu stranice slične stranice, ova veza će biti naznačena na poseban način. U Google Chrome-u (), na primjer, prikazat će se katanac sa natpisom "Pouzdano" u zelenoj boji, kada kliknete na njega vidjet ćete neke informacije vezane za zaštitu ličnih podataka:
Šta je HTTPS? Strogo govoreći, to nije nezavisan protokol. Ovo je standardni HTTP, koji radi putem mehanizama TLS ili SSL, sposoban da garantuje enkripciju, što sprečava hakere da presretnu i dobiju poverljive podatke.
Podrazumevano, kada se radi sa sigurnim protokolom, koristi se port 443 (ako se sećate, za standardni HTTP je 80). HTTPS enkripcija koristi dužine ključeva od 40, 56, 128 i 256 bita (). Međutim, prve dvije opcije ne treba ni razmatrati, jer ne mogu pružiti dovoljan nivo sigurnosti.
U posljednje vrijeme pretraživači, posebno Google, aktivno uvjeravaju vlasnike svih stranica da pređu na siguran protokol, suptilno nagovještavajući da će se ova točka uzeti u obzir prilikom rangiranja. Kao rezultat toga, sada mnogi resursi (čak i obični blogovi), a ne samo stranice koje su usko povezane s prijenosom ličnih podataka, već rade s HTTPS-om.
Osim toga, vodeći hosteri nude kupovinu sigurnog SSL certifikata, koji je neophodan za omogućavanje sigurne veze.
Naravno, nismo uzeli u obzir sve nijanse korištenja HTTP (HTTPS) protokola, kojih ima mnogo. Ova tema bi mogla zauzeti nekoliko impresivnih priručnika. Međutim, obrađeni su glavni aspekti koji će biti korisni i naprednom korisniku i webmasteru. Ako i dalje niste zadovoljni količinom primljenih informacija, lako ih možete dopuniti iz sljedećeg video predavanja, u kojem se, posebno, detaljnije govori o metodama:
HTTP protokol ili HyperText Transfer Protocol je glavni protokol (World Wide Web). Glavni zadatak protokola je osigurati prijenos hiperteksta preko mreže. Protokol precizno opisuje format poruke za razmjenu klijenata i servera.
HTTP protokol je opisan u RFC 2616(HTTP1.1).
Osnova protokola je da osigura interakciju između klijenta i servera koristeći jedan ASCII zahtjev i sljedeći odgovor na njega u RFC 822 MIME standardu.
U praksi, HTTP protokol radi na portu 80, ali se može drugačije konfigurirati. I iako TCP/IP nije obavezan, on ostaje poželjniji, jer se brine o razdvajanju i sklapanju poruka i ne “napreže” ni pretraživač ni server.
Treba napomenuti da se HTTP protokol može koristiti ne samo u web tehnologijama, već iu drugim OOP aplikacijama (objektivno orijentisanim).
URL
Osnova klijent-server web komunikacije je zahtjev. Zahtjev se šalje korištenjem URL-a—Uniform Internet Resource Locator. Dozvolite mi da vas podsjetim šta je URL.
Jasna i jednostavna URL struktura sastoji se od sljedećih elemenata:
- Protokol;
- Host;
- Luka;
- Resource directory;
- Oznake (Upit).
Napomena: http protokol je protokol za jednostavne, nesigurne veze. Sigurne veze rade koristeći https protokol. Sigurniji je za razmjenu podataka.
Metode HTTP zahtjeva
Jedan od parametara URL-a specificira ime hosta s kojim želimo komunicirati. Ali ovo nije dovoljno. Morate odrediti radnju koju ćete poduzeti. Ovo se može učiniti pomoću metode definirane HTTP protokolom.
HTTP metode
- Metoda/Opis
- GLAVA/Pročitajte naslov web stranice
- GET/Pročitajte web stranicu
- POST/Dodaj na web stranicu
- PUT/Save web stranicu
- TRACE/Pošalji zahtjev za povrat
- DELETE/Brisanje web stranice
- OPCIJE/Opcije prikaza
- CONNECT/Rezervirano za buduću upotrebu
Pogledajmo detaljnije HTTP metode
GET metoda. zahtijeva stranicu (fajl, objekt) kodiranu korištenjem MIME standarda. Ovo je najčešće korištena metoda. Struktura metode:
GET naziv datoteke HTTP/1.1
HEAD metoda. Ovaj metod zahtijeva zaglavlje poruke. Međutim, stranica se ne učitava. Ova metoda vam omogućava da saznate kada je stranica zadnji put osvježena, što je neophodno za upravljanje kešom stranice. Ova metoda vam omogućava da provjerite funkcionalnost traženog URL-a.
PUT metoda. Ova metoda može staviti stranicu na server. Tijelo PUT zahtjeva uključuje stranicu koja će biti hostovana, a koja je MIME kodirana. Ova metoda zahtijeva identifikaciju klijenta.
POST metoda. Ova metoda dodaje sadržaj postojećoj stranici. Koristi se kao primjer za dodavanje posta na forum.
DELETE metoda. Ova metoda uništava stranicu. Metoda brisanja zahtijeva potvrdu prava korisnika na brisanje.
TRACE metoda. Ovo je metoda otklanjanja grešaka. On daje instrukcije serveru da pošalje zahtjev nazad i omogućava mu da zna da li je zahtjev klijenta oštećen ili ne kada se vraća sa servera.
CONNECT metoda– rezervni metod, ne koristi se.
OPTIONS metoda omogućava vam da ispitujete svojstva servera i svojstva bilo koje datoteke.
U komunikaciji zahtjev-odgovor između klijenta i servera, server nužno generiše odgovor. Ovo može biti web stranica ili statusna traka sa statusnim kodom. Dobro znate statusni kod. Jedan od kodova je dobro poznati kod 404 – Stranica nije pronađena.
Grupe statusnih kodova
1hh: Spremnost servera, kod 100 – server je spreman za obradu zahtjeva klijenata;
2xx: Uspjeh.
- Šifra 200 – zahtjev je uspješno obrađen;
- Kod 204 – Nema sadržaja.
3xx: Preusmjeravanje.
- Kod 301 – Tražena stranica je premještena;
- Kod 304 – Stranica u kešu je i dalje relevantna.
4xx: Greška klijenta.
