Zgjatja e protokollit HTTP. Bazat e aplikacionit në ueb

Ne kemi publikuar një libër të ri, Marketingu i përmbajtjes në mediat sociale: Si të futeni brenda kokës së ndjekësve tuaj dhe t'i bëni ata të dashurohen me markën tuaj.

Abonohu

HTTP është ajo që lejon transferimin e të dhënave. Fillimisht, ajo u krijua për dërgimin dhe marrjen e dokumenteve që përmbajnë lidhje brenda për të bërë kalimin në burime të palëve të treta.

Shkurtesa lexon "HyperText Transfer Protocol", që përkthyer do të thotë "protokoll transferimi". HTTP i përket grupit 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 flisni mirë gjuhën. Për të deshifruar mesazhin, përdorni një fjalor. Duke kuptuar thelbin, ju i përgjigjeni të huajit në Rusisht dhe i dërgoni përgjigjen. I huaji merr përgjigjen dhe me ndihmën e një përkthyesi deshifron mesazhin. Për të thjeshtuar të gjithë mekanizmin, protokollet e internetit HTTP kryejnë funksionin e një përkthyesi. 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 transmeton 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 lëshon një komandë të re dhe gjithçka përsëritet.

Kështu, protokolli HTTP ju lejon të shkëmbeni informacion midis aplikacioneve të ndryshme të përdoruesve dhe serverëve të veçantë të internetit, si dhe të lidheni me burimet e uebit (zakonisht shfletuesit). Sot, protokolli i përshkruar siguron funksionimin e të gjithë rrjetit. 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, për shembull, WebDAV ose SOAP. Në këtë rast, protokolli është një mjet transporti. Shumë programe gjithashtu mbështeten në HTTP si mjetin kryesor për shkëmbimin e informacionit. 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 TCP 80 për këtë qëllim. Nëse porti nuk është specifikuar, softueri i klientit do të përdorë portin 80 të tipit TCP 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.

Cili është ndryshimi midis HTTP dhe HTTPS

Dallimi mund të zbulohet edhe nga dekodimi i shkurtesave. HTTPS do të thotë Siguria e Protokollit të Transferimit të Hypertext. Kështu, HTTP është një protokoll i pavarur dhe HTTPS është një shtesë për ta mbrojtur atë. HTTP transmeton informacion të pambrojtur, ndërsa HTTPS siguron 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ë sistemit të pagesave.

Cilat janë rreziqet e transmetimit të të dhënave të pambrojtura? Një program interceptor mund t'i transferojë ato te sulmuesit në çdo kohë. HTTPS ka një organizim teknik kompleks, i cili ju lejon të mbroni me besueshmëri informacionin dhe të eliminoni mundësinë e aksesit të paautorizuar në të. Dallimi qëndron në portet. HTTPS zakonisht funksionon në portin 443.

Kështu, HTTP përdoret për transferimin e të dhënave dhe HTTPS lejon transferimin 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 i përdorur 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".

Ky funksion është veçanërisht i rëndësishëm për shkëmbimin e informacionit nëpërmjet WebSocket (ka specifikimin RFC 6455, që ju lejon të shkëmbeni të dhëna në çdo kohë, pa kërkesa të panevojshme HTTP). Për të migruar në WebSocket, një përdorues dërgon një kërkesë me titullin Upgrade dhe vlerën "websocket". Më pas, serveri përgjigjet me "101 Protokolle Ndërrimi". Pas këtij momenti, fillon transferimi i informacionit përmes WebSocket.

22.04.05 13625

Qëllimi i protokollit

Protokolli i Transferimit të HyperText (HTTP)është një protokoll i nivelit të lartë (d.m.th., i nivelit të aplikacionit) që siguron shpejtësitë e nevojshme të transferimit të të dhënave të kërkuara për sistemet e informacionit hipermedial të shpërndarë. HTTP është përdorur nga projekti World Wide Web që nga viti 1990.

Sistemet praktike të informacionit kërkojnë më shumë se rikthim, modifikim dhe shënim primitiv të të dhënave. HTTP/1.0 ofron një grup të hapur metodash që mund të përdoren për të specifikuar qëllimet e një kërkese. Ato janë ndërtuar mbi një disiplinë referimi, ku një Identifikues Universal i Burimeve (URI), në formën e një vendndodhjeje (URL) ose emrit (URN), përdoret për të treguar burimin në të cilin duhet të zbatohet një metodë e caktuar. Formati i mesazhit është i ngjashëm me Postën në Internet ose Zgjatjet e Postës në Internet me shumë qëllime (MIME).

HTTP/1.0 përdoret gjithashtu për komunikime ndërmjet shfletuesve të ndryshëm të përdoruesve dhe portave që i japin akses hipermedias në protokollet ekzistuese të internetit si SMTP, NNTP, FTP, Gopher dhe WAIS. HTTP/1.0 është krijuar për të lejuar porta të tilla të transferojnë të dhëna përmes serverëve proxy pa asnjë humbje duke përdorur këto protokolle të mëparshme.

Struktura e Përgjithshme

HTTP bazohet në një paradigmë kërkesë/përgjigje. Programi kërkues (zakonisht i quajtur klient) krijon një lidhje me programin e shërbimit marrës (zakonisht i quajtur server) dhe i dërgon një kërkesë serverit në formën e mëposhtme: metoda e kërkesës, URI, versioni i protokollit, i ndjekur nga një mesazh i ngjashëm me MIME që përmban informacione për kontrollin e kërkesës, informacione për klientin dhe ndoshta për trupin e mesazhit. Serveri përgjigjet me një mesazh që përmban një varg statusi (përfshirë versionin e protokollit dhe një kod statusi suksesi ose gabimi), i ndjekur nga një mesazh i ngjashëm me MIME që përfshin informacione rreth serverit, metainformacion për përmbajtjen e përgjigjes dhe ndoshta përgjigjen vetë trupi. Duhet të theksohet se një program mund të jetë njëkohësisht klient dhe server. Përdorimi i këtyre termave në këtë tekst i referohet vetëm rolit të kryer nga programi gjatë atij sesioni të caktuar komunikimi, dhe jo funksioneve të përgjithshme të programit.

Në internet, komunikimet zakonisht bazohen në protokollet TCP/IP. Për WWW, numri i paracaktuar i portit është TCP 80, por mund të përdoren edhe numra të tjerë portash - kjo nuk përjashton mundësinë e përdorimit të HTTP si protokoll të nivelit të lartë.

Për shumicën e aplikacioneve, një sesion hapet nga klienti për çdo kërkesë dhe mbyllet nga serveri pasi të jetë përfunduar përgjigja ndaj kërkesës. Megjithatë, kjo nuk është një veçori e protokollit. Si klienti ashtu edhe serveri duhet të jenë në gjendje të mbyllin seancën e komunikimit, për shembull, si rezultat i disa veprimeve të përdoruesit. Në çdo rast, një shkëputje e inicuar nga secila palë përfundon kërkesën aktuale, pavarësisht nga statusi i saj.

Koncepte të përgjithshme

Një kërkesë është një mesazh i dërguar nga një klient në një server.
Rreshti i parë i këtij mesazhi përfshin metodën që do të zbatohet në burimin e kërkuar, identifikuesin e burimit dhe versionin e protokollit për t'u përdorur. Për pajtueshmërinë me protokollin HTTP/0.9, ekzistojnë dy formate të kërkesave HTTP:

Pyetje = Simple-Query | Kërkesë e plotë Simple-quest = "MERRNI" PS Requested-URI CRLF Kërkesë e plotë = Line-Status *(General-Header | Request-Header | Content-Header) CRLF [Kërkesë-Përmbajtja]

Nëse një server HTTP/1.0 merr një kërkesë të thjeshtë, ai duhet të përgjigjet me një përgjigje të thjeshtë HTTP/0.9. Një klient HTTP/1.0 i aftë për të përpunuar një përgjigje të plotë nuk duhet të dërgojë kurrë një kërkesë të thjeshtë.

Statusi i linjës

Linja e statusit fillon me një rresht me emrin e metodës, e ndjekur nga URI-ja e kërkesës dhe versioni i protokollit që përdoret. Linja e statusit përfundon me karaktere CRLF. Elementet e linjës ndahen me hapësira (SP). Karakteret LF dhe CR nuk lejohen në vijën e statusit, me përjashtim të sekuencës mbyllëse CRLF.

String-Status = Metoda SP Kërkesë URI SP Version-HTTP CRLF

Duhet të theksohet se ndryshimi midis linjës së statusit të kërkesës së plotë dhe linjës së statusit të kërkesës së thjeshtë është prania e fushës HTTP-Version.

Metoda

Fusha Metodë specifikon metodën që duhet të zbatohet në burimin e identifikuar nga URI-ja e kërkesës. Emrat e metodave janë të ndjeshme ndaj shkronjave të vogla. Lista ekzistuese e metodave mund të zgjerohet.

