URL ja päringu parameetrid. Postitamine – millist meetodit kasutatakse http-päringu edastamiseks vormis ja ilma vormita? Kuidas teha http taotlusi

HTTP (Hyper Text Transport Protocol) on keel, milles brauserid "vestlevad" veebiserveritega, mis on kõige olulisem Interneti-protokoll...

Taotluste tüübid

Taotlused saab jagada kahte tüüpi:

SAADA;
POSTITA.

SAADA kasutatakse saidi aadressi sisestamisel brauseri real või järgige linki. POSTITA teenindab vormide esitamiseks, näiteks veebisaidil registreerumisel või artikli kommentaari avaldamisel. Vormi esitamiseks peate tavaliselt klõpsama nuppu "Esita" või midagi sarnast:

Sest lihtsus mõistmine erinevust saab esitada järgmiselt:

SAADA kasutatud lugemiseks veebisaidid (loeme Internetist);
POSTITA teenindab avaldamiseks teave veebisaitidel (kirjutame Internetti)

URL ja päringu parameetrid

Mõlemal juhul on see nõutav URL(Uniform Resource Locator) taotletud dokumendist.

URL - see on aadress lehekülgi Internetis. Reeglina näeb see välja selline:
http://<хост>/<путь>
Näiteks:
http://www.example.ru/about.php
Või see, kui peate skriptile parameetrid edastama:
http://<хост>/<путь>?<параметры>
Kus<параметры>on vormipaaride komplekt:
<имя>=<значение>
sümboliga eraldatud & .
Näide:
http://www.example.ru/news.php?id=100&show_comments=yes

Võite kogeda küsimus: Mille eestülekandmine skripti parameetrid? Dünaamiline lehel(aka script), erinevalt staatilisest, suudab toota mitmesugust teavet. Näiteks kuvab uudistevoo skript kas viimaste uudiste teadaannete loendi või konkreetse artikli kogu teksti. Skript saab talle edastatud parameetrite põhjal aru, mida kasutaja täpselt näha soovib.

See võiks toimida nii. Viimaste uudiste loendi hankimine: http://www.example.ru/news.php(URL ilma parameetriteta). Kviitung täistekst uudiste artikkel: http://www.example.ru/news.php ?id=1 (URL sisaldab parameetrina uudise numbrit).

URL-i parameetrite käsitlemine

Ja nüüd kirjutame selle uudisvoo jaoks stsenaariumi. Ta saab kaks režiimi:

Meil on kokku kolm uudist:

“Nad on hakanud kontrollima toiduaineid uuel viisil”;
"Varssavi ei avalda Minski-vastaste võimalike meetmete loetelu";
"Pavel Astahhov kavatseb taotleda paljude Udmurtia ametnike tagasiastumist"

TÄHELEPANU! Näide on lihtsustatud. Keegi ei salvesta uudiseid kunagi skriptikoodi. Selline teave tuleks salvestada andmebaasi. Aga see on hoopis teise õppetunni teema!

Nüüd on meil oluline õppida, kuidas töödelda URL-i kaudu edastatud parameetreid. Niisiis, luua fail news.php:

"; kaja" "; kaja" Viimased uudised"; kaja""; kaja" "; kaja"

"; kaja ""; kaja $uudised[$i]; kaja ""; kaja "

"; kaja""; kaja""; ) // Funktsioon konkreetse uudise kuvamiseks. funktsioon show_item($news, $id) ( echo " "; kaja" "; kaja" Uudised #$id"; kaja""; kaja" "; echo "Tagasi uudiste loendisse"; kaja "

"; kaja $uudis[$id - 1]; kaja "

"; kaja"

"; kaja "Kujutage ette, et seal on palju teksti ja pilte :)"; kaja "

"; kaja""; kaja""; ) ) // Sisenemispunkt. // Looge uudiste massiiv. $news = array(); $news = "Nad vastavad kvaliteedi eest. Nad hakkasid toidukaupu uuel viisil kontrollima."; $news = "Varssavi ei avalda Minski-vastaste võimalike meetmete nimekirja"; $news = "Pavel Astahhov kavatseb taotleda mitme Udmurtia ametniku tagasiastumist"; / / Kas uudise ID edastati parameetrina if (isset($_GET["id"])) ( show_item($news, $_GET["id"]); ) else ( show_list($news); ) ?>

