URL(Lokues Uniform i Burimeve)- lokalizues (lokator) uniform i burimit. URLështë një mënyrë e standardizuar e regjistrimit të adresës së një burimi në internet.

URI(Identifikuesi uniform i burimit)- identifikues i unifikuar (uniform) i burimit. URIështë një sekuencë karakteresh që identifikon një burim abstrakt ose fizik.

URI - është më shumë koncept i përgjithshëm sesa një URL. Një URI jo gjithmonë tregon se si të merret një burim, ndryshe nga një URL, por vetëm e identifikon atë. Një URL është një URI që, përveç identifikimit të një burimi, gjithashtu ofron informacion për vendndodhjen e atij burimi. Në të vërtetë, çdo URL përmban informacion të mjaftueshëm për të gjetur me saktësi faqen. Më vonë gjatë këtij kursi, kur përdorim adresat e faqeve, ne do t'i përmbahemi shkurtesave të URL-së.

Struktura e adresës së faqes

Kthehu tek URL http://school.it2moro.ru/ . Mund të ndahet në 3 pjesë:

1. http://
2. shkolla
3. it2moro

Pjesa e parë adresat (http://) përcakton protokollin për ndërveprimin ndërmjet shfletuesit dhe serverit. Në rastin tonë, ky është protokolli HTTP, i cili do të diskutohet më vonë.

Pjesa e dytë shiriti i adresave quhet SUBdomain, dhe e treta - domain. Ato shërbejnë për të identifikuar një faqe të veçantë duke përdorur shërbimin DNS. DNS (Sistemi i emrave të domenit, sistemi i emrave të domenit) - kompjuter sistemi i shpërndarë për informacion në lidhje me domenet. Më së shpeshti përdoret për të marrë një adresë IP nga emri i hostit (kompjuteri ose pajisja). Ka një numër të madh serverësh DNS në rrjet që, me emrin e domenit të një burimi, mund të "sugjerojnë" vendndodhjen e tij reale, të përcaktuar nga adresa IP.

Kodi burimor i faqes HTML

Tani le të shohim se çfarë merr shfletuesi në përgjigje të kërkesës së krijuar HTTP. Një faqe mund të përbëhet nga tekst, fotografi, hiperlidhje, fusha hyrëse, butona dhe elementë të tjerë. Informacioni për të gjithë këtë u transferua nga serveri në internet në shfletuesin, i cili gjeneroi pamjen përfundimtare të faqes. Të dhënat e transmetuara përshkruhen duke përdorur protokollin HTML.

HTML(Gjuha e shënjimit të hipertekstit, gjuha e shënjimit të hipertekstit)është gjuha standarde e shënimit për dokumentet në internet. gjuha HTML interpretuar nga shfletuesi dhe shfaqet si një dokument në një formë të lexueshme nga njeriu.

Mund të themi se shfletuesit kryejnë dy funksione kryesore - ky është ndërveprimi me serverët e uebit përmes Kërkesat HTTP , si dhe konvertimin e kodit HTML të marrë nga serveri në një paraqitje vizuale.

URI (Identifikues Uniform i Burimeve) është një identifikues uniform (uniform) i burimit. URI - një varg karakteresh që ju lejon të identifikoni çdo burim: një dokument, imazh, skedar, shërbim, kuti e-mail, etj. Para së gjithash, ne po flasim, natyrisht, për burimet e internetit dhe në mbarë botën Web. URI ofron një mënyrë të thjeshtë dhe të zgjerueshme për të identifikuar burimet. Zgjerimi i URI-ve do të thotë që tashmë ekzistojnë disa skema identifikimi brenda URI-ve dhe do të krijohen të tjera në të ardhmen.

Marrëdhënia midis URI, URL dhe URN

Diagrami i Venit që tregon nëngrupet e skemës URI: URL dhe URN.

Një URI është ose një URL ose një URN ose të dyja.

• Një URL është një URI që, përveç identifikimit të një burimi, gjithashtu ofron informacion për vendndodhjen e atij burimi.
• Një URN është një URI që identifikon vetëm një burim në një hapësirë ​​të caktuar emri (përkatësisht, në një kontekst specifik), por nuk specifikon vendndodhjen e tij. Për shembull, urn URN:ISBN:0-395-36341-1 është një URI që tregon burimin (libri) 0-395-36341-1 në hapësirën e emrave ISBN, por ndryshe nga një URL, një URN nuk tregon vendndodhja e atij burimi: nuk thotë se në cilin dyqan mund të blihet ose në cilën faqe të shkarkohet.

Meqenëse një URI nuk tregon gjithmonë se si të merret një burim, ndryshe nga një URL, por vetëm e identifikon atë, kjo bën të mundur përshkrimin e përdorimit të burimeve RDF (Resource Description Framework) që nuk mund të merren nëpërmjet internetit (për shembull, një person, një makinë, qytet, etj.).

Historia

Në vitin 1990, në Gjenevë, Zvicër, brenda mureve të Këshillit Evropian për Kërkime Bërthamore, shkencëtari britanik Tim Berners-Lee shpiku gjetësin e burimeve URL. Meqenëse URL-ja është nëngrupi më i përdorur i URI-së, i njëjti vit 1990 konsiderohet të jetë viti i lindjes së URI-së. Por në mënyrë rigoroze, koncepti URI u dokumentua vetëm në qershor 1994 në RFC 1630.

Një version i ri URI u përcaktua në 1998 në RFC 2396, në të njëjtën kohë fjala Universale emri u ndryshua në Uniformë.

disavantazhet

URL-ja ishte një risi themelore në internet, kështu që parimet URI u dokumentuan të jenë plotësisht të pajtueshme me URL-të. Këtu erdhi pengesa e madhe e URI-së, e cila erdhi si një trashëgimi nga URL-ja. URI-të, si URL-të, mund të përdorin vetëm një grup të kufizuar karakteresh latine dhe shenjash pikësimi (madje edhe më të vogla se ASCII). Me fjalë të tjera, nëse duam të përdorim karaktere cirilike, ose hieroglife, ose, të themi, karaktere specifike të gjuhës frënge, në URI, atëherë do të duhet të kodojmë URI-në në të njëjtën mënyrë që kodohen URL-të me karaktere Unicode. Wikipedia. Për shembull, një linjë si:

https://en.wikipedia.org/wiki/Cyrillic

koduar në URL si:

https://ru.wikipedia.org/wiki/%D0%9A%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%86%D0%B0

Meqenëse shkronjat e të gjitha alfabeteve i nënshtrohen një transformimi të tillë, përveç atij të përdorur në gjuhe angleze Karakteret latine, pastaj URI-të me fjalë në gjuhë të tjera (madje edhe ato evropiane) humbasin aftësinë e tyre për t'u perceptuar nga njerëzit. Dhe kjo është në kundërshtim të madh me parimin e internacionalizmit të shpallur nga të gjitha organizatat kryesore të internetit, përfshirë W3C dhe ISOC. Ky problem synohet të zgjidhet me standardin IRI. Identifikuesi i Burimeve të Ndërkombëtarizuara) janë identifikues të burimeve ndërkombëtare në të cilët karakteret e Unicode mund të përdoren pa probleme dhe që nuk do të cenonin të drejtat e gjuhëve të tjera. Gjithashtu, krijuesi i URI-së, Tim Berners-Lee, tha se sistemi i emrave të domenit që qëndron në themel të URL-së është vendim i keq, e cila imponon një arkitekturë hierarkike mbi burimet që nuk janë të përshtatshme për ueb-in e hipertekstit.

Struktura URI

URI = [skema ":"] hierarkike - pjesa [ "?" kërkesë ] [ fragment "#" ]

Në këtë hyrje:

Skema

skema e aksesit në burim (shpesh tregon një protokoll rrjeti), p.sh. http, ftp, skedar, ldap, mailto, urn

pjesë hierarkike

përmban të dhëna, zakonisht të organizuara në formë hierarkike, të cilat së bashku me të dhënat në një komponent johierarkik hetim, përdoren për të identifikuar një burim brenda objektit të një skeme URI. Zakonisht pjesë hierarkike përmban shtegun drejt burimit (dhe ndoshta, përpara tij, adresën e serverit në të cilin ndodhet) ose identifikuesin e burimit (në rastin e një URN).

hetim

ky komponent opsional URI është përshkruar më sipër.

Fragment

(gjithashtu opsionale)

Ju lejon të identifikoni në mënyrë indirekte një burim dytësor duke iu referuar primarit dhe duke specifikuar informacion shtese. Një burim dytësor i identifikueshëm mund të jetë një pjesë ose nëngrup i një primar, një përfaqësim i tij ose një burim tjetër i përcaktuar ose përshkruar nga një burim i tillë.

Analiza e strukturës URI. Për të ashtuquajturin URI "parsing" (eng. analizë), domethënë, për të zbërthyer një URI në pjesët përbërëse të tij dhe identifikimin e tyre pasues, është më e përshtatshme të përdoret sistemi i shprehjes së rregullt, i cili tani është i disponueshëm në pothuajse të gjitha gjuhët moderne programimit. RFC 3986 rekomandon përdorimin e modelit të mëposhtëm për të analizuar një URI:

Ky model përfshin 9 grupet e treguara më sipër me numra (për më shumë mbi modelet dhe grupet, shihni Shprehjet e rregullta), të cilat analizojnë plotësisht dhe saktë strukturën tipike të një URI, ku:

• grupi 2 - skema,
• grupi 4 - burimi,
• grupi 5 - rruga,
• grupi 7 - kërkesa,
• grupi 9 - fragment.

Kështu, nëse përdorni këtë model për të analizuar, për shembull, një URI tipike:

http://www.ics.uci.edu/pub/ietf/uri/#I ngjashëm

atëherë 9 grupet e mësipërme të modeleve do të prodhojnë respektivisht rezultatet e mëposhtme:

1. http:
2. //www.ics.uci.edu
3. www.ics.uci.edu
4. /pub/ietf/uri/
5. asnjë rezultat
6. asnjë rezultat
7. #I lidhur
8. të lidhura

Shembuj URI:

URI absolute

• https://ru.wikipedia.org/wiki/URI
• ftp://ftp.is.co.za/rfc/rfc1808.txt
• file://C:\UserName.HostName\Projects\Wikipedia_Articles\URI.xml
• file:///C:/file.wsdl
• file:///Users/John/Documents/Projects/Web/MyWebsite/about.html
• ldap:///c=GB?objectClass?one
• mailto: [email i mbrojtur]
• gllënjka: [email i mbrojtur]
• lajmet:comp.infosystems.www.servers.unix
• data:text/plain;charset=iso-8859-7,%be%be%be
• tel: +1-816-555-1212
• telnet://192.0.2.16:80/
• urn:oasis:emrat:specifikimi:docbook:dtd:xml:4.1.2

2) URI-të relative