Metoda = "MERRNI" | "KOKË" | "PUT" | "POST" | "FSHI" | "LINK" | "UNLIDH" | shtesë-metodë

Lista e metodave të lejuara nga një burim i caktuar mund të specifikohet në fushën Titull-Përmbajtja e "Pikëve". Megjithatë, klienti informohet gjithmonë nga serveri nëpërmjet kodit të statusit të përgjigjes nëse një metodë e caktuar lejohet për burimin e specifikuar, pasi vlefshmëria e metodave të ndryshme mund të ndryshojë në mënyrë dinamike. Nëse një metodë e caktuar është e njohur për serverin, por nuk lejohet për burimin e specifikuar, serveri DUHET të kthejë një kod statusi "405 Metoda nuk lejohet" dhe një kod statusi "501 nuk është zbatuar" nëse metoda nuk dihet. ose nuk mbështetet nga serveri i caktuar. Metodat e zakonshme HTTP/1.0 janë përshkruar më poshtë.

MARR

Metoda GET përdoret për të tërhequr çdo informacion të identifikuar nga URI-ja e kërkesës. Nëse URI-ja e kërkesës i referohet një procesi që prodhon të dhëna, përgjigja do të jetë të dhënat e gjeneruara nga ai proces, jo vetë kodi i procesit (përveç nëse është prodhimi i procesit).

Metoda GET ndryshohet në "GET me kusht" nëse mesazhi i kërkesës përfshin një fushë të kokës "Nëse-Modifikuar-Që". Në përgjigje të një GET të kushtëzuar, trupi i burimit të kërkuar transmetohet vetëm nëse ai është modifikuar që nga data e specifikuar në titullin "Nëse-Modifikuar-Që". Algoritmi për përcaktimin e kësaj përfshin rastet e mëposhtme:

• Nëse kodi i statusit të përgjigjes së kërkesës është i ndryshëm nga "200 OK", ose data e specifikuar në fushën e titullit "If-Modified-Since" është e pasaktë, përgjigja do të jetë identike me përgjigjen ndaj një kërkese normale GET.
• Nëse burimi ka ndryshuar që nga data e specifikuar, përgjigja do të jetë gjithashtu identike me përgjigjen ndaj një kërkese të rregullt GET.
• Nëse burimi nuk është modifikuar që nga data e specifikuar, serveri do të kthejë një kod statusi "304 Nuk është modifikuar".

Përdorimi i metodës së kushtëzuar GET ka për qëllim shkarkimin e rrjetit, pasi ju lejon të shmangni transmetimin e informacionit të tepërt përmes rrjetit.

KOKË

Metoda HEAD është e ngjashme me metodën GET, përveç që serveri nuk kthen një Trup përgjigjeje në përgjigje. Informacioni meta i përmbajtur në titujt HTTP të një përgjigjeje ndaj një kërkese HEAD duhet të jetë identik me informacionin e përmbajtur në titujt HTTP të një përgjigjeje ndaj një kërkese GET. Kjo metodë mund të përdoret për të marrë metainformacion rreth një burimi pa e transmetuar vetë burimin përmes rrjetit. Metoda "KOKË e kushtëzuar", e ngjashme me GET me kusht, është e papërcaktuar.

POST

Metoda POST përdoret për t'i kërkuar serverit që të pranojë informacionin e përfshirë në kërkesë si në varësi të burimit të specifikuar në vijën e statusit në fushën "Kërkesë URI". Metoda POST është krijuar për të lejuar përdorimin e një metode të zakonshme për funksionet e mëposhtme:

• Abstrakt i burimeve ekzistuese
• Shtimi i mesazheve në grupe lajmesh, lista postare ose grupe të ngjashme artikujsh
• Dorëzimi i blloqeve të të dhënave në proceset e përpunimit të të dhënave
• Zgjerimi i bazave të të dhënave përmes një operacioni shtojcë

Funksioni aktual i kryer nga metoda POST përcaktohet nga serveri dhe zakonisht varet nga URI-ja e kërkesës. Informacioni që shtohet trajtohet si një vartës i URI-së së specifikuar në të njëjtin kuptim që një skedar është në varësi të drejtorisë në të cilën ndodhet, një artikull i ri është në varësi të grupit të lajmeve të cilit i shtohet, një hyrje është në varësi të bazën e të dhënave.

Klienti mund të propozojë një URI për të identifikuar burimin e ri duke përfshirë një titull "URI" në kërkesë. Megjithatë, serveri duhet ta trajtojë këtë URI vetëm si një aluzion dhe mund ta ruajë trupin e kërkesës nën një URI të ndryshme ose pa URI fare.

Nëse një burim i ri është krijuar si rezultat i përpunimit të një kërkese POST, përgjigja duhet të ketë një kod statusi "201 Krijuar" dhe të përmbajë URI-në e burimit të ri.

VENDOSJE

Metoda PUT kërkon që serveri të ruajë Trupin e Kërkesës nën një URI të barabartë me URI-në e kërkesës. Nëse URI-ja e kërkesës i referohet një burimi tashmë ekzistues, Trupi i Kërkesës duhet të trajtohet si një version i modifikuar i atij burimi. Nëse burimi i referuar nga URI-ja e kërkesës nuk ekziston dhe URI-ja e dhënë mund të konsiderohet një përshkrim për një burim të ri, serveri mund të krijojë një burim me URI-në e dhënë. Nëse është krijuar një burim i ri, serveri duhet të informojë klientin kërkues përmes një përgjigjeje me kodin e statusit "201 Krijuar". Nëse një burim ekzistues është modifikuar, një përgjigje "200 OK" duhet të dërgohet për të informuar klientin se operacioni përfundoi me sukses. Nëse një burim me URI të specifikuar nuk mund të krijohet ose modifikohet, duhet të dërgohet një mesazh gabimi i duhur.

Dallimi themelor midis metodave POST dhe PUT është kuptimi i ndryshëm i fushës Request URI. Për metodën POST, kjo URI specifikon një burim që do të menaxhojë informacionin e përfshirë në trupin e kërkesës si një shtojcë. Burimi mund të jetë një proces përpunimi i të dhënave, një portë për në ndonjë protokoll tjetër ose një burim i veçantë që lejon shënime. Në të kundërt, URI për një kërkesë PUT identifikon informacionin që përmban Kërkesa-Përmbajtja. Përdoruesi i kërkesës PUT e di saktësisht se çfarë URI synon të përdorë, dhe marrësi i kërkesës nuk duhet të përpiqet ta zbatojë kërkesën në ndonjë burim tjetër.

FSHIJE

Metoda DELETE përdoret për të fshirë burimet e identifikuara nga një URI e kërkesës. Rezultatet e kësaj metode në server mund të ndryshohen përmes ndërhyrjes njerëzore (ose ndonjë mjeti tjetër). Në parim, klienti nuk mund të jetë kurrë i sigurt se operacioni i fshirjes ka përfunduar, edhe nëse kodi i statusit i dërguar nga serveri tregon se veprimi ishte i suksesshëm. Megjithatë, serveri nuk duhet të raportojë suksesin derisa, në kohën e përgjigjes, të jetë gati të fshijë burimin në fjalë ose ta zhvendosë atë në një zonë të paarritshme.

LIDHJE

Metoda LINK vendos marrëdhënie midis burimit ekzistues të specifikuar në URI-në e kërkesës dhe burimeve të tjera ekzistuese. Dallimi midis metodës LINK dhe metodave të tjera që lejojnë vendosjen e lidhjeve midis dokumenteve është se metoda LINK nuk lejon kalimin e Trupit të Kërkesës në një kërkesë dhe se si rezultat i kësaj metode nuk krijohen burime të reja.

LIDHJE

Metoda UNLINK heq një ose më shumë lidhje lidhjesh për burimin e specifikuar në URI-në e kërkesës. Këto marrëdhënie mund të vendosen duke përdorur metodën LINK ose ndonjë metodë tjetër që mbështet kokën "Link". Heqja e një lidhjeje në një burim nuk do të thotë që burimi pushon së ekzistuari ose bëhet i padisponueshëm për referenca të ardhshme.

Fushat e Kërkesës-Header

Fushat Request-Header lejojnë klientin t'i kalojë serverit informacion shtesë në lidhje me kërkesën dhe për vetë klientin.

Kërkesë-Header = Prano | Prano-Charset | Prano-Enkodimi | Prano-Gjuha | Autorizimi | Nga | Nëse-Modifikuar-Që nga | Pragma | Referues | Përdoruesi-Agjent | zgjerim-kokë

Për më tepër, titujt shtesë mund të përcaktohen përmes mekanizmit të zgjerimit; aplikacionet që nuk i njohin ato duhet t'i trajtojnë këto tituj si Përmbajtje Header.

Disa nga fushat e kokës së kërkesës do të diskutohen më poshtë.

Nga