Nüüd vaatame seda üksikasjalikult, mida me kirjutasime?

Kõigepealt anname teada kaks funktsiooni kes teeb HTML-i genereerida. Esimene kuvab uudiste loendi, teine - konkreetse uudise tekst. Juhtimine antakse neile funktsioonidele üle ainult siis, kui me neile helistame. Tuleme nende juurde hiljem tagasi.

Täitmine skript algab kohast, kus kommentaar on märgitud sisenemispunkt. Loome massiivi, mis koosneb kolmest uudisest. Tuletame teile seda meelde massiivi elementide nummerdamine algab nullist!

Edasi kontrollimine, oli seal läbis id uudised parameetrina. URL-i kaudu edastatud parameetrid salvestatakse süsteemimuutujas $_GET. See on assotsiatiivne massiiv (või teisisõnu sõnaraamat).

Tuletame meelde, et assotsiatiivne massiiv (või sõnastik) on andmestruktuur, mis sisaldab võtme-väärtuste paare.

Sõnastiku võtmed $_GET on parameetrite nimed. Funktsioon isset() tagastab tõeseks, kui muutuja määratletud. Seega
if (isset($_GET["id"]))
peaks lugema: "kui päringu URL sisaldab id parameetrit".

Nüüd pöördume tagasi funktsioonide juurde. Siin on kõik lihtne, kuid juhime tähelepanu kahele punktile.

Esiteks , ei pruugi olla täiesti selge, miks me lisame $iühest ja teisest lahutame. Seda tehakse selleks, et kasutaja nägi URL-i esimene uudis on: "news.php?id=1", mitte "news.php?id=0". See on hea vorm ja ei midagi enamat.

Teiseks , pöörake tähelepanu reale:
kaja "Uudised #$id";
Kahekordne tsitaadid erinevad alates vallaline sest kui nende sees on nimed muutujad(märgiga $ ), siis need asendatakse väärtusi need samad muutujad. Rida sisse vallaline jutumärkides jääb samaks ilma asendamiseta muutuvad väärtused.

Järgmises õppetükis vaatame, kuidas sisu saata Kasutaja poolt täidetud HTML-vorm ja protsessi tema.

Oleme otsustanud, et brauser (klient) saadab serverile HTTP päringuid ja server saadab kliendile HTTP vastused. Need päringud ja vastused vormistatakse teatud reeglite järgi. Seal on midagi süntaksi taolist, kuidas ja mis järjekorras seda kirjutada. Peab olema rangelt määratletud struktuur.

Vaatame lähemalt seda struktuuri, mille abil HTTP-protokolli päringuid ja vastuseid ehitatakse.

HTTP-päring koosneb kolmest põhiosast, mis kuvatakse allpool loetletud järjekorras. Päiste ja kirja sisu vahel on tühi rida (eraldajana), see tähistab reavahetuse märki.

1. Taotlusliin

2. Sõnumi päised

Tühi string (eraldaja)

3. sõnumi sisu (Entity Body) – valikuline parameeter

Päringu string– määrab edastusmeetodi, ligipääsetava URL-i ja HTTP-protokolli versiooni.

Pealkirjad– kirjeldada sõnumite sisu, edastada erinevaid parameetreid ja muud teavet ja teavet.

sõnumi sisu- need on andmed ise, mis päringus edastatakse. Sõnumi sisu on valikuline parameeter ja see võib puududa.

Kui saame serverilt vastusepäringu, on sõnumi sisu enamasti veebilehe sisu. Kuid serverisse päringuid tehes võib see mõnikord ka esineda, näiteks kui edastame tagasisideankeedis täidetud andmed serverisse.

Vaatleme iga taotluse elementi üksikasjalikumalt järgmistes märkustes.

Võtame näiteks ühe tõelise palve serverile. Olen iga päringu osa esile tõstnud erineva värviga: päringu rida on roheline, päised on oranžid ja sõnumi sisu on sinine.

Brauseri taotlus:

GET / HTTP/1.1

Host: veebisait

Kasutajaagent: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0

Nõustu: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Aktsepteeri keel: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3

Aktsepteeri kodeering: gzip, tühjenda

Küpsis: wp-sätted

Ühendus: hoia elus

Järgmises näites on sõnumi keha juba olemas.

Serveri vastus:

HTTP/1.1 200 OK

Sisutüüp: tekst/html; charset=UTF-8

Edastus-kodeering: tükeldatud

Ühendus: hoia elus

Elus hoidmine: ajalõpp = 5

Server: Apache

X-Pingback: //site/xmlrpc.php

Pealkirjata dokument

Need on sõnumid, mida vahetatakse kliendi ja serveri vahel HTTP-protokolli kaudu.

Muide, ma seadistasin aruandeid, eesmärke ja sündmusi Yandex Metrica ja Google Analyticsi süsteemides.

HTTP-päring ehk sõnum koosneb kolmest osast: päringureast ja HTTP-sõnumi sisust.

Päringu string või algusrida: serverile saadetud päringus rida, mis sisaldab päringu tüüpi (meetodit), taotletud lehe URI-d ja versiooni (nt HTTP/1.1). Serveri vastuses sisaldab see rida HTTP-protokolli versiooni ja vastuse koodi. Vastuse kood on kolmekohaline täisarv. Tavaliselt järgneb sellele tühikuga eraldatud selgitav fraas, mis selgitab koodi, näiteks: 200 OK või 404 Not Found.

HTTP päringu meetodid (tüübid): HANKI, POSTITSE, PANGE, PAIGISTA, PEA, KUSTUTA, JÄLGI. Kõige sagedamini kasutatakse HTTP-päringus GET- või POST-meetodeid: GET-i kasutatakse veebilehe sisu pärimiseks määratud URI-l. URI on lehe aadress täpsustamata , näiteks /internet/chto-takoe-http-zapros-soobshhenie/ site/internet/chto-takoe-http-zapros-soobshhenie/ asemel. Brauser võib edastada parameetreid GET-is URI-s pärast "? ": GET /index.php?param1=value1¶m2=value2. Lisaks tavalisele GET-meetodile on olemas ka tingimuslik GET ja osaline GET. Tingimuslikud GET-päringud sisaldavad If-Modified-Since, If-Match, If-Range ja sarnaseid päiseid.

POST – kasutatakse teabe saatmiseks aadressile . Andmete saatmisel POST-meetodil näidatakse see HTTP-sõnumi sisus, mitte brauseri aadressi sisestusreal, nagu tehakse andmete saatmisel GET-meetodil. Näiteks kommentaari saatmisel artikli all asuva vormi kaudu edastatakse teave serverisse POST-meetodil. Samuti laaditakse failid serverisse üles POST meetodil.

- see on osa päringust, mis sisaldab erinevaid parameetreid, mida kasutatakse veebilehe õigeks koostamiseks.

HTTP-sõnumi sisu— sisaldab serverist saadud andmeid, näiteks HTML-koodi kujul loodud veebilehte või ressurssi, näiteks pilti.

HTTP sõnumite näidised:

HTTP päring serverile:

GET /internet/chto-takoe-http-zapros-soobshhenie/ HTTP/1..9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 ( KHTML, nagu Gecko) Chrome/40.0.2150.0 Aktsepti-kodeering: gzip, deflate, sdch Aktsepteeri keel: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4 Küpsis: wp- seaded-1=hidetb%3D; wp-settings-time-1=1424958215; wordpress_test_cookie=WP+küpsis;

Vastus serverist:

HTTP/1.1 200 OK – vastuse stardijoon: Server: nginx/1.6.2 Kuupäev: pühapäev, 19. aprill 2015 00:22:50 GMT sisutüüp: tekst/html; charset=UTF-8 sisu pikkus: 9431 Ühendus: elushoidmine Elus hoidmine: timeout=30 X-Powered-By: PHP/5.5.22 Aegub: kolmapäev, 11. jaanuar 1984 05:00:00 GMT vahemälu juhtimine: no-cache, must-revalidate, max-age=0 Pragma: no-cache Vary: Accept-Encoding Content-Encoding: gzip Järgneb vastuse keha (html-leht).

HTTP on protokoll hüperteksti edastamiseks hajutatud süsteemide vahel. Tegelikult on http tänapäevase veebi põhielement. Ennast lugupidavate veebiarendajatena peaksime sellest võimalikult palju teadma.

Vaatame seda protokolli läbi meie elukutse objektiivi. Esimeses osas käsitleme põhitõdesid ja vaatame päringuid/vastuseid. Järgmises artiklis vaatleme üksikasjalikumaid funktsioone, nagu vahemälu, ühenduse töötlemine ja autentimine.