• /relative/URI/with/absolute/path/to/resource.txt
• //example.org/scheme-relative/URI/with/absolute/path/to/resource.txt
• relative/path/to/resource.txt
• ../../../resource.txt
• burimi.txt
• /resource.txt#frag01
• #frag01

[vargu bosh] - ekuivalente me analizimin e identifikuesit nga analizuesi me rezultatin [vargu bosh], d.m.th. lidhja të çon në objektin e paracaktuar në skemën e paracaktuar

Shërbimi DNS

DNS - sistemi i emrave të domenit. Emrat e domeneve DNS janë sinonim me një adresë IP, ashtu si emrat në librin e adresave të telefonit tuaj janë sinonim me numrat e telefonit. Ato janë karaktere, jo numerike; ato janë më të përshtatshme për memorizimin dhe orientimin; kanë kuptim. www.irnet.ru → tabelat DNS →193.232.70.36 Emrat e domeneve janë gjithashtu unikë, d.m.th. Nuk ka dy emra domenesh identike në botë. Emrat e domenit, ndryshe nga adresat IP, janë opsionale, ato blihen veçmas.

Oriz. 2. Hierarkia në sistemin DNS.

Gjithashtu unike janë adresat që tregohen në zarfe kur dërgoni letra me postë të rregullt. Nuk ka shtete në botë me të njëjtin emër. Dhe nëse emrat e qyteteve përsëriten ndonjëherë, atëherë në kombinim me ndarjen në njësi më të mëdha administrative si rrethe dhe rajone, ato bëhen unike. Dhe emrat e rrugëve nuk duhet të përsëriten brenda të njëjtit qytet. Kështu, një adresë e bazuar në emra gjeografikë dhe administrativë identifikon në mënyrë unike një destinacion. Domenet kanë një hierarki të ngjashme. Emrat e domeneve ndahen nga njëri-tjetri me pika: lingvo.yandex.ru, krkime.com.

DNS ka karakteristikat e mëposhtme:

• Shpërndarja e administratës. Njerëz ose organizata të ndryshme janë përgjegjëse për pjesë të ndryshme të strukturës hierarkike.
• Shpërndarja e ruajtjes së informacionit. Çdo nyje rrjeti duhet domosdoshmërisht të ruajë vetëm ato të dhëna që përfshihen në të fushën e përgjegjësisë, dhe (ndoshta) adresat serverët DNS rrënjë.
• Memoria e informacionit. Nyjë ndoshta ruajnë një sasi të caktuar të dhënash jo nga zona e tyre e përgjegjësisë për të reduktuar ngarkesën në rrjet.
• Struktura hierarkike, në të cilën të gjitha nyjet kombinohen në një pemë, dhe secila nyje mund të përcaktojë në mënyrë të pavarur punën e nyjeve në rrjedhën e poshtme, ose deleguar(transmetojnë) ato në nyje të tjera.
• Rezervimi. Disa serverë (zakonisht) janë përgjegjës për ruajtjen dhe mirëmbajtjen e nyjeve (zonave) të tyre, të ndara si fizikisht ashtu edhe logjikisht, gjë që siguron sigurinë e të dhënave dhe vazhdimin e punës edhe nëse njëri prej nyjeve dështon.

Nivelet e domenit. Ekzistojnë tre nivele domenesh.

Domenet së pari ose niveli më i lartë ndahen ne dy grupe:

1) Këto janë domene me përkatësi territoriale, për shembull: .ru .by .ua .de .us, etj. Domethënë, këto janë domene që i janë caktuar një vendi të caktuar. Duke i përdorur ato, për shembull, mund të përcaktoni se cilit shtet i përket një sajt i caktuar.

2) Grupi i dytë i domeneve të nivelit të parë janë domene të një qëllimi specifik. Për shembull: .com - për organizatat tregtare, .info - për faqet informative, .tv - për kompanitë televizive, etj. Këto domene mund të përcaktojnë fokusin specifik të faqes. Edhe pse, të themi të drejtën, kohët e fundit ato janë përdorur gjithnjë e më shumë për çdo qëllim dhe shpesh nuk i përmbahen qëllimit të tyre.

Domenet e nivelit të lartë nuk mund të përdoren si adresa e faqes suaj. Ato shërbejnë për të krijuar domene niveli i dytë , kështu që ju mund të regjistroni një domen të nivelit të dytë në cilindo nga domenet e nivelit të parë. Domeni i nivelit të dytë përbëhet nga elementët e mëposhtëm: www.site_name.domeni i nivelit të parë. Për shembull: www.webmastermix.ru. Rekomandohet përdorimi i emrave të domeneve të nivelit të dytë për adresën e faqes në internet. Ata lexohen dhe mbahen mend më së miri nga njerëzit, si dhe perceptohen nga motorët e kërkimit. Prandaj, shumica e faqeve kanë emra domenesh të këtij niveli të veçantë.

Përveç kësaj, ka domene niveli i tretë . Ato krijohen në bazë të domeneve të nivelit të dytë. Domeni i nivelit të tretë duket si ky: www.forum.webmastermix.ru. Duke regjistruar një domen të nivelit të dytë, ju mund të krijoni në mënyrë të pavarur sa më shumë domene të nivelit të tretë sipas tij sipas dëshirës. Ju mund të regjistroni një emër domaini për faqen tuaj duke përdorur shërbime speciale.

TEKNOLOGJI WEB: HTML, JAVASCRIPT

Pjesa e parë e bllokut didaktik mbi këtë temë iu kushtua teknologjive të internetit. Tani fillojmë të studiojmë teknologjitë e përdorura në rrjet i gjere boteror, ose teknologjive të internetit.

Së pari ju duhet të kuptoni konceptet themelore të teknologjive të internetit: një faqe interneti dhe një faqe interneti. Një faqe ueb është njësia më e vogël logjike e World Wide Web, e cila është një dokument që identifikohet në mënyrë unike nga një URL unike. Një faqe interneti është një grup faqesh interneti të lidhura tematikisht të vendosura në të njëjtin server dhe në pronësi të të njëjtit pronar. Në një rast të veçantë, një faqe interneti mund të përfaqësohet nga një faqe interneti e vetme. World Wide Web është koleksioni i të gjitha faqeve të internetit.

Baza e të gjithë World Wide Web është gjuha e shënjimit të hipertekstit HTML - Hyper Text Markup Language (Fig. 3). Shërben për shënimin logjik (semantik) të një dokumenti (faqe web). Ndonjëherë keqpërdoret për të kontrolluar mënyrën se si shfaqet përmbajtja e faqes së internetit në një ekran monitori ose kur del në një printer, gjë që është thelbësisht në kundërshtim me ideologjinë e adoptuar në World Wide Web.

Oriz. 3. Teknologjitë e internetit

Fletët e stilit Cascading (CSS) janë krijuar për të kontrolluar shfaqjen e përmbajtjes së faqes së internetit. CSS është në shumë mënyra të ngjashme me stilet e përdorura në përpunuesin popullor të fjalëve Word.

Gjuhët e skriptimit përdoren për t'i dhënë dinamikë faqeve të internetit (menytë me zbritje, animacione). Gjuha standarde e skriptimit në World Wide Web është JavaScript. Thelbi i gjuhës JavaScript është ECMAScript.

HTML, CSS, JavaScript janë gjuhët me të cilat mund të krijoni faqe interneti në mënyrë arbitrare komplekse. Por kjo është vetëm dispozitë gjuhësore, ndërsa në shfletues dokumentet paraqiten si një grup objektesh, grupi i llojeve të të cilave është Modeli i Objekteve të Shfletuesit (BOM). Modeli i objektit të shfletuesit është unik për secilin model, dhe për këtë arsye ka probleme gjatë krijimit të aplikacioneve ndër-shfletues. Prandaj, Konsorciumi i Uebit propozoi modeli i objektit dokument (DOM), i cili është një mënyrë standarde e paraqitjes së faqeve në internet duke përdorur një grup objektesh.

Sintaksë HTML moderne përshkruar duke përdorur një gjuhë të zgjeruar Shënimi XML– Gjuha e zgjerueshme e shënjimit. XML do t'ju lejojë të krijoni gjuhët tuaja të shënjimit, të ngjashme me HTML në formën e një DTD. Ka shumë gjuhë të tilla: për paraqitjen e formulave matematikore dhe kimike, njohuritë etj.

Siç mund të shihet nga sa më sipër, të gjitha teknologjitë e internetit janë të ndërlidhura ngushtë. Kuptimi i këtij fakti do ta bëjë më të lehtë për të kuptuar qëllimin e një mekanizmi të veçantë të përdorur për krijimin e aplikacioneve në internet.

EMAIL