Nëse fusha Nga është e pranishme, ajo duhet të përmbajë adresën e plotë të postës elektronike të përdoruesit që kontrollon programin e agjentit që bën kërkesat. Kjo adresë duhet të specifikohet në formatin e përcaktuar në RFC 822. Formati i kësaj fushe është: From = "From" ":" specifikimi i adresës. Për shembull:

Nga: [email i mbrojtur]

Kjo fushë mund të përdoret për funksionet e hyrjes, si dhe për të identifikuar burimin e kërkesave të pasakta ose të padëshiruara. Nuk duhet të përdoret si një formë e paklasifikuar e kontrollit të aksesit. Interpretimi i kësaj fushe është se kërkesa që përpunohet bëhet në emër të përdoruesit të caktuar, i cili pranon përgjegjësinë për metodën e përdorur. Në veçanti, agjentët e robotëve duhet të përdorin këtë titull në mënyrë që personi përgjegjës për robotin të mund të kontaktohet nëse shfaqen probleme. Adresa e postës në internet e treguar në këtë fushë nuk duhet të përputhet me adresën e hostit nga i cili është dërguar kjo kërkesë. Kurdoherë që është e mundur, adresa duhet të jetë një adresë interneti e aksesueshme, pavarësisht nëse është në të vërtetë një adresë e-mail në internet ose një përfaqësim i një e-mail interneti të një adrese nga sisteme të tjera postare.

Shënim: Një klient nuk duhet të përdorë fushën Nga titulli pa lejen e përdoruesit, pasi kjo mund të bie ndesh me interesat e tij private ose me sistemin e tij lokal të sigurisë. Rekomandohet fuqimisht që përdoruesit t'i jepet opsioni për të çaktivizuar, aktivizuar ose modifikuar këtë fushë në çdo kohë përpara se të bëjë një kërkesë.

Nëse-Modifikuar-Që

Fusha e kokës If-Modified-Since përdoret me metodën GET për ta kushtëzuar: nëse burimi i kërkuar nuk ka ndryshuar në kohën e specifikuar në këtë fushë, një kopje e atij burimi nuk do të kthehet nga serveri; në vend të kësaj, do të kthehet një përgjigje "304 e pa modifikuar" pa një organ të përgjigjes.

If-Modified-Since = "If-Modified-Since" ":" Data HTTP

Shembull i përdorimit të një titulli:

Qëllimi i kësaj veçorie është të mundësojë përditësimin efikas të informacionit të cache-it lokal me një minimum informacioni të transferuar. I njëjti rezultat mund të arrihet duke përdorur metodën HEAD të ndjekur nga një GET nëse serveri ka treguar se përmbajtja e dokumentit ka ndryshuar.

Përdorues-Agjent

Fusha e titullit User-Agent përmban informacion në lidhje me agjentin e përdoruesit që dërgoi kërkesën. Kjo fushë përdoret për statistika, gjurmimin e gabimeve të protokollit dhe njohjen automatike të agjentëve të përdoruesit. Edhe pse nuk kërkohet, agjentët e përdoruesve duhet ta përfshijnë gjithmonë këtë fushë në kërkesat e tyre. Fusha mund të përmbajë vargje të shumta që përfaqësojnë emrin e produktit softuerik, një prerje opsionale përpara që tregon versionin e produktit dhe produkte të tjera softuerike që janë një pjesë e rëndësishme e agjentit të përdoruesit. Sipas konventës, produktet renditen në rend zbritës të rëndësisë së tyre për identifikimin e aplikacionit.

User-Agent = "User-Agent" ":" 1*(produkt) product = string ["/" product-version] product-version = string

Agjenti i përdoruesit: CERN-LineMode/2.15 libwww/2.17b3

Rreshti që përshkruan emrin e produktit duhet të jetë i shkurtër dhe i saktë - përdorimi i këtij titulli për të reklamuar çdo informacion tjetër të parëndësishëm nuk lejohet dhe do të konsiderohet në kundërshtim me protokollin. Megjithëse çdo varg mund të jetë i pranishëm në fushën e versionit të produktit, vargu duhet të përdoret vetëm për të treguar versionin e produktit. Fusha Përdorues-Agjent mund të përfshijë informacion shtesë në komente që nuk janë pjesë e vlerës së saj.

Struktura e reagimit

Pas marrjes dhe interpretimit të kërkesës, serveri dërgon një përgjigje në përputhje me formularin e mëposhtëm:

Përgjigje = Përgjigje e thjeshtë | Përgjigje e plotë Përgjigje e thjeshtë = [ Përgjigje-Përmbajtja ] Përgjigje e plotë = Statusi i linjës *(Titulli i zakonshëm | Kreu i përgjigjes | Përmbajtja-Header) CRLF [ Përgjigje-Përmbajtja ]

Një përgjigje e thjeshtë duhet të dërgohet vetëm në përgjigje të një Kërkese të thjeshtë HTTP/0.9, ose nëse serveri mbështet vetëm protokollin e kufizuar HTTP/0.9. Nëse një klient dërgon një kërkesë të plotë HTTP/1.0 dhe merr një përgjigje që nuk fillon me një linjë statusi, ai duhet të supozojë se përgjigja e serverit është një përgjigje e thjeshtë dhe ta përpunojë atë në përputhje me rrethanat. Duhet të theksohet se Simple-Response përbëhet vetëm nga informacioni i kërkuar (pa tituj) dhe rrjedha e të dhënave ndalon në momentin që serveri mbyll seancën e komunikimit.

Statusi i linjës

Rreshti i parë i Kërkesës së Plotë është Linja e Statusit, e përbërë nga versioni i protokollit i ndjekur nga një kod numerik statusi dhe një fjali tekstuale të lidhur. Të gjithë elementët Line-Status janë të ndara me hapësira. Karakteret CR dhe LF nuk lejohen, me përjashtim të sekuencës pasuese CRLF.

Line-Status=Version-HTTP SP Status-Kodi SP Frazë-Shpjegim.

Meqenëse Linja e Statusit gjithmonë fillon me versionin e protokollit "HTTP/" 1*DIGIT "." 1*DIGIT (p.sh. HTTP/1.0), ekzistenca e kësaj shprehje konsiderohet thelbësore për të përcaktuar nëse përgjigja është një përgjigje e thjeshtë ose një përgjigje e plotë. Edhe pse formati Simple-Response nuk e pengon shfaqjen e një rreshti të tillë (që do të çonte në keqinterpretimin e mesazhit të përgjigjes si përgjigje e plotë), gjasat për një ndodhi të tillë janë afër zeros.

Kodi i statusit dhe shpjegimi për të

Elementi i Kodit të Statusit është një kod i plotë 3-shifror që identifikon rezultatin e një përpjekjeje për të interpretuar dhe plotësuar kërkesën. Fraza shpjeguese pas saj ka për qëllim një përshkrim të shkurtër teksti të Kodit të Statusit. Kodi i statusit synohet të përdoret nga një makinë, ndërsa fraza shpjeguese është menduar për një person. Klientit nuk i kërkohet të ekzaminojë dhe të shfaqë Frazën Shpjeguese.

Shifra e parë e Kodit të Statusit synon të përcaktojë klasën e përgjigjes. Dy shifrat e fundit nuk luajnë ndonjë rol kategorizues. Ka 5 kuptime për shifrën e parë:

1. 1xx: Informative - Nuk përdoret, por e rezervuar për përdorim në të ardhmen
2. 2xx: Sukses - Kërkesa u pranua plotësisht, u kuptua dhe u pranua për përpunim.
3. 3xx: Ridrejtimi - Klienti duhet të ndërmarrë veprime të mëtejshme për të përfunduar me sukses kërkesën. Veprimi shtesë i kërkuar ndonjëherë mund të kryhet nga klienti pa ndërveprim të përdoruesit, por rekomandohet fuqimisht që kjo të ndodhë vetëm në rastet kur metoda e përdorur në kërkesë është indiferente (GET ose HEAD).
4. 4xx: Gabim klienti - Një kërkesë që përmban sintaksë të pavlefshme nuk mund të përfundojë me sukses. Klasa 4xx synon të përshkruajë rastet kur është bërë një gabim nga ana e klientit. Nëse klienti nuk e ka përfunduar ende kërkesën kur merr një përgjigje me Kodin e Statusit - 4xx, duhet të ndalojë menjëherë transmetimin e të dhënave në server. Ky lloj Kodi i Statusit është i zbatueshëm për çdo metodë të përdorur në kërkesë.
5. 5xx: Gabim serveri - Serveri nuk ishte në gjendje të jepte një përgjigje për një kërkesë të paraqitur saktë. Në këto raste
   serveri ose e di se ka bërë një gabim ose nuk është në gjendje të përpunojë kërkesën. Me përjashtim të përgjigjeve ndaj kërkesave HEAD, serveri dërgon një përshkrim të gjendjes së gabimit dhe nëse kushti është i përkohshëm apo i përhershëm në Përmbajtjen e Përgjigjeve. Ky lloj Kodi i Statusit është i zbatueshëm për çdo metodë të përdorur në kërkesë.