Ka selles artiklis viitan peamiselt RFC 2616 standardile: Hypertext Transfer Protocol -- HTTP/1.1.

HTTP põhitõed

HTTP võimaldab suhtlust mitme hosti ja kliendi vahel ning toetab mitmesuguseid võrgusätteid.

Põhimõtteliselt kasutatakse suhtluseks TCP/IP-d, kuid see pole ainus võimalik valik. Vaikimisi kasutab TCP/IP porti 80, kuid kasutada saab ka teisi.

Suhtlemine hosti ja kliendi vahel toimub kahes etapis: päring ja vastus. Klient genereerib HTTP päringu, millele server annab vastuse (teate). Veidi hiljem vaatame seda tööskeemi üksikasjalikumalt.

HTTP-protokolli praegune versioon on 1.1, milles on kasutusele võetud mõned uued funktsioonid. Minu arvates on neist olulisemad: pidevalt avatud ühenduse tugi, uus andmeedastusmehhanism chunked transfer kodeering, uued päised vahemällu salvestamiseks. Vaatleme mõnda neist selle artikli teises osas.

URL

Veebisuhtluse tuumaks on päring, mis saadetakse URL-i (Uniform Resource Locator) kaudu. Olen kindel, et te juba teate, mis on URL, kuid täielikkuse huvides otsustasin öelda paar sõna. URL-i struktuur on väga lihtne ja koosneb järgmistest komponentidest:

Protokoll võib olla kas http tavaliste ühenduste jaoks või https turvalisemaks andmevahetuseks. Vaikimisi port on 80. Sellele järgneb serveris oleva ressursi tee ja parameetrite ahel.

meetodid

URL-i abil määratleme hosti täpse nime, millega tahame suhelda, kuid milliseid toiminguid peame tegema, saab edastada ainult HTTP-meetodit kasutades. Loomulikult saame teha mitut tüüpi toiminguid. HTTP rakendab kõige vajalikumaid, mis sobivad enamiku rakenduste vajadustega.

Olemasolevad meetodid:

SAADA: juurdepääs olemasolevale ressursile. URL loetleb kogu vajaliku teabe, et server saaks soovitud ressursi leida ja vastusena tagastada.

POSTITA: kasutatakse uue ressursi loomiseks. POST-i päring sisaldab tavaliselt kogu vajalikku teavet uue ressursi loomiseks.

PANGE: värskendage praegust ressurssi. PUT-päring sisaldab värskendatavaid andmeid.

KUSTUTA: kasutatakse olemasoleva ressursi kustutamiseks.

Need meetodid on kõige populaarsemad ja neid kasutavad kõige sagedamini erinevad tööriistad ja raamistikud. Mõnel juhul saadetakse PUT- ja DELETE-päringud POST-i saatmisega, mille sisu näitab ära toimingu, mida ressursiga on vaja teha: luua, värskendada või kustutada.

HTTP toetab ka teisi meetodeid:

PEA: sarnane GET-iga. Erinevus seisneb selles, et seda tüüpi päringu puhul sõnumit ei edastata. Server võtab vastu ainult päised. Kasutatakse näiteks selleks, et teha kindlaks, kas ressurssi on muudetud.

TRACE: edastamise ajal läbib päring palju pöörduspunkte ja puhverservereid, millest igaüks sisestab oma teabe: IP, DNS. Seda meetodit kasutades näete kogu vahepealset teavet.

VALIKUD: kasutatakse konkreetse ressursi serveri võimaluste, sätete ja konfiguratsiooni määratlemiseks.

Olekukoodid

Vastuseks kliendi päringule saadab server vastuse, mis sisaldab ka olekukoodi. Sellel koodil on eriline tähendus, et klient saaks selgemalt aru, kuidas vastust tõlgendada:

1xx: teabeteated

Nende koodide komplekt võeti kasutusele HTTP/1.1-s. Server saab saata päringu kujul: Oodata: 100-continue, mis tähendab, et klient saadab endiselt ülejäänud päringu. HTTP/1.0 kasutavad kliendid ignoreerivad neid päiseid.

2xx: eduteated