Posta elektronike (email, e-mail, nga posta elektronike angleze) është një teknologji dhe shërbimet që ajo ofron për dërgimin dhe marrjen e mesazheve elektronike (të quajtura "letra" ose " emailet”) nga shpërndarja rrjeti kompjuterik. Dallimi kryesor nga sistemet e tjera të mesazheve është mundësia e dërgimit të vonuar dhe një sistem i zhvilluar i ndërveprimit midis serverëve të pavarur të postës.

E-mail bën të mundur dërgimin dhe marrjen e mesazheve, përgjigjen automatikisht në letrat e korrespondentëve duke përdorur adresat e tyre, dërgimin e kopjeve të një letre tek disa marrës në të njëjtën kohë, përcjelljen e letrës së marrë në një adresë tjetër, përdorimin e emrave logjikë në vend të adresave (numerike ose emrat e domain), krijoni disa nënseksione të kutisë postare për të gjitha llojet e korrespondencës, përfshini skedarët e tekstit me shkronja, përdorni sistemin "reflektori i postës" për të zhvilluar diskutime me një grup korrespondentësh tuaj, etj. Për të dërguar një mesazh postar me e-mail, duhet të specifikoni adresën e kutisë postare. Kutia postare e një abonenti të postës elektronike është një zonë në hard diskun e një serveri postar kushtuar një përdoruesi.

Zhvillimi i teknologjisë së internetit ka çuar në shfaqjen e protokolleve moderne për mesazhe, të cilat ofrojnë mundësi të mëdha për përpunimin e letrave, një shumëllojshmëri shërbimesh dhe lehtësinë e përdorimit. Për shembull, Protokolli SMTP, i cili funksionon në parimin klient-server, është krijuar për të dërguar mesazhe nga një kompjuter te një adresues. Normalisht, qasja në serverin SMTP nuk mbrohet me fjalëkalim, kështu që çdo server i njohur në rrjet mund të përdoret për të dërguar postë. Ndryshe nga serverët për dërgimin e letrave, qasja në serverë për ruajtjen e mesazheve mbrohet me një fjalëkalim. Prandaj, duhet të përdorni një server ose shërbim që ka Llogaria. Këta serverë përdorin protokollet POP dhe IMAP, të cilat ndryshojnë në mënyrën se si ruhen mesazhet.

Në përputhje me protokollin POP3, mesazhet që mbërrijnë në një adresë specifike ruhen në server derisa të shkarkohen në kompjuter gjatë sesionit të ardhshëm. Pas shkarkimit të mesazheve, mund të shkëputeni nga rrjeti dhe të filloni të lexoni postën. Kështu, përdorimi i postës përmes protokollit POP3 është më i shpejti dhe më i përshtatshëm për t'u përdorur.

Protokolli IMAP është i përshtatshëm për ata njerëz që përdorin një lidhje të përhershme me rrjetin. Mesazhet e marra në adresë ruhen gjithashtu në server, por, ndryshe nga POP3, kur kontrolloni postën, së pari do të shkarkohen vetëm titujt e mesazheve. Vetë letra mund të lexohet pasi të keni zgjedhur titullin e mesazhit (ajo do të shkarkohet nga serveri). Është e qartë se me një lidhje dial-up, puna me postë duke përdorur këtë protokoll çon në humbje të pajustifikuar të kohës.

Ekzistojnë disa protokolle për marrjen dhe transmetimin e postës ndërmjet sistemeve me shumë përdorues.

Përshkrimi i shkurtër i disa prej tyre:

1) SMTP (Simple Mail Transfer Protocol)është një protokoll rrjeti i krijuar për transmetimin e postës elektronike në rrjetet TCP / IP, dhe transmetimi duhet domosdoshmërisht të iniciohet nga vetë sistemi transmetues.

MTA (Mail Transfer Agent) - agjent i transferimit të postës - është komponenti kryesor i sistemit të transferimit të postës në internet, i cili përfaqëson këtë kompjuter rrjeti për sistemin e postës elektronike të rrjetit. Zakonisht, përdoruesit nuk punojnë me MTA, por me programin MUA (Mail User Agent) - një klient e-mail. Në mënyrë skematike, parimi i ndërveprimit është paraqitur në figurë.

2) POP, POP2, POP3 (Protokolli i Postës)- tre protokolle mjaft të thjeshta jo të këmbyeshme, të krijuara për t'i dërguar postën një përdoruesi nga një server qendror postar, për ta fshirë atë prej tij dhe për të identifikuar një përdorues me emër/fjalëkalim. POP përfshin SMTP, i cili përdoret për të transferuar postë me origjinë nga një përdorues. Mesazhet e postës mund të merren në formën e titujve, pa marrë të gjithë letrën.

Pasi të vendoset një lidhje, protokolli POP3 kalon në tre gjendje të njëpasnjëshme.

1. Autorizimi Klienti kalon nëpër procedurën e vërtetimit
2. Transaksioni i klientit merr informacion për gjendjen e kutisë postare, pranon dhe fshin postën.
3. Përditësimi i serverit fshin emailet e zgjedhura dhe mbyll lidhjen.

3) IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 (Protokolli i Qasjes së Mesazheve në Internet) - i ofron përdoruesit mundësi të pasura për të punuar me kuti postare të vendosura në një server qendror

o IMAP ruan postën në server në drejtoritë e skedarëve dhe gjithashtu i ofron klientit mundësinë për të kërkuar vargje në mesazhet e postës në vetë serverin.

o IMAP2 - përdoret në raste të rralla.

o IMAP3 - zgjidhje e papajtueshme, e pa përdorur.

o IMAP2bis - Zgjerimi IMAP2, i lejon serverët të analizojnë strukturën MIME (Zgjatjet e postës në internet me shumë qëllime) të një mesazhi, përdoret ende sot.

o IMAP4 është një IMAP2bis i ridizajnuar dhe i përmirësuar që mund të përdoret kudo.

o IMAP4rev1 - Zgjeron IMAP me një grup të madh funksionesh, duke përfshirë ato të përdorura nga DMSP (Sistemi i shpërndarë i postës për kompjuterë personalë).

4) ACAP (Application Configuration Access Protocol) - një protokoll i krijuar për të punuar me IMAP4; shton mundësinë e një abonimi në kërkim dhe një abonim në tabelat e buletinit, kuti postare dhe përdoret për të kërkuar libra adresash.

5) DMSP (ose PCMAIL) është një protokoll për marrjen / dërgimin e postës, e veçanta e të cilit është se një përdorues mund të ketë më shumë se një stacion pune në përdorim. Stacioni i punës përmban informacione të statusit në lidhje me postën, drejtorinë përmes së cilës bëhet shkëmbimi, i cili, kur lidhet me serverin, përditësohet në gjendja e tanishme në serverin e postës.

6) MIME është një standard që përcakton mekanizmat për dërgimin e llojeve të ndryshme të informacionit përmes emailit, duke përfshirë tekstin në gjuhë të ndryshme nga anglishtja që përdorin kodime të karaktereve të ndryshme nga ASCII, si dhe përmbajtje binare 8-bit si fotografi, muzikë, filma dhe programe. .

Punë e pavarur.

Ekzekutoni shembullin e dhënë në tekst (prospekte) ruajeni në dosjen e vet në desktop.

9.2. Puna me një mësues:

Kur shfaqen probleme ose veprimet e gabuara kontaktoni mësuesin për të korrigjuar gabimet.

Në fund të orës së mësimit, tregoni mësuesit një raport mbi punën e kryer dhe merrni një kredi për këtë punë.

9.3. Kontrolli i nivelit fillestar dhe përfundimtar të njohurive:

Testimi kompjuterik .

Informacione të ngjashme.

Dhe kështu me radhë Së pari, ne po flasim, natyrisht, për burimet e internetit dhe World Wide Web. URI ofron një mënyrë të thjeshtë dhe të zgjerueshme për të identifikuar burimet. Zgjerimi i URI do të thotë se ka tashmë disa skema identifikimi brenda URI-ve dhe do të krijohen të tjera në të ardhmen.
Për më shumë detaje, shihni"Struktura URI" më poshtë.

Shembujt më të famshëm të URI-ve janë URN-të. Një URL është një URI që, përveç identifikimit të një burimi, gjithashtu ofron informacion për vendndodhjen e atij burimi. Dhe një URN është një URI që identifikon një burim në një hapësirë ​​të caktuar emri (dhe për rrjedhojë në një kontekst specifik). Për shembull, urn URN:ISBN:0-395-36341-1 është një URI që tregon burimin (libri) 0-395-36341-1 në hapësirën e emrit ISBN, por ndryshe nga një URL, një URN nuk tregon vendndodhjen e atij burimi. Megjithatë, kohët e fundit ka pasur një tendencë për të thënë thjesht URI për çdo varg identifikues, pa elaborim të mëtejshëm. Pra, ndoshta termat URL dhe URN së shpejti do të bëhen një gjë e së kaluarës.

Historia

Një version i ri i URI u përcaktua në 1998 në RFC 2396, në të njëjtën kohë fjala Universale emri u ndryshua në Uniformë. Në dhjetor 1999, RFC 2732 prezantoi ndryshime të vogla në specifikimin URI për të siguruar përputhshmërinë me gushtin 2002. RFC 3305 njoftoi zhvlerësimin e termit të URL-së dhe përparësisë së URI-së. Struktura dhe sintaksa aktuale e URI-ve rregullohet nga RFC 3986, i lëshuar në janar 2005. Shumë teknologjinë më të fundit Semantic Web (p.sh. RDF) bazohen në standardin URI. Tani roli kryesor në zhvillimin e URI i përket Konsorciumit World Wide Web.

disavantazhet

URL-ja ishte një risi themelore në internet, kështu që parimet URI u dokumentuan të jenë plotësisht të pajtueshme me URL-të. Këtu erdhi pengesa e madhe e URI-së, e cila erdhi si një trashëgimi nga URL-ja. Në një URI, si në një URL, mund të përdoret vetëm një grup i kufizuar karakteresh latine dhe shenjash pikësimi (madje më pak se në cirilik, ose hieroglifë, ose, të themi, karaktere specifike franceze, atëherë do të duhet të kodojmë URI-në në në të njëjtën mënyrë si në Wikipedia URL-të janë të koduara me karaktere Unicode... Për shembull, një varg si:

http://en.wikipedia.org/wiki/Microcredit

koduar në URL si:

http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0 %B8%D1%82

Meqenëse shkronjat e të gjitha alfabeteve i nënshtrohen një transformimi të tillë, përveç alfabetit latin të përdorur në anglisht, URI-të me fjalë në gjuhë të tjera (madje edhe ato evropiane) humbasin aftësinë e tyre për t'u perceptuar nga njerëzit. Dhe kjo është në kundërshtim të madh me parimin e internacionalizmit, të shpallur nga të gjitha organizatat kryesore të internetit, duke përfshirë W3C dhe IRI (eng. Identifikuesi i Burimeve Ndërkombëtare ) janë identifikues të burimeve ndërkombëtare në të cilët karakteret e Unicode mund të përdoren pa probleme dhe që nuk do të cenonin të drejtat e gjuhëve të tjera. Ndërsa është e vështirë të thuhet paraprakisht nëse identifikuesit do të jenë në gjendje ndonjëherë. Ky format synon të krijojë identifikues që janë plotësisht të pavarur nga konteksti, pra të pavarur nga protokolli, domeni, shtegu, aplikacioni dhe platforma. absolutisht i pavarur.

Gjithashtu, krijuesi i URI-së, Tim Berners-Lee, tha se sistemi i emrave të domenit që qëndron në bazë të URL-së është një vendim i keq, duke imponuar një arkitekturë hierarkike mbi burimet që nuk janë të përshtatshme për ueb-in e hipertekstit.

Struktura URI

Analiza e strukturës URI

Për të ashtuquajturin URI "parsing" (eng. analizë), domethënë, për zbërthimin e URI-ve në pjesët e tyre përbërëse dhe identifikimin e tyre të mëvonshëm, është më e përshtatshme të përdoret sistemi i shprehjes së rregullt, i cili tani është i disponueshëm në pothuajse të gjitha gjuhët moderne të programimit. Modeli i mëposhtëm rekomandohet për analizimin e një URI:

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))? 12 3 4 5 6 7 8 9

Ky model përfshin 9 grupet e treguara më sipër me numra (për më shumë mbi modelet dhe grupet, shihni Shprehjet e rregullta), të cilat analizojnë plotësisht dhe saktë strukturën tipike të një URI, ku:

• grupi 2 - skema,
• grupi 4 - burimi,
• grupi 5 - rruga,
• grupi 7 - kërkesa,
• grupi 9 - fragment.

Kështu, nëse përdorni këtë model për të analizuar, për shembull, një URI tipike:

http://www.ics.uci.edu/pub/ietf/uri/#I ngjashëm

atëherë 9 grupet e mësipërme të modeleve do të prodhojnë respektivisht rezultatet e mëposhtme:

1. http:
2. //www.ics.uci.edu
3. www.ics.uci.edu
4. /pub/ietf/uri/
5. asnjë rezultat
6. asnjë rezultat
7. #I lidhur
8. të lidhura

Dallimi midis URI dhe URL

Një URI jo gjithmonë tregon se si të merret një burim, ndryshe nga një URL, por vetëm e identifikon atë. Kjo bën të mundur përshkrimin e përdorimit të burimeve RDF (Resource Description Framework) që nuk mund të merren nëpërmjet internetit (për shembull, një person, një makinë, një qytet, etj.).

Shembuj URI

URI absolute

http://ru.wikipedia.org/wiki/URI ftp://ftp.is.co.za/rfc/rfc1808.txt skedari://C:\UserName.HostName\Projects\Wikipedia_Articles\URI.xml ldap: ///c=GB?objectClass?one mailto: [email i mbrojtur] gllënjka: [email i mbrojtur] news:comp.infosystems.www.servers.unix data:text/plain;charset=iso-8859-7,%be%fg%be tel:+1-816-555-1212 telnet://192.0.2.16:80 /urn:oasis:names:specification:docbook:dtd:xml:4.1.2

Lidhjet URI

/relative/URI/with/absolute/path/to/resource.txt relative/path/to/resource.txt ../../../resource.txt resource.txt /resource.txt#frag01 #frag01 [bosh linjë]

Shiko gjithashtu

Lidhjet

• RFC 3986 / STD 66 (nga 2005)
• RFC 2396 (datë 1998) - version i vjetëruar sintaksë

Shënime

Fondacioni Wikimedia. 2010 .

Shihni se çfarë është "Uri" në fjalorë të tjerë:

Uri- mund t'i referohet: Gjeografia: * Kantoni Uri është një kanton (rajon) i Zvicrës * Uri (Indi), një rajon dhe qytet në Kashmir * Uri (SS), një qytet në Sardenjë, Itali * Úri, një fshat në Pest qarku, Hungari * URI sumeriane, toka e AgadeURI, një tre… … Wikipedia

uro- URÎ, urăsc, vb. IV. 1.trans. A avea un puternic sentiment de antipatie, de duşmănie împotriva cuiva sau a ceva; a nu putea suferi pe cineva sau ceva. 2.refl. impers. (Construit cu dativul) A se plictisi, a se sătura de ceva sau de cineva. ♢… … Dicționar Roman

uri- urì interj., urỹ NdŽ, Jn, Aln, ùri kartojant 1. nusakomas puolančio šuns(ar šunų) urzgimas: Tik urỹ urỹ ir apipuolo mane šunes K.Būg(Ds). Urì urì šunes kad pradeda loti Šmn. ║ Ds sakoma pjudant šuniu. 2. Vžns nusakomas triukšmingas… … Fjalori i gjuhës lituaneze

Puna me URI

Çdo ditë ne përdorim Identifikuesit Uniform të Burimeve (URI) kur kërkoni diçka në WWW. URI-të nevojiten për të identifikuar dhe kërkuar lloji i ri burim. Duke përdorur një URI, ju mund të përdorni jo vetëm faqet e internetit, por edhe një server FTP, një shërbim Web dhe skedarë lokalë.

Termi përdoret shpesh në vend të URI Gjetësi uniform i burimeve (URL). URI është një term i përgjithshëm që përdoret për t'iu referuar burimeve. Një URL është një URI e lidhur me skemat e njohura URI si http, ftp dhe mailto. Në dokumentacionin teknik, termi URL nuk përdoret më.

Një term tjetër që mund ta dini tashmë - Emri uniform i burimit (URN). Një URN është një URI e standardizuar që përdoret për të identifikuar një burim, pavarësisht nga vendndodhja e tij në rrjet.

Le të analizojmë pjesët e një URI që i referohet një faqeje në faqen e internetit Global Knowledge:

http://www.globalknowledge.net:80/training/generic.asp?pageid=1078&country=DACH