Më poshtë jepen kuptimet individuale të Kodeve të Statusit dhe Frazave shpjeguese përkatëse. Këto fraza shpjeguese rekomandohen vetëm - ato mund të zëvendësohen me çdo frazë tjetër që ruajnë kuptimin e tyre dhe lejohen nga protokolli.

Status-Code = "200" ; OK | "201"; Krijuar | "202"; Pranuar | "203"; Informacion i përkohshëm | "204"; Pa përmbajtje | "300"; Zgjedhje të Shumëfishta | "301"; Lëvizur përgjithmonë | "302"; Lëvizur përkohësisht | "303"; Metoda | "304"; Nuk është modifikuar | "400"; Kërkesë e keqe | "401"; I paautorizuar | "402"; Kërkohet Pagesa | "403"; Ndaluar | "404"; Nuk u gjet | "405"; Metoda nuk lejohet | "406"; Asnjë e pranueshme | "407"; Kërkohet vërtetimi i përfaqësuesit | "408"; Përfundimi i kërkesës | "409"; Konflikti | "410"; Iku | "500"; Gabim i brendshëm i serverit | "501"; Nuk është zbatuar | "502"; Bad Gateway | "503"; Shërbimi i padisponueshëm | "504"; Kohëzgjatja e portës | Kodi i Zgjerimit Kodi i Zgjerimit = 3DIGIT Frazë-Shpjegim = varg *(varg SP)

Aplikacionet HTTP nuk janë të nevojshme për të kuptuar të gjitha Kodet e Statusit, megjithëse një kuptim i tillë është padyshim i dëshirueshëm. Megjithatë, aplikacionet duhet të jenë në gjendje të njohin klasat e kodeve të statusit (të identifikuara nga shifra e parë) dhe t'i trajtojnë të gjitha Kodet e statusit të statusit të përgjigjes sikur të ishin ekuivalente me Kodin e Statusit x00.

Fushat e përgjigjes së kokës

Fushat e kokës së përgjigjes lejojnë serverin të kalojë informacion shtesë në lidhje me përgjigjen që nuk mund të përfshihet në linjën e statusit. Këto fusha të kokës nuk kanë për qëllim të përcjellin informacion në lidhje me përmbajtjen e përgjigjes së dërguar në përgjigje të kërkesës, por ato mund të përmbajnë informacion për vetë serverin.

Përgjigje-Header= Publike | Riprovo-Pas | Serveri | WWW-Autentifiko | zgjerim-kokë

Megjithëse fushat shtesë të kokës së përgjigjes mund të zbatohen përmes një mekanizmi shtesë, aplikacionet që nuk i njohin këto fusha duhet t'i trajtojnë ato si fusha të Përmbajtjes së kokës. Një përshkrim i plotë i këtyre fushave mund të gjendet në specifikimin e protokollit CERN HTTP.

Koncepte të përgjithshme

Kërkesa e plotë dhe Përgjigja e plotë mund të përdoren për të përcjellë disa informacione në kërkesa dhe përgjigje të veçanta. Ky informacion është Request-Content ose Response-Content, përkatësisht, dhe Përmbajtja-Header.

Fushat Titull-Përmbajtje

Fushat Header-Content përmbajnë meta-informacion opsional në lidhje me Request-Content ose Response-Content, përkatësisht. Nëse trupi i mesazhit (kërkesës ose përgjigjes) përkatës nuk është i pranishëm, atëherë Përmbajtja-Header përmban informacion në lidhje me burimin e kërkuar.

Disa nga fushat e titullit të përmbajtjes janë përshkruar më poshtë.

Lejo

Fusha Allow header është një listë e metodave që mbështet burimi i identifikuar nga URI-ja e kërkesës. Qëllimi i kësaj fushe është të informojë me saktësi marrësin për metodat e vlefshme që lidhen me burimin; kjo fushë duhet të jetë e pranishme në përgjigjen me kodin e statusit “405 Metoda nuk lejohet”.

Lejo = "Lejo" ":" 1#metodë

Shembull përdorimi:

Lejo: MERR, KOKË, VENDOS

Sigurisht, klienti mund të provojë metoda të tjera. Megjithatë, rekomandohet të ndiqni metodat e treguara në këtë fushë. Kjo fushë nuk ka vlerë të paracaktuar; nëse lihet e papërcaktuar, grupi i metodave të lejuara përcaktohet nga serveri në momentin e çdo kërkese.

Përmbajtja-Gjatësia

Fusha Content-Length specifikon madhësinë e trupit të mesazhit të dërguar nga serveri në përgjigje të kërkesës ose, në rastin e një kërkese HEAD, madhësinë e trupit të mesazhit që do të dërgohej në përgjigje të kërkesës GET.

Content-Length = "Content-Length" ":" 1*DIGIT

Për shembull:

Përmbajtja-Gjatësia: 3495

Edhe pse nuk kërkohet, aplikacionet inkurajohen fuqimisht të përdorin këtë fushë për të analizuar madhësinë e mesazhit që transmetohet, pavarësisht nga lloji i informacionit që përmban. Për fushën Content-Length, çdo vlerë e plotë më e madhe se zero është e vlefshme.

Lloji i përmbajtjes

Fusha e kokës Content-Type identifikon llojin e informacionit në trupin e mesazhit që i dërgohet palës marrëse ose, në rastin e metodës HEAD, llojin e informacionit (media) që do të dërgohej nëse do të përdorej metoda GET.

Content-Type = "Content-Type" ":" lloji i mjedisit

Llojet e mediave përcaktohen veçmas.
Shembull:

Lloji i përmbajtjes: tekst/html; charset=ISO-8859-4

Fusha Content-Type nuk ka vlerë të paracaktuar.

E modifikuara e fundit

Fusha e titullit përmban datën dhe kohën në të cilën pala dërguese beson se burimi është modifikuar për herë të fundit. Semantika e kësaj fushe përcaktohet në terma që përshkruajnë se si marrësi duhet ta interpretojë atë: nëse marrësi ka një kopje të burimit që është më e vjetër se data e kaluar në fushën "Modifikimi i fundit", atëherë kopja duhet të konsiderohet e vjetëruar. .

Last-Modified = "Last-Modified" ":" Data HTTP

Shembull përdorimi:

Kuptimi i saktë i kësaj fushe kokë varet nga zbatimi i palës dërguese dhe nga natyra e vetë burimit. Për skedarët, kjo thjesht mund të jetë koha e fundit e modifikimit. Për portat e bazës së të dhënave, kjo mund të jetë koha kur të dhënat në bazën e të dhënave u përditësuan për herë të fundit. Në çdo rast, marrësi duhet të shqetësohet vetëm për rezultatin - çfarë është në fushën e caktuar - dhe të mos shqetësohet se si është marrë rezultati.

Trupi i mesazhit

Trupi i mesazhit i referohet përkatësisht Kërkesës-Përmbajtjes ose Përgjigjes-Përmbajtjes. Trupi i mesazhit, nëse është i pranishëm, dërgohet në kërkesën ose përgjigjen HTTP/1.0 në formatin dhe kodimin e specifikuar nga fushat Header-Content.

Message-Body = *OCTET (ku OCTET është çdo karakter 8-bit)

Trupi i mesazhit përfshihet në kërkesë vetëm nëse metoda e kërkesës nënkupton praninë e tij. Për specifikimin HTTP/1.0, këto metoda janë POST dhe PUT. Në përgjithësi, prania e një trupi mesazhi tregohet nga prania e fushave të titullit të përmbajtjes, si Përmbajtja-Gjatësia dhe/ose Përmbajtja-Transferimi-Encoding në kërkesën e transmetuar.

Për mesazhet e përgjigjes, prania e një trupi mesazhi në përgjigje varet nga metoda e përdorur në kërkesë dhe kodi i statusit. Të gjitha përgjigjet ndaj kërkesave HEAD nuk duhet të përmbajnë një trup mesazhi, megjithëse prania e disa fushave të kokës së mesazhit mund të tregojë praninë e mundshme të një të tillë. Prandaj, përgjigjet "204 pa përmbajtje", "304 jo të modifikuara" dhe "406 asnjë e pranueshme" nuk duhet të përfshijnë gjithashtu një trup mesazhi.

Mire keq

Protokolli i transferimit të hipertekstit HTTP (RFC 1945, 2068) është krijuar për të transferuar dokumente hiperteksti nga një server në një klient. Protokolli HTTP është një protokoll i shtresës së aplikacionit. Sipas RFC, protokolli i tij i transportit duhet të jetë një protokoll i orientuar drejt lidhjes që transferon të dhënat në mënyrë të besueshme dhe nuk ruan kufijtë midis mesazheve. Në praktikë, në shumicën dërrmuese të rasteve, protokolli i transportit për HTTP është TCP, me serverin HTTP (serverin e uebit) që pret një lidhje nga ana e klientit, standard në portin TCP 80 dhe klienti HTTP (shfletuesi i uebit) fillon. lidhjen.

