Protokolli i Transferimit të HyperText (HTTP) është një protokoll i shtresës së aplikacionit që lidh aplikacionet nëpër sisteme informacioni të shpërndara, të përbashkëta ose heterogjene. Protokolli i lejon aplikacionet të shkëmbejnë të dhëna në një mënyrë të lexueshme nga njeriu.
Siç sugjeron emri i tij, fillimisht HTTP kishte për qëllim të transferonte midis aplikacioneve të ashtuquajturin hipertekst, i cili është një lloj i veçantë i të dhënave të krijuar në përputhje me standardin HTML (HyperText Markup Language). Një dokument hipertekst përbëhet nga të dhëna të etiketuara me etiketa HTML dhe është një kombinim i tekstit, imazheve, hiperlidhjeve dhe mjeteve të tjera të paraqitjes së të dhënave. Hiperlidhjet - një nga pjesët më të rëndësishme të një dokumenti HTML - janë zona ndërvepruese që mund të manipulohen për të prodhuar të dhënat e lidhura me hiperlidhjen. Kjo lejon një përdorues që punon me informacionin e hipertekstit të lundrojë brenda një grupi dokumentesh apo edhe në të gjithë internetin, duke marrë informacione me interes duke përdorur hiperlidhjet kontekstuale.
Protokolli HTTP është një superstrukturë mbi protokollin TCP dhe është një mjet për të kontrolluar përmbajtjen e të dhënave të transmetuara. Ndryshe nga TCP, i cili nuk mori parasysh strukturën e paketave të transmetuara, HTTP fut meta-informacione në të dhëna, gjë që lejon marrësin të interpretojë saktë të dhënat e marra. Interneti global (i quajtur gjithashtu World Wide Web ose WWW) funksionon në bazë të HTTP. Versioni i parë i protokollit - HTTP / 0.9 - kishte aftësi mjaft të kufizuara, por me zhvillimin aktiv të rrjetit botëror, u shfaqën versione të reja: HTTP / 1.0 dhe HTTP / 1.1, duke lejuar kontrollin e transmetimit jo vetëm të informacionit të hipertekstit mbi rrjetet kompjuterike, por edhe skedarët binare arbitrare: zëri, grafika, arkivore etj.
Për shkak të faktit se HTTP është një shtesë mbi protokollin TCP, ka edhe dy anë të transferimit të të dhënave: klienti dhe serveri.
Klienti fillon lidhjen dhe kërkon disa të dhëna ose shërbime nga serveri. Klienti, si rregull, është një program i quajtur shfletues (shfletues), i cili lejon shfaqjen e informacionit të hipertekstit dhe marrjen e skedarëve të formateve të tjera. Për të marrë disa informacione me interes, klienti dërgon një kërkesë në server që përmban një përshkrim të informacionit të kërkuar.
Kur transmetoni të dhëna përmes HTTP, një server quhet një server në internet. Ky program përpunon kërkesat nga klientët, duke transmetuar të dhënat e kërkuara në formën e përgjigjeve (përgjigje), që përmbajnë, përveç të dhënave të kërkuara, edhe meta-informacione që i përshkruajnë ato.
Marrja e të dhënave me interes për përdoruesin përbëhet nga fazat e mëposhtme:
Përdoruesi fut adresën e burimit të interesit në linjën e shfletuesit.
Shfletuesi, bazuar në informacionin e marrë nga përdoruesi, si dhe duke marrë parasysh cilësimet e tij dhe konfigurimin e sistemit operativ, gjeneron një kërkesë.
Shfletuesi lidhet me një server, ndoshta në një kompjuter të largët, dhe i dërgon kërkesën atij.
Serveri, duke analizuar kërkesën, kryen veprimet e nevojshme: gjeneron një përgjigje, duke përfshirë trupin e dokumentit të kërkuar. Nëse është një dokument hipertekst, ai ngarkohet nga një skedar ose gjenerohet në mënyrë dinamike përmes një skripti. Përgjigja përfshin gjithashtu informacion në lidhje me të dhënat që përmban.
Serveri dërgon përgjigjen te shfletuesi.
Shfletuesi analizon përgjigjen dhe ose ruan të dhënat që rezultojnë në një skedar, ose, në rastin e një dokumenti hipertekst, analizon etiketat HTML dhe shfaq dokumentin në ekran.
Duhet të theksohet se programi i klientit mund të jetë jo vetëm shfletuesi, megjithatë, të gjitha hapat, me përjashtim, ndoshta, nga i pari, kryhen në çdo rast.
Duhet të theksohet se këtu merret parasysh lidhja e drejtpërdrejtë e klientit me serverin që përmban informacionin me interes, megjithatë, kjo nuk është gjithmonë e mundur për shkak të rrethanave të ndryshme. Në këtë rast, lidhja mund të bëhet përmes një ose më shumë pikave të ndërmjetme të lidhjes. Këto pika të ndërmjetme mund të ndahen në tre grupe:
Proxy servers (proxy-server) - një program ndërmjetës që kryen funksionet e një klienti dhe një serveri në mënyrë që të krijojë kërkesa në emër të klientëve të tjerë. Kërkesat shërbehen nga serveri proxy, ose u përcillen atyre me ndryshime në to (në këtë rast, serveri proxy quhet opaque) ose i pandryshuar (në këtë rast, serveri proxy quhet transparent). Një server proxy lejon një grup kompjuterësh të veprojnë si një klient i vetëm, i cili përdoret shpesh kur rrjetet lokale janë të lidhura me internetin.
Gateway - si një server proxy, ai përkthen kërkesat, megjithatë, unë nuk i nënshtroj ato për ndryshim. Porta merr një kërkesë nga klienti për serverin që përmban burimin e kërkuar. Kështu, klienti nuk mund të përcaktojë nëse po lidhet përmes një porte ose drejtpërdrejt me serverin që përmban.
Një tunel është një program ndërmjetës që mban një lidhje. Edhe pse pasi të vendoset lidhja, tuneli nuk konsiderohet si një element transmetimi përmes protokollit HTTP, lidhja zakonisht inicohet nga kërkesa HTTP. Tuneli ndërpret punën e tij nëse të paktën një nga pjesëmarrësit në shkëmbimin e të dhënave mbyll lidhjen.
Për të ruajtur funksionalitetin e transferimit të të dhënave gjatë lidhjes përmes pikave të ndërmjetme, nuk kërkohen ndryshime në kërkesat dhe përgjigjet, përveç në rastin e një serveri proxy: në këtë rast, kërkesa e klientit duhet të përmbajë fusha shtesë. Sidoqoftë, nga këndvështrimi i serverit, shkëmbimi i të dhënave kryhet drejtpërdrejt me klientin, prandaj nuk bëhen ndryshime në kërkesat. Prandaj, gjatë zhvillimit të programit, nuk është marrë parasysh mundësia e lidhjes përmes pikave të ndërmjetme.
Kërkesa e dërguar nga klienti në server shërben për identifikimin e saktë të burimit të kërkuar, si dhe përmban informacionin e nevojshëm për përpunimin e saktë të kërkesës.
Sipas strukturës së saj, kërkesa përbëhet nga tre pjesë:
Vargu i pyetjes
Blloku i kokës
Linja e kërkesës përbëhet nga tre fusha, të ndara me karaktere hapësinore (kodi ASCII 20h, këtu e tutje SP) dhe përfundon me një kombinim të dy karaktereve: kthimi i transportit (kodi ASCII 0Dh, këtu e tutje CR) dhe furnizimi i linjës (kodi ASCII 0Ah, këtu e tutje LF )... Elementet e vargut të pyetjes përfaqësohen nga fushat e mëposhtme:
Metoda - përcakton metodën e përpunimit që do të aplikohet në burimin e kërkuar. Në varësi të metodës së specifikuar, formati i kërkesës mund të jetë i ndryshëm. Metodat e vlefshme:
Gjatë zhvillimit të programit, mbështetja u prezantua vetëm për metodën GET, për faktin se është kjo metodë që shfletuesi specifikon në kërkesën e krijuar si parazgjedhje.
Burimi URI (Identifikuesi i Burimeve Universale) (URI i burimit) - tregon vendndodhjen e burimit të kërkuar në një format të standardizuar, domethënë është adresa e burimit. Kur përdorni metodën GET, ky varg mund të përfshijë një grup parametrash që i kalohen serverit si vargje të formatit "parameter_name = parameter_value", të ndara me ampersand `&". Blloku i parametrave është në fund të vargut URI dhe i ndarë nga adresa me pikëpyetjen "?".
Versioni i protokollit HTTP - gjatë zhvillimit të programit, u zbatua mbështetje për marrjen e kërkesave që korrespondojnë me versionet 1.0 dhe 1.1, të cilat korrespondojnë përkatësisht me vargjet "HTTP / 1.0" dhe "HTTP / 1.1".
Blloku i kokës që ndjek linjën e kërkesës mund të përbëhet nga një ose më shumë tituj:
Kreu i kërkesës - përmban fusha që shërbejnë si modifikues të kërkesës dhe përmbajnë informacion në lidhje me kërkesën dhe konfigurimin e makinës së klientit.
Kreu i objektit - nëse kërkesa përfshin disa objekte (bashkësi të dhënash arbitrare), fushat e këtij titulli përshkruajnë objektin, duke treguar formatin e tij, kodimin dhe parametrat e tjerë.
Titulli i zakonshëm - përmban parametrat e shërbimit të nevojshëm për të siguruar transmetimin e saktë dhe për të mundësuar shërbime shtesë si caching.
Seksioni i titullit përfundon me dy palë karaktere CR dhe LF, gjë që e bën të lehtë përcaktimin e faktit të përfundimit të marrjes së një kërkese, pasi vetë kërkesa nuk mund të përmbajë një kombinim të tillë karakteresh.
Përgjigja e dërguar nga serveri te klienti mund të gjenerohet vetëm si rezultat i përpunimit të kërkesës së klientit. Ai përmban një përshkrim të rezultateve të ekzekutimit të pyetjes dhe, nëse kërkohen të dhëna, përfshin burimin e kërkuar.
Për nga struktura e saj, përgjigja përbëhet nga pjesët e mëposhtme:
Shiriti i statusit
Blloku i kokës
Linja e statusit përbëhet nga tre fusha, të ndara me karaktere SP dhe përmban një sekuencë karakteresh CR, LF në fund. Artikujt e shiritit të statusit:
Versioni i protokollit HTTP - programi i zhvilluar gjithmonë përdor vargun "HTTP / 1.1".
Kodi i statusit është një kod numerik me tre karaktere që identifikon rezultatin e një kërkese. Megjithëse standardi përcakton një grup mjaft të madh të kodeve të statusit, programi përdor kodet e mëposhtme:
- 200 - përfundimi me sukses;
- 400 - kërkesë e pavlefshme;
- 401 - akses i paautorizuar;
- 404 - burimi nuk u gjet;
- 405 - metodë e pazbatueshme;
- 505 është një version HTTP i pambështetur.
Një frazë arsyeje është një frazë e shkurtër që shpjegon kodin e statusit të një kërkese. Standardi ofron një grup standard frazash, por programi e ka modifikuar pak këtë grup.
Blloku i titullit që ndjek shiritin e statusit mund të përbëhet nga një ose më shumë tituj:
Kreu i kërkesës
Titulli i objektit
Titulli i përgjithshëm
Një shqyrtim i detajuar i titujve është bërë në paragrafin 2.2.3.3.
Seksioni i kokës përfundon me dy palë karaktere CR dhe LF, të ndjekur nga një grup arbitrar karakteresh - një objekt. Kur programi është duke u ekzekutuar, objekte të tilla mund të jenë vetëm dokumente hiperteksti në format HTML, të krijuara në mënyrë dinamike nga shtojcat.
Kemi publikuar një libër të ri, "Marketingu i përmbajtjes në mediat sociale: Si të hyni në krye të abonentëve dhe të bini në dashuri me markën tuaj".
HTTP është ai që lejon transferimin e të dhënave. Fillimisht, ai u krijua për të dërguar dhe marrë dokumente që përmbajnë lidhje brenda për të kryer një kalim te burimet e palëve të treta.
Shkurtesa lexon "HyperText Transfer Protocol", që do të thotë "protokoll për transferim". HTTP i përket një grupi të shtresave të aplikacionit bazuar në specifikat e përdorura nga OSI.
Për të kuptuar më mirë se çfarë do të thotë HTTP, le të shohim një analogji të thjeshtë. Le të imagjinojmë se po komunikoni me një të huaj në një rrjet social. Ai ju dërgon një mesazh në anglisht, ju e merrni atë. Por ju nuk mund ta kuptoni përmbajtjen, sepse nuk e dini gjuhën sa duhet. Përdorni një fjalor për të deshifruar mesazhin. Duke kuptuar thelbin, ju i përgjigjeni të huajit në Rusisht dhe i dërgoni përgjigjen. I huaji merr një përgjigje dhe me ndihmën e një përkthyesi deshifron mesazhin. Për të thjeshtuar të gjithë mekanizmin, protokollet e internetit HTTP veprojnë si përkthyes. Me ndihmën e tyre, shfletuesi mund të përkthejë përmbajtjen e koduar të faqeve të internetit dhe të shfaqë përmbajtjen e tyre.
Për çfarë është HTTP?
Protokolli HTTP përdoret për të shkëmbyer informacione duke përdorur një model klient-server. Klienti harton dhe dërgon një kërkesë në server, më pas serveri e përpunon dhe analizon atë, pas së cilës krijohet një përgjigje dhe i dërgohet përdoruesit. Në fund të këtij procesi, klienti bën një komandë të re dhe gjithçka përsëritet.
Kështu, protokolli HTTP bën të mundur shkëmbimin e informacionit midis aplikacioneve të ndryshme të përdoruesve dhe serverëve të veçantë të ueb-it, si dhe lidhjen me burimet e ueb-it (zakonisht shfletuesit). Sot, protokolli i përshkruar fuqizon të gjithë rrjetin. Protokolli i transferimit të të dhënave HTTP përdoret gjithashtu për të transferuar informacion mbi protokolle të tjera të nivelit më të ulët si WebDAV ose SOAP. Në këtë rast, protokolli është një mjet transporti. Shumë programe gjithashtu mbështeten në HTTP si mjetin e tyre kryesor të komunikimit. Të dhënat paraqiten në formate të ndryshme, për shembull, JSON ose XML.
HTTP është një protokoll për shkëmbimin e informacionit përmes një lidhjeje IP / TCP. Në mënyrë tipike, serveri përdor portin 80 të llojit TCP për këtë. Nëse nuk specifikohet asnjë port, softueri i klientit do të përdorë portin TCP 80 si parazgjedhje. Në disa raste, mund të përdoren porte të tjera.
Protokolli HTTP përdor një skemë kriptimi simetrik dhe përdor kriptosisteme simetrike. Kriptosistemet simetrike përfshijnë përdorimin e të njëjtit çelës për të kriptuar dhe deshifruar informacionin.
Si ndryshon HTTP nga HTTPS
Dallimi mund të gjendet edhe nga dekodimi i shkurtesave. HTTPS do të thotë Mbrojtja e Protokollit të Transferimit të Hypertext. Kështu, HTTP është një protokoll i veçantë, dhe HTTPS është një shtesë për ta mbrojtur atë. Nëpërmjet HTTP, informacioni transmetohet i pasigurt dhe HTTPS ofron mbrojtje kriptografike. Kjo është veçanërisht e vërtetë për burimet me autorizim përgjegjës. Këto mund të jenë rrjete sociale ose faqe të sistemeve të pagesave.
Pse është i rrezikshëm transferimi i të dhënave të pambrojtura? Një program përgjues mund t'i transmetojë ato te kriminelët kibernetikë në çdo kohë. HTTPS ka një organizim teknik kompleks, i cili ju lejon të mbroni me besueshmëri informacionin dhe të përjashtoni mundësinë e aksesit të paautorizuar në të. Dallimi qëndron edhe te portet. HTTPS zakonisht funksionon në portin 443.
Kështu, HTTP përdoret për transmetimin e të dhënave dhe HTTPS lejon transmetimin e sigurt të të dhënave duke përdorur kriptim dhe autorizim në burime me një nivel të lartë sigurie.
Funksionalitet shtesë
HTTP është i pasur me funksionalitet dhe është i pajtueshëm me shtesa të ndryshme. Specifikimi 1.1 në përdorim sot lejon që kreu i Përmirësimit të përdoret për të kaluar dhe për të punuar përmes protokolleve të tjera gjatë shkëmbimit të të dhënave. Për ta bërë këtë, përdoruesi duhet të dërgojë një kërkesë në server me këtë kokë. Nëse serveri duhet të kalojë në një shkëmbim specifik duke përdorur një protokoll tjetër, ai i kthen një kërkesë klientit, i cili shfaq statusin "Kërkohet përmirësimi 426".
Kjo veçori është veçanërisht e rëndësishme për shkëmbimin e informacionit nëpërmjet WebSocket (ka specifikimin RFC 6455, ju lejon të shkëmbeni të dhëna në çdo kohë, pa kërkesa të panevojshme HTTP). Për të kaluar në WebSocket, një përdorues dërgon një kërkesë me titullin Upgrade dhe vlerën "websocket". Serveri më pas përgjigjet me "101 Protokolle Ndërrimi". Pas këtij momenti fillon transferimi i informacionit nëpërmjet WebSocket.
Këtu keni një përshkrim të aspekteve kryesore të protokollit HTTP, protokollit të rrjetit që ka lejuar shfletuesin tuaj të ngarkojë faqet e internetit që nga fillimi i viteve '90 e deri më sot. Ky artikull është shkruar për ata që sapo kanë filluar të punojnë me rrjetet kompjuterike dhe të zhvillojnë aplikacione rrjeti, dhe për të cilët është ende e vështirë të lexojnë vetë specifikimet zyrtare.
HTTP- një protokoll i përhapur i transferimit të të dhënave, i destinuar fillimisht për transferimin e dokumenteve të hipertekstit (d.m.th., dokumente që mund të përmbajnë lidhje që ju lejojnë të organizoni kalimin në dokumente të tjera).
Shkurtesa HTTP qëndron për Protokolli i Transferimit të HyperText, "Protokolli i Transferimit të Hipertekstit". Sipas specifikimeve OSI, HTTP është një protokoll i shtresës së aplikacionit (i sipërm, i 7-të). Versioni aktual i protokollit, HTTP 1.1, përshkruhet në specifikimin RFC 2616.
Protokolli HTTP supozon përdorimin e një strukture të transferimit të të dhënave klient-server. Aplikacioni klient gjeneron një kërkesë dhe ia dërgon serverit, pas së cilës softueri i serverit e përpunon këtë kërkesë, gjeneron një përgjigje dhe ia dërgon atë klientit. Aplikacioni i klientit më pas mund të vazhdojë të dërgojë kërkesa të tjera, të cilat do të përpunohen në mënyrë të ngjashme.
Një problem që tradicionalisht zgjidhet duke përdorur protokollin HTTP është shkëmbimi i të dhënave midis një aplikacioni përdoruesi që akseson burimet e ueb-it (zakonisht një shfletues ueb) dhe një serveri uebi. Për momentin, është falë protokollit HTTP që sigurohet puna e World Wide Web.
Gjithashtu, HTTP përdoret shpesh si një protokoll komunikimi për protokollet e tjera të shtresave të aplikacionit si SOAP, XML-RPC dhe WebDAV. Në këtë rast, protokolli HTTP thuhet se përdoret si "transport".
API-ja e shumë produkteve softuerike nënkupton gjithashtu përdorimin e HTTP për transferimin e të dhënave - vetë të dhënat mund të jenë në çdo format, për shembull, XML ose JSON.
Në mënyrë tipike, transmetimi i të dhënave përmes protokollit HTTP kryhet përmes lidhjeve TCP / IP. Softueri i serverit zakonisht përdor portin TCP 80 (dhe nëse porti nuk është specifikuar në mënyrë eksplicite, atëherë zakonisht softueri i klientit përdor portin e 80-të si parazgjedhje për lidhjet e hapura HTTP), megjithëse mund të përdorë çdo tjetër.
Si mund të dërgoj një kërkesë HTTP?
Mënyra më e lehtë për të kuptuar protokollin HTTP është të përpiqeni të aksesoni manualisht një burim ueb. Imagjinoni që jeni një shfletues dhe keni një përdorues që me të vërtetë dëshiron të lexojë artikujt e Anatoli Alizar.Supozoni se ai ka futur sa vijon në shiritin e adresave:
Http://alizar.habrahabr.ru/
Prandaj, ju, si një shfletues në internet, tani duhet të lidheni me serverin në internet në alizar.habrahabr.ru.
Për ta bërë këtë, mund të përdorni çdo mjet të përshtatshëm të linjës së komandës. Për shembull telnet:
Telnet alizar.habrahabr.ru 80
Do të sqaroj menjëherë se nëse ndryshoni mendjen papritur, atëherë shtypni Ctrl + "]", dhe më pas futni - kjo do t'ju lejojë të mbyllni lidhjen HTTP. Përveç telnetit, mund të provoni nc (ose ncat) sipas dëshirës tuaj.
Pasi të lidheni me serverin, duhet të dërgoni një kërkesë HTTP. Nga rruga, kjo është shumë e lehtë - kërkesat HTTP mund të përbëhen nga vetëm dy rreshta.
Për të formuar një kërkesë HTTP, është e nevojshme të hartoni një linjë fillestare, dhe gjithashtu të vendosni të paktën një kokë - ky është titulli Host, i cili kërkohet dhe duhet të jetë i pranishëm në çdo kërkesë. Fakti është se shndërrimi i një emri domain në një adresë IP kryhet në anën e klientit, dhe, në përputhje me rrethanat, kur hapni një lidhje TCP, serveri i largët nuk ka asnjë informacion se cila adresë është përdorur për lidhjen: mund të jetë, për shembull, adresa alizar.habrahabr.ru, habrahabr.ru ose m.habrahabr.ru - dhe në të gjitha këto raste përgjigjja mund të ndryshojë. Mirëpo, në fakt, në të gjitha rastet, lidhja e rrjetit hapet me nyjen 212.24.43.44, dhe edhe nëse fillimisht, kur është hapur lidhja, nuk është vendosur kjo adresë IP, por një emër domeni, serveri nuk është i informuar për kjo në çfarëdo mënyre - dhe kjo është arsyeja pse kjo adresë është e nevojshme të kalojë në kokën e Host.
Vargu i kërkesës fillestare (fillestare) për HTTP 1.1 është i përbërë si më poshtë:
Për shembull (një linjë fillimi si kjo mund të tregojë se faqja kryesore e faqes po kërkohet):
Dhe, sigurisht, mos harroni se çdo teknologji bëhet shumë më e thjeshtë dhe më e qartë kur filloni ta përdorni atë.
Fat i mirë dhe mësim i frytshëm!
Etiketa: Shto etiketa
HTTP(Protokolli i Transferimit të HyperText - "Protokolli i Transferimit të Hipertekstit") - një protokoll i nivelit të aplikimit për transferimin e të dhënave (fillimisht - në formën e dokumenteve të hipertekstit). HTTP bazohet në teknologjinë "klient-server", domethënë supozohet se ka konsumatorë (klientë) që iniciojnë një lidhje dhe dërgojnë një kërkesë dhe ofruesit (serverët) që presin një lidhje për të marrë një kërkesë, kryejnë veprimet e nevojshme dhe ktheni një mesazh me rezultatin.
HTTP përdoret gjithashtu si "transport" për protokollet e tjera të shtresave të aplikacionit si SOAP, XML-RPC, WebDAV.
Objekti kryesor i manipulimit në HTTP është burimi i treguar nga URI (Uniform Resource Identifier) në kërkesën e klientit. Në mënyrë tipike, këto burime janë skedarë të ruajtur në server, por ato mund të jenë objekte logjike ose diçka abstrakte. Një tipar i protokollit HTTP është aftësia për të specifikuar në një kërkesë dhe një përgjigje mënyrën e paraqitjes së të njëjtit burim me parametra të ndryshëm: formati, kodimi, gjuha etj. Kjo është falë mundësisë së specifikimit të metodës së kodimit të një mesazhi. që klienti dhe serveri mund të shkëmbejnë të dhëna binare, megjithëse ky protokoll është tekst.
HTTP është një protokoll i nivelit të aplikacionit, i ngjashëm me të janë FTP dhe SMTP është një protokoll i thjeshtë i transferimit të postës. Mesazhet shkëmbehen sipas skemës së zakonshme "kërkesë-përgjigje". HTTP përdor URI globale për të identifikuar burimet. Ndryshe nga shumë protokolle të tjera, HTTP është pa shtetësi. Kjo do të thotë që nuk ka ruajtje të një gjendjeje të ndërmjetme ndërmjet çifteve kërkesë-përgjigje. Komponentët që përdorin HTTP mund të ruajnë në mënyrë të pavarur informacionin e gjendjes të lidhur me kërkesat dhe përgjigjet më të fundit. Shfletuesi kërkues mund të gjurmojë vonesat e përgjigjes. Serveri mund të ruajë adresat IP dhe të kërkojë titujt e klientëve më të fundit. Megjithatë, vetë protokolli nuk është në dijeni të kërkesave dhe përgjigjeve të mëparshme, nuk ofron mbështetje të brendshme shtetërore dhe nuk ka kërkesa të tilla.
Zgjerimi
Aftësitë e protokollit mund të zgjerohen lehtësisht duke zbatuar titujt e tij duke ruajtur përputhshmërinë me klientët dhe serverët e tjerë. Ata do të injorojnë titujt e panjohur, por gjithsesi mund të marrin funksionalitetin që u nevojitet për detyra specifike.
HTTP / 1.1- versioni aktual i protokollit. E re në këtë version ishte mënyra e "lidhjes së vazhdueshme": një lidhje TCP mund të mbetet e hapur pas dërgimit të një përgjigjeje ndaj një kërkese, e cila lejon dërgimin e kërkesave të shumta në një lidhje të vetme. Klienti tani është i detyruar të dërgojë informacion për emrin e hostit të cilit i referohet, gjë që ka bërë të mundur një organizim më të lehtë të hostimit të përbashkët.
HTTP nuk ruan informacionin e transaksionit, kështu që transaksioni tjetër duhet të fillojë nga e para. Avantazhi është se një server HTTP mund t'i shërbejë shumë më shumë klientëve në një kornizë kohore të caktuar, meqenëse shpenzimet shtesë të sesioneve të gjurmimit nga një lidhje në tjetrën eliminohen. Ekziston gjithashtu një disavantazh: programet më komplekse CGI duhet të përdorin fusha të fshehta të hyrjes ose mjete të jashtme, të tilla si cookies, për të ruajtur informacionin e transaksionit.
Metodat e kërkesës HTTP
Metoda HTTP- një sekuencë e çdo karakteri, përveç karaktereve të kontrollit dhe ndarësve, që tregojnë funksionimin kryesor në burim. Zakonisht metoda është një fjalë e shkurtër angleze e shkruar me shkronja të mëdha. Vini re se emri i metodës është i ndjeshëm ndaj shkronjave të vogla.
Çdo server duhet të mbështesë të paktën metodat GET dhe HEAD. Nëse serveri nuk e njeh metodën e specifikuar nga klienti, atëherë ai duhet të kthejë statusin 501 (Nuk u zbatua). Nëse serveri e njeh metodën, por ajo nuk është e zbatueshme për një burim specifik, atëherë kthehet një mesazh me kodin 405 (Method Not Allowed). Në të dyja rastet, serveri DUHET të përfshijë një titull Lejo në mesazhin e përgjigjes me një listë të metodave të mbështetura.
Përveç metodave GET dhe HEAD, shpesh përdoret metoda POST.
-
Titujt (parametrat) e kërkesës HTTP, përgjigjet, entitetet
Të gjithë titujt në protokollin HTTP ndahen në katër grupe kryesore (në rendin e mëposhtëm, rekomandohet t'i dërgoni titujt marrësit):
Titujt e Përgjithshëm(Titujt kryesorë) - duhet të përfshihen në çdo mesazh të klientit dhe serverit.
Titujt e Kërkesave(Titujt e kërkesës) - përdoret vetëm në kërkesat e klientëve.
Titujt e përgjigjeve(Titujt e përgjigjeve) - vetëm për përgjigjet nga serveri.
Titujt e entitetit(Titujt e entitetit) - shoqërojnë çdo entitet të mesazhit. Titujt e entitetit ndahen në një klasë të veçantë në mënyrë që të mos ngatërrohen me titujt e kërkesave ose titujt e përgjigjeve kur transmetohen përmbajtje të shumëfishta (MIME).
Të gjithë titujt HTTP të nevojshëm për funksionimin përshkruhen në RFC-të kryesore. Nëse është e nevojshme, mund të krijoni titujt tuaj. Tradicionalisht, parashtesa "X-" u shtohet emrave të këtyre titujve shtesë për të shmangur konfliktet e emrave me ato ndoshta ekzistuese.
Linjat pas linjës së kërkesës kryesore (GET /index.html HTTP / 1.1) kanë formatin e mëposhtëm: Parametri: vlera. Kështu vendosen parametrat e pyetjes. Kjo është opsionale, të gjitha rreshtat pas linjës kryesore të pyetjes mund të mungojnë; në këtë rast, serveri pranon vlerën e tyre të paracaktuar ose bazuar në rezultatet e kërkesës së mëparshme (kur punon në modalitetin Connection: Keep-Alive).
Parametri Lidhje(lidhja) - mund të jetë Keep-Alive dhe mbyll. Në HTTP 1.0, serveri që dërgon të dhënat e kërkuara pasohet nga një shkëputje nga klienti dhe transaksioni konsiderohet i përfunduar nëse titulli Connection: Keep Alive nuk dërgohet. Në HTTP 1.1, serveri nuk e heq lidhjen si parazgjedhje dhe klienti mund të bëjë kërkesa të tjera. Për shkak se shumë dokumente kanë dokumente të tjera të ngulitura në to - imazhe, korniza, aplikacione etj. - kjo kursen kohë dhe shpenzime për një klient të cilit përndryshe do t'i duhej të lidhej vazhdimisht me të njëjtin server për të marrë vetëm një faqe. Kështu, në HTTP 1.1, një transaksion mund të kalohet derisa klienti ose serveri të mbyllin në mënyrë të qartë lidhjen.
Parametri Përdorues-Agjent- vlera është "pika e kodit" e shfletuesit.
Parametri Pranoje- një listë e llojeve të përmbajtjes të mbështetura nga shfletuesi sipas renditjes së preferencës së tyre për këtë shfletues.
Parametri Mikpritës- emri i domenit nga i cili kërkohet burimi. E dobishme nëse serveri ka disa serverë virtualë nën të njëjtën adresë IP. Në këtë rast, emri i domenit virtual përcaktohet nga kjo fushë.
Parametri E modifikuara e fundit(ndryshuar së fundi) (W3C Last-Modified) Data dhe ora kur dokumenti u modifikua për herë të fundit. Duke e përdorur atë, klienti, si në rastin me ETag, mund të kontaktojë serverin me kërkesën "If-Modified-Since" - në këtë rast, serveri duhet të krahasojë datën e modifikimit të fundit të kopjes së ruajtur në klient me data aktuale e modifikimit të fundit. Nëse përputhen, do të thotë se kopja në memorien e klientit nuk është e vjetëruar dhe nuk ka nevojë të shkarkohet përsëri (kodi i përgjigjes "304 nuk është modifikuar"). Last-Modified është gjithashtu i nevojshëm për përpunimin e saktë të faqes nga robotët që përdorin informacione për datën e modifikimit të faqes për të renditur rezultatet e kërkimit sipas datës, si dhe për të përcaktuar shpeshtësinë e përditësimeve të faqes suaj.
Për dokumentet SSI, Apache do të lëshojë "Last-Modified" nëse specifikohet direktiva "XBitHack full" (për shembull, në skedarin .htaccess)
Parametri ETag(objectlabel) - Prezantuar në HTTP 1.1 (W3C ETag). ETag përdoret për t'i caktuar çdo faqe një identifikues unik, vlera e të cilit ndryshon kur ndryshohet faqja (dokumenti). ETag është një hash ("gjurmë gishti") i bajteve të dokumentit, nëse të paktën një bajt në dokument ndryshon, atëherë do të ndryshojë edhe ETag. ETag përdoret kur ruani një dokument. Ky titull ruhet në klient dhe në rast të ri-aksesit në dokument, ai lejon shfletuesin të kontaktojë serverin me një kërkesë 'Nëse nuk përputhet' dhe serveri duhet, me vlerën e etiketës ETag, të përcaktojë nëse dokumenti (faqja) ka ndryshuar, dhe nëse jo, përgjigjuni me kodin '304 Nuk është modifikuar'.
Parametri Skadon(skadimi) (W3C Skadon) - i tregon shfletuesit se çfarë intervali kohor mund të konsiderohet që kopja e faqes në cache është e freskët dhe të mos kontaktojë fare serverin me kërkesa. Kjo është e përshtatshme për skedarët që e dini me siguri se nuk do të ndryshojnë për orën / ditën / muajin tjetër: për shembull, imazhi i sfondit të faqes.
Titujt e tjerë të HTTP:
HTTP_X_COMING_FROM
HTTP_COMING_FROM
HTTP_X_CLUSTER_CLIENT_IP
HTTP_XROXY_CONNECTION
HTTP_PROXY_CONNECTION
HTTP_USERAGENT_VIA - përfaqësues
HTTP_X_FORWARDED_FOR
HTTP_X_FORWARDED
HTTP_FORWARDED_FOR
Një shembull i analizimit të një kërkese HTTP
Një kërkesë HTTP përbëhet nga tre pjesë: një linjë kërkese (përgjigje), një seksion kokë, i ndjekur nga një trup opsional. Titujt janë tekst i thjeshtë, me çdo titull të ndarë nga tjetri me një karakter të linjës së re (\ r \ n), ndërsa trupi mund të jetë ose tekst ose të dhëna binare. Trupi është i ndarë nga kokat me dy vija të reja.
Kreu i kërkesës përbëhet nga linja kryesore (e parë) e pyetjes dhe linjat pasuese që përsosin pyetjen në linjën kryesore. Mund të mungojnë edhe rreshtat pasues.
Klienti fillon një transaksion si më poshtë:
Klienti komunikon me serverin duke përdorur numrin e portit të caktuar, numri i parazgjedhur i portit zyrtar është 80. Më pas klienti dërgon një kërkesë dokumenti duke specifikuar metodën, adresën e dokumentit dhe numrin e versionit HTTP. Për shembull në linjën kryesore të kërkesës GET /index.html HTTP / 1.1
përdoret metoda GET, e cila kërkon dokumentin index.html duke përdorur versionin 1.1 të HTTP.
Klienti dërgon informacionin e kokës (opsionale, kërkohet titulli i hostit) për t'i treguar serverit informacionin e konfigurimit të tij dhe formatet e dokumentit që mund të pranojë. Të gjitha informacionet e kokës renditen rresht pas rreshti, me një emër dhe vlerë në secilën rresht. Për shembull, titulli më poshtë, i dërguar nga klienti, përmban emrin dhe numrin e versionit të tij, si dhe informacione për disa nga llojet e dokumenteve të preferuara të klientit: Host: list.mail.ru Agjenti i përdoruesit: Mozilla / 5.0 (Ubuntu; X11 ; Linux x86_64; rv: 8.0) Gecko / 20100101 Firefox / 8.0 Prano: tekst / html, aplikacion / xhtml + xml, aplikacion / xml; q = 0.9, * / *; q = 0.8
Titulli përfundon me një rresht bosh.
Duke dërguar kërkesën dhe titujt, klienti mund të dërgojë të dhëna shtesë, për shembull, për skriptet CGI.
Serveri i përgjigjet kërkesës së klientit si më poshtë:
Pjesa e parë e përgjigjes së serverit është një linjë statusi që përmban tre fusha: versionin HTTP, kodin e statusit dhe përshkrimin. Fusha e versionit përmban numrin e versionit të HTTP që ky server po përdor për të dërguar përgjigjen. Kodi i statusit është një numër treshifror që tregon rezultatin e serverit që përpunon kërkesën e klientit. Përshkrimi pas kodit të statusit është thjesht tekst i lexueshëm nga njeriu që shpjegon kodin e statusit. Për shembull, shiriti i statusit HTTP / 1.1 304 Nuk është modifikuar
tregon se serveri po përdor HTTP 1.1 për përgjigjen. Kodi i statusit 304 do të thotë që klienti ka kërkuar dokumentin duke përdorur metodën GET, ka përdorur kokën If-Modified-Since ose If-None-Match dhe dokumenti nuk ka ndryshuar që nga ai moment.
Pas shiritit të statusit, serveri i dërgon klientit informacionin e kokës që përmban informacion për vetë serverin dhe dokumentin e kërkuar. Më poshtë është një titull shembulli: Data: Thu, 15 Dhjetor 2011 09:34:15 GMT Serveri: Apache / 2.2.21 (Debian) X-Powered-By: PHP / 5.3.8-1 + b1 Skadon: Pej, 19 nëntor 1981 08:52:00 GMT Cache-Control: pa dyqan, pa memorie, duhet të rivlerësohet, pas-kontroll = 0, kontroll paraprak = 0 Pragma: pa memorie Ndrysho: Prano-Encoding Content-Encoding: gzip Keep - Alive: timeout = 5, max = 100 Lidhja: Keep-Alive Content-Lloji: text / html; grup karakteresh = utf-8
Titulli përfundon me një rresht bosh.
Nëse kërkesa e klientit është e suksesshme, atëherë të dhënat e kërkuara dërgohen. Mund të jetë një kopje e një skedari ose prodhimi i një programi CGI. Nëse kërkesa e klientit nuk mund të plotësohet, të dhëna shtesë dërgohen në formën e një shpjegimi miqësor për përdoruesit se pse serveri nuk ishte në gjendje të përmbushte kërkesën.
Kodi i statusit HTTP
Kodi i statusit HTTPështë pjesë e rreshtit të parë të përgjigjes së serverit. Është një numër i plotë treshifror. Shifra e parë tregon klasën e gjendjes. Kodi i përgjigjes zakonisht pasohet nga një frazë shpjeguese në anglisht, e ndarë me një hapësirë, e cila i shpjegon personit arsyen e kësaj përgjigjeje të veçantë.
Klienti mund të mos i dijë të gjitha kodet e statusit, por është përgjegjësi e klientit të përgjigjet sipas klasës së kodit. Aktualisht, dallohen pesë klasa të kodeve të statusit:
200 OK(Mirë). Prezantuar në HTTP / 1.0. Kërkesë e suksesshme për burime. Nëse klienti ka kërkuar ndonjë të dhënë, atëherë ato janë në kokën dhe/ose trupin e mesazhit.
1xx: Informative. Kodet e informacionit të statusit që informojnë klientin se serveri është në proces të përpunimit të një kërkese. Përgjigja e klientit ndaj këtyre kodeve nuk kërkohet;
2xx: Sukses.
302 Gjetur(U gjet). Prezantuar në HTTP / 1.0. Dokumenti i kërkuar është përkohësisht i disponueshëm në një URI tjetër të specifikuar në kokën në fushën Vendndodhja.
404 Nuk u gjet. Prezantuar në HTTP / 1.0. Serveri e kuptoi kërkesën, por nuk gjeti një burim që përputhet në URI-në e specifikuar.
3xx: Ridrejtimi Kodet e klasës 3xx i tregojnë klientit të bëjë një kërkesë tjetër (zakonisht në një URI tjetër) për të përfunduar me sukses operacionin. Nga kjo klasë, pesë kodet 301, 302, 303, 305 dhe 307 u referohen drejtpërdrejt ridrejtimeve (ridrejtimeve). Serveri specifikon adresën në të cilën klienti duhet të bëjë një kërkesë në kokën Vendndodhja. Shumë klientë, kur ridrejtojnë me kodet 301 dhe 302, gabimisht aplikojnë metodën GET në burimin e dytë, pavarësisht se kërkesa e parë ishte me një metodë tjetër. Për të shmangur konfuzionin në versionin HTTP / 1.1, u prezantuan kodet 303 dhe 307 në vend të 302. Mënyra e kërkesës duhet të ndryshohet vetëm nëse serveri përgjigjet me 303. Në raste të tjera, kërkesa e radhës duhet bërë me metodën origjinale.
4xx: Gabim klienti. Klasa 4xx e kodeve ka për qëllim të tregojë gabime nga ana e klientit. Kur përdorni të gjitha metodat përveç HEAD, serveri duhet t'i kthejë përdoruesit një shpjegim hiperteksti në trupin e mesazhit.
5xx: Gabim serveri
Lidhje të ngjashme HTTP 1.1
HTTP / 2
HTTP / 2 (fillimisht HTTP / 2.0) është versioni i dytë kryesor i protokollit të rrjetit HTTP. Protokolli bazohet në SPDY (HTTP Compatible Protocol i zhvilluar nga Google).
Protokolli HTTP / 2 është binar. Krahasuar me standardin e mëparshëm, metodat e ndarjes së të dhënave në fragmente dhe transportimit të tyre ndërmjet serverit dhe klientit janë ndryshuar.
Në HTTP / 2, serveri ka të drejtë të dërgojë përmbajtje që nuk është kërkuar ende nga klienti. Kjo do t'i lejojë serverit të dërgojë menjëherë skedarë shtesë që shfletuesit do t'i nevojiten për të shfaqur faqet, pa pasur nevojë që shfletuesi të analizojë faqen kryesore dhe të kërkojë shtesat e nevojshme.
.) Për shkak të mundësisë së specifikimit të metodës së kodimit të mesazhit, klienti dhe serveri mund të shkëmbejnë të dhëna binare, megjithëse ky protokoll është tekstual.
Proxy servers
Historia e zhvillimit
HTTP / 0.9
Përveç metodës së zakonshme GET, ekziston edhe një dallim. Kërkesat e kushtëzuara GET përmbajnë If-Modified-Since, If-Match, If-Range dhe të ngjashme. GET-et e pjesshme përmbajnë Gamë në kërkesë. Rendi i ekzekutimit të kërkesave të tilla përcaktohet veçmas nga standardet.
KOKË
Ngjashëm me metodën GET, përveç që trupi mungon në përgjigjen e serverit. Një kërkesë HEAD përdoret zakonisht për të tërhequr meta të dhënat, për të kontrolluar nëse ekziston një burim (vlefshmëria e URL-së) dhe për të parë nëse ai ka ndryshuar që nga hera e fundit që është aksesuar.
Titujt e përgjigjes mund të ruhen në memorie të fshehtë. Nëse meta të dhënat e një burimi nuk përputhen me informacionin përkatës në cache, kopja e burimit shënohet si e vjetëruar.
POST
Përdoret për të transferuar të dhënat e përdoruesit në një burim të caktuar. Për shembull, në blogje, vizitorët zakonisht mund të fusin komentet e tyre mbi postimet në një formë HTML, pas së cilës ato postohen në server dhe vendosen në faqe. Në këtë rast, të dhënat e transmetuara (në shembullin me blog - teksti i komentit) përfshihen në trupin e kërkesës. Po kështu, duke përdorur metodën POST zakonisht ngarkon skedarë në server.
Ndryshe nga metoda GET, metoda POST nuk konsiderohet idempotente, domethënë, përsëritja e të njëjtave kërkesa POST disa herë mund të sjellë rezultate të ndryshme (për shembull, pas çdo paraqitjeje komenti, do të shfaqet një kopje e këtij komenti).
Nëse rezultati i ekzekutimit është 200 (Ok), mesazhi për rezultatin e ekzekutimit të kërkesës duhet të përfshihet në trupin e përgjigjes. Nëse është krijuar një burim, serveri DUHET të kthejë një përgjigje 201 (Krijuar) me URI-në e burimit të ri në kokën e vendndodhjes.
Mesazhi i përgjigjes së serverit në metodën POST nuk është memorizuar.
VENDOSJE
Përdoret për të shkarkuar përmbajtjen e kërkesës në URI të specifikuar në kërkesë. Nëse burimi nuk ekzistonte në URI të specifikuar, serveri e krijon atë dhe kthen statusin 201 (Krijuar). Nëse burimi është ndryshuar, serveri kthen 200 (Ok) ose 204 (Pa përmbajtje). Serveri NUK DUHET të injorojë titujt e pavlefshëm të Përmbajtjes-* të dërguara nga klienti së bashku me mesazhin. Nëse ndonjë prej këtyre titujve nuk mund të njihet ose nuk është i vlefshëm në kushtet aktuale, atëherë duhet të kthehet një kod gabimi 501 (I pazbatuar).
Dallimi themelor midis metodave POST dhe PUT është në kuptimin e qëllimit të URI-ve të burimeve. Metoda POST supozon se përmbajtja e transmetuar nga klienti do të përpunohet në URI të specifikuar. Duke përdorur PUT, klienti supozon se përmbajtja që ngarkohet përputhet me burimin në URI-në e dhënë.
Mesazhet e përgjigjes së serverit në metodën PUT nuk ruhen në memorie të fshehtë.
PATCH
Ngjashëm me PUT, por vlen vetëm për një pjesë të një burimi.
FSHIJE
Heq burimin e specifikuar.
GJURME
Kthen kërkesën e marrë në mënyrë që klienti të mund të shohë se çfarë informacioni po shtojnë ose ndryshojnë serverët e ndërmjetëm në kërkesë.
LIDHJE
Lidh burimin e specifikuar me të tjerët.
LIDHJE
Heq lidhjen e burimit të specifikuar me të tjerët.
LIDH
Konverton lidhjen e kërkesës në një tunel transparent TCP / IP, zakonisht për të lehtësuar krijimin e një lidhjeje të sigurt SSL përmes një përfaqësuesi të pakriptuar.
Kodet e statusit
Kodi i statusit është pjesë e rreshtit të parë të përgjigjes së serverit. Është një numër i plotë me tre arabisht. Shifra e parë tregon klasën e gjendjes. Kodi i përgjigjes zakonisht pasohet nga një frazë shpjeguese në anglisht, e ndarë me një hapësirë, e cila i shpjegon personit arsyen e kësaj përgjigjeje të veçantë. Shembuj:
201 Uebfaqja e krijuar 403 Qasja lejohet vetëm për përdoruesit e regjistruar 507 Hapësirë ruajtëse e pamjaftueshme
Klienti mëson nga kodi i përgjigjes për rezultatet e kërkesës së tij dhe përcakton se çfarë veprimesh duhet të ndërmarrë më pas. Seti i kodeve të statusit është standard dhe përshkruhet në RFC-të përkatëse. Futja e kodeve të reja duhet të bëhet vetëm pas konsultimit me IETF. Klienti mund të mos i dijë të gjitha kodet e statusit, por është përgjegjësi e klientit të përgjigjet sipas klasës së kodit.
Aktualisht ekzistojnë pesë klasa të kodeve të statusit.
1xx Informative (rus. Informative)Kjo klasë përmban kode që informojnë për procesin e transmetimit. Në HTTP / 1.0, mesazhet me kode të tilla duhet të injorohen. Në HTTP / 1.1, klienti duhet të jetë i përgatitur të pranojë këtë klasë mesazhi si një përgjigje normale, por nuk ka nevojë të dërgojë asgjë në server. Vetë mesazhet nga serveri përmbajnë vetëm vijën fillestare të përgjigjes dhe, nëse kërkohet, disa fusha të kokës specifike për përgjigjen. Proxy serverët duhet të dërgojnë mesazhe të tilla më tej nga serveri te klienti.
2xx Sukses (rus. Sukses)Mesazhet e kësaj klase informojnë për rastet e pranimit dhe përpunimit të suksesshëm të kërkesës së klientit. Në varësi të statusit, serveri mund të transmetojë gjithashtu titujt dhe trupin e mesazhit.
Ridrejtimi 3xx (rus. Ridrejtimi )Kodet e klasës 3xx informojnë klientin se duhet bërë një kërkesë tjetër (zakonisht në një URI të ndryshme) në mënyrë që të përfundojë me sukses operacioni. Nga kjo klasë, pesë kode,,, dhe i referohen drejtpërdrejt ridrejtimeve (ridrejtimeve). Serveri specifikon adresën në të cilën klienti duhet të bëjë një kërkesë në kokën Vendndodhja. Kjo lejon përdorimin e fragmenteve në URI të synuar.
4xx Gabim klienti (rus. Gabim klienti)Klasa 4xx e kodeve ka për qëllim të tregojë gabime nga ana e klientit. Kur përdorni të gjitha metodat përveç HEAD, serveri duhet t'i kthejë përdoruesit një shpjegim hiperteksti në trupin e mesazhit.
Për të mësuar përmendësh vlerat e kodeve nga 400 në 417, ekzistojnë teknika të mnemonikës ilustruese
Gabim serveri 5xx (rus. gabim serveri)Kodet 5xx ndahen për rastet e funksionimit të pasuksesshëm për shkak të fajit të serverit. Për të gjitha situatat përveç përdorimit të metodës HEAD, serveri duhet të përfshijë një shpjegim në trupin e mesazhit që klienti do t'i shfaqë përdoruesit.
Titujt
Trupi i mesazhit
Trupi i mesazhit HTTP (trupi i mesazhit), nëse është i pranishëm, përdoret për të përcjellë trupin e objektit të lidhur me kërkesën ose përgjigjen. Trupi i mesazhit ndryshon nga trupi i entitetit vetëm kur aplikohet kodimi i transferimit, siç tregohet nga fusha e titullit Transfer-Encoding.
Mesazh-trup = entitet-trup |
Fusha Transfer-Encoding DUHET të përdoret për të treguar çdo kodim transferimi të aplikuar nga një aplikacion për të siguruar transferimin e sigurt dhe të saktë të mesazhit. Fusha Transfer-Encoding është një veti e mesazhit, jo e objektit, dhe kështu mund të shtohet ose hiqet nga çdo aplikacion në zinxhirin e kërkesës/përgjigjes.
Rregullat që rregullojnë vlefshmërinë e një trupi mesazhi në një mesazh janë të ndryshme për kërkesat dhe përgjigjet.
Prania e një trupi mesazhi në një kërkesë tregohet duke shtuar një fushë të titullit të gjatësisë së përmbajtjes ose të kodimit të transferimit në titujt e kërkesës. Një trup mesazh MUND të shtohet në një kërkesë vetëm kur metoda e kërkesës pranon një trup-entitet.
Nëse trupi i mesazhit përfshihet apo jo në mesazhin e përgjigjes varet nga metoda e kërkesës dhe nga kodi i statusit të përgjigjes. Të gjitha përgjigjet ndaj një kërkese me metodën HEAD DUHET të mos përfshijnë një trup mesazhi, edhe nëse fushat e titullit të entitetit janë të pranishme për t'ju bërë të besoni se entiteti është i pranishëm. Çdo përgjigje me kodet e statusit 1xx (Informative), 204 (Pa përmbajtje) dhe 304 (Pa Modifikuar) do të përmbajë një trup mesazhi. Të gjitha përgjigjet e tjera përmbajnë trupin e mesazhit, edhe nëse është me gjatësi zero.
Shembuj të dialogëve HTTP
Kërkesë normale GET
Ekzistojnë dy lloje kryesore të miratimeve:
- Menaxhuar nga serveri (eng. Drejtuar nga serveri).
- Menaxhuar nga klienti (eng. I drejtuar nga agjentët).
Të dy llojet mund të përdoren në të njëjtën kohë ose secili prej tyre veç e veç.
Specifikimi kryesor i protokollit (RFC 2616) gjithashtu thekson të ashtuquajturin negocim transparent (eng. Negocim transparent) si kombinim i preferuar i të dy llojeve. Mekanizmi i fundit nuk duhet të ngatërrohet me teknologjinë e pavarur të negocimit të përmbajtjes transparente (TCN, rus. Negocim transparent për përmbajtjen , shih RFC 2295), i cili nuk është pjesë e protokollit HTTP, por mund të përdoret me të. Të dy kanë dallime domethënëse në parimin e funksionimit dhe vetë kuptimin e fjalës "transparente" (transparente). Në specifikimin HTTP, transparenca nënkupton që procesi është i padukshëm për klientin dhe serverin, dhe në teknologjinë TCN, transparenca nënkupton disponueshmërinë e një liste të plotë opsionesh burimesh për të gjithë pjesëmarrësit në procesin e shpërndarjes së të dhënave.
Serveri i menaxhuar
Nëse ka shumë versione të një burimi, serveri mund të analizojë titujt e kërkesës së klientit për të kthyer atë që mendon se është më e përshtatshme. Analizat kryesore janë titujt Accept, Accept-Charset, Accept-Encoding, Accept-Languages dhe User-Agent. Është e dëshirueshme që serveri të përfshijë kokën Vary në përgjigje, duke treguar parametrat me të cilët përmbajtja dallohet nga URI-ja e kërkuar.
Vendndodhja gjeografike e klientit mund të përcaktohet nga adresa IP e largët. Kjo është e mundur për shkak të faktit se adresat IP, si emrat e domeneve, janë të regjistruara për një person ose organizatë specifike. Gjatë regjistrimit, tregohet rajoni në të cilin do të përdoret hapësira e dëshiruar e adresës. Këto të dhëna janë të disponueshme publikisht, dhe në internet mund të gjeni bazat përkatëse të të dhënave të shpërndara lirisht dhe modulet e gatshme të softuerit për të punuar me to (duhet të përqendroheni në fjalët kyçe "Geo IP").
Duhet mbajtur mend se kjo metodë është në gjendje të përcaktojë vendndodhjen sa më shumë që të jetë e mundur me një saktësi të qytetit (prandaj përcaktohet vendi). Në këtë rast, informacioni është i rëndësishëm vetëm në kohën e regjistrimit të hapësirës së adresave. Për shembull, nëse një ofrues i Moskës regjistron një sërë adresash që tregojnë Moskën dhe fillon të ofrojë akses për klientët nga rajoni më i afërt i Moskës, atëherë pajtimtarët e tij mund të vëzhgojnë në disa site se ata janë nga Moska, dhe jo nga Krasnogorsk ose Dzerzhinsky.
Negocimi i drejtuar nga serveri ka disa disavantazhe:
- Serveri supozon vetëm se cili opsion është më i preferuari për përdoruesin përfundimtar, por nuk mund të dijë saktësisht se çfarë nevojitet për momentin (për shembull, versioni në rusisht ose anglisht).
- Ka shumë tituj të grupit Prano, por pak burime me opsione të shumta. Si rezultat, pajisja është e mbingarkuar.
- Cache e përbashkët krijon një kufizim në aftësinë për të lëshuar të njëjtën përgjigje ndaj kërkesave identike nga përdorues të ndryshëm.
- Kalimi i titujve të Prano mund të zbulojë gjithashtu disa informacione rreth preferencave të tij, si gjuhët e përdorura, shfletuesi, kodimi.
I drejtuar nga klienti
Në këtë rast, lloji i përmbajtjes përcaktohet vetëm në anën e klientit. Për ta bërë këtë, serveri kthen me një kod statusi 300 (Zgjedhje të shumëfishta) ose 406 (Nuk pranohet) një listë opsionesh, midis të cilave përdoruesi zgjedh atë të duhurin. Negocimi i drejtuar nga klienti është i mirë kur përmbajtja ndryshon në parametrat më të zakonshëm (për shembull, gjuha dhe kodimi) dhe përdoret një cache publike.
Disavantazhi kryesor është ngarkesa shtesë, pasi duhet të bëni një kërkesë shtesë për të marrë përmbajtjen e dëshiruar.
Miratimi transparent
Ky negocim është plotësisht transparent për klientin dhe serverin. Në këtë rast, përdoret një cache e përbashkët, e cila përmban një listë opsionesh si për negociatat e drejtuara nga klienti. Nëse cache i kupton të gjitha këto opsione, atëherë ai e bën vetë zgjedhjen, si në negociatat e drejtuara nga serveri. Kjo zvogëlon ngarkesën në serverin fillestar dhe eliminon një kërkesë shtesë nga klienti.
Specifikimi themelor HTTP nuk detajon mekanizmin transparent të negociatave.
Përmbajtje e shumëfishtë
Protokolli HTTP mbështet transferimin e shumë entiteteve brenda një mesazhi të vetëm. Për më tepër, entitetet mund të transferohen jo vetëm në formën e një sekuence me një nivel të vetëm, por në formën e një hierarkie me folenë e elementeve në njëri-tjetrin. Llojet e mediave me shumë pjesë / * përdoren për të treguar përmbajtje të shumëfishtë. Puna me lloje të tilla kryhet sipas rregullave të përgjithshme të përshkruara në RFC 2046 (përveç nëse specifikohet ndryshe nga një lloj i veçantë media). Nëse marrësi nuk di të punojë me llojin, atëherë ai e trajton atë në të njëjtën mënyrë si shumëpjesësh / të përzier.
Parametri kufitar tregon ndarjen midis llojeve të ndryshme të mesazheve të transmetuara. Për shembull, parametri DestAddress i kaluar nga formulari kalon vlerën e adresës së postës elektronike dhe elementi pasues AttachedFile1 dërgon përmbajtjen binare të imazhit në formatin .jpg
Nga ana e serverit, mesazhe të shumta me përmbajtje mund të dërgohen në përgjigje të pjesëve të shumta të burimeve të kërkuara. Në këtë rast, përdoret lloji i medias multipart / byteranges.
Në anën e klientit, kur dorëzoni një formular HTML, përdoret më shpesh metoda POST. Shembull tipik: Dërgoni faqet e emailit me bashkëngjitje skedarësh. Kur dërgoni një letër të tillë, shfletuesi gjeneron një mesazh të llojit të të dhënave shumëpjesëshe / formës, duke u integruar në të si pjesë të veçanta të futura nga përdoruesi, subjektin e letrës, adresën e marrësit, vetë tekstin dhe skedarët e bashkangjitur:
POST /send-message.html HTTP / 1.1 Pritësi: mail.example.com Referuesi: http://mail.example.com/send-message.html Agjenti i përdoruesit: BrowserForDummies / 4.67b Lloji i përmbajtjes: shumëpjesësh / formë- të dhëna; kufiri = "Asrf456BGe4h" Gjatësia e përmbajtjes: (madhësia totale, duke përfshirë kokat e fëmijëve) Lidhja: Keep-live Keep-Alive: 300 (vijë bosh) (preambula mungon) --Asrf456BGe4h Përmbajtja-Dispozita: forma-të dhënat; emri = "Destadresa" (vijë bosh) [email i mbrojtur]--Asrf456BGe4h Përmbajtja-Dispozita: forma-të dhënat; emri = "Titulli i mesazhit" (vijë bosh) jam i indinjuar --Asrf456BGe4h Përmbajtja-Dispozita: forma-të dhëna; emri = "Teksti i mesazhit" (vijë bosh) Përshëndetje Vasily! Luani yt i zbutur që la me mua javën e kaluar ma copëtoi të gjithë divanin. Ju lutemi kthejeni atë së shpejti! Bashkangjitur dy foto me pasoja. --Asrf456BGe4h Përmbajtja-Dispozita: forma-të dhënat; emri = "AttachedFile1"; emri i skedarit = "horror-photo-1.jpg" Lloji i përmbajtjes: imazh / jpeg (vijë bosh) (përmbajtja binare e fotos së parë) --Asrf456BGe4h Përmbajtja-Dispozita: forma-të dhënat; emri = "AttachedFile2"; emri i skedarit = "horror-photo-2.jpg" Lloji i përmbajtjes: imazh / jpeg (vijë bosh) (përmbajtja binare e fotos së dytë) --Asrf456BGe4h-- (mungon epilogu)
Në shembull, në titujt Content-Disposition, parametri i emrit përputhet me atributin e emrit në etiketat HTML dhe