Pjesa e parë e URI quhet skema (skema). Një skemë përcakton një hapësirë ​​emri URI dhe mund të ngushtojë sintaksën e një shprehjeje pas skemës. Shumë skema emërtohen sipas protokolleve përkatëse (si http, ftp) që përdorin, por kjo nuk është e detyrueshme. Në shembullin tonë, ID-ja e skemës është http. Kufizues i qarkut(// në këtë shembull) ndan skemën nga pjesa tjetër e URL-së.

Kufizuesi i skemës ndiqet nga emri i serverit ose adresa IP në shënim dhjetor me pika, p.sh. www.globalknowledge.net.

Pas emrit të serverit ose adresës IP është një numër porti që identifikon lidhjen me një aplikacion specifik në server. Nëse nuk specifikohet asnjë numër porti, përdoret numri i paracaktuar i portit për atë protokoll (për shembull, porta 80 për HTTP).

Mënyra specifikon faqen (dhe direktorinë) e burimit të kërkuar. Nuk përfaqëson domosdoshmërisht një skedar fizik në server, por mund të krijohet në mënyrë dinamike. Në këtë rast, shtegu është /training/generic.asp.

Nga rruga e simbolit? ndahet pjesa e fundit e kësaj URI, e quajtur pyetje. Në shembullin tonë, kërkesa përcaktohet nga vargu pageid=1078&country=DACH. Një varg pyetësor mund të përbëhet nga disa komponentë, secili prej të cilëve specifikon një variabël dhe një vlerë, të kombinuara me karakterin &. Komponentë të shumtë të pyetjeve mund të kombinohen me simbolin &. Pra, në shembullin tonë, komponenti i parë është pageid=1078 me variablin pageid të vendosur në 1078, dhe komponenti i dytë është country=DACH.

Seksionet brenda një burimi mund të identifikohen me fragmente. Fragmente përdoren për t'u lidhur me seksionet brenda një faqeje HTML. Në zhvillimin e faqeve të internetit, fragmentet quhen gjithashtu faqerojtës. Karakteri # ndan identifikuesin e fragmentit nga shtegu. Në URL-në http;//www.microsoft.com/net/basics/glossary.asp#NETFramework, fragmenti është vargu #NETFramework.

Nëse karakteri # i shtohet vargut të pyetjes, atëherë ai nuk është më një fragment. Një URL mund të përmbajë një varg pyetjesh ose një fragment, por jo të dyja.

Karaktere të shumta janë të rezervuara në URI - ato nuk mund të shfaqen në emrat e hosteve ose shtigjet sepse janë karaktere të veçanta kufizuese. Karakteret e mëposhtme janë të rezervuara në URI:

; / ? : @ & = + $ ,

Klasa Uri nga hapësira e emrave të Sistemit përmbledh Identifikuesin Uniform të Burimeve. Ai përmban veti dhe metoda për analizimin, krahasimin dhe kombinimin e URI-ve.

Ju mund të krijoni një objekt Uri duke kaluar një varg URI te konstruktori:

Uri baseURI = Uri i ri ("http://site");

Nëse tashmë ekziston një objekt bazë Uri, mund të krijoni një URI të re duke kombinuar URI-në bazë me një URI relative:

Uri baseURI = Uri i ri ("http://site"); Uri newURI = Uri i ri (baseURI, "my/csharp/web/level2/2_2.php");

Nëse URI bazë tashmë përmban një shteg, ai injorohet. URI i ri bazohet vetëm në skemën, portin dhe emrin e serverit.

Klasa Uri ka disa fusha statike vetëm për lexim që ju lejojnë të merrni disa nga skemat e përdorura zakonisht:

Uri.UriSchemeFile

Skema e skedarëve përdoret për të aksesuar skedarët lokalisht ose në burimet e rrjetit të përbashkët, të cilat mund të emërtohen sipas konventës qëllim universal emrat ( Konventa Universale e Emërtimit, UNC).

Uri.UriSchemeFtp

Protokolli FTP me skemën ftp përdoret për të marrë skedarë nga një server ftp dhe, anasjelltas, për të vendosur skedarë në një server ftp.

Uri.UriSchemeGopher

Protokolli Gopher ishte pararendësi i HTTP. Ai siguroi mundësinë për të parë në mënyrë hierarkike informacionin tekstual për përmbajtjen, i cili ishte më i lartë se FTP. Por shpejt u zëvendësua nga protokolli HTTP.

Uri.UriSchemeHttp, Uri.UriSchemeHttps

Këto dy skema janë të njohura: http dhe https. Skema https përdoret për shkëmbim të sigurt.

Uri.UriSchemeMailto

Skema mailto përdoret për të dërguar mesazhe postare.

Uri.UriSchemeNews, Uri.UriSchemeNntp

Skemat e lajmeve dhe nntp përdoren në grupet e lajmeve që përdorin protokollin NNTP.

Klasa Uri ka metoda statike për të kontrolluar skemën e saktë dhe emrin e hostit: Uri.CheckSchemeName() kthen true nëse emri i skemës është i saktë dhe metoda UriCheckHostName() jo vetëm që kontrollon emrin e hostit, por gjithashtu kthen një vlerë numërimi UriHostNameType që tregon llojin e hostit.

Klasa Uri ka shumë veti vetëm për lexim që ju lejojnë të përdorni të gjitha pjesët e një URI. Në tabelën e mëposhtme, ne përdorim URI-në e mësipërme si shembull për të demonstruar përdorimin e vetive:

AbsoluteUri	Kjo veçori tregon URI-në e plotë. Nëse numri i specifikuar porti për protokollin është i barabartë me numrin e portit të paracaktuar, konstruktori Uri e heq atë automatikisht. Për shembullin tonë, vlera e vetive AbsoluteUri duket si kjo: http://www.globalknowledge.net/t raining/generic.asp?pageid=1078&country=DACH. Nëse një emër skedari i kalohet konstruktorit të klasës Uri, vetia AbsoluteUri i paraprin automatikisht emrit të skedarit me skemën file://.
Skema	Skema është pjesa e parë e URI-së, dhe në këtë rast kjo veti kthen vlerën http.
Mikpritës	Vetia Host tregon emrin e hostit nga URI: www.globalknowledge.net
Autoriteti	Nëse numri i portit është i barabartë me numrin e paracaktuar të përdorur nga protokolli, vetia Autoritet tregon të njëjtin varg si vetia Host. Nëse përdoret një numër i ndryshëm porti, atëherë vetia Autoritet tregon edhe numrin e portit.
lloji i emrit të hostit	Lloji i emrit të hostit varet nga emri i përdorur. Në këtë rast, merret e njëjta vlerë e numërimit UriHostNameType që u diskutua më lart.
port	Duke përdorur veçorinë Port, merret numri i portit - 80.
Rruga Absolute	Rruga absolute fillon pas numrit të portit në URI dhe përfundon përpara vargut të pyetjes. Në këtë rast, është /training/generic.asp.
rrugë lokale	Rruga lokale jep vlerën /training/generic.asp. Siç mund ta shihni, për një kërkesë HTTP, nuk ka asnjë ndryshim midis AbsolutePath dhe LocalPath. Dallimi shfaqet nëse URI i referohet një burimi të rrjetit të përbashkët. Për një URI të skedarit të formës:\\server\share\directory\file.txt, vetia LocalPath kthen vetëm emrat e drejtorive dhe skedarëve, ndërsa vetia AbsolutePath përfshin emrat e serverit dhe të aksioneve.
Pyetje	Vetia Query tregon vargun që ndjek shtegun: ?pageid=1078&country=DACH.
PathAndQuery	Vetia PathAndQuery jep kombinimin e shtegut dhe vargut të pyetjes: /training/generic.asp?pageid=1078&country=DACH.
Fragment	Nëse shtegu ndiqet nga një fragment, ai kthehet në veçorinë Fragment. Rruga mund të ndiqet vetëm nga një varg pyetjesh ose një fragment. Fragmenti identifikohet me simbolin #
segmente	Vetia Segments kthen një grup vargjesh të formuar nga shtegu. Në këtë rast, kemi tre segmente: /, trainim/ dhe generic.asp.
Informacioni i përdoruesit	Emri i përdoruesit i vendosur në URI mund të lexohet nga vetia UserInfo. Kalimi i emrave të përdoruesve është i zakonshëm në Protokolli FTP, dhe nëse specifikohet një përdorues jo anonim, si p.sh. ftp:// [email i mbrojtur], atëherë vetia UserInfo do të kthejë myuser.

Përveç atyre të listuara, ka disa veçori të tjera që kthejnë vlerat boolean nëse URI përfaqëson një skedar, një shteg UNC, një adresë reagime ose nëse protokolli përdor numrin e paracaktuar të portit. Këto janë veçoritë IsFile, IsUnc, IsLoopback dhe IsDefaultPort, përkatësisht.

Për të hyrë në çdo burim rrjeti, duhet të dini se ku ndodhen dhe si mund të aksesohen. World Wide Web përdor një skemë të standardizuar adresimi dhe identifikimi, duke marrë parasysh përvojën e adresimit dhe identifikimit të e-mail, Gopher, WAIS, telnet, ftp dhe të ngjashme. - URL, Gjetësi Uniform i Burimeve.

URI(Identifikuesi Uniform i Burimeve, Identifikuesi Universal burim) (RFC 2396, gusht 1998) është një varg karakteresh kompakte për identifikimin e një burimi abstrakt ose fizik. Një burim është çdo objekt që i përket një hapësire. Përfshin dhe anashkalon URL-të e përcaktuara më parë (RFC 1738/RFC 1808) dhe URN-të (RFC 2141, RFC 2611).

URI synon të identifikojë në mënyrë unike çdo burim.

Disa nëngrupe të URI-ve:

URN(Uniform Resource Emri) - Një skemë private "urn:" URI me një nëngrup "namespace" që duhet të jetë unik dhe i pandryshuar edhe nëse burimi nuk ekziston më ose nuk është i disponueshëm.

Supozohet se, për shembull, shfletuesi e di se ku ta kërkojë këtë burim.

Sintaksë:

urn:namespace: data1.data2,more-data ku hapësira e emrit specifikon se si përdoren të dhënat pas ":"-së së dytë.

Shembull URN:

urna:ISBN: 0-395-36341-6

ISBN - klasifikues tematik për botuesit

0-395-36341-6 - numër specifik temat e një libri ose reviste

Me marrjen e një URN, programi i klientit hyn në ISBN (drejtoria "klasifikuesi i temës për botuesit" në internet). Dhe ai merr një dekodim të numrit të lëndës "0-395-36341-6" (për shembull: "kimia kuantike").

URN përdoret gjerësisht në rrjetet P2P (si edonkey).

Një shembull URN që tregon një imazh të diskut Adobe Photoshop v8.0 në rrjetin edonkey:

urn:ed2k://|skedar|AdobePhotoshopv8.0.iso|940769280|b34c101c90b6dedb4071094cb1b9f2d3|/

ed2k - tregon në një rrjet

Adobe Photoshop v8.0.iso - emri i skedarit

940769280 - madhësia në bajt

- identifikuesi i skedarit (llogaritur duke përdorur një funksion hash)

URL e unifikuar e gjetësit të burimeve:

URL(Uniform Resource Locator, RFC 1738) - një gjetës i unifikuar i burimeve (tregues), një mënyrë e standardizuar për të regjistruar një adresë burimi në WWW dhe në internet. URL-ja ka një strukturë fleksibël dhe të zgjerueshme për vendndodhjen më natyrale të burimeve në rrjet, e cila e identifikon burimin nga mënyra se si aksesohet (për shembull, "vendndodhja e tij në rrjet"), në vend që ta identifikojë atë me emrin ose atributet e tjera të këtij burimi.

Shembuj URL:

http://www.ipm.kstu.ru/index.php

ftp://www.ipm.kstu.ru/

Një grup i kufizuar karakteresh ASCII përdoret për të përfaqësuar një adresë.

Forma e përgjithshme e adresës mund të përfaqësohet si më poshtë:

<схема>://<логин>:<пароль>@<хост>:<порт>/<полный-путь-к-ресурсу >

skema e aksesit të burimeve: http, ftp, gopher, mailto, news, telnet, file, man, info, whatis, ldap, wais, etj.

Hyrja: Fjalëkalimi- emri i përdoruesit dhe fjalëkalimi i përdorur për të hyrë në burim

mikpritës emri i domenit të hostit ose adresa e tij IP.

Port- porta pritës për t'u lidhur

rruga e plotë drejt burimit - specifikimi i informacionit për vendndodhjen e burimit (varet nga protokolli).

Shembuj URL:

http://example.com #default kërkesë për faqen e fillimit

http://www.example.com/site/map.html #request faqe e dhënë në drejtorinë e specifikuar

http://example.com:81/script.php #connect to port jo standard

http://example.org/script.php?key=value #request me parametër që kalon në skript

ftp://user: [email i mbrojtur]#lidhu me serverin ftp me autorizim

http://192.168.0.1/example/www #lidhu me adresën e rrjetit

file:///srv/www/htdocs/index.html #hap skedarin lokal

gopher://example.com/1 #lidhu me serverin gopher

URL - Uniform Resource Locators përshkruan në mënyrë eksplicite se si të arrihet te objekti.

Ardhja e URL-ve është bërë një risi e rëndësishme në internet. Sidoqoftë, që nga shpikja e tij dhe deri më sot, standardi i URL-së ka një pengesë serioze - ai mund të përdorë vetëm një grup të kufizuar karakteresh, madje edhe më të vogla se në ASCII: shkronja latine, numra dhe vetëm disa shenja pikësimi - .

Nëse duam të përdorim karaktere cirilike, ose hieroglife, ose, të themi, karaktere specifike franceze në URL, atëherë karakteret që na duhen duhet të rikodohen në një mënyrë të veçantë.

Në Wikipedia në gjuhën ruse, dikush sheh shembuj çdo ditë kodimi url, pasi gjuha ruse përdor karaktere cirilike. Për shembull, një linjë si:

http://en.wikipedia.org/wiki/Microcredit

koduar në URL si:

http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0 %B8%D1%82

Një konvertim i tillë ndodh në dy faza: së pari, çdo karakter cirilik kodohet në Unicode (UTF-8) në një sekuencë prej dy bajtësh, dhe më pas çdo bajt i kësaj sekuence shkruhet në paraqitje heksadecimal:

M → D0 dhe 9C → %D0%9C

dhe → D0 dhe B8 → %D0%B8

në → D0 dhe BA → %D0%BA

p → D1 dhe 80 → %D1%80, etj.

Çdo kod i tillë heksadecimal bajti, sipas specifikimit të URL-së, paraprihet nga një shenjë përqindjeje (%) - prandaj edhe termi anglisht "encoding për qind" e ka origjinën, që tregon mënyrën se si karakteret janë të koduara në URL dhe URI.

Meqenëse shkronjat e të gjitha alfabeteve i nënshtrohen një transformimi të tillë, përveç alfabetit bazë latin, një URL me fjalë në shumicën dërrmuese të gjuhëve (përveç anglisht, italisht, latinisht) mund të bëhet e palexueshme për një person.

E gjithë kjo është në kundërshtim me parimin e internacionalizmit të shpallur nga të gjitha organizatat kryesore të internetit, duke përfshirë W3C dhe ISOC. Standardi IRI (International Resource Identifier) ​​është krijuar për të zgjidhur këtë problem - identifikuesit ndërkombëtarë të burimeve në të cilët karakteret Unicode mund të përdoren pa probleme, dhe për këtë arsye nuk do të cenonin të drejtat e gjuhëve të tjera.

Skema të tjera URL

Skema HTTP.

Skema specifikon identifikuesin e saj, adresën e makinës, portën TCP, shtegun në drejtorinë e serverit, variablat dhe vlerat e tyre, etiketën.

Sintaksë:

http://[ [:@][:][?]]

http - emri i skemës

përdorues - emër përdoruesi

host - emri i hostit

port - numri i portit

pyet (<имя-поля>=<значение>{&<имя-поля>=<значение>) - varg pyetjesh

Përcaktuar në RFC 2068. Si parazgjedhje, port=80.

Shembuj:
http://ipm.kstu.ru/internet/index.php

Ky është lloji më i zakonshëm i URI-së që përdoret në dokumentet WWW. Emri i skemës (http) ndiqet nga një shteg që përbëhet nga adresa e domenit të makinës dhe adresa e plotë e dokumentit HTML në pemë Server HTTP.

Një adresë IP mund të përdoret gjithashtu si një adresë makine:

http://195.208.44.20/internet/index.php

Nëse serveri i protokollit HTTP funksionon në diçka tjetër përveç 80 Porta TCP, atëherë kjo pasqyrohet në adresën:

http://195.208.44.20:8080/internet/index.php

http://195.208.44.20/internet/index.php#metka1
Karakteri "#" ndan emrin e dokumentit nga emri i etiketës.

Variablat dhe vlerat e tyre kalohen si më poshtë:
http://ipm.kstu.ru/internet/index.php?var1=value1&vard2=value2

Vlerat "var1" dhe "var2" janë emrat e ndryshoreve, dhe "vlera1" dhe "vlera2" janë vlerat e tyre.

Skema FTP

Kjo skemë ju lejon të adresoni arkivat e skedarëve FTP.

Sintaksë:

ftp://[ [:@][:]

ftp - emri i skemës

përdorues - emër përdoruesi

fjalëkalimi - fjalëkalimi i përdoruesit

host - emri i hostit

port - numri i portit

url-path - shtegu i skedarit dhe vetë skedari

Përcaktuar në RFC 1738. Si parazgjedhje, port=21, përdorues=anonim, fjalëkalim=adresa e emailit, nëse specifikohet një emër, por nuk ka fjalëkalim, kërkohet në dialog.

duket si:

//...//[;lloj= ], ku :

Shembuj: ftp://ipm.kstu.ru/students/name/

Për të specifikuar një emër përdoruesi dhe fjalëkalim, duhet të shkruani si kjo:
ftp://emri: [email i mbrojtur]://ipm.kstu.ru/students/name/

Në këtë rast, këta parametra ndahen nga adresa e makinës me simbolin "@" dhe nga njëri-tjetri me një dy pika.

Skema Mailto

Kjo skemë është për dërgimin e postës.

Sintaksë:

mailto:[ {,,...}][?]

mailto - emri i skemës

e-mail-1 ( @) - adresa e parë e emailit

përdorues - emër përdoruesi

host - emri i hostit

e-mail-2 - adresa e dytë e postës elektronike

pyet (<имя-поля-заголовка>=<значение>{&<имя-поля-заголовка>=<значение>) - varg pyetjesh

mailto: [email i mbrojtur]

Në këtë skemë kalohen fushat dhe vlerat e tyre:

mailto: [email i mbrojtur]?subject=Subject_of_the_mail&body=Text_to_be_embedded_in_the_mail

Adresa e marrësit mund të shkruhet gjithashtu si vlera e fushës për:

mailto: [email i mbrojtur]?subject=Subject_of_the_mail&body=Text_to_be_embedded_in_the_mail

Çfarë është HTTP?

Dokumenti i parë (por jo standard) është RFC1945 (Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk maj 1996)

Versioni i fundit është RFC2616 (Protokolli i Transferimit të Hipertekstit -- HTTP/1.1 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee qershor 1999)

Protokolli i Transferimit të Hipertekstit është një protokoll transferimi hiperteksti, një protokoll i nivelit të lartë (domethënë, i nivelit të aplikacionit). Përdoret nga shërbimi WWW për të transferuar faqe në internet.

HTTP (HyperText Transfer Protocol, RFC 2616, versioni aktual HTTP/1.1) është një protokoll transferimi hiperteksti. Ky protokoll fillimisht ishte menduar për shkëmbimin e dokumenteve të hipertekstit, tani aftësitë e tij janë zgjeruar ndjeshëm (në veçanti, janë shtuar veçoritë e mbështetjes së transmetimit).

HTTP është një protokoll tipik klient-server, mesazhet shkëmbehen sipas skemës "kërkesë-përgjigje" në formën e komandave ASCII. Një tipar i protokollit HTTP është aftësia për të specifikuar në kërkesë dhe përgjigje se si i njëjti burim përfaqësohet nga parametra të ndryshëm: formati, kodimi, gjuha etj. Falë aftësisë për të specifikuar se si kodohet mesazhi, klienti dhe serveri mund të shkëmbejnë të dhëna binare, megjithëse ky protokoll është tekst.

HTTP është një protokoll i shtresës së aplikacionit, por përdoret gjithashtu si "transport" për protokollet e tjera të aplikacionit si SOAP, XML-RPC, WebDAV.

Protokolli HTTP përcakton një metodë kërkesë-përgjigje të ndërveprimit midis një programi klient dhe një programi serveri brenda kornizës së Bota e Teknologjisë rrjet i gjerë.

Për të shkarkuar një faqe interneti në një shfletues klienti, ai dërgon një kërkesë në një program të veçantë të instaluar në kompjuterin e serverit, i quajtur server http, dhe përpunon të dhënat e marra prej tij. Në këtë rast, funksioni i shfletuesit është të pyesë serverin faqe specifike, merrni dhe shfaqeni në ekranin e përdoruesit. Nga ana tjetër, serveri e pranon kërkesën, kërkon dokumentin e kërkuar dhe i jep klientit ose përmbajtjen e skedarit të gjetur ose një mesazh gabimi nëse një skedar i tillë nuk është gjetur ose qasja në të është refuzuar për ndonjë arsye. Një pikë e rëndësishme për të kuptuar këtë proces është se serveri http nuk analizon përmbajtjen e dokumentit të transmetuar. Përafërsisht, http-server nuk i intereson se çfarë është brenda skedarit të kërkuar, ai ia kalon atë vetëm shfletuesit dhe shfletuesi tashmë kujdeset për të gjithë punën e strukturimit dhe shfaqjes së informacionit të marrë.

Kërkimi për faqen e kërkuar kryhet në një drejtori specifike, e cila është e ndarë në kompjuterin e serverit për këtë faqe - një lidhje me këtë drejtori është e pranishme në adresën e futur nga përdoruesi. Në rastin kur kërkesa nuk i bëhet një dokumenti specifik, por faqes në tërësi, serveri http zëvendëson automatikisht të ashtuquajturën "faqe fillestare" në vend të emrit të skedarit të transferuar, i cili quhet index.htm ose index.html (në disa raste - default. htm ose default.html). Ky dokument duhet të gjendet në direktoriumin rrënjësor të caktuar për të pritur faqen tuaj, ose, nëse specifikohet ndryshe, në një drejtori të quajtur WWW. Të gjithë skedarët e tjerë mund të vendosen ose në të njëjtin direktori ose në drejtori të ndërlidhura, gjë që ndonjëherë është e përshtatshme, veçanërisht kur faqja përmban disa seksione ose tituj tematikë.

Përveç nëndosjeve që krijoni, në të cilët jeni i lirë të vendosni pothuajse çdo përmbajtje që ju nevojitet, direktoria e serverit zakonisht përmban disa drejtori të tjera që duhen përmendur veçmas. E para është dosja CGI-BIN, ku vendosen skriptet CGI dhe skriptet e tjera të drejtuara nga faqja juaj. aplikacionet interaktive, si dhe disa drejtori shërbimesh të nevojshme për funksionimin normal server. Në faza fillestare ato thjesht duhet të injorohen. Ndonjëherë në të njëjtën direktori ku ruhet index.html, ka një rresht skedarë shtesë: not_found.html - dokumenti që shfaqet nëse serveri http nuk mund të gjejë skedarin e kërkuar nga përdoruesi, i ndaluar.html - shfaqet si mesazh gabimi nëse refuzohet qasja në dokumentin e kërkuar dhe në fund robots.txt - skedari , në të cilën në mënyrë të veçantë përshkruan rregullat për indeksimin e faqes tuaj nga motorët e kërkimit.

Në shumicën e rasteve, dhe veçanërisht kur publikoni një faqe kryesore në serverë që ofrojnë pritje falas, përdoruesve u mohohet qasja në drejtoritë e shërbimeve dhe dosjen CGI-BIN, dhe ndryshimi i përmbajtjes së skedarëve not_found dhe të ndaluar.html është gjithashtu i pamundur. Kjo duhet të merret parasysh nëse planifikoni të përfshini ndonjë përmbajtje ndërvepruese në burimin tuaj që kërkon të paktën aftësinë për të vendosur skedarë në një nga dosjet e shërbimit. Në disa raste, mund të mos ju lejohet të krijoni drejtori të ndërlidhura në server, në të cilin rast përdoruesi do të duhet të jetë i kënaqur me vetëm një direktori të rezervuar për nevojat tuaja.

Nga sa më sipër, bëhet e qartë se shfletuesi i klientit mund të marrë dhe përpunojë vetëm informacione nga serveri, dhe ta vendosë dhe modifikojë atë vetëm nëse ngarkimi i skedarëve në server zbatohet bazuar në protokollin HTTP duke përdorur skriptet speciale CGI të përfshira në server. web -ndërfaqe. Në të gjitha rastet e tjera, duhet të përdorni të ashtuquajturin server ftp, në të cilin, duke përdorur softuer special, mund të transferoni dosjet e nevojshme, duke i ngarkuar automatikisht në drejtorinë e caktuar për faqen tuaj. Në të dyja rastet, do t'ju duhet të dini emrin tuaj të hyrjes dhe fjalëkalimin për të hyrë në sistem. Duhet mbajtur mend gjithashtu se shumica programet e serverit(veçanërisht Apache për platformat e përputhshme me UNIX) bëjnë dallimin midis karaktereve të vogla dhe të mëdha, kështu që të gjithë emrat e skedarëve dhe shtesat e tyre duhet të shkruhen për të shmangur gabimet shkronja të vogla, dhe domosdo në latinisht. Kjo e fundit është për shkak të dallimeve në përpunimin e kodimeve të gjuhës ruse, të cilat janë tipike për serverë të caktuar.

Protokolli HTTP funksionon si më poshtë: programi i klientit krijon një lidhje TCP me serverin (numri standard i portit është 80) dhe lëshon një kërkesë HTTP për të. Serveri përpunon këtë kërkesë dhe lëshon një përgjigje HTTP për klientin.

Ndërveprimi ndërmjet klientit dhe serverit në internet kryhet duke shkëmbyer mesazhe. Mesazhet HTTP ndahen në kërkesa klient-server dhe përgjigje server-klient.

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 vjen një linjë fillestare, pastaj ndoshta një ose më shumë fusha të kokës, të quajtura gjithashtu tituj, pastaj një rresht bosh (d.m.th., një rresht i përbërë nga karaktere CR dhe LF), që tregon fundin e titullit fushat, dhe më pas ndoshta pjesa e tekstit të mesazhit:

vargu fillestar

fusha e kokës 1

fusha e kokës 2

fusha e kokës N

trupi i mesazhit

Titujt HTTP

Formati i vargut fillestar të klientit dhe serverit ndryshojnë dhe do të diskutohet më poshtë. Ekzistojnë katër lloje të titujve:

Titujt e përgjithshëm (general-headers), të cilët mund të jenë të pranishëm si në kërkesë ashtu edhe në përgjigje;

Titujt e kërkesës (titujt e kërkesës), të cilat mund të jenë të pranishme vetëm në kërkesë;

Titujt e përgjigjes (titujt e përgjigjes), të cilat mund të jenë të pranishme vetëm në përgjigje;

Titujt e entitetit që i referohen trupit të mesazhit dhe përshkruajnë përmbajtjen e tij.

Çdo titull 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ën 1.

Tabela 1

Titujt HTTP

kokë	Qëllimi
Titujt e objekteve
lejojnë	Liston metodat e mbështetura nga serveri
kodimi i përmbajtjes	Mënyra e kodimit të trupit të mesazhit, për shembull për të zvogëluar madhësinë
gjatësia e përmbajtjes	Gjatësia e mesazhit në bajt
lloji i përmbajtjes	Përmban përcaktimin e llojit të përmbajtjes MIME të përgjigjes. Në varësi të vlerës së llojit të përmbajtjes, shfletuesi e trajton përgjigjen si një faqe HTML, një imazh gif ose jpeg, një skedar që do të ruhet në disk ose diçka tjetër dhe ndërmerr veprimet e duhura. Disa lloje të përmbajtjes: tekst/html - tekst në Formati HTML(faqe interneti); text/plain - tekst i thjeshtë (i ngjashëm me "notepad"); imazh/jpeg - imazh në format JPEG; imazh/gif - i njëjtë, në formatin GIF; Ai gjithashtu mund të kalojë një kodim për të dhënat e tekstit. Për shembull: charset=windows-1251 charset=koi8-rus Content-Length - gjatësia e përmbajtjes së përgjigjes në bajt (madhësia e skedarit). Last-Modified - data dhe ora kur dokumenti është modifikuar për herë të fundit.
ETag	Një etiketë unike e burimeve në server që ju lejon të krahasoni burimet
Skadon	Data dhe ora kur burimi në server do të ndryshohet dhe ai duhet të merret përsëri
E modifikuara e fundit	Data dhe ora e modifikimit të fundit të përmbajtjes
Titujt e përgjigjes
Mosha	Numri i sekondave për të riprovuar kërkesën për të marrë përmbajtje të re
vendndodhjen	URI e burimit për të hyrë për të marrë përmbajtjen
Riprovo-Pas	Data dhe ora ose numri i sekondave pas së cilës kërkesa duhet të riprovohet për të marrë një përgjigje të suksesshme
server	Emri i softuerit të serverit që dërgoi përgjigjen
Titujt e kërkesës
pranoj	Lista e llojeve të përmbajtjes të mbështetura nga shfletuesi sipas radhës së preferencës nga ky shfletues, për shembull: Prano: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword , aplikacion/vnd. ms-powerpoint, */* Kjo është padyshim e nevojshme për rastin kur serveri mund të lëshojë të njëjtin dokument në formate të ndryshme. Vlera e këtij parametri përdoret kryesisht nga skriptet CGI për të gjeneruar një përgjigje të përshtatur për një shfletues të caktuar.
Prano Charset	Kodimet e karaktereve në të cilat klienti mund të pranojë përmbajtje teksti
Prano kodimin	Mënyra se si serveri mund të kodojë mesazhin
Mikpritës	Numri i hostit dhe portit nga i cili kërkohet dokumenti
If-Modified-Since If-Match If-None-Match If-Range If-Unmodified-Since	Kërkoni titujt për qasje të kushtëzuar në një burim
Gama	Kërkoni një pjesë të një dokumenti
Agjenti i përdoruesit	Emri i softuerit të klientit - vlera është "emri i kodit" i shfletuesit, për shembull: Mozilla/4.0 (i pajtueshëm; MSIE 5.0; Windows 95; DigExt)
Titujt e përgjithshëm
lidhje	Lidhja (lidhja) - mund të marrë vlerat Keep-Alive dhe mbyll. Keep-Alive ("keep alive") do të thotë që pas lëshimit të këtij dokumenti, lidhja me serverin nuk ndërpritet dhe mund të lëshohen më shumë kërkesa. Shumica e shfletuesve punojnë në modalitetin Keep-Alive, pasi ju lejon të "shkarkoni" një faqe html dhe fotografi për të në një lidhje me serverin. Pasi të vendoset, Keep-Alive vazhdon deri në gabimin e parë ose të specifikuar në mënyrë eksplicite në kërkesën e ardhshme Lidhja: mbyllje. mbyll - Lidhja mbyllet pas përgjigjes ndaj kësaj kërkese.
Data	Data dhe ora e krijimit të mesazhit
pragma	Komanda të veçanta, specifike për zbatimin në lidhje me përmbajtjen që transferohet
Kodimi i transferimit	Si është koduar mesazhi gjatë transmetimit

Në disa tituj, vlera është një datë dhe orë. Ato duhet të jenë në formatin e përshkruar në RFC 1123, për shembull:

Trupi i mesazhit përmban informacionin aktual të transmetuar - ngarkesën e mesazhit. Trupi i mesazhit është një sekuencë oktetesh (bajt). Trupi i mesazhit mund të jetë i koduar, me metodën e kodimit të specifikuar në kokën e objektit Content-Encoding.

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 opsionalisht një trup mesazhi.

Vargu i kërkesës fillon me një metodë, e ndjekur nga ID-ja e burimit të kërkuar, versioni i protokollit dhe karakteret vijuese të fundit të linjës:

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

Metoda specifikon metodën për t'u aplikuar në burimin e kërkuar. Për shembull, metoda GET thotë se klienti dëshiron të marrë përmbajtjen e burimit. Identifikuesi identifikon burimin e kërkuar. Versioni HTTP tregohet nga një varg si ky:

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

Metodat e protokollit HTTP

Konsideroni metodat themelore 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 klientit të përcaktojë opsionet dhe/ose kërkesat që lidhen me burimin, ose aftësitë e serverit, pa ndërmarrë asnjë veprim mbi burimin ose pa nisur një shkarkim të tij.

Nëse përgjigja e serverit nuk është një mesazh gabimi, atëherë titujt e entitetit 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 synon t'i drejtohet serverit në tërësi.

Nëse identifikuesi i 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 identifikuesi i burimit të kërkuar tregon në një dokument (për shembull, një dokument teksti, një imazh grafik, një video), atëherë serveri kthen përmbajtjen e këtij dokumenti (përmbajtja e skedarit). Nëse burimi i kërkuar është një aplikacion (program) që gjeneron të dhëna, atëherë të dhënat e gjeneruara kthehen në trupin e mesazhit të përgjigjes në vend të një imazhi binar të 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). NË rasti i fundit Emri i dosjes mund të specifikohet me ose pa karakterin "/" në fund. Në mungesë të këtij simboli në fund të identifikuesit, serveri lëshon një nga përgjigjet e ridrejtimit (me kodet e statusit 301 ose 302).

Bëhet një dallim midis "GET me kusht", në të cilin mesazhi i kërkesës përfshin krerët 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 ai plotëson kushtet e përshkruara në titujt e dhënë. Metoda e kushtëzuar GET është krijuar për të reduktuar shkarkim i panevojshëm rrjeti, sepse ju lejon të mos rifreskoni të dhënat e ruajtura tashmë nga klienti.

Bëhet gjithashtu një dallim midis "GET-it të 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 transferimin e vetëm një pjese të një objekti. Metoda e pjesshme GET synon të reduktojë ngarkesën e panevojshme të rrjetit duke kërkuar vetëm një pjesë të një objekti kur pjesa tjetër tashmë është ngarkuar nga klienti. Vlera e kokës Range është diapazoni i bajteve që do të merren. Bajtet numërohen nga 0. Bajtet e fillimit dhe të fundit të një diapazoni ndahen me një karakter "-". Nëse keni nevojë të merrni disa vargje, atëherë ato renditen të ndara me presje.

Metoda HEAD është identike me GET, përveç që serveri nuk kthen një trup mesazhi në përgjigje. Meta-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. Kjo metodë mund të përdoret për të marrë informacion rreth objektit të kërkesës pa kaluar drejtpërdrejt trupin e objektit. Metoda HEAD përdoret shpesh për të testuar lidhjet e hipertekstit.

Metoda POST përdoret për një kërkesë në të cilën serveri i adresuar merr të dhënat e përfshira në trupin e mesazhit (objekt) të kërkesës dhe i dërgon ato për përpunim në aplikacionin e specifikuar si burimi i kërkuar. POST është projektuar të jetë një metodë e zakonshme për t'u zbatuar karakteristikat e mëposhtme:

Shënimi i burimeve ekzistuese;

Postimi i një mesazhi në një bord buletinesh (BBS), grupe lajmesh, lista postare ose grupe të ngjashme artikujsh;

Kalimi i një blloku të dhënash, të tilla si 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 identifikuesi i burimit të kërkuar. Së bashku me metodën GET, metoda POST përdoret kur krijohen aplikacione CGI. Shfletuesi mund të gjenerojë 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 METHOD me një vlerë POST.

Një veprim i kryer nga metoda POST mund të kryejë një veprim në server dhe të mos kalojë asnjë përmbajtje si rezultat i operacionit. Në këtë rast, 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 201 (Krijuar) dhe përfshin një titull të përgjigjes së vendndodhjes.

Trupi i mesazhit që përcillet në kërkesë me metodën 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 krijohet një burim i ri, atëherë serveri informon agjentin e përdoruesit në lidhje me të me anë të një përgjigjeje me një kod statusi 201 (Created, Created).

Dallimi themelor ndërmjet metodave POST dhe PUT është kuptim të ndryshëm identifikuesin e burimit të kërkuar. URI në një kërkesë POST identifikon burimin që trajton objektin e përfshirë në trupin e mesazhit. Ky burim mund të jetë një aplikacion që merr të dhënat. Në të kundërt, një 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 atë URI burimit të përfshirë.

Metoda DELETE i kërkon serverit të fshijë burimin që ka identifikuesin e kërkuar. Një kërkesë me këtë metodë mund të refuzohet nga serveri nëse përdoruesi nuk ka leje për të fshirë burimin e kërkuar.

Metoda TRACE përdoret për të kthyer një kërkesë të kaluar në shtresën e protokollit HTTP. Marrësi i kërkesës (serveri i uebit) ia dërgon mesazhin e marrë klientit si një trup i objektit të përgjigjes me një kod statusi 200 (OK). Një kërkesë 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 ta përdorë atë informacion për testim ose diagnostikim.

Nëse kërkesa është e suksesshme, atëherë përgjigja përmban të gjithë mesazhin e kërkesës në trupin e mesazhit të përgjigjes, dhe titulli i llojit të përmbajtjes ka vlerën "mesazh/http".

Kodet e përgjigjes

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 numerik statusi, një frazë shpjeguese, e ndarë me hapësira dhe karaktere në fund të rreshtit:

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

Versioni i protokollit ka të njëjtën vlerë si në kërkesë.

Elementi Status-Code është një kod i plotë treshifror (treshifror) i rezultatit të të kuptuarit dhe plotësimit të kërkesës. Fraza-Arsyeja është një përshkrim i shkurtër tekstual i kodit të statusit. Kodi i statusit është për përpunimin e softuerit dhe fraza shpjeguese është 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 vlera për shifrën e parë:

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

2xx: Kodet e suksesit- veprimi është pranuar, 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ë përmbushë një kërkesë të vlefshme.

Shprehjet e arsyes për çdo kod statusi janë të listuara në RFC 2068 dhe rekomandohen, por mund të zëvendësohen me të njëjtat pa ndikuar në protokollin. Për shembull, në versionet e lokalizuara në gjuhën ruse të serverëve HTTP, këto fraza zëvendësohen nga ato ruse. Tabela 2 tregon kodet e përgjigjes së serverit HTTP.

tabela 2

Kodet e përgjigjes së serverit HTTP

Kodi	Fraza shpjeguese sipas RFC 2068	Fraza ekuivalente shpjeguese në rusisht
1xx: Kodet e informacionit
	Vazhdoni	Vazhdoni
2xx: Kodet e suksesit
	Ne rregull	Ne rregull
	Krijuar	Krijuar
	pa përmbajtje	Nuk ka përmbajtje
	Rivendos përmbajtjen	Rivendos përmbajtjen
	Përmbajtja e pjesshme	Përmbajtja e pjesshme
3xx: Kodet e ridrejtimit
	Lëvizur përkohësisht	Zhvendosur përkohësisht
	Nuk është modifikuar	I pa modifikuar
4xx: Kodet e gabimit të klientit
	Kerkese e keqe	Kërkesë e thyer
	I paautorizuar	I paautorizuar
	nuk u gjet	Nuk u gjet
	Metoda nuk lejohet	Metoda nuk lejohet
	Përfundimi i kërkesës	Koha e kërkesës mbaroi
	Konflikti	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
5xx: Kodet e gabimit të serverit
	e brendshme gabim serveri	Gabim i brendshëm serverët
	Nuk është zbatuar	Nuk zbatohet
	sherbim i padisponueshem	Shërbimi është i padisponueshëm
	Versioni HTTP nuk mbështetet	Versioni i pambështetur i HTTP

Linja e statusit ndiqet nga titujt (e përgjithshme, përgjigja dhe objekti) dhe opsionalisht nga pjesa kryesore e mesazhit.

Një nga funksionet më të rëndësishme ueb serverështë të ofrojë akses në një pjesë të lokalit sistemi i skedarëve. Për ta bërë këtë, në cilësimet e serverit specifikohet një direktori e caktuar, e cila është rrënja për këtë server. Të publikosh një dokument, pra ta bësh atë në dispozicion të përdoruesve kush e "vizitoi" këtë server (pasi keni bërë një lidhje me të nëpërmjet HTTP), ju duhet ta kopjoni këtë dokument në direktoria rrënjësore Ueb serveri ose një nga nëndrejtoritë e tij. Kur lidheni përmes protokollit HTTP, në server krijohet një proces me të drejtat e përdoruesit, i cili, si rregull, nuk ekziston në realitet, 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.

Merrni parasysh shembulli më i thjeshtë Kërkesë HTTP. Nëse shkruajmë adresën http://yandex.ru në dritaren e adresës së shfletuesit, shfletuesi do të përcaktojë adresën IP të serverit yandex.ru dhe do t'i dërgojë kërkesën e mëposhtme HTTP në portin e 80-të:

MERRNI http://yandex.ru/ HTTP/1.0

Prano: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Prano-Gjuha: en

Cookie: yandexuid=2464977781018373381

Agjenti i përdoruesit: Mozilla/4.0 (i pajtueshëm; MSIE 5.5; Windows 98)
Pritësi: yandex.ru

Referues: narod.ru

Lidhja proxy: Keep Alive

Kërkesa dërgohet në formë teksti të pakriptuar. Pjesa më e rëndësishme e kërkesës ndodhet në rreshtin e parë: Ky është lloji i kërkesës (GET), URL-ja e dokumentit të kërkuar (http://yandex.ru) dhe versioni. Protokolli HTTP(HTTP/1.0). Parametrat e pyetjes janë renditur më poshtë. Çdo rresht korrespondon me një parametër. Rreshti fillon me emrin e parametrit, i ndjekur nga një dy pika dhe vlerën e parametrit.

Prano - lloji i të dhënave që shfletuesi mund të pranojë (në kodimin MIME).

Accept-Language është gjuha e preferuar në të cilën shfletuesi dëshiron të pranojë të dhëna. User-Agent - lloji i programit që dërgoi kërkesën.

Host - Emri DNS (ose IP) i hostit të cilit i drejtohet kërkesa.

Cookie - cookie (të dhëna që janë ruajtur nga serveri në disku lokal klienti kur vizitoi këtë host herën e fundit).

Referues - hosti nga faqja e të cilit po dërgojmë kërkesën. Kështu, për shembull, nëse jemi në faqen http://narod.ru dhe klikojmë në lidhjen http://yandex.ru atje, atëherë kërkesa do të dërgohet në hostin yandex.ru dhe në fushën e kërkesës së referuesit do të përmbajë emrin e hostit narod.ru.

Grupi i parametrave të pyetjes nuk është i fiksuar. Përveç sa më sipër, mund të ketë parametra të tjerë.

Parametrat më interesantë janë referuesi dhe cookie. Këto parametra përdoren kryesisht për të identifikuar përdoruesin nga serveri.

Kërkesa GET mund të përmbajë të dhëna të kaluara nga klienti te serveri. Ato transmetohen drejtpërdrejt përmes një URL duke përdorur protokollin CGI. Të dhënat ndahen nga URL-ja me një "?" dhe janë të lidhura me shenjën "&":

MARR ?<параметр 1>=<значение 1>&<параметр 2>=<значение 2>&…

Ky lloj transferimi i të dhënave në server është i përshtatshëm, por ka kufizime në vëllim. Vargjet shumë të mëdha të të dhënave nuk mund të transmetohen përmes URL-së. Për qëllime të tilla, ekziston një lloj tjetër kërkese: një kërkesë POST. Një kërkesë POST është shumë e ngjashme me një kërkesë GET, me ndryshimin e vetëm që të dhënat në kërkesën POST kalohen veçmas nga vetë kreu i kërkesës:

Trupi i kërkesës duhet të ndahet nga kreu me një rresht bosh. Nëse serveri ndeshet me një varg bosh në një kërkesë POST, atëherë gjithçka që vijon konsiderohet trupi i kërkesës (të dhënat e transmetuara). Vini re sa më poshtë: formati i të dhënave në trupin e kërkesës POST është arbitrar. Megjithëse formati CGI përdoret më së shpeshti, ai nuk kërkohet. Për më tepër, një kërkesë POST nuk kërkon një trup kërkese dhe mund të kalojë të dhëna edhe përmes një URL.

Përveç formatit CGI, ndonjëherë për të transferuar sasi të mëdha informacioni (për shembull, skedarë) përdorni të ashtuquajturat. formati shumëpjesësh (formati i të dhënave të transmetuara përcaktohet nga parametri Content-Type):

Shfletuesit modernë përmbajnë mjete për zhvilluesit e uebit për të marrë disa informacione rreth kërkesave për postim që po dërgohen. Nëse duhet të shikoni titujt e vetëm disa kërkesave, përdorimi i tyre do të jetë më i lehtë dhe më i shpejtë se metodat e tjera.

Nëse jeni duke përdorur Firefox, mund të përdorni tastierën e tij të internetit. Ai shfaq titujt e kërkesës dhe përmbajtjen e të transmetuarit biskota. Për ta nisur atë, hapni menunë e shfletuesit, klikoni në artikullin "Zhvillimi i Uebit" dhe zgjidhni "Konsola e Uebit". Në panelin që shfaqet, aktivizoni butonin "Rrjeti". Futni emrin e metodës në fushën e filtrit - post. Në varësi të qëllimeve tuaja, klikoni në butonin e formularit që dërgon kërkesën e kërkuar ose rifresko faqen. Konsola do të shfaqë kërkesën e paraqitur. Klikoni mbi të me miun për të parë më shumë detaje.

Shfletuesi Google Chrome ka mjete të fuqishme korrigjimi. Për t'i përdorur ato, klikoni në ikonën e çelësit dhe më pas zgjeroni artikullin "Personalizoni dhe kontrolloni Google Chrome". Zgjidhni "Tools" dhe hapni "Developer Tools". Në shiritin e veglave, zgjidhni skedën Rrjeti dhe dorëzoni kërkesën. Gjeni kërkesën e kërkuar në listë dhe klikoni mbi të për të parë detajet.

Shfletuesi Opera ka mjete të integruara zhvilluesish për Opera Dragonfly. Për t'i hapur ato, klikoni me të djathtën në faqen e dëshiruar dhe zgjidhni artikullin menyja e kontekstit"Elementi i inspektimit". Shkoni te skedari "Rrjeti" i mjeteve të zhvilluesit dhe dorëzoni kërkesën e dëshiruar. Gjeni atë në listë dhe zgjeroni atë për të ekzaminuar titujt dhe përgjigjet e serverit.

Internet Explorer 9 përfshin një paketë të quajtur "F12 Developer Tools" që ofron informacion i detajuar mbi kërkesat e përfunduara. Ato hapen duke shtypur butonin F12 ose duke përdorur menynë "Tools" që përmban artikullin me të njëjtin emër. Për të parë kërkesën, shkoni te skeda "Rrjeti". Gjeni një pyetje të dhënë në përmbledhje dhe klikoni dy herë për të zgjeruar detajet.

Shfletuesit Chrome dhe Internet Explorer 9 përmbajnë mjete të integruara që ju lejojnë të shqyrtoni në detaje kërkesën e postimit të dorëzuar. Për detaje të plota, përdorni ato ose Firefox me plugin-in Firebug të instaluar. Është shumë i dobishëm për ekzaminimin e shpeshtë të pyetjeve, për shembull, kur korrigjoni faqet e internetit.

Nëse dëshironi të shihni një kërkesë të dërguar nga një program tjetër përveç shfletuesit, përdorni korrigjuesin HTTP të Fiddler. Ai funksionon si një server proxy dhe përgjon kërkesat nga çdo program, dhe ofron informacion shumë të detajuar mbi titujt dhe përmbajtjen e tyre.