Në terma të ueb-it, gjithçka që një përdorues mund të aksesojë - dokumente, imazhe, programe - quhen burime. Çdo burim ka një adresë unike për Ueb-in, e quajtur identifikues universal i burimit (URI - Universal Resource Identifier). Në rastin më të përgjithshëm, URI duket kështu:

protokoll://user:password@host:port/path/file?paremeters#fragment

Fushat individuale URI kanë kuptimin e mëposhtëm:

protokoll - protokoll i aplikacionit përmes të cilit aksesohet burimi;

përdorues - përdoruesi në emër të të cilit aksesohet burimi ose vetë përdoruesi si burim;

fjalëkalimi - fjalëkalimi i përdoruesit për vërtetim kur hyni në burim;

host - adresa IP ose emri i serverit në të cilin ndodhet burimi;

port - numri i portit në të cilin serveri po funksionon, duke siguruar qasje në burim;

rrugë - shtegu drejt skedarit që përmban burimin;

skedar - skedar që përmban burimin;

parametrat - parametrat për përpunim nga resursi-programi;

fragment - pika në skedar nga e cila duhet të shfaqet burimi.

Ndërveprimi ndërmjet klientit dhe serverit në internet kryhet duke shkëmbyer mesazhe. Mesazhet HTTP ndahen në kërkesat e klientit për serverin dhe përgjigjet e serverit për klientin.

Mesazhet e kërkesës dhe përgjigjes kanë një format të përbashkët. Të dy llojet e mesazheve duken kështu: së pari ka një linjë fillestare, pastaj ndoshta një ose më shumë fusha të kokës, të quajtura thjesht kokë, pastaj një rresht bosh (d.m.th., një rresht i përbërë nga karakteret CR dhe LF), që tregon fundi i fushave të kokës dhe më pas ndoshta trupi i mesazhit:

vija e fillimit

fusha e kokës 1

fusha e kokës 2

fusha e kokës N

trupi i mesazhit

Formatet fillestare të linjës së klientit dhe serverit ndryshojnë dhe do të diskutohen më poshtë. Ekzistojnë katër lloje të titujve:

titujt e përgjithshëm, të cilët mund të jenë të pranishëm si në kërkesë ashtu edhe në përgjigje;

kokat e kërkesave, të cilat mund të jenë të pranishme vetëm në kërkesë;

kokat e përgjigjeve, të cilat mund të jenë të pranishme vetëm në përgjigje;

titujt e entitetit, të cilët i referohen trupit të mesazhit dhe përshkruajnë përmbajtjen e tij.

Çdo kokë përbëhet nga një titull, një karakter ":" me dy pika dhe një vlerë. Titujt më të rëndësishëm janë paraqitur në tabelë. 1.

Tabela 1
Titujt e protokollit HTTP
Drejtimi	Qëllimi
Titujt e objekteve
	Liston metodat e mbështetura nga serveri
Përmbajtja-Enkodimi	Mënyra se si është koduar trupi i mesazhit, për shembull për të zvogëluar madhësinë
	Gjatësia e mesazhit në bajt
	Lloji i përmbajtjes dhe ndoshta disa parametra
	Një etiketë unike e burimeve në server që ju lejon të krahasoni burimet
	Data dhe ora kur burimi në server do të ndryshojë dhe duhet të merret përsëri
	Data dhe ora e modifikimit të fundit të përmbajtjes
Titujt e përgjigjes
	Numri i sekondave pas të cilave kërkesa duhet të përsëritet për të marrë përmbajtje të re
	URI e burimit për të hyrë për të marrë përmbajtjen
	Data dhe ora ose numri i sekondave pas së cilës kërkesa duhet të përsëritet për të marrë një përgjigje të suksesshme
	Emri i softuerit të serverit që dërgoi përgjigjen
Titujt e kërkesës
	Llojet e përmbajtjes që klienti "kupton" dhe mund të luajë
	Kodimet e karaktereve në të cilat klienti mund të pranojë përmbajtje teksti
	Mënyra se si serveri mund të kodojë mesazhin
	Numri i hostit dhe portit nga i cili kërkohet dokumenti
Nëse-Modifikuar-Që Nëse-Unmodifikuar-Që	Kërkoni titujt për qasje në burim të kushtëzuar
	Kërkoni një pjesë të një dokumenti
	Emri i softuerit të klientit
Titujt e përgjithshëm
	Tregon që serveri të mbyllë ose të mbajë të gjallë seancën
	Data dhe ora e krijimit të mesazhit

Një përshkrim i detajuar i titujve HTTP/1.0 mund të gjendet në RFC 2068.

Trupi i mesazhit përmban informacionin aktual që transmetohet - ngarkesën e mesazhit. Trupi i mesazhit është një sekuencë oktetesh (bajt). Trupi i mesazhit mund të kodohet, për shembull, për të zvogëluar sasinë e informacionit të transmetuar, dhe metoda e kodimit tregohet në kokën e objektit të kodimit të përmbajtjes.

Një mesazh kërkese nga një klient në një server përbëhet nga një linjë kërkese, tituj (të përgjithshëm, kërkesa, objekt) dhe ndoshta një trup mesazhi. Linja e kërkesës fillon me metodën, e ndjekur nga identifikuesi i burimit që kërkohet, versioni i protokollit dhe karakteret e fundit të rreshtit:

<Метод> <Идентификатор> <Версия HTTP>

Metoda specifikon një komandë të protokollit HTTP për t'u aplikuar në burimin e kërkuar. Për shembull, metoda GET tregon se klienti dëshiron të marrë përmbajtjen e një burimi. Identifikuesi identifikon burimin që kërkohet. Versioni HTTP tregohet nga një rresht si ky:

HTTP/<версия>.<подверсия>

RFC 2068 prezanton protokollin HTTP/1.1.

Le të shohim metodat kryesore të protokollit HTTP.

Metoda OPTIONS kërkon informacion në lidhje me opsionet e lidhjes (p.sh. metodat, llojet e dokumenteve, kodimet) që serveri mbështet për burimin e kërkuar. Kjo metodë i lejon një klienti të specifikojë opsionet dhe/ose kërkesat që lidhen me aftësitë e një burimi ose serveri pa kryer asnjë veprim mbi burimin ose pa shkaktuar ngarkimin e tij.

Nëse përgjigja e serverit nuk është një mesazh gabimi, atëherë titujt e objekteve përmbajnë informacion që mund të mendohet si opsione lidhjeje. Për shembull, titulli Lejo liston të gjitha metodat e mbështetura nga serveri për një burim të caktuar.

Nëse identifikuesi i burimit të kërkuar është një yll ("*"), atëherë kërkesa OPTIONS ka për qëllim t'i drejtohet serverit në tërësi.

Nëse ID-ja e burimit të kërkuar nuk është një yll, atëherë kërkesa OPTIONS zbatohet për opsionet që janë të disponueshme kur lidheni me burimin e specifikuar.

Metoda GET ju lejon të merrni çdo informacion në lidhje me burimin e kërkuar. Në shumicën e rasteve, nëse ID e burimit të kërkuar tregon për një dokument (p.sh., dokument HTML, dokument teksti, grafik, video), atëherë serveri kthen përmbajtjen e atij dokumenti (përmbajtja e skedarit). Nëse burimi i kërkuar është një aplikacion (program) që gjeneron disa të dhëna gjatë funksionimit të tij, atëherë këto të dhëna kthehen në trupin e mesazhit të përgjigjes, dhe jo një imazh binar i skedarit të ekzekutueshëm. Kjo përdoret, për shembull, kur krijohen aplikacione CGI. Nëse identifikuesi i burimit të kërkuar tregon në një direktori (direktori, dosje), atëherë, në varësi të cilësimeve të serverit, ose përmbajtja e drejtorisë (lista e skedarëve) ose përmbajtja e një prej skedarëve të vendosur në këtë direktori (zakonisht index.html ose Default.htm). Kur kërkohet për një dosje, emri i saj mund ose nuk mund të tregohet me një "/" në fund. Nëse ky karakter nuk është i pranishëm në fund të identifikuesit të burimit, serveri lëshon një nga përgjigjet e ridrejtimit (me kodet e statusit 301 ose 302).

Një variant i metodës GET është "GET i kushtëzuar", në të cilin mesazhi i kërkesës përfshin titujt e kërkesës If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match ose If-Range . Metoda e kushtëzuar GET kërkon transferimin e një objekti vetëm nëse i plotëson kushtet e përshkruara në kokat e dhëna. Për shembull, nëse titulli If-Modified-Since është i pranishëm, përmbajtja e burimit të kërkuar do të merret vetëm nëse ato nuk kanë ndryshuar që nga momenti kohor i specifikuar si vlera e këtij titulli. Metoda e kushtëzuar GET synon të zvogëlojë ngarkesën e panevojshme të rrjetit, pasi shmang rimbushjen e të dhënave të ruajtura tashmë nga klienti.

Ekziston gjithashtu një "GET i pjesshëm" në të cilin mesazhi i kërkesës përfshin një kokë të kërkesës Range. Një GET i pjesshëm kërkon që vetëm një pjesë e një objekti të transferohet. Metoda e pjesshme GET është projektuar për të reduktuar shpenzimet e panevojshme të rrjetit duke kërkuar vetëm një pjesë të një objekti kur një pjesë tjetër është shkarkuar tashmë nga klienti. Vlera e kokës së Range është vargu "bytes=" i ndjekur nga diapazoni i bajteve që do të merren. Bajtet numërohen duke filluar nga 0. Bajtet e fillimit dhe mbarimit të diapazonit ndahen me një karakter “–”. Të dy bajtët e fillimit dhe të mbarimit në interval mund të mungojnë. Nëse keni nevojë të merrni disa vargje, ato renditen të ndara me presje. Nëse disa nga vargjet e listuara kryqëzohen, serveri i bashkon ato. Mesazhi i përgjigjes për një kërkesë të pjesshme GET duhet të përmbajë një kokë të diapazonit të përmbajtjes që specifikon diapazonin që duhet kaluar. Nëse serveri dërgon vargje të shumta jo të mbivendosura, titulli i llojit të përmbajtjes merr vlerën speciale "multypart/byteranges". Trupi i mesazhit ndahet në pjesë të ndara nga një ndarës i gjeneruar nga serveri dhe kalohet si parametër i kokës së llojit të përmbajtjes. Çdo pjesë e veçantë përmban titujt e saj të llojit të përmbajtjes dhe gamës së përmbajtjes, me një rresht bosh përpara përmbajtjes së diapazonit.

Metoda HEAD është identike me GET, përveç se serveri nuk e kthen trupin e mesazhit në përgjigje. Informacioni i përfshirë në titujt HTTP të një përgjigjeje ndaj një kërkese HEAD është identik me informacionin e dhënë në përgjigje të një kërkese GET për të njëjtin burim. Kjo metodë mund të përdoret për të marrë informacion rreth një objekti të kërkesës pa kaluar drejtpërdrejt në trupin e objektit. Metoda HEAD mund të përdoret për të testuar lidhjet e hipertekstit.

Metoda POST përdoret për një kërkesë në të cilën serveri i adresuar pranon të dhënat e përfshira në trupin e mesazhit të kërkesës (objekt) dhe ia dërgon ato aplikacionit të specifikuar si burimi i kërkuar për përpunim. POST është krijuar për të zbatuar funksionet e mëposhtme në një mënyrë të përgjithshme:

shënimi i burimeve ekzistuese;

postimi i një mesazhi në sistemin e tabelës së buletinit (BBS), grupeve të lajmeve, listave postare ose grupeve të ngjashme të artikujve;

transferimi i një blloku të dhënash, për shembull rezultati i një hyrjeje në një formë, në një proces përpunimi;

ekzekutimi i pyetjeve në bazat e të dhënave (DB);

Në fakt, funksioni i kryer nga metoda POST përcaktohet nga aplikacioni i treguar nga ID-ja e burimit të kërkuar. Së bashku me metodën GET, metoda POST përdoret kur krijohen aplikacione CGI. Shfletuesi mund të lëshojë kërkesa me metodën POST kur dorëzon formularët. Për ta bërë këtë, elementi FORM i dokumentit HTML që përmban formularin duhet të ketë një atribut metodë me vlerën POST.

Një aplikacion i iniciuar nga POST mund të kryejë një veprim në server dhe të mos kthejë asnjë përmbajtje si rezultat. Në varësi të faktit nëse përgjigja përfshin një trup mesazhi që përshkruan rezultatin apo jo, kodi i statusit në përgjigje mund të jetë ose 200 (OK) ose 204 (Pa përmbajtje).

Nëse burimi në server është krijuar, përgjigja përmban një kod statusi prej 201 (Krijuar) dhe përfshin një titull të përgjigjes së vendndodhjes.

Trupi i mesazhit që dërgohet në një kërkesë PUT ruhet në server dhe identifikuesi i burimit të kërkuar do të jetë identifikuesi i dokumentit të ruajtur. Nëse identifikuesi i burimit të kërkuar tregon për një burim tashmë ekzistues, atëherë objekti i përfshirë në trupin e mesazhit trajtohet si një version i modifikuar i burimit të vendosur në server. Nëse është krijuar një burim i ri, serveri njofton agjentin e përdoruesit duke iu përgjigjur me kodin e statusit 201 (Krijuar).

Dallimi midis metodave POST dhe PUT është vlera e ndryshme ID e burimit të kërkuar. URI në kërkesën POST identifikon burimin që përpunon objektin e përfshirë në trupin e mesazhit. Ky burim mund të jetë aplikacioni që merr të dhënat. Në të kundërt, URI në një kërkesë PUT identifikon entitetin e përfshirë në kërkesë si trupin e mesazhit, domethënë, agjenti i përdoruesit ia cakton URI-në e dhënë burimit të përfshirë.

Metoda DELETE kërkon që serveri të fshijë një burim që ka ID-në e kërkuar. Një kërkesë me këtë metodë mund të refuzohet nga serveri nëse përdoruesi nuk ka të drejtë të fshijë burimin e kërkuar.

Metoda TRACE përdoret për të kthyer kërkesën e transmetuar në nivelin e protokollit HTTP. Marrësi i kërkesës (serveri uebi) ia dërgon mesazhin e marrë klientit si trupi i një mesazhi përgjigjeje me një kod statusi 200 (OK). Kërkesa TRACE nuk duhet të përmbajë një trup mesazhi.

TRACE lejon klientin të shohë se çfarë po merr serveri në anën tjetër dhe t'i përdorë këto të dhëna për testim ose diagnostikim.

Nëse kërkesa është e suksesshme, përgjigja përmban të gjithë mesazhin e kërkesës në trupin e mesazhit të përgjigjes dhe titulli i objektit Content-Type është "mesazh/http".

Informacione të hollësishme rreth metodave të protokollit HTTP/1.1 mund të gjenden në RFC 2068.

Pas marrjes dhe interpretimit të mesazhit të kërkesës, serveri përgjigjet me një mesazh përgjigjeje HTTP.

Rreshti i parë i përgjigjes është linja e statusit. Ai përbëhet nga versioni i protokollit, një kod statusi numerik, një frazë shpjeguese, e ndarë me hapësira dhe karaktere në fund të rreshtit:

<Версия HTTP> <Код состояния> <Поясняющая фраза>

Versioni i protokollit ka të njëjtin kuptim si në kërkesë.

Elementi Status-Code është një kod i plotë treshifror (treshifror) për rezultatin e të kuptuarit dhe plotësimit të kërkesës. Fraza-Arsyeja është një përshkrim i shkurtër teksti i kodit të statusit. Kodi i statusit synohet të përpunohet nga softueri dhe fraza shpjeguese është menduar për përdoruesit.

Shifra e parë e kodit të statusit përcakton klasën e përgjigjes. Dy shifrat e fundit nuk kanë ndonjë rol specifik në klasifikim. Ka 5 kuptime për shifrën e parë:

1xx: Kodet e informacionit – kërkesa e marrë, përpunimi vazhdon.

2xx: Kodet e suksesshme - veprimi është marrë, kuptuar dhe përpunuar me sukses.

3xx: Kodet e ridrejtimit - duhet të ndërmerren veprime të mëtejshme për të përfunduar kërkesën.

4xx: Kodet e gabimit të klientit - kërkesa ka një gabim sintaksor ose nuk mund të plotësohet.

5xx: Kodet e gabimit të serverit - Serveri nuk është në gjendje të plotësojë një kërkesë të vlefshme.

Frazat shpjeguese për çdo kod statusi janë të listuara në RFC 2068 dhe rekomandohen, por mund të zëvendësohen me ato ekuivalente pa kufizime protokolli. Për shembull, në versionet e lokalizuara në gjuhën ruse të serverëve HTTP, këto fraza zëvendësohen me ato ruse. Në tabelë 2 tregon kodet e përgjigjes së serverit HTTP.

tabela 2
Kodet e përgjigjes së serverit HTTP
	Fraza shpjeguese sipas
1xx: Kodet e informacionit
		Vazhdoni
2xx: Kodet e suksesshme
		Nuk ka përmbajtje
		Rivendosja e përmbajtjes
	Përmbajtje e pjesshme	Përmbajtja e pjesshme
3xx: Kodet e ridrejtimit
	Lëvizur përkohësisht	Lëvizur përkohësisht
		I pa modifikuar
4xx: Kodet e gabimit të klientit
		Kerkese e keqe
		I paautorizuar
		Nuk u gjet
	Metoda nuk lejohet	Metoda nuk lejohet
	Përfundimi i kërkesës	Koha e kërkesës mbaroi
		Konflikti
	Gjatësia e kërkuar	Gjatësia e kërkuar
	Kërkoni një subjekt shumë të madh	Objekti i kërkesës është shumë i madh