Kui klient sai koodi sarjast 2xx, siis päring saadeti edukalt. Levinuim variant on 200 OK. GET-päringu korral saadab server vastuse sõnumi sisus. On ka teisi võimalikke vastuseid:

202 Vastu võetud: taotlus võetakse vastu, kuid see ei pruugi sisaldada vastuses olevat ressurssi. See on kasulik serveripoolsete asünkroonsete päringute korral. Server määrab, kas ressurss saata või mitte.
204 Sisu puudub: vastuse kehas pole teadet.
205 Sisu lähtestamine: annab serverile käsu lähtestada dokumendi esitus.
206 Osaline sisu: vastus sisaldab ainult osa sisust. Täiendavad päised määravad sisu ja muu teabe kogupikkuse.

3xx: ümbersuunamine

Omamoodi sõnum kliendile vajadusest teha veel üks tegevus. Kõige tavalisem kasutusjuht on kliendi ümbersuunamine teisele aadressile.

301 Kolis alaliselt: Ressursi leiate nüüd teiselt URL-ilt.
303 Vt Muu: Ressursi võib ajutiselt leida teiselt URL-ilt. Päis Asukoht sisaldab ajutist URL-i.
304 Muutmata: server teeb kindlaks, et ressurssi ei ole muudetud ja klient peab kasutama vastuse vahemällu salvestatud versiooni. Teabe identiteedi kontrollimiseks kasutatakse ETag-i (Entity Tag hash);

4xx: kliendi vead

Seda sõnumiklassi kasutab server, kui ta otsustab, et päring saadeti ekslikult. Kõige tavalisem kood on 404 ei leitud. See tähendab, et ressurssi serverist ei leitud. Muud võimalikud koodid:

400 halb taotlus: Küsimus koostati valesti.
401 Volitamata: päringu esitamiseks on vaja autentimist. Teave edastatakse autoriseerimise päise kaudu.
403 Keelatud: server ei lubanud juurdepääsu ressursile.
405 Meetod pole lubatud: Ressursile juurdepääsuks kasutati kehtetut HTTP-meetodit.
409 Konflikt: server ei saa taotlust täielikult töödelda, kuna proovib muuta ressursi uuemat versiooni. See juhtub sageli PUT-i päringutega.

5xx: serveri vead

Koodide seeria, mida kasutatakse päringu töötlemisel serveri vea tuvastamiseks. Kõige tavalisem: 500 Internal Server Error. Muud valikud:

501 Ei rakendata: server ei toeta nõutud funktsioone.
503 Teenus pole saadaval: See võib juhtuda, kui serveris on tõrge või see on ülekoormatud. Tavaliselt sel juhul server ei reageeri ja vastuseks antud aeg saab läbi.

Taotluse/vastuse sõnumivormingud

Järgmisel pildil näete skemaatiliselt kliendi päringu saatmist, serveri poolt vastuse töötlemist ja saatmist.

Vaatame HTTP kaudu edastatava sõnumi struktuuri:

Sõnum = *() CRLF [ ] = Request-Line | Olekurida = Välja nimi ":" Välja väärtus

Sõnumi päise ja sisu vahel peab olema tühi rida. Pealkirju võib olla mitu:

Vastuse keha võib sisaldada kogu teavet või osa sellest, kui vastav funktsioon on lubatud (Transfer-Encoding: chunked). HTTP/1.1 toetab ka Transfer-Encodingi päist.

Üldpealkirjad

Siin on mitut tüüpi päiseid, mida kasutatakse nii päringutes kui ka vastustes.

Mõned asjad oleme selles artiklis juba käsitlenud, mõnda käsitleme üksikasjalikumalt teises osas.

Päist kaudu kasutatakse TRACE päringus ja seda värskendavad kõik puhverserverid.

Pragma päist kasutatakse kohandatud päiste loetlemiseks. Näiteks Pragma: no-cache on sama, mis Cache-Control: no-cache. Sellest räägime lähemalt teises osas.

Päist Kuupäev kasutatakse päringu/vastuse kuupäeva ja kellaaja salvestamiseks.

Protokolli muutmiseks kasutatakse päist Upgrade.

Transfer-Encoding on ette nähtud vastuse jagamiseks mitmeks tükiks, kasutades Transfer-Encoding: chunked. See on HTTP/1.1 uus funktsioon.

Olemi päised

Olemi päised edastavad sisu kohta metateavet:

Kõik päised, mille eesliide on sisu – annavad teavet sõnumi keha struktuuri, kodeeringu ja suuruse kohta.

Päis Expires sisaldab olemi aegumisaega ja kuupäeva. Väärtus "ei aegu kunagi" tähendab aega + 1 kood praegusest hetkest. Viimati muudetud sisaldab olemi viimati muudetud kellaaega ja kuupäeva.

Nende päiste abil saate määrata oma ülesannete jaoks vajaliku teabe.

Taotluse vorming

Taotlus näeb välja umbes selline:

SP on žetoonide eraldaja. HTTP versioon on määratud HTTP-versioonis. Tegelik taotlus näeb välja selline:

GET /articles/http-basics HTTP/1.1 Host: www.articles.com Ühendus: hoia elus Vahemälu-juhtimine: vahemälu puudub Pragma: vahemälu puudub Nõustu: text/html,application/xhtml+xml,application/xml; q=0,9,*/*;q=0,8

Võimalike päringu päiste loend:

Päis Accept määrab toetatud MIME tüübid, keele ja märgikodeeringu. Päised From, Host, Referer ja User-Agent sisaldavad teavet kliendi kohta. If- prefiksid on mõeldud tingimuste loomiseks. Kui tingimus ei lähe läbi, ilmub tõrge 304 muutmata.

Vastuse vorming

Vastuse vorming erineb ainult oleku ja päiste arvu poolest. Olek näeb välja selline:

Olekurida = HTTP-versiooni SP olek-kood SP põhjus-fraas CRLF

HTTP versioon
Olekukood
Inimloetav olekuteade

Tavaline olek näeb välja umbes selline:

HTTP/1.1 200 OK

Vastuste päised võivad olla järgmised:

Vanus on aeg sekundites, mil sõnum serveris loodi.
ETagistage MD5 olemid, et kontrollida vastuse muudatusi ja muudatusi.
Asukohta kasutatakse ümbersuunamiseks ja see sisaldab uut URL-i.
Server määrab serveri, kus vastus genereeriti.

Arvan, et tänaseks teooriast piisab. Nüüd vaatame tööriistu, mida saame kasutada HTTP-sõnumite jälgimiseks.

Tööriistad HTTP-liikluse tuvastamiseks

HTTP-liikluse jälgimiseks on palju tööriistu. Siin on mõned neist:

Kõige sagedamini kasutatav on Chrome'i arendaja tööriistad.

Kui me räägime silurist, võite kasutada Fiddleri:

HTTP-liikluse jälgimiseks vajate curl, tcpdump ja tshark.

HTTP-ga töötamiseks mõeldud raamatukogud – jQuery AJAX

Kuna jQuery on nii populaarne, on sellel ka tööriistad AJAX-i päringute HTTP-vastuste haldamiseks. Teavet jQuery.ajax(settings) kohta leiate ametlikult veebisaidilt.

Sätete objekti edastamisel ja tagasihelistamisfunktsiooni beforeSend abil saame määrata päringu päised meetodiga setRequestHeader().

$.ajax(( url: "http://www.articles.com/latest", tüüp: "GET", beforeSend: funktsioon (jqXHR) ( jqXHR.setRequestHeader("Accepts-Language", "en-US,et" "); ) ));

Kui soovite taotluse olekut töödelda, saate seda teha järgmiselt:

$.ajax(( statusCode: ( 404: function()) ( alert("lehte ei leitud"); ) ));

Alumine rida

Siin see on HTTP-protokolli põhitõdede tutvustus. Teine osa sisaldab veelgi huvitavamaid fakte ja näiteid.

Tutvustame teile HTTP-protokolli peamiste aspektide kirjeldust – võrguprotokolli, mis 90ndate algusest tänapäevani võimaldab teie brauseris veebilehti laadida. See artikkel on kirjutatud neile, kes alles alustavad arvutivõrkudega töötamist ja võrgurakenduste arendamist ning kellel on endiselt raske iseseisvalt ametlikke spetsifikatsioone lugeda.

HTTP- laialdaselt kasutatav andmeedastusprotokoll, mis oli algselt mõeldud hüpertekstdokumentide (st dokumentide, mis võivad sisaldada linke, mis võimaldavad navigeerida teistele dokumentidele) edastamiseks.

Lühend HTTP tähistab Hüperteksti edastusprotokoll, "hüperteksti edastusprotokoll". Vastavalt OSI spetsifikatsioonile on HTTP rakenduse (ülemise, 7.) kihi protokoll. Protokolli praegust versiooni HTTP 1.1 on kirjeldatud RFC 2616 spetsifikatsioonis.

HTTP-protokoll hõlmab andmeedastusstruktuuri klient-server kasutamist. Kliendirakendus genereerib päringu ja saadab selle serverisse, misjärel serveritarkvara töötleb päringu, genereerib vastuse ja saadab selle tagasi kliendile. Seejärel saab kliendirakendus jätkata teiste päringute saatmist, mida töödeldakse samamoodi.

Ülesanne, mida traditsiooniliselt lahendatakse HTTP-protokolli abil, on andmevahetus veebiressurssidele ligi pääseva kasutajarakenduse (tavaliselt veebibrauseri) ja veebiserveri vahel. Praegu töötab World Wide Web just tänu HTTP-protokollile.

HTTP-d kasutatakse sageli ka teiste rakenduskihi protokollide (nt SOAP, XML-RPC ja WebDAV) transpordiprotokollina. Sel juhul kasutatakse HTTP-protokolli transpordina.

Paljude tarkvaratoodete API eeldab ka HTTP kasutamist andmeedastuseks - andmed ise võivad olla mis tahes vormingus, näiteks XML või JSON.

Tavaliselt toimub HTTP andmeedastus TCP/IP ühenduste kaudu. Sel juhul kasutab serveritarkvara tavaliselt TCP-porti 80 (ja kui port pole selgesõnaliselt määratud, kasutab klienttarkvara tavaliselt HTTP-ühenduste avamiseks vaikimisi porti 80), kuigi võib kasutada ka mis tahes muud porti.

Kuidas saata HTTP-päring?

Lihtsaim viis HTTP-protokolli mõistmiseks on proovida mõnele veebiressursile käsitsi juurde pääseda. Kujutage ette, et olete brauser ja teil on kasutaja, kes tõesti soovib lugeda Anatoli Alizari artikleid.

Oletame, et ta sisestas aadressiribale järgmise:

Http://alizar.habrahabr.ru/

Seetõttu peate nüüd veebibrausrina looma ühenduse veebiserveriga aadressil alizar.habrahabr.ru.

Selleks võite kasutada mis tahes sobivat käsurea utiliiti. Näiteks telnet:

Telnet alizar.habrahabr.ru 80

Lubage mul kohe selgitada, et kui muudate oma meelt ootamatult, vajutage klahvikombinatsiooni Ctrl + “]” ja seejärel sisestusklahvi – see võimaldab teil HTTP-ühenduse sulgeda. Lisaks telnetile võid proovida nc-i (või ncat) – olenevalt maitsest.

Pärast serveriga ühenduse loomist peate saatma HTTP-päringu. See on muide väga lihtne – HTTP päringud võivad koosneda vaid kahest reast.

HTTP päringu genereerimiseks tuleb koostada algusrida ja määrata ka vähemalt üks päis – see on hosti päis, mis on kohustuslik ja peab olema igas päringus. Fakt on see, et domeeninime teisendamine IP-aadressiks toimub kliendi poolel ja vastavalt TCP-ühenduse avamisel pole kaugserveril teavet selle kohta, millist aadressi ühenduse loomiseks kasutati: see võib olla näiteks aadress alizar.habrahabr.ru, habrahabr.ru või m.habrahabr.ru – ja kõigil neil juhtudel võib vastus erineda. Kuid tegelikult avatakse võrguühendus kõigil juhtudel sõlmega 212.24.43.44 ja isegi kui algselt ei olnud ühenduse avamisel määratud see IP-aadress, vaid mingi domeeninimi, siis serverit sellest ei teavitata. igal juhul - ja seepärast on see aadress vajalik hosti päises.

HTTP 1.1 algus (esialgne) päringurida koostatakse järgmise skeemi järgi:

Näiteks (selline algusjoon võib viidata sellele, et taotletakse saidi avalehte):

Ja muidugi ärge unustage, et iga tehnoloogia muutub palju lihtsamaks ja selgemaks, kui hakkate seda kasutama.

Edu ja viljakat õppimist!

Sildid: lisa sildid