Fundi i tryezës. 2
	Fraza shpjeguese sipas	Fraza ekuivalente shpjeguese në rusisht
5xx: Kodet e gabimit të serverit
	Gabim i brendshëm i serverit	Gabim i brendshëm i serverit
	Nuk është zbatuar	Nuk zbatohet
	sherbim i padisponueshem	Shërbimi është i padisponueshëm
	Versioni HTTP nuk mbështetet	Versioni HTTP nuk mbështetet

Informacione të hollësishme rreth kodeve të përgjigjeve dhe titujve që shoqërojnë këto përgjigje mund të gjenden në RFC 2068.

Linja e statusit ndiqet nga titujt (e përgjithshme, përgjigja dhe objekti) dhe ndoshta një trup mesazhi.

Një nga funksionet më të rëndësishme të një serveri ueb është të sigurojë akses në një pjesë të sistemit lokal të skedarëve. Për ta bërë këtë, në cilësimet e serverit specifikohet një direktori e caktuar, e cila është direktoria rrënjësore për këtë server në internet. Për të publikuar një dokument, domethënë për ta bërë atë të disponueshëm për përdoruesit që "vizitojnë" këtë server (duke u lidhur me të nëpërmjet HTTP), duhet ta kopjoni këtë dokument në direktoriumin rrënjë të serverit në internet ose në një nga nëndrejtoritë e tij. Kur lidheni përmes HTTP, krijohet një proces në server me të drejtat e përdoruesit, i cili, si rregull, nuk ekziston në të vërtetë, por është krijuar posaçërisht për të parë burimet e serverit. Duke konfiguruar të drejtat dhe lejet e një përdoruesi të caktuar, ju mund të kontrolloni aksesin në burimet e Uebit.

Përshëndetje, të dashur lexues të faqes së blogut. Kur studioni mekanizmin përgjegjës për funksionimin e duhur të Internetit, nuk ka shpëtim nga nevoja për t'i kushtuar kohë aspekteve të tij kryesore, të cilat, pa dyshim, përfshijnë protokollin e transferimit të të dhënave HTTP dhe versionin e tij të sigurt HTTPS.

Baza për funksionimin e këtij mjeti, i cili lejon shfletuesin e përdoruesit të hapë skedarët dhe dokumentet e nevojshme për të marrë informacion, është teknologjia "klient-server", detajet e së cilës do të diskutohen në këtë artikull më poshtë.

Sigurisht, ata që duan t'i kushtojnë vërtet aktivitetet e tyre punës me rrjetet kompjuterike dhe zhvillimit të programeve të rrjetit duhet ta studiojnë këtë çështje në maksimum për të marrë kualifikimet e duhura. Por ne nuk kemi nevojë për këtë.

Gjëja kryesore është të kuptoni se çfarë është HTTP në terma të përgjithshëm dhe cilat janë tiparet kryesore të HTTPS, si dhe të kuptoni parimet bazë që janë të ngulitura në to. Një njohuri e tillë do të jetë e dobishme, ndër të tjera, për optimizimin dhe promovimin e faqes suaj të internetit, do të merrni konfirmim të pakushtëzuar për këtë nga kjo dhe artikujt pasues mbi këtë temë.

Çfarë është HTTP dhe si funksionon?

Për të marrë dokumentin e dëshiruar në internet, përdoruesi duhet vetëm të fusë URL-në e dëshiruar në shiritin e kërkimit të shfletuesit (më shumë rreth strukturës së URL-së), i cili përmban vetëm emrin e protokollit HTTP (ose HTTPS).

3. HTTP/Versioni— tregohet modifikimi aktual i protokollit. Për momentin është HTTP 1.1 (mund të lexoni specifikimet e tij). Sidoqoftë, versioni tjetër i protokollit 2.0 ekziston tashmë në formë drafti, i cili bazohet në .

Rreshti i fundit përfaqëson Koka e pritësit si pjesë e një kërkese HTTP të dërguar nga shfletuesi te serveri në përputhje me IP-në e marrë nga DNS. Për ç'farë është kjo? Për të identifikuar sitin e dëshiruar, pasi serverët e uebit zakonisht presin më shumë se një burim.

Le të shohim një shembull të qartë për të përforcuar atë që kemi mësuar. Le të themi se shfletuesi mori një "detyrë" nga përdoruesi për të shfaqur një faqe me adresën e mëposhtme:

Http://subscribe.ru/group/

Pastaj një kërkesë HTTP duke përdorur metodën GET mund të përpilohet si më poshtë (në këtë rast zakonisht nuk ka asnjë trup mesazhi):

GET /grup/ HTTP/1.1 Host: subscribe.ru

Për qartësi, unë kam dhënë vetëm një shembull shumë të thjeshtë, duke përfshirë një kokë Host; në fakt, mund të ketë disa prej tyre. Por kjo nuk është e gjitha. Në fund të fundit, komunikimi i plotë kërkon një dialog, i cili vendoset pasi serveri t'i përgjigjet kërkesës së shfletuesit. Linja fillestare e përgjigjes gjithashtu mund të përshkruhet në mënyrë skematike:

Shpjegimi i kodit të statusit të HTTP/Versionit

Tani le të shohim shkurtimisht përbërjen e përgjigjes së serverit:

1. Versioni HTTP tregohet në analogji me kërkesën.

2. Kodi i statusit(Kodi i Statusit) - tre numra që informojnë për statusin e dokumentit të kërkuar nga shfletuesi. Për shembull, 200 - OK, faqja ekziston dhe do të shfaqet në shfletues, 301 - është bërë një ridrejtim në një URL tjetër, - nuk ka asnjë faqe interneti në atë adresë (ndoshta është fshirë ose përdoruesi ka bërë një gabim kur duke futur URL-në).

3. Shpjegim(Frazë arsyeje) - teksti i shtesës në kodin e përgjigjes. Në disa raste, shpjegimi mund të ndryshojë nga standardi ose të mungojë fare. Kjo është gjithashtu për shkak të konfigurimit të softuerit të pritur në server.

Shembull i vërtetë? Ju lutem. Le të përpiqemi të marrim përgjigjen e serverit ndaj kërkesës që dhashë si shembull më lart (url "http://subscribe.ru/group/"). Do të duket kështu (linja fillestare e kokës):

HTTP/1.1 200 OK Serveri: nginx Data: Sht, 10 Qershor 2017 06:36:38 GMT Lloji i Përmbajtjes: tekst/html; charset=utf-8 Lidhja: keep-live Përmbajtja-Gjuha: ru Set-Cookie: Subscribe::Viziter=UQkivlk7k3YO3DgjAxM2Ag==; skadon=E enjte, 31-dhjetor-37 23:55:55 GMT; domain=subscribe.ru; path=/ P3P: policyref="/w3c/p3p.xml", CP="NOI PSA OUR BUS UNI"

Në këtë rast, nuk ka asnjë tekst shpjegimi dhe mesazhi, i cili, kur përdoret metoda GET, mund të përmbajë, për shembull, kodin HTML të dokumentit të kërkuar (faqes së internetit). Në varësi të llojit të aplikacionit të klientit, këto seksione mund të jenë të pranishme.

Pra, le të përmbledhim shkurtimisht sa më sipër. Nëse përdoruesi fut URL-në e faqes që kërkon, duke synuar të marrë përmbajtjen e saj për shikim, shfletuesi dërgon një kërkesë GET në serverin e dëshiruar dhe merr një përgjigje. Si rezultat i këtij komunikimi, ose (në rrethana të favorshme) do të shfaqet përmbajtja e dokumentit të kërkuar ose jo.

Në çdo rast, përmbajtja e përgjigjes HTTP të serverit (përfshirë kodin e statusit) mund të sigurojë informacion të dobishëm në lidhje me dokumentin e kërkuar.

Në mënyrë që informacioni i mësipërm të futet pa mundim në enigmë, mungon një shembull specifik. Ne do ta shikojmë atë duke përdorur një nga (ky shfletues ueb është mjeti im i punës) i quajtur HTTP Headers.

Është i përshtatshëm sepse jep një pamje të plotë të ndërveprimit klient-server, duke ofruar përmbajtje në "një shishe" Kërkesa (kërkesë) HTTP dhe përgjigja (përgjigje). Shikoni dokumentin që prodhoi kjo shtojcë kur ndiqni një lidhje nga një faqe e blogut tim në një tjetër:

Këtu në krye është metoda GET, me të cilën shfletuesi akseson serverin, si dhe statusi i faqes, i shënuar me kodin e statusit 200 OK, i cili bën të qartë se serveri ka transmetuar të gjitha të dhënat në lidhje me atë të kërkuar. faqe interneti.

Gjithashtu me interes Titujt HTTP, treguar me poshte. Për shembull, artikulli "Referues" jep informacion në formën e URL-së nga e cila është bërë kalimi.

Drejtimi "Agjenti i përdoruesit" pasqyron saktësisht aplikacionin e klientit që dërgoi kërkesën në serverin e uebit. Në këtë rast, ky është një shfletues, por mund të ketë të tjerë (pajisje celulare, robotë kërkimi, etj.). Të dhënat e paraqitura në Agjentin e Përdoruesit janë të nevojshme që softueri i serverit të identifikojë aplikacionin që dërgon kërkesën.

Vetëm robotët e motorëve të kërkimit, të cilat skanojnë faqet e faqeve të internetit për të marrë informacione që ndikojnë në renditjen, janë me interes parësor për ne, sepse janë ata që vendosin për fatin e një faqeje të caktuar për sa i përket efektivitetit të promovimit të saj.

Kjo është arsyeja pse në botimin e ardhshëm unë planifikoj të ndalem më në detaje se si të shikojmë titujt HTTP dhe të kontrolloj kodet e përgjigjes së serverit posaçërisht për një kërkesë roboti, e cila është jashtëzakonisht e rëndësishme për webmasterët në dritën e optimizimit të burimeve të SEO. Prandaj, abonohuni për të marrë artikullin më të fundit në kohën e duhur.

Çfarë është e veçantë për protokollin e sigurt HTTPS?

Jam i sigurt se të gjithë përdoruesit e internetit, pa përjashtim, përfshirë fillestarët, janë të vetëdijshëm për ekzistencën e një protokolli të veçantë të quajtur HTTPS (Hypertext Transfer Protocol Secure), i cili shërben për mbrojtjen e të dhënave personale në shërbimet ku përdoret transferimi i tyre (sistemet e pagesave, online dyqane, portale të mëdha të specializuara, etj.) d.).

Nëse futni adresën e faqes së një siti të ngjashëm, kjo lidhje do të tregohet në një mënyrë të veçantë. Në Google Chrome (), për shembull, do të shfaqet një dry me mbishkrimin "Trusted" në të gjelbër, kur të klikoni mbi të do të shihni disa informacione që lidhen me mbrojtjen e të dhënave personale:

Çfarë është HTTPS? Në mënyrë të rreptë, nuk është një protokoll i pavarur. Ky është HTTP standard, i cili funksionon përmes mekanizmave TLS ose SSL, i aftë për të garantuar enkriptim, i cili parandalon hakerat të përgjojnë dhe marrin të dhëna konfidenciale.

Si parazgjedhje, kur përdorni një protokoll të sigurt, përdoret porti 443 (nëse ju kujtohet, për HTTP standarde është 80). Kriptimi HTTPS përdor gjatësitë kryesore prej 40, 56, 128 dhe 256 bit (). Sidoqoftë, dy opsionet e para as nuk duhet të merren parasysh, pasi ato nuk mund të ofrojnë një nivel të mjaftueshëm sigurie.

Kohët e fundit, motorët e kërkimit, veçanërisht Google, kanë bindur në mënyrë aktive pronarët e të gjitha faqeve që të kalojnë në një protokoll të sigurt, duke lënë të kuptohet në mënyrë delikate se kjo pikë do të merret parasysh gjatë renditjes. Si rezultat, tani shumë burime (madje edhe bloge të rregullta), dhe jo vetëm sajte të lidhura ngushtë me transferimin e të dhënave personale, tashmë punojnë me HTTPS.

Për më tepër, hostet kryesorë ofrojnë blerjen e një certifikate të sigurt SSL, e cila është e nevojshme për të mundësuar një lidhje të sigurt.

Sigurisht, ne nuk kemi marrë parasysh të gjitha nuancat e përdorimit të protokollit HTTP (HTTPS), nga të cilat ka shumë. Kjo temë mund të marrë disa manuale mbresëlënëse. Megjithatë, aspektet kryesore që do të jenë të dobishme si për përdoruesin e avancuar ashtu edhe për webmaster janë të mbuluara. Nëse ende nuk jeni të kënaqur me sasinë e informacionit të marrë, mund ta plotësoni lehtësisht nga ligjërata e mëposhtme video, e cila, në veçanti, flet më në detaje për metodat:

Protokolli HTTP ose HyperText Transfer Protocol është protokolli kryesor (i World Wide Web). Detyra kryesore e protokollit është të sigurojë transmetimin e hipertekstit në rrjet. Protokolli përshkruan saktësisht formatin e mesazhit për shkëmbimin e klientëve dhe serverëve.

Protokolli HTTP përshkruhet në RFC 2616 (HTTP1.1).

Baza e protokollit është të sigurojë ndërveprimin midis klientit dhe serverit duke përdorur një kërkesë ASCII dhe përgjigjen e mëposhtme ndaj saj në standardin RFC 822 MIME.

Në praktikë, protokolli HTTP funksionon në portin 80, por mund të konfigurohet ndryshe. Dhe megjithëse TCP/IP nuk është i detyrueshëm, ai mbetet i preferueshëm, pasi kujdeset për ndarjen dhe montimin e mesazheve dhe nuk "sforcon" as shfletuesin dhe as serverin.

Duhet të theksohet se protokolli HTTP mund të përdoret jo vetëm në teknologjitë e uebit, por edhe në aplikacione të tjera OOP (të orientuar drejt objektivave).

URL

Baza e komunikimit në ueb klient-server është kërkesa. Kërkesa dërgohet duke përdorur një URL - Gjetësi Uniform i Burimeve të Internetit. Më lejoni t'ju kujtoj se çfarë është një URL.

Një strukturë e qartë dhe e thjeshtë URL përbëhet nga elementët e mëposhtëm:

• Protokolli;
• Mikpritës;
• Porti;
• Drejtoria e burimeve;
• Etiketat (Pyetje).

Shënim: Protokolli http është një protokoll për lidhje të thjeshta dhe jo të sigurta. Lidhjet e sigurta funksionojnë duke përdorur protokollin https. Është më i sigurt për shkëmbimin e të dhënave.

Metodat e kërkesës HTTP

Një nga parametrat e URL-së specifikon emrin e hostit me të cilin duam të komunikojmë. Por kjo nuk mjafton. Ju duhet të përcaktoni veprimin që duhet të bëni. Kjo mund të bëhet duke përdorur një metodë të përcaktuar nga protokolli HTTP.

Metodat HTTP

• Metoda/Përshkrimi
• HEAD/Lexoni titullin e faqes në internet
• GET/Lexo faqen e internetit
• POST/Shto në faqen e internetit
• PUT/Ruaj faqen e internetit
• GJURMIMI/Kërkesa për dërgim
• FSHI/Fshi një faqe interneti
• OPTIONS/Opsionet e ekranit
• LIDHUR/E rezervuar për përdorim në të ardhmen

Le të shohim metodat HTTP në më shumë detaje

Metoda GET. kërkon një faqe (skedar, objekt) të koduar duke përdorur standardin MIME. Kjo është metoda më e përdorur. Struktura e metodës:
GET emri i skedarit HTTP/1.1

Metoda KOKË. Kjo metodë kërkon kokën e mesazhit. Megjithatë, faqja nuk ngarkohet. Kjo metodë ju lejon të zbuloni herën e fundit që është rifreskuar faqja, e cila është e nevojshme për të menaxhuar cache-in e faqes. Kjo metodë ju lejon të kontrolloni funksionalitetin e URL-së së kërkuar.

Metoda PUT. Kjo metodë mund ta vendosë faqen në server. Trupi i kërkesës PUT përfshin faqen që do të presë, e cila është e koduar MIME. Kjo metodë kërkon identifikimin e klientit.

Metoda POST. Kjo metodë shton përmbajtje në një faqe ekzistuese. Përdoret si shembull për të shtuar një postim në një forum.

Metoda DELETE. Kjo metodë shkatërron faqen. Metoda e fshirjes kërkon konfirmimin e të drejtave të përdoruesit për fshirje.

Metoda TRACE. Kjo është një metodë korrigjimi. Ai udhëzon serverin të dërgojë kërkesën përsëri dhe e lejon atë të dijë nëse kërkesa e klientit është e dëmtuar apo jo kur kthehet nga serveri.

Metoda LIDHJE– metoda rezervë, e pa përdorur.

Metoda OPTIONS ju lejon të kërkoni vetitë e serverit dhe vetitë e çdo skedari.

Në komunikimin kërkesë-përgjigje ndërmjet klientit dhe serverit, serveri domosdoshmërisht gjeneron një përgjigje. Kjo mund të jetë një faqe interneti ose një shirit statusi me një kod statusi. Ju e dini mirë kodin e statusit. Një nga kodet është kodi i njohur 404 – Faqja nuk u gjet.

Grupet e kodit të statusit

1хх: Gatishmëria e serverit, Kodi 100 - serveri është gati të përpunojë kërkesat e klientit;

2xx: Suksese.

• Kodi 200 – kërkesa u përpunua me sukses;
• Kodi 204 – Pa përmbajtje.

3xx: Ridrejtimi.

• Kodi 301 – Faqja e kërkuar është zhvendosur;
• Kodi 304 - Faqja në cache është ende e rëndësishme.

4xx: Gabim klienti.