URL(Locator uniform de resurse)- un localizator uniform (identificator de locație) al resursei. URL este o modalitate standardizată de scriere a adresei unei resurse pe Internet.

URI(Identificator uniform de resurse)- identificator de resursă unificat (uniform). URI este o secvență de caractere care identifică o resursă abstractă sau fizică.

URI - e mai mult concept general, mai degrabă decât adresa URL. Un URI nu indică întotdeauna cum să obțineți o resursă, spre deosebire de o adresă URL, ci doar o identifică. Un URL este un URI care, pe lângă identificarea unei resurse, oferă și informații despre locația acelei resurse. Într-adevăr, orice URL conține suficiente informații pentru a localiza cu precizie pagina. Mai târziu în acest curs, când folosim adrese de site-uri web, ne vom menține la abrevierile URL.

Structura adresei site-ului

Să revenim la URL http://school.it2moro.ru/ . Poate fi împărțit în 3 părți:

1. http://
2. şcoală
3. it2moro

Prima parte adrese (http://) definește protocolul de interacțiune între browser și server. În cazul nostru, acesta este protocolul HTTP, care va fi discutat în continuare.

A doua parte bara de adrese se numește SUBDOMENIU și al treilea - domeniu. Acestea servesc la identificarea unui anumit site folosind serviciul DNS. DNS (Domain Name System) - computer sistem distribuit pentru informații despre domenii. Cel mai adesea folosit pentru a obține o adresă IP de la un nume de gazdă (calculator sau dispozitiv). Există un număr mare de servere DNS în rețea care, pe baza numelui de domeniu al unei resurse, pot „să spună” locația reală a acesteia, determinată de adresa sa IP.

Codul sursă al paginii HTML

Acum să ne uităm la ce primește browserul ca răspuns la solicitarea HTTP generată. O pagină poate consta din text, imagini, hyperlinkuri, câmpuri de introducere, butoane și alte elemente. Informațiile despre toate acestea au fost transferate de pe serverul web în browser, ceea ce a generat aspectul final al paginii. Datele transmise sunt descrise folosind protocolul HTML.

HTML(HyperText Markup Language, limbaj de marcare hipertext)- un limbaj de marcare standard pentru documentele de pe Internet. limbaj HTML interpretat de browser și afișat ca document într-o formă care poate fi citită de om.

Putem spune că browserele îndeplinesc două funcții principale - interacționează cu serverele web prin intermediul solicitări HTTP , precum și conversia codului HTML primit de la server într-o reprezentare vizuală.

URI (Identificator uniform de resurse) - identificator de resursă unificat (uniform). URI este un șir de caractere care vă permite să identificați orice resursă: un document, imagine, fișier, serviciu, căsuță de e-mail etc. În primul rând, vorbim, desigur, despre resursele Internetului și ale World Wide Web. URI-urile oferă o modalitate simplă și extensibilă de a identifica resursele. Extensibilitatea URI-urilor înseamnă că mai multe scheme de identificare există deja în cadrul URI-urilor și multe altele vor fi create în viitor.

Relația dintre URI, URL și URN

Diagrama Venn care arată subseturile schemei URI: URL și URN.

Un URI este fie un URL, fie un URN, sau ambele.

• Un URL este un URI care, pe lângă identificarea unei resurse, oferă și informații despre locația acelei resurse.
• Un URN este un URI care identifică doar o resursă într-un anumit spațiu de nume (și, prin urmare, într-un context specific), dar nu indică locația acesteia. De exemplu, URN urn:ISBN:0-395-36341-1 este un URI care indică resursa (cartea) 0-395-36341-1 în spațiul de nume ISBN, dar spre deosebire de o adresă URL, un URN nu indică locația respectivei resurse: nu spune în ce magazin o puteți cumpăra sau pe ce site o puteți descărca.

Deoarece un URI nu indică întotdeauna cum se obține o resursă, spre deosebire de o adresă URL, ci doar o identifică, acest lucru face posibilă descrierea resurselor folosind RDF (Resource Description Framework) care nu pot fi obținute prin Internet (de exemplu, o persoană, o mașină, oraș etc.).

Poveste

În 1990, localizatorul de resurse URL a fost inventat de omul de știință britanic Tim Berners-Lee la Geneva, Elveția, în cadrul zidurilor Consiliului European pentru Cercetare Nucleară. Deoarece URL-ul este cel mai folosit subset al URI, 1990 este, de asemenea, considerat a fi anul în care s-a născut URI. Dar, strict vorbind, conceptul URI a fost documentat abia în iunie 1994 în RFC 1630.

O noua versiune URI a fost definit în 1998 în RFC 2396, în același timp cuvântul universalîn titlu a fost înlocuit cu Uniformă.

Defecte

URL-ul a devenit o inovație fundamentală pe Internet, iar principiile URI au fost documentate pentru a asigura compatibilitatea deplină cu URL-urile. De aici provine marele dezavantaj al URI-urilor, care vine ca o moștenire de la URL-uri. URI-urile, precum adresele URL, pot folosi doar un set limitat de caractere latine și semne de punctuație (chiar mai puțin decât ASCII). Cu alte cuvinte, dacă vrem să folosim caractere chirilice, sau hieroglife sau, să zicem, caractere specifice ale limbii franceze într-un URI, atunci va trebui să codificăm URI-ul în același mod în care Wikipedia codifică URL-urile cu caractere Unicode. De exemplu, o linie ca:

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

codificat în adresa URL ca:

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

Deoarece literele tuturor alfabetelor, cu excepția celui folosit în Limba engleză Alfabetul latin, apoi URI-urile cu cuvinte în alte limbi (chiar și europene) își pierd capacitatea de a fi percepute de oameni. Și acest lucru este în contradicție flagrantă cu principiul internaționalismului proclamat de toate organizațiile de conducere ale internetului, inclusiv W3C și ISOC. Standardul IRI este conceput pentru a rezolva această problemă. Identificator de resurse internaționalizate) - identificatori internaționali de resurse în care caracterele Unicode ar putea fi folosite fără probleme și care nu ar încălca drepturile altor limbi. De asemenea, creatorul URI-ului, Tim Berners-Lee, a spus că sistemul de nume de domeniu care stă la baza URL-ului este decizie proasta, care impune resurselor o arhitectură ierarhică nepotrivită pentru web-ul hipertext.

Structura URI

URI = [schema ":"] ierarhic - Partea [ "?" cerere ] [ fragment „#” ]

În această intrare:

Sistem

schema de accesare a unei resurse (indicând adesea un protocol de rețea), de exemplu, http, ftp, fișier, ldap, mailto, urn

Partea ierarhică

conține date, de obicei organizate într-o formă ierarhică, care, împreună cu datele într-o componentă neierarhică cerere, servesc la identificarea unei resurse în domeniul de aplicare al schemei URI. De obicei ierarhic-parte conține calea către resursă (și, eventual, înaintea acesteia, adresa serverului pe care se află) sau identificatorul resursei (în cazul unui URN).

Cerere

această componentă URI opțională este descrisă mai sus.

Fragment

(de asemenea, o componentă opțională)

Vă permite să identificați indirect o resursă secundară, referindu-vă la cea primară și indicând Informații suplimentare. O resursă secundară identificabilă poate fi o parte sau un subset al uneia primare, o reprezentare a acesteia sau o altă resursă definită sau descrisă de o astfel de resursă.

Analizarea structurii URI. Pentru așa-numita „parsare” a URI-urilor analizare), adică pentru a descompune un URI în părțile sale componente și pentru a le identifica ulterior, este cel mai convenabil să folosiți sistemul de expresii regulate, care este acum disponibil în aproape toate limbile moderne programare. RFC 3986 recomandă utilizarea următorului model pentru a analiza URI-urile:

Acest model include 9 grupuri indicate de numerele de mai sus (pentru mai multe informații despre modele și grupuri, consultați Expresii regulate), care analizează cel mai complet și mai precis structura URI tipică, unde:

• grupa 2 - schema,
• grupa 4 - sursa,
• grupa 5 - cale,
• grupa 7 - cerere,
• grupa 9 - fragment.

Astfel, dacă utilizați acest șablon pentru a analiza, de exemplu, un astfel de URI tipic:

http://www.ics.uci.edu/pub/ietf/uri/#Related

atunci cele 9 grupuri de modele de mai sus vor da următoarele rezultate:

1. http:
2. //www.ics.uci.edu
3. www.ics.uci.edu
4. /pub/ietf/uri/
5. nici un rezultat
6. nici un rezultat
7. #Legate de
8. Legate de

Exemple de URI:

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 protected]
• înghiţitură: [email protected]
• știri: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:names:specification:docbook:dtd:xml:4.1.2

2) URI-uri relative

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

[șir gol] - echivalent cu analizarea identificatorului cu rezultatul [șir gol], adică linkul duce la obiectul implicit din schema implicită

serviciu DNS

DNS - Sistem de nume de domeniu. Numele de domenii DNS sunt sinonime pentru adrese IP, la fel cum numele din agenda telefonului dvs. sunt sinonime pentru numerele de telefon. Sunt simbolice, nu numerice; sunt mai convenabile pentru memorare și orientare; ele poartă o încărcătură semantică. www.irnet.ru → Tabelele DNS →193.232.70.36 Numele de domenii sunt și ele unice, adică. Nu există două nume de domenii identice în lume. Numele de domenii, spre deosebire de adresele IP, sunt opționale; sunt achiziționate suplimentar.

Orez. 2. Ierarhia în sistemul DNS.

Adresele care sunt indicate pe plicuri la livrarea scrisorilor prin poștă obișnuită sunt, de asemenea, unice. Nu există țări în lume cu aceleași nume. Și dacă numele orașelor se repetă uneori, atunci, în combinație cu împărțirea în unități administrative mai mari, cum ar fi districtele și regiunile, devin unice. Și numele străzilor nu trebuie repetate în același oraș. Astfel, adresa, pe baza denumirilor geografice și administrative, identifică în mod unic destinația. Domeniile au o ierarhie similară. Numele de domenii sunt separate unele de altele prin puncte: lingvo.yandex.ru, krkime.com.

DNS are următoarele caracteristici:

• Administrare distribuită. Diferite persoane sau organizații sunt responsabile pentru diferite părți ale structurii ierarhice.
• Stocare distribuită a informațiilor. Fiecare nod de rețea trebuie să stocheze în mod necesar doar datele care sunt incluse în el zona de responsabilitate, și (eventual) adrese servere DNS root.
• Memorarea în cache a informațiilor. Nod Pot fi stocați o anumită cantitate de date în afara zonei dvs. de responsabilitate pentru a reduce sarcina în rețea.
• Structura ierarhica, în care toate nodurile sunt combinate într-un arbore și fiecare nod poate determina fie în mod independent funcționarea nodurilor inferioare, fie delega(transmite) la alte noduri.
• Rezervare. Mai multe servere, separate atât fizic, cât și logic, sunt responsabile pentru stocarea și întreținerea nodurilor (zonele), ceea ce asigură siguranța datelor și continuarea lucrului chiar dacă unul dintre noduri eșuează.

Niveluri de domeniu. Există trei niveluri de domenii.

Domenii mai întâi sau nivel superior sunt împărțite în două grupe:

1) Acestea sunt domenii cu afiliere teritorială, de exemplu: .ru .by .ua .de .us etc. Adică acestea sunt domenii care sunt alocate unei anumite țări. Folosindu-le, puteți, de exemplu, să determinați cărei țări îi aparține un anumit site.

2) Al doilea grup de domenii de prim nivel sunt domenii cu un scop specific. De exemplu: .com - pentru organizații comerciale, .info - pentru site-uri de informare, .tv - pentru companii de televiziune etc. Folosind aceste domenii, puteți determina focalizarea specifică a site-ului. Deși, să spun adevărul, recent sunt din ce în ce mai folosiți în orice fel și adesea nu respectă scopul lor.

Domeniile de prim nivel nu pot fi folosite ca adresă a site-ului dvs. web. Sunt folosite pentru a crea domenii al doilea nivel , prin urmare, puteți înregistra un domeniu de nivel al doilea pe oricare dintre domeniile de nivel întâi. Un domeniu de nivel al doilea este format din următoarele elemente: www.nume_site.domeniu de prim nivel. De exemplu: www.webmastermix.ru. Se recomandă utilizarea numelor de domenii de nivel al doilea pentru adresa site-ului. Ele sunt cel mai bine citite și amintite de oameni și sunt, de asemenea, percepute de motoarele de căutare. Prin urmare, majoritatea site-urilor au nume de domenii la acest nivel.

În plus, există domenii al treilea nivel . Ele sunt create pe baza domeniilor de nivel al doilea. Domeniul de al treilea nivel arată astfel: www.forum.webmastermix.ru. Înregistrând un domeniu de nivel al doilea, puteți crea în mod independent câte domenii de nivel al treilea pe baza acestuia doriți. Puteți înregistra un nume de domeniu pentru site-ul dvs. folosind servicii speciale.

TEHNOLOGII WEB: HTML, JAVASCRIPT

Prima parte a blocului didactic al temei de mai sus a fost dedicată tehnologiilor Internet. Acum începem să studiem tehnologiile utilizate în World wide web, sau tehnologii web.

În primul rând, trebuie să înțelegeți conceptele de bază ale tehnologiilor web: site-ul web și pagina web. O pagină web este cea mai mică unitate logică a World Wide Web, care este un document identificat în mod unic printr-o adresă URL unică. Un site web este o colecție de pagini web legate tematic, situate pe același server și deținute de același proprietar. Într-un caz particular, un site web poate fi reprezentat de o singură pagină web. World Wide Web este colecția tuturor site-urilor web.

Baza întregului World Wide Web este limbajul de marcare hipertext HTML - Hyper Text Markup Language (Fig. 3). Servește pentru marcarea logică (semantică) a unui document (pagină web). Este uneori folosit greșit pentru a controla modul în care conținutul paginilor web este afișat pe un ecran de monitor sau atunci când este transmis către o imprimantă, ceea ce este fundamental contrar ideologiei adoptate pe World Wide Web.

Orez. 3. Tehnologii web

Foile de stil în cascadă (CSS) sunt folosite pentru a controla afișarea conținutului paginii web. CSS este în multe privințe similar cu stilurile folosite în popularul procesor de text Word.

Limbajele de scripting sunt folosite pentru a adăuga dinamism paginilor web (meniuri derulante, animație). Limbajul standard de scripting de pe World Wide Web este JavaScript. Nucleul limbajului JavaScript este ECMAScript.

HTML, CSS, JavaScript sunt limbi cu ajutorul cărora puteți crea site-uri web atât de complexe după cum doriți. Dar acesta este doar suport lingvistic, în timp ce în browsere documentele sunt reprezentate ca o colecție de obiecte, ale căror multe tipuri sunt modelul de obiect al browserului (BOM). Modelul obiect al browserului este unic pentru fiecare model și astfel creează probleme la crearea aplicațiilor cross-browser. Prin urmare, Consorțiul Web a propus model de obiect document (DOM), care este un mod standard de reprezentare a paginilor web folosind un set de obiecte.

Sintaxă HTML modern descrise folosind un limbaj extensibil Marcaj XML– Limbajul de marcare extensibil. XML vă va permite să vă creați propriile limbaje de marcare, similar cu HTML sub forma unui DTD. Există multe astfel de limbaje: pentru reprezentarea formulelor matematice și chimice, cunoștințe etc.

După cum se poate observa din cele de mai sus, toate tehnologiile web sunt strâns legate între ele. Înțelegerea acestui fapt va facilita înțelegerea scopului unui anumit mecanism utilizat pentru a crea aplicații web.

E-MAIL

Poștă electronică (e-mail, e-mail, din poșta electronică engleză) - tehnologie și serviciile pe care le oferă pentru trimiterea și primirea mesajelor electronice (numite „scrisori” sau „ e-mailuri") peste un distribuit rețea de calculatoare. Principala diferență față de alte sisteme de transmisie a mesajelor este posibilitatea livrării întârziate și un sistem dezvoltat de interacțiune între servere de mail independente.

E-mailul face posibilă trimiterea și primirea mesajelor, răspunderea automată la scrisorile corespondenților folosind adresele acestora, trimiterea simultană a copiilor unei scrisori către mai mulți destinatari, trimiterea unei scrisori primite la o altă adresă, utilizarea numelor logice în loc de adrese (numerice sau nume de domenii), creați mai multe subsecțiuni ale unei căsuțe poștale pentru diferite tipuri de corespondență, includeți fișiere text în scrisori, utilizați sistemul „reflector de e-mail” pentru a conduce discuții cu un grup de corespondenți etc. Pentru a trimite un mesaj poștal prin e-mail, trebuie să furnizați o adresă de cutie poștală. Cutia poștală a unui abonat de e-mail este o zonă de pe hard disk-ul serverului de e-mail care este rezervată utilizatorului.

Dezvoltarea tehnologiei Internet a dus la apariția protocoalelor moderne de mesagerie, care oferă oportunități mai mari de procesare a scrisorilor, o varietate de servicii și ușurință în utilizare. De exemplu, Protocolul SMTP, lucrând pe principiul client-server, este conceput pentru a trimite mesaje de la un computer către destinatar. De obicei, accesul la un server SMTP nu este protejat de o parolă, așa că puteți utiliza orice server cunoscut din rețea pentru a trimite e-mailuri. Spre deosebire de serverele pentru trimiterea de scrisori, accesul la serverele pentru stocarea mesajelor este protejat prin parolă. Prin urmare, este necesar să utilizați un server sau serviciu în care există Cont. Aceste servere funcționează folosind protocoalele POP și IMAP, care diferă prin modul în care stochează mesajele.

În conformitate cu protocolul POP3, mesajele care ajung la o anumită adresă sunt stocate pe server până când sunt descărcate pe computer în timpul următoarei sesiuni. După descărcarea mesajelor, vă puteți deconecta de la rețea și puteți începe să citiți e-mailurile. Astfel, utilizarea e-mailului POP3 este cea mai rapidă și mai convenabilă de utilizat.

Protocolul IMAP este convenabil pentru acele persoane care folosesc o conexiune constantă la rețea. Mesajele primite la adresă sunt stocate și pe server, dar, spre deosebire de POP3, la verificarea e-mailurilor, vor fi descărcate mai întâi doar anteturile mesajelor. Scrisoarea în sine poate fi citită după selectarea titlului mesajului (va fi descărcată de pe server). Este clar că, cu o conexiune dial-up, lucrul cu poșta folosind acest protocol duce la pierderi nejustificate de timp.

Există mai multe protocoale pentru primirea transferurilor de e-mail între sisteme multi-utilizator.

Scurtă descriere a unora dintre ele:

1) SMTP (Simple Mail Transfer Protocol) este un protocol de rețea conceput pentru transmiterea de e-mail prin rețele TCP/IP, iar transmisia trebuie neapărat inițiată de sistemul de trimitere însuși.

MTA (Mail Transfer Agent) - agent de transfer de e-mail - este componenta principală a sistemului de transfer de e-mail prin Internet, care reprezintă acest computer de rețea pentru un sistem de e-mail în rețea. De obicei, utilizatorii nu lucrează cu MTA, ci cu programul MUA (Mail User Agent), un client de e-mail. Principiul interacțiunii este prezentat schematic în figură.

2) POP, POP2, POP3 (Post Office Protocol)- trei protocoale destul de simple, neinterschimbabile, concepute pentru a livra e-mail unui utilizator de pe un server central de e-mail, a le șterge de pe acesta și a identifica utilizatorul după nume/parolă. POP include SMTP, care este folosit pentru a transfera e-mailuri provenite de la utilizator. Mesajele de e-mail pot fi primite ca antete, fără a primi întregul mesaj.

După stabilirea unei conexiuni, protocolul POP3 trece prin trei stări succesive

1. Autorizare Clientul este supus unei proceduri de autentificare
2. Clientul tranzacției primește informații despre starea cutiei poștale, acceptă și șterge e-mail.
3. Serverul de actualizare șterge e-mailurile selectate și închide conexiunea.

3) IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 (Internet Message Access Protocol) - oferă utilizatorului oportunități bogate de a lucra cu cutiile poștale situate pe un server central

o IMAP stochează corespondența pe server în directoare de fișiere și oferă clientului posibilitatea de a căuta șiruri în mesajele de e-mail pe serverul însuși.

o IMAP2 - folosit în cazuri rare.

o IMAP3 este o soluție incompatibilă și nu este utilizată.

o IMAP2bis - extensia IMAP2, permite serverelor să înțeleagă structura MIME (Multipurpose Internet Mail Extensions) a unui mesaj, este încă folosită.

o IMAP4 - IMAP2bis reluat și extins, care poate fi folosit oriunde.

o IMAP4rev1 - extinde IMAP cu un set mare de funcții, inclusiv cele utilizate în DMSP (Distributed Mail System for Personal Computers).

4) ACAP (Application Configuration Access Protocol) este un protocol conceput pentru a funcționa cu IMAP4; adaugă posibilitatea de a căuta abonamente și de a vă abona la panouri de mesaje, cutii poştaleși este folosit pentru a căuta în agende de adrese.

5) DMSP (sau PCMAIL) este un protocol de primire/trimitere de mail, a cărui particularitate este că utilizatorul poate avea mai mult de o stație de lucru în uz. Stație de lucru conține informații de stare despre e-mail, directorul prin care are loc schimbul, care, atunci când este conectat la server, este actualizat la starea curenta pe serverul de mail.

6) MIME este un standard care definește mecanisme de trimitere a diferitelor tipuri de informații folosind poșta electronică, inclusiv text în alte limbi decât engleza, care utilizează codificări de caractere altele decât ASCII, precum și conținut binar pe 8 biți, cum ar fi imagini, muzică, filme si programe.

Muncă independentă.

Urmați exemplul dat în text (fișe) și salvați propriul folder pe desktop.

9.2. Lucrul cu un profesor:

Dacă apar dificultăţi sau acțiuni greșite contactați profesorul dumneavoastră pentru a corecta erorile.

Până la sfârșitul lecției, arătați profesorului un raport despre munca finalizată și primiți credit pentru această lucrare.

9.3. Controlul nivelului inițial și final de cunoștințe:

Testarea pe computer .

Informații conexe.

Etc. În primul rând, vorbim, desigur, despre resursele Internetului și ale World Wide Web. URI-urile oferă o modalitate simplă și extensibilă de a identifica resursele. Extensibilitatea URI-urilor înseamnă că mai multe scheme de identificare există deja în cadrul URI-urilor și multe altele vor fi create în viitor.
Vezi mai multe detalii.„structură URI” de mai jos.

Cele mai cunoscute exemple de URI sunt URN-urile. Un URL este un URI care, pe lângă identificarea unei resurse, oferă și informații despre locația acelei resurse. Un URN este un URI care identifică o resursă într-un anumit spațiu de nume (și, prin urmare, într-un context specific). De exemplu, URN urn:ISBN:0-395-36341-1 este un URI care indică resursa (cartea) 0-395-36341-1 în spațiul de nume ISBN, dar spre deosebire de o adresă URL, un URN nu indică locația respectivei resurse. Cu toate acestea, recent a existat o tendință de a vorbi pur și simplu despre URI despre orice șir de identificare, fără clarificări suplimentare. Deci, poate că termenii URL și URN vor deveni în curând un lucru din trecut.

Poveste

O nouă versiune a URI a fost definită în 1998 în RFC 2396, în același timp cuvântul universalîn titlu a fost înlocuit cu Uniformă. În decembrie 1999, RFC 2732 a introdus modificări minore la specificația URI, asigurând compatibilitatea cu august 2002, RFC 3305 a anunțat învechirea termenului URL și precedență URI. Structura și sintaxa URI actuale sunt guvernate de RFC 3986, lansat în ianuarie 2005. Mulți Cele mai noi tehnologii web semantic (de ex. RDF) se bazează pe standardul URI. Acum, rolul principal în dezvoltarea URI aparține Consorțiului World Wide Web.

Defecte

URL-ul a devenit o inovație fundamentală pe Internet, iar principiile URI au fost documentate pentru a asigura compatibilitatea deplină cu URL-urile. De aici provine marele dezavantaj al URI-urilor, care vine ca o moștenire de la URL-uri. Într-un URI, ca și într-o adresă URL, puteți utiliza doar un set limitat de caractere latine și semne de punctuație (chiar mai mici decât în ​​chirilic, sau hieroglife sau, să zicem, caractere specifice ale limbii franceze), atunci va trebui să codificăm URI-ul în același mod ca în Wikipedia URL-urile sunt codificate cu caractere Unicode... De exemplu, o linie ca:

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

codificat în adresa URL ca:

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

Deoarece literele tuturor alfabetelor, cu excepția alfabetului latin folosit în limba engleză, sunt supuse unei astfel de transformări, URI-urile cu cuvinte în alte limbi (chiar și europene) își pierd capacitatea de a fi percepute de oameni. Și acest lucru este în contradicție flagrantă cu principiul internaționalismului, proclamat de toate organizațiile de top din Internet, inclusiv W3C și IRI (engleză. Identificator internațional de resurse ) - identificatori internaționali de resurse în care caracterele Unicode ar putea fi folosite fără probleme și care nu ar încălca drepturile altor limbi. Deși este dificil de spus în avans dacă identificatorii vor putea vreodată să . Acest format caută să creeze identificatori care sunt complet independenți de context, adică independent de protocol, domeniu, cale, aplicație și platformă - sunt absolut independent.

De asemenea, creatorul URI-ului, Tim Berners-Lee, a spus că sistemul de nume de domenii care stă la baza URL-ului este o soluție proastă, impunând resurselor o arhitectură ierarhică care nu este potrivită pentru web-ul hipertext.

Structura URI

Analizarea structurii URI

Pentru așa-numita „parsare” a URI-urilor (în engleză. analizare), adică pentru a descompune un URI în părțile sale componente și ulterior a le identifica, cel mai convenabil este să folosiți sistemul de expresii regulate, care este acum disponibil în aproape toate limbajele de programare moderne. Este recomandat să utilizați următorul model pentru a analiza URI-urile:

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

Acest model include 9 grupuri indicate de numerele de mai sus (pentru mai multe informații despre modele și grupuri, consultați Expresii regulate), care analizează cel mai complet și mai precis structura URI tipică, unde:

• grupa 2 - schema,
• grupa 4 - sursa,
• grupa 5 - cale,
• grupa 7 - cerere,
• grupa 9 - fragment.

Astfel, dacă utilizați acest șablon pentru a analiza, de exemplu, un astfel de URI tipic:

Http://www.ics.uci.edu/pub/ietf/uri/#Related

atunci cele 9 grupuri de modele de mai sus vor da următoarele rezultate:

1. http:
2. //www.ics.uci.edu
3. www.ics.uci.edu
4. /pub/ietf/uri/
5. nici un rezultat
6. nici un rezultat
7. #Legate de
8. Legate de

Diferența dintre URI și URL

Un URI nu indică întotdeauna cum să obțineți o resursă, spre deosebire de o adresă URL, ci doar o identifică. Acest lucru face posibilă descrierea utilizând RDF (Resource Description Framework) resurse care nu pot fi obținute prin Internet (de exemplu, o persoană, o mașină, un oraș etc.).

Exemple de URI

URI-uri absolute

http://ru.wikipedia.org/wiki/URI ftp://ftp.is.co.za/rfc/rfc1808.txt file://C:\UserName.HostName\Projects\Wikipedia_Articles\URI.xml ldap: ///c=GB?objectClass?one mailto: [email protected]înghiţitură: [email protected] 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

Link URI-uri

/relative/URI/with/absolute/path/to/resource.txt relative/path/to/resource.txt ../../../resource.txt resource.txt /resource.txt#frag01 #frag01 [blank linia]

Vezi si

Legături

• RFC 3986 / STD 66 (din 2005)
• RFC 2396 (din 1998) - versiune învechită sintaxă

Note

Fundația Wikimedia. 2010.

Vedeți ce este „Uri” în alte dicționare:

Uri- se poate referi la:Geografie: * Cantonul Uri este un canton (regiune) al Elveției * Uri (India), o regiune și un oraș din Kashmir * Uri (SS), un oraș din Sardinia, Italia * Úri, un sat din Pest județul, Ungaria * URI sumeriană, ținutul AgadeURI, a trei... ... Wikipedia

urî- URÎ, urăsc, vb. IV. 1. tranz. Avea un puternic sentiment de antipatie, de dușmănie împotriva cuiva sau a ceva; a nu putea suferi pe cineva sau ceva. 2.ref. impers. (Construit cu dativul) A se plictisi, a se satura de ceva sau de cineva. ♢… …Dicționar Român

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… … Dicționar al limbii lituaniene

Lucrul cu URI-uri

În fiecare zi folosim Identificatori uniformi de resurse (URI), când căutăm ceva pe WWW. URI-urile sunt necesare pentru a identifica și a interoga noul fel resursă. Folosind un URI, puteți accesa nu numai pagini Web, ci și un server FTP, un serviciu Web și fișiere locale.

Termenul este adesea folosit în locul URI Localizator uniform de resurse (URL). URI este un termen general folosit pentru a lega resurse. Un URL este un URI asociat cu scheme URI populare, cum ar fi http, ftp și mailto. Termenul URL nu mai este folosit în documentația tehnică.

Un alt termen pe care poate îl cunoașteți deja este Nume uniform al resursei (URN). Un URN este un URI standardizat utilizat pentru a identifica o resursă, indiferent de locația acesteia în rețea.

Să analizăm părțile URI-ului care leagă la o pagină de pe site-ul Global Knowledge:

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

Prima parte a URI este numită sistem. O schemă definește un spațiu de nume URI și poate restrânge sintaxa expresiei care urmează schema. Multe scheme sunt denumite după protocoalele corespunzătoare (cum ar fi http, ftp) pe care le folosesc, dar acest lucru nu este obligatoriu. În exemplul nostru, identificatorul de schemă este http. Limitator de circuit(// în acest exemplu) separă schema de restul adresei URL.

Delimitatorul schemei este urmat de numele serverului sau adresa IP în notație zecimală cu puncte, de exemplu www.globalknowledge.net.

După numele serverului sau adresa IP este un număr de port care identifică conexiunea la o anumită aplicație de pe server. Dacă nu este specificat un număr de port, este utilizat numărul de port implicit pentru acel protocol (de exemplu, portul 80 pentru HTTP).

cale specifică pagina (și directorul) resursei solicitate. Nu reprezintă neapărat un fișier fizic pe server, dar poate fi creat dinamic. În acest caz, calea arată ca /training/generic.asp.

Din calea prin simbol? ultima parte a acestui URI este separată, numită interogare. În exemplul nostru, cererea este definită de linia pageid=1078&country=DACH. Un șir de interogare poate consta din mai multe componente, fiecare dintre acestea specificând o variabilă și o valoare, unite prin caracterul &. Mai multe componente de interogare pot fi combinate folosind caracterul &. Deci, în exemplul nostru, prima componentă este pageid=1078 cu variabila pageid și valoarea 1078, iar a doua componentă este country=DACH.

Secțiunile dintr-o resursă pot fi identificate ca fragmente. Fragmente sunt folosite pentru a lega secțiunile dintr-o pagină HTML. În dezvoltarea paginilor Web, fragmentele sunt numite și marcaje. Caracterul # separă identificatorul fragmentului de cale. În adresa URL http;//www.microsoft.com/net/basics/glossary.asp#NETFramework fragmentul este șirul #NETFramework.

Dacă caracterul # este adăugat la șirul de interogare, atunci acesta nu mai este un fragment. O adresă URL poate conține un șir de interogare sau un fragment, dar nu ambele.

Utilizarea mai multor caractere este rezervată într-un URI - ele nu pot apărea în numele de gazdă sau căi deoarece sunt caractere delimitare speciale. Următoarele caractere sunt rezervate în URI:

; / ? : @ & = + $ ,

clasa Uri din spațiul de nume System încapsulează URI-ul. Conține proprietăți și metode pentru analizarea, compararea și combinarea URI-urilor.

Puteți crea un obiect Uri pasând șirul URI către constructor:

Uri baseURI = new Uri("http://site");

Dacă există deja un obiect URI de bază, puteți crea un nou URI combinând URI de bază cu un URI relativ:

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

Dacă URI-ul de bază conține deja o cale, aceasta este ignorată. Noul URI se bazează numai pe schemă, portul și numele serverului.

Clasa Uri are mai multe câmpuri statice numai pentru citire care vă permit să obțineți câteva scheme comune:

Uri.UriSchemeFile

Schema de fișiere este utilizată pentru a accesa fișiere local sau pe resurse partajate de rețea, care pot fi denumite conform convenției scop universal nume ( Convenția Universală de Numire, UNC).

Uri.UriSchemeFtp

Protocolul FTP cu schema ftp este folosit pentru a primi fișiere de la un server ftp și, dimpotrivă, pentru a plasa fișiere pe un server ftp.

Uri.UriSchemeGopher

Protocolul Gopher a fost predecesorul HTTP. A oferit capacitatea de a vizualiza ierarhic informații text despre conținut, în care era superior FTP. Dar a fost înlocuit curând de protocolul HTTP.

Uri.UriSchemeHttp, Uri.UriSchemeHttps

Aceste două scheme sunt bine cunoscute: http și https. Schema https este utilizată pentru schimbul securizat.

Uri.UriSchemeMailto

Schema mailto este folosită pentru a trimite mesaje e-mail.

Uri.UriSchemeNews, Uri.UriSchemeNntp

Schemele de știri și nntp sunt utilizate în grupurile de știri care utilizează protocolul NNTP.

Clasa Uri are metode statice pentru a verifica dacă schema și numele de gazdă sunt corecte: Uri.CheckSchemeName() returnează adevărat dacă numele schemei este corect și metoda UriCheckHostName() nu numai că verifică numele gazdei, dar returnează și o valoare de enumerare UriHostNameType care indică tipul gazdei.

Clasa Uri are o mulțime de proprietăți numai pentru citire care vă permit să accesați toate părțile URI-ului. Următorul tabel folosește URI-ul de mai sus ca exemplu pentru a demonstra utilizarea proprietăților:

AbsoluteUri	Această proprietate arată URI-ul complet. Dacă numărul specificat portul de protocol este egal cu numărul de port implicit, constructorul Uri îl elimină automat. Pentru exemplul nostru, valoarea proprietății AbsoluteUri arată astfel: http://www.globalknowledge.net/t raining/generic.asp?pageid=1078&country=DACH. Dacă un nume de fișier este transmis constructorului clasei Uri, proprietatea AbsoluteUri precede automat numele fișierului cu schema file://.
Sistem	Schema este prima parte a URI-ului, iar în acest caz această proprietate returnează valoarea http.
Gazdă	Proprietatea Gazdă arată numele de gazdă din URI: www.globalknowledge.net
Autoritate	Dacă numărul portului este egal cu numărul utilizat de protocolul implicit, proprietatea Authority arată același șir ca și proprietatea Host. Dacă se folosește un alt număr de port, proprietatea Autoritate afișează, de asemenea, numărul portului.
HostNameType	Tipul de nume de gazdă depinde de numele utilizat. În acest caz, se obține aceeași valoare a enumerației UriHostNameType care a fost discutată mai sus.
Port	Folosind proprietatea Port, se obține numărul portului - 80.
Calea Absolută	Calea absolutăîncepe după numărul portului din URI și se termină înaintea șirului de interogare. În acest caz este /training/generic.asp.
LocalPath	Calea locală dă valoarea /training/generic.asp. După cum puteți vedea, pentru o solicitare HTTP nu există nicio diferență între AbsolutePath și LocalPath. Diferența apare dacă URI-ul se referă la o resursă de rețea partajată. Pentru un URI în formatul fișier:\\server\share\directory\file.txt, proprietatea LocalPath returnează numai numele directorului și fișierelor, iar proprietatea AbsolutePath include numele serverului și al partajării.
Interogare	Proprietatea Interogare arată linia care urmează calea: ?pageid=1078&country=DACH.
PathAndQuery	Proprietatea PathAndQuery oferă calea și combinația șirului de interogare: /training/generic.asp?pageid=1078&country=DACH.
Fragment	Dacă calea este urmată de un fragment, acesta este returnat în proprietatea Fragment. Calea poate fi urmată doar de un șir de interogare sau fragment. Fragmentul este identificat prin simbolul #
Segmente	Proprietatea Segments returnează o matrice de șiruri formate din cale. În acest caz avem trei segmente: /, training/ și generic.asp.
Informații utilizator	Numele de utilizator setat în URI poate fi citit din proprietatea UserInfo. Transmiterea numelor de utilizator este comună în protocol FTPși dacă este specificat un utilizator non-anonim, de exemplu ftp:// [email protected], atunci proprietatea UserInfo va returna myuser.

În plus față de cele enumerate, există câteva alte proprietăți care returnează valori booleene dacă URI-ul reprezintă un fișier, cale UNC, adresă părere sau dacă numărul de port implicit este utilizat pentru acest protocol. Aceste proprietăți sunt IsFile, IsUnc, IsLoopback și, respectiv, IsDefaultPort.

Pentru a accesa orice resurse de rețea, trebuie să știți unde se află acestea și cum să le accesați. World Wide Web folosește o schemă standardizată de adresare și identificare care ține cont de experiența de adresare și identificare a e-mailului, Gopher, WAIS, telnet, ftp etc. - URL, Uniform Resource Locator.

URI(Identificator uniform de resurse, ID universal resursă) (RFC 2396, august 1998) - un șir compact de caractere pentru a identifica o resursă abstractă sau fizică. O resursă este înțeleasă ca orice obiect aparținând unui anumit spațiu. Include și suprascrie adrese URL definite anterior (RFC 1738/RFC 1808) și URN-uri (RFC 2141, RFC 2611).

Un URI este destinat să identifice în mod unic orice resursă.

Unele subseturi de URI:

URNĂ Uniform Resource Name - O schemă URI privată „urn:” cu un subset de „namespace” care trebuie să fie unic și imuabil chiar dacă resursa nu mai există sau este inaccesibilă.

Se presupune că, de exemplu, browserul știe unde să caute această resursă.

Sintaxă:

urn:namespace: data1.data2,more-data, unde namespace determină modul în care sunt utilizate datele după al doilea „:”.

Exemplu de URN:

urnă: ISBN: 0-395-36341-6

ISBN - clasificator de subiecte pentru edituri

0-395-36341-6 - număr specific subiectul unei cărți sau al unei reviste

La primirea URN-ului, programul client accesează ISBN (directorul „clasificator de subiecte pentru edituri” de pe Internet). Și obține o decodare a numărului subiectului „0-395-36341-6” (de exemplu: „chimie cuantică”).

URN este utilizat pe scară largă în rețelele P2P (cum ar fi edonkey).

Un exemplu de URN care indică o imagine de disc Adobe Photoshop v8.0 din rețeaua edonkey:

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

ed2k - indică către rețea

Adobe Photoshop v8.0.iso - numele fișierului

940769280 - dimensiunea în octeți

- identificatorul fișierului (calculat folosind o funcție hash)

URL uniform de localizare a resurselor:

URL(Uniform Resource Locator, RFC 1738) - un localizator unificat (index) de resurse, o modalitate standardizată de înregistrare a unei adrese de resurse pe WWW și pe Internet. O adresă URL are o structură flexibilă și extensibilă pentru a indica locația resurselor pe web într-un mod cât se poate de natural, identificând o resursă după modul în care este accesată (de exemplu, „locația sa web”), mai degrabă decât identificând-o după nume sau alte atribute a acelei resurse.

Exemple de adrese URL:

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

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

Un set limitat de caractere ASCII este utilizat pentru a reprezenta o adresă.

Aspectul general al adresei poate fi reprezentat astfel:

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

schema de acces la resurse: http, ftp, gopher, mailto, news, telnet, file, man, info, whatis, ldap, wais etc.

Parola de logare- numele de utilizator și parola utilizate pentru a accesa resursa

gazdă numele de domeniu al gazdei sau adresa IP.

Port- portul gazdă pentru conexiune

calea completă către resursă - clarificarea informațiilor despre localizarea resursei (în funcție de protocol).

Exemple de adrese URL:

http://example.com #query pagina de pornire implicită

http://www.example.com/site/map.html #request pagina datăîn directorul specificat

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

http://example.org/script.php?key=value #request cu parametrii trecuți la script

ftp://utilizator: [email protected]#conectați-vă la un server ftp cu autorizație

http://192.168.0.1/example/www #conectare după adresa de rețea

file:///srv/www/htdocs/index.html #deschideți fișierul local

gopher://example.com/1 #conectați-vă la serverul gopher

URL - Uniform Resource Locators descrie în mod explicit cum să ajungeți la obiect.

Apariția URL-urilor a fost o inovație semnificativă pe Internet. Cu toate acestea, din momentul inventării sale și până în prezent, standardul URL are un dezavantaj serios - poate folosi doar un set limitat de caractere, chiar mai mic decât în ​​ASCII: litere latine, cifre și doar câteva semne de punctuație.

Dacă vrem să folosim caractere chirilice sau hieroglife sau, de exemplu, caractere franceze specifice în URL, atunci caracterele de care avem nevoie trebuie să fie recodate într-un mod special.

În Wikipedia în limba rusă vezi exemple în fiecare zi codificare URL, deoarece limba rusă folosește caractere chirilice. De exemplu, o linie ca:

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

codificat în adresa URL ca:

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

Această conversie are loc în două etape: în primul rând, fiecare caracter chirilic este codificat în Unicode (UTF-8) într-o secvență de doi octeți, apoi fiecare octet al acestei secvențe este scris în notație hexazecimală:

M → D0 și 9C → %D0%9C

și → D0 și B8 → %D0%B8

la → D0 și BA → %D0%BA

p → D1 și 80 → %D1%80 etc.

Conform specificației URL, fiecare astfel de cod de octet hexazecimal este precedat de un semn de procente (%) - de aici provine termenul englezesc „procent-encoding”, care indică modul în care caracterele sunt codificate în URL-uri și URI-uri.

Deoarece literele tuturor alfabetelor, cu excepția alfabetului latin de bază, sunt supuse acestei transformări, o adresă URL cu cuvinte în marea majoritate a limbilor (cu excepția limbilor engleze, italiene, latine) poate deveni imposibil de citit pentru oameni.

Toate acestea contrazic principiul internaționalismului proclamat de toate organizațiile de top din Internet, inclusiv W3C și ISOC. Standardul IRI (International Resource Identifier) ​​este destinat să rezolve această problemă - identificatori internaționali de resurse în care caracterele Unicode ar putea fi folosite fără probleme și, prin urmare, nu ar încălca drepturile altor limbi.

Alte scheme URL

Schema HTTP.

Schema indică identificatorul său, adresa mașinii, portul TCP, calea în directorul serverului, variabilele și valorile acestora și eticheta.

Sintaxă:

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

http - numele schemei

utilizator - nume de utilizator

gazdă - nume de gazdă

port - numărul portului

interogare(<имя-поля>=<значение>{&<имя-поля>=<значение>) - șir de interogare

Definit în RFC 2068. Implicit, port=80.

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

Acesta este cel mai comun tip de URI utilizat în documentele WWW. După numele schemei (http) este o cale constând din adresa de domeniu a mașinii și adresa completă a documentului HTML din arbore server HTTP.

De asemenea, este posibil să utilizați o adresă IP ca adresă de mașină:

http://195.208.44.20/internet/index.php

Dacă serverul de protocol HTTP rulează pe altceva decât 80 Port TCP, atunci acest lucru se reflectă în adresa:

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

http://195.208.44.20/internet/index.php#metka1
Caracterul „#” separă numele documentului de numele etichetei.

Variabilele și valorile lor sunt transmise după cum urmează:
http://ipm.kstu.ru/internet/index.php?var1=value1&vard2=value2

Valorile „var1” și „var2” sunt numele variabilelor, iar „valoare1” și „valoare2” sunt valorile acestora.

Schema FTP

Această schemă vă permite să adresați arhivele de fișiere FTP.

Sintaxă:

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

ftp - numele schemei

utilizator - nume de utilizator

parola - parola utilizator

gazdă - nume de gazdă

port - numărul portului

url-path - calea către fișier și fișierul în sine

Definit în RFC 1738. Implicit, port=21, utilizator=anonim, parolă=adresă de e-mail, dacă numele este specificat, dar parola nu este, atunci se solicită în dialog.

are forma:

//...//[;tip= ], Unde :

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

Pentru a specifica numele de utilizator și parola, trebuie să le scrieți astfel:
ftp://name:parola@ftp://ipm.kstu.ru/students/name/

În acest caz, acești parametri sunt separați de adresa mașinii prin simbolul „@” și unul de celălalt prin două puncte.

Schema MAILTO

Această schemă este concepută pentru a trimite e-mail.

Sintaxă:

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

mailto - numele schemei

e-mail-1 ( @) - prima adresă de e-mail

utilizator - nume de utilizator

gazdă - nume de gazdă

e-mail-2 - a doua adresă de e-mail

interogare(<имя-поля-заголовка>=<значение>{&<имя-поля-заголовка>=<значение>) - șir de interogare

mailto: [email protected]

Această schemă transferă câmpuri și valorile acestora:

mailto: [email protected]?subject=Email_subject&body=Text_which_will_be_inserted_in_the_email

Adresa destinatarului poate fi scrisă și ca valoare a câmpului către:

mailto: [email protected]?subject=Email_subject&body=Text_which_will_be_inserted_in_the_email

Ce este HTTP?

Primul document (dar nu un standard) este RFC1945 (Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk mai 1996)

Ultima versiune - RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee iunie 1999)

Hypertext Transfer Protocol este un protocol de transfer hipertext, un protocol de nivel înalt (și anume, nivelul aplicației). Folosit de serviciul WWW pentru a transmite pagini Web.

HTTP (HyperText Transfer Protocol, RFC 2616, versiunea curentă HTTP/1.1) - protocol de transfer hipertext. Acest protocol a fost inițial destinat schimbului de documente hipertext, dar acum capacitățile sale au fost extinse semnificativ (în special, au fost adăugate funcții de suport pentru streaming).

HTTP este un protocol tipic client-server; mesajele sunt schimbate conform schemei cerere-răspuns sub formă de comenzi ASCII. O caracteristică a protocolului HTTP este capacitatea de a specifica în cerere și răspuns metoda de reprezentare a aceleiași resurse prin diverși parametri: format, codificare, limbă etc. Datorită capacității de a specifica modul în care este codificat un mesaj, clientul și serverul pot face schimb de date binare, deși acest protocol este bazat pe text.

HTTP este un protocol la nivel de aplicație, dar este folosit și ca „transport” pentru alte protocoale de aplicație, cum ar fi SOAP, XML-RPC, WebDAV.

Protocolul HTTP definește o metodă cerere-răspuns de interacțiune între un program client și un program server din interior Lumea tehnologiei Wide Web.

Pentru a încărca o pagină web în browserul clientului, acesta trimite un program special instalat pe computerul server, numit server http, o solicitare corespunzătoare și prelucrează datele primite de la acesta. În acest caz, funcția browserului este de a solicita de la server pagina specifică, primiți-l și afișați-l pe ecranul utilizatorului. Serverul acceptă cererea, caută documentul solicitat și oferă clientului fie conținutul fișierului găsit, fie un mesaj de eroare dacă un astfel de fișier nu a fost găsit sau accesul la acesta este interzis dintr-un motiv oarecare. Un punct important pentru a înțelege acest proces este că serverul http nu analizează conținutul documentului transmis. În linii mari, serverului http nu-i pasă ce se află în interiorul fișierului solicitat, doar îl transferă în browser, iar browserul își asumă toată munca de structurare și afișare a informațiilor primite.

Căutarea paginii solicitate se efectuează într-un anume director, care este alocat pe computerul serverului acestui site - un link către acest director este prezent în adresa introdusă de utilizator. În cazul în care accesul nu se face la un document anume, ci la site în ansamblu, serverul http înlocuiește automat numele fișierului transferat cu așa-numita „pagină de pornire”, care se numește index.htm sau index. .html (în unele cazuri - default. htm sau default.html). Acest document trebuie să fie localizat în directorul rădăcină rezervat pentru găzduirea site-ului dvs. sau, dacă este specificat în mod specific, într-un director numit WWW. Toate celelalte fișiere pot fi plasate fie în același director, fie în subdirectoare, ceea ce este uneori convenabil, mai ales când site-ul conține mai multe secțiuni sau titluri tematice.

Pe lângă subfolderele pe care le creați, în care aveți libertatea de a plasa aproape orice conținut de care aveți nevoie, directorul serverului conține de obicei mai multe directoare care ar trebui menționate separat. În primul rând, acesta este folderul CGI-BIN, unde se află scripturile CGI și alte scripturi rulate de pe site-ul dvs. aplicații interactive, precum și mai multe directoare de servicii necesare pentru operatie normala Server. Pe stadiul inițial pur și simplu nu ar trebui să le acorzi atenție. Uneori, în același director în care este stocat index.html există un număr de fișiere suplimentare: not_found.html - un document care este afișat în cazul în care serverul http nu a putut găsi fișierul solicitat de utilizator, forbidden.html - afișat ca mesaj de eroare dacă accesul la documentul solicitat este refuzat și, în final, robots.txt - a dosar , în care într-un mod special descrie regulile de indexare a site-ului dvs. de către motoarele de căutare.

În cele mai multe cazuri, și mai ales când se publică o pagină de pornire pe servere care oferă găzduire gratuită, accesul la directoarele de servicii și la folderul CGI-BIN este interzis utilizatorilor, iar modificarea conținutului fișierelor not_found și forbidden.html este, de asemenea, imposibilă. Acesta este ceva de luat în considerare dacă intenționați să includeți în resursa dvs. orice conținut interactiv care necesită, cel puțin, capacitatea de a plasa fișiere într-unul dintre folderele de serviciu. În unele cazuri, vi se poate interzice crearea de subdirectoare pe server, caz în care utilizatorul va trebui să se mulțumească cu un singur director alocat nevoilor dumneavoastră.

Din tot ceea ce s-a spus, devine clar că browserul clientului poate primi și procesa informații de la server doar și le poate plasa și modifica numai dacă încărcarea fișierelor pe server este implementată pe baza protocolului HTTP folosind scripturi CGI speciale incluse în interfață web server. În toate celelalte cazuri, trebuie să utilizați așa-numitul server ftp, pe care îl puteți transfera fisierele necesare, încărcându-le automat în directorul desemnat pentru site-ul dvs. În ambele cazuri, va trebui să vă cunoașteți numele de conectare și parola pentru a accesa sistemul. De asemenea, trebuie amintit că majoritatea programe server(în special, Apache pentru platformele compatibile cu UNIX) fac diferența între caracterele mici și mari, astfel încât toate numele fișierelor și extensiile lor ar trebui scrise pentru a evita erorile litere mici, și întotdeauna în latină. Acesta din urmă se datorează diferențelor de procesare a codificărilor în limba rusă, caracteristice anumitor servere.

Protocolul HTTP funcționează după cum urmează: programul client stabilește o conexiune TCP cu serverul (portul standard numărul 80) și îi emite o solicitare HTTP. Serverul procesează această solicitare și emite un răspuns HTTP către client.

Interacțiunea dintre client și serverul Web se realizează prin schimbul de mesaje. Mesajele HTTP sunt împărțite în solicitări client către server și răspunsuri server către client.

Mesajele de solicitare și răspuns au un format comun. Ambele tipuri de mesaje arată astfel: mai întâi există o linie de început, apoi poate unul sau mai multe câmpuri de antet, numite și antete, apoi o linie goală (adică o linie formată din caracterele CR și LF), care indică sfârșitul din câmpurile antetului și apoi, eventual, corpul mesajului:

linia de start

câmpul antet 1

câmpul antet 2

câmpul antet N

Conținutul mesajului

Antetele protocolului HTTP

Formatele liniei de pornire client și server sunt diferite și vor fi discutate mai jos. Există patru tipuri de titluri:

Anteturi generale, care pot fi prezente atât în ​​cerere, cât și în răspuns;

Antetele cererii, care pot fi prezente doar în cerere;

Antete de răspuns, care pot fi prezente numai în răspuns;

Anteturi de entitate, care se referă la corpul mesajului și descriu conținutul acestuia.

Fiecare antet constă dintr-un titlu, un caracter două puncte „:” și o valoare. Cele mai importante rubrici sunt prezentate în Tabelul 1.

tabelul 1

Antetele protocolului HTTP

Titlu	Scop
Anteturi obiect
Permite	Listează metodele acceptate de server
Codificarea conținutului	Modul în care este codificat corpul mesajului, de exemplu pentru a reduce dimensiunea
Conținut-Lungime	Lungimea mesajului în octeți
Tipul de conținut	Conține desemnarea tipului de conținut MIME a răspunsului. În funcție de valoarea Content-Type, browserul interpretează răspunsul ca o pagină HTML, o imagine gif sau jpeg, un fișier care urmează să fie salvat pe disc sau altceva și ia măsurile corespunzătoare. Unele tipuri de conținut: text/html - text in format HTML(pagină web); text/plain - text simplu (similar cu Notepad); imagine/jpeg - imagine în format JPEG; imagine/gif - la fel, în format GIF; Poate transmite, de asemenea, codificarea datelor text. De exemplu: charset=windows-1251 charset=koi8-rus Content-Length - lungimea conținutului răspunsului în octeți (dimensiunea fișierului). Last-Modified - data și ora ultimei modificări a documentului.
ETag	O etichetă unică de resurse pe server care vă permite să comparați resurse
Expiră	Data și ora la care resursa de pe server va fi modificată și trebuie să fie preluată din nou
Modificat ultima dată	Data și ora la care conținutul a fost modificat ultima dată
Antete de răspuns
Vârstă	Numărul de secunde după care solicitarea trebuie repetată pentru a obține conținut nou
Locație	URI-ul resursei de accesat pentru a obține conținutul
Reîncercați-După	Data și ora sau numărul de secunde după care cererea trebuie repetată pentru a obține un răspuns de succes
Server	Numele software-ului server care a trimis răspunsul
Antete de solicitare
Accept	O listă de tipuri de conținut acceptate de browser în ordinea preferințelor browserului, de exemplu: Accept: imagine/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application /vnd. ms-powerpoint, */* Acest lucru este evident necesar pentru cazul în care serverul poate scoate același document în formate diferite. Valoarea acestui parametru este folosită în principal de scripturile CGI pentru a genera un răspuns adaptat pentru un anumit browser.
Accept-Charset	Codificări de caractere în care clientul poate accepta conținut text
Acceptare-Codare	Modul în care serverul poate codifica mesajul
Gazdă	Numărul gazdei și portului de la care este solicitat documentul
Dacă-Modificat-Dincă Dacă-Se potrivește Dacă-Niciunul-Se potrivește Dacă-Range Dacă-Nemodificat-Dincă	Antete de solicitare pentru acces condiționat la resurse
Gamă	Solicitați o parte dintr-un document
Agent utilizator	Nume software client - valoarea este „codul” browserului, de exemplu: Mozilla/4.0 (compatibil; MSIE 5.0; Windows 95; DigExt)
Titluri generale
Conexiune	Conexiune - poate lua valorile Keep-Alive și close. Keep-Alive înseamnă că după emiterea acestui document, conexiunea la server nu este întreruptă și pot fi emise mai multe solicitări. Majoritatea browserelor funcționează în modul Keep-Alive, deoarece vă permite să „descărcați” o pagină html și imagini pentru aceasta într-o singură conexiune la server. Odată setat, modul Keep-Alive este menținut până la prima eroare sau până la următoarea solicitare Connection: close este specificată în mod explicit. close ("închidere") - conexiunea este închisă după ce răspunde la această solicitare.
Data	Data și ora la care a fost generat mesajul
Pragma	Comenzi speciale, dependente de implementare, referitoare la conținutul transferat
Transfer-Codificare	Metodă de codificare a unui mesaj în timpul transmisiei

În unele anteturi, valoarea este data și ora. Acestea trebuie să fie prezentate în formatul descris în RFC 1123, de exemplu:

Corpul mesajului conține informațiile reale care sunt transmise - sarcina utilă a mesajului. Corpul mesajului este o secvență de octeți (octeți). Corpul mesajului poate fi codificat, cu metoda de codificare specificată în antetul obiectului Content-Encoding.

Un mesaj de solicitare de la un client către un server constă dintr-o linie de solicitare, anteturi (general, cereri, obiect) și, eventual, un corp de mesaj.

Linia de solicitare începe cu metoda, urmată de identificatorul resursei solicitate, versiunea protocolului și caracterele de final de linie:

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

Metodă specifică metoda de aplicat resursei solicitate. De exemplu, metoda GET indică faptul că clientul dorește să recupereze conținutul unei resurse. Identificatorul identifică resursa solicitată. Versiunea HTTP este indicată printr-o linie ca aceasta:

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

Metode de protocol HTTP

Să ne uităm la principalele metode ale protocolului HTTP.

Metoda OPȚIUNI solicită informații despre opțiunile de conectare (de exemplu, metode, tipuri de documente, codificări) pe care serverul le suportă pentru resursa solicitată. Această metodă permite unui client să specifice opțiunile și/sau cerințele asociate cu o resursă sau cu capabilitățile serverului fără a efectua nicio acțiune asupra resursei sau a determina încărcarea acesteia.

Dacă răspunsul serverului nu este un mesaj de eroare, atunci anteturile obiectelor conțin informații care pot fi considerate opțiuni de conexiune. De exemplu, antetul Allow listează toate metodele acceptate de server pentru o anumită resursă.

Dacă identificatorul de resursă solicitat este un asterisc (“*”), atunci cererea OPȚIUNI este destinată să se adreseze serverului în întregime.

Dacă ID-ul resursei solicitate nu este un asterisc, atunci solicitarea OPȚIUNI se aplică opțiunilor care sunt disponibile la conectarea la resursa specificată.

Metoda GET vă permite să obțineți orice informație legată de resursa solicitată. În cele mai multe cazuri, dacă identificatorul de resurse solicitat indică un document (de exemplu, un document text, o grafică, un videoclip), atunci serverul returnează conținutul acelui document (conținutul fișierului). Dacă resursa solicitată este o aplicație (program) care generează date, atunci datele generate sunt returnate în corpul mesajului de răspuns, mai degrabă decât o imagine binară a fișierului executabil. Acesta este folosit, de exemplu, la crearea aplicațiilor CGI. Dacă identificatorul resursei solicitate indică către un director (director, folder), atunci, în funcție de setările serverului, fie conținutul directorului (lista de fișiere), fie conținutul unuia dintre fișierele aflate în acest director (de obicei index.html sau Default.htm). ÎN acest din urmă caz Numele folderului poate fi specificat fie cu sau fără simbolul „/” la sfârșit. Dacă acest caracter nu este prezent la sfârșitul identificatorului, serverul emite unul dintre răspunsuri cu redirecționare (cu codurile de stare 301 sau 302).

Se face o distincție între „GET condiționat” în care mesajul de solicitare include anteturile cererii If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match sau If-Range. Metoda GET condiționată solicită transferul unui obiect numai dacă îndeplinește condițiile descrise în anteturile date. Metoda GET condiționată este concepută pentru a reduce descărcare inutilă rețea, deoarece vă permite să evitați reîncărcarea datelor deja salvate de client.

Se face, de asemenea, o distincție între „GET parțial” și „GET parțial”, în care mesajul de solicitare include un antet de solicitare Range. Un GET parțial solicită ca doar o parte a unui obiect să fie transferată. Metoda GET parțială este concepută pentru a reduce supraîncărcarea inutilă a rețelei prin solicitarea doar a unei părți a unui obiect atunci când o altă parte a fost deja descărcată de client. Valoarea antetului Range este intervalul de octeți care trebuie recuperați. Octeții sunt numerotați începând de la 0. Octeții de început și de sfârșit ai intervalului sunt separați printr-un caracter „–”. Dacă trebuie să obțineți mai multe intervale, acestea sunt listate separate prin virgule.

Metoda HEAD este identică cu GET, cu excepția faptului că serverul nu returnează corpul mesajului în răspuns. Metainformațiile conținute în anteturile de răspuns HTTP la o solicitare HEAD sunt identice cu informațiile furnizate ca răspuns la o solicitare GET. Această metodă poate fi folosită pentru a obține informații despre un obiect de solicitare fără a trece direct corpul obiectului. Metoda HEAD este adesea folosită pentru a testa legăturile hipertext.

Metoda POST este utilizată pentru o cerere în care serverul adresat acceptă datele incluse în corpul mesajului de cerere (obiect) și le trimite spre procesare către aplicația specificată ca resursă solicitată. POST este conceput pentru a implementa o metodă comună următoarele funcții:

Rezumat al resurselor existente;

Postarea unui mesaj într-un sistem de buletin board (BBS), grupuri de știri, liste de corespondență sau un grup similar de articole;

Transferarea unui bloc de date, de exemplu rezultatul unei intrări într-un formular, către un proces de procesare;

Executarea de interogări către baze de date (DB);

De fapt, funcția îndeplinită de metoda POST este determinată de aplicația la care se indică ID-ul resursei solicitate. Alături de metoda GET, metoda POST este utilizată la crearea aplicațiilor CGI. Browserul poate emite solicitări cu metoda POST atunci când trimite formulare. Pentru a face acest lucru, elementul FORM al documentului HTML care conține formularul trebuie să aibă un atribut METHOD cu valoarea POST.

O acțiune efectuată prin metoda POST poate efectua o acțiune pe server și să nu returneze niciun conținut ca rezultat al operației. În acest caz, în funcție de faptul dacă răspunsul include un corp de mesaj care descrie rezultatul sau nu, codul de stare din răspuns poate fi fie 200 (OK) fie 204 (Fără conținut).

Dacă resursa de pe server a fost creată, răspunsul conține un cod de stare 201 (Creat) și include un antet de răspuns Locație.

Corpul mesajului, care este transmis într-o cerere cu metoda PUT, este stocat pe server, iar identificatorul resursei solicitate va fi identificatorul documentului salvat. Dacă identificatorul de resurse solicitat indică o resursă deja existentă, atunci obiectul inclus în corpul mesajului este tratat ca o versiune modificată a resursei situate pe server. Dacă a fost creată o nouă resursă, serverul notifică agentul utilizator răspunzând cu codul de stare 201 (Creat).

Diferența fundamentalăîntre metodele POST și PUT este sens diferit ID-ul resursei solicitate. URI-ul din cererea POST identifică resursa care procesează obiectul inclus în corpul mesajului. Această resursă ar putea fi aplicația care primește datele. În schimb, URI-ul dintr-o cerere PUT identifică entitatea inclusă în cerere ca fiind corpul mesajului, adică agentul utilizator atribuie URI-ul dat resursei incluse.

Metoda DELETE solicită serverului să șteargă o resursă care are ID-ul solicitat. O solicitare cu această metodă poate fi respinsă de server dacă utilizatorul nu are drepturi de a șterge resursa solicitată.

Metoda TRACE este utilizată pentru a returna cererea transmisă la nivel de protocol HTTP. Destinatarul cererii (serverul Web) trimite mesajul primit înapoi către client ca corpul unui obiect de răspuns cu un cod de stare de 200 (OK). Solicitarea TRACE nu trebuie să conțină un corp de mesaj.

TRACE permite clientului să vadă ce primește serverul la celălalt capăt și să utilizeze aceste date pentru testare sau diagnosticare.

Dacă cererea are succes, răspunsul conține întregul mesaj de solicitare în corpul mesajului de răspuns, iar antetul obiectului Content-Type este „message/http”.

Codurile de răspuns

După primirea și interpretarea mesajului de solicitare, serverul răspunde cu un mesaj de răspuns HTTP.

Prima linie a răspunsului este linia de stare. Este alcătuit din versiunea protocolului, un cod de stare numeric, o frază explicativă, separate prin spații și caractere de final de linie:

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

Versiunea de protocol are aceeași semnificație ca și în cerere.

Elementul Status-Code este un cod întreg din trei cifre (trei cifre) pentru rezultatul înțelegerii și satisfacerii cererii. Motivul-Expresia este o scurtă descriere text a codului de stare. Codul de stare este destinat să fie procesat de software, iar fraza explicativă este destinată utilizatorilor.

Prima cifră a codului de stare determină clasa răspunsului. Ultimele două cifre nu au un rol specific în clasificare. Există 5 semnificații pentru prima cifră:

1xx: Coduri de informații - cerere primită, procesarea continuă.

2xx: Coduri de succes- acțiunea a fost primită, înțeleasă și procesată cu succes.

3xx: coduri de redirecționare - trebuie luate măsuri suplimentare pentru a finaliza solicitarea.

4xx: coduri de eroare client - cererea are o eroare de sintaxă sau nu poate fi finalizată.

5xx: coduri de eroare server - serverul nu poate finaliza o solicitare validă.

Expresia-motiv pentru fiecare cod de stare este listată în RFC 2068 și este recomandată, dar poate fi înlocuită cu altele echivalente fără a afecta protocolul. De exemplu, în versiunile localizate în limba rusă ale serverelor HTTP, aceste expresii sunt înlocuite cu cele rusești. Tabelul 2 prezintă codurile de răspuns ale serverului HTTP.

masa 2

Codurile de răspuns ale serverului HTTP

Cod	Expresie explicativă conform RFC 2068	Expresie explicativă echivalentă în rusă
1xx: coduri de informații
	Continua	Continua
2xx: coduri de succes
	Bine	Bine
	Creată	Creată
	Fara continut	Fara continut
	Resetați conținutul	Resetați conținutul
	Conținut parțial	Conținut parțial
3xx: coduri de redirecționare
	Mutat temporar	Mutat temporar
	Nemodificat	Nemodificat
4xx: coduri de eroare client
	Cerere greşită	Cerere greşită
	Neautorizat	Neautorizat
	Nu a fost găsit	Nu a fost găsit
	metoda nepermisa	Metoda nepermisa
	Solicitare Timeout	Cererea a expirat
	Conflict	Conflict
	Lungimea necesară	Lungimea necesară
	Entitatea solicitată este prea mare	Obiectul de solicitare este prea mare
5xx: coduri de eroare server
	Intern Eroare de server	Eroare internă servere
	Neimplementat	Neimplementat
	Serviciu indisponibil	Serviciul nu este disponibil
	Versiunea HTTP nu este acceptată	Versiunea HTTP nu este acceptată

Linia de stare este urmată de anteturi (general, răspuns și obiect) și, eventual, un corp de mesaj.

Una dintre cele mai importante funcții server web este de a oferi acces la o parte din local Sistemul de fișiere. Pentru a face acest lucru, în setările serverului este specificat un anumit director, care este directorul rădăcină pentru acest server. A publica un document, adică a-l realiza accesibile utilizatorilor, care a „vizitat” acest server (conectat la acesta prin protocolul HTTP), trebuie să copiați acest document în directorul rădăcină Server web sau unul dintre subdirectoarele acestuia. La conectarea prin HTTP, pe server este creat un proces cu drepturi de utilizator, care, de regulă, nu există cu adevărat, dar este creat special pentru a vizualiza resursele serverului. Prin configurarea drepturilor și a permisiunilor unui anumit utilizator, puteți controla accesul la resursele Web.

Sa luam in considerare cel mai simplu exemplu Solicitare HTTP. Dacă introducem adresa http://yandex.ru în fereastra de adresă a browserului, browserul va determina adresa IP a serverului yandex.ru și îi va trimite următoarea solicitare HTTP pe portul 80:

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

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

Accept-Language: en

Cookie: yandexuid=2464977781018373381

User-Agent: Mozilla/4.0 (compatibil; MSIE 5.5; Windows 98)
Gazdă: yandex.ru

Referitor: narod.ru

Conexiune proxy: Keep-Alive

Solicitarea este transmisă sub formă de text necriptat. Cea mai importantă parte a cererii se află în prima linie: Acesta este tipul de solicitare (GET), adresa URL a documentului solicitat (http://yandex.ru) și versiunea Protocolul HTTP(HTTP/1.0). Următorii sunt parametrii cererii. Fiecare linie corespunde unui parametru. Linia începe cu numele parametrului, urmat de două puncte și valoarea parametrului.

Accept - tipul de date pe care browserul le poate accepta (în codificare MIME).

Accept-Language - limba preferată în care browserul dorește să accepte date. User-Agent - tip de program care a trimis solicitarea.

Gazdă – numele DNS (sau IP) al gazdei căreia îi este adresată cererea.

Cookie - cookie-uri (date care au fost salvate de server pe disc local client, când a vizitat această gazdă ultima dată).

Referer - gazda de pe pagina căreia trimitem solicitarea. Deci, de exemplu, dacă ne aflăm pe pagina http://narod.ru și facem clic pe linkul http://yandex.ru acolo, atunci cererea va fi trimisă gazdei yandex.ru și câmpul de solicitare referitor va conține numele de gazdă narod.ru.

Setul de parametri de cerere nu este fix. Pe lângă cei enumerați, pot fi prezenți și alți parametri.

Cei mai interesanți parametri sunt referer și cookie. Acești parametri sunt utilizați în primul rând pentru a identifica utilizatorul pe server.

O solicitare GET poate conține date trimise de la client către server. Acestea sunt transmise direct printr-un URL folosind protocolul CGI. Datele sunt separate de adresa URL printr-un „?” și conectat prin „&”:

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

Acest tip de transfer de date către server este convenabil, dar are limitări ale volumului. Cantități prea mari de date nu pot fi transferate prin URL. În astfel de scopuri, există un alt tip de solicitare: o cerere POST. O solicitare POST este foarte asemănătoare cu o GET, singura diferență fiind că datele dintr-o solicitare POST sunt trimise separat de antetul cererii în sine:

Corpul cererii trebuie separat de antet printr-o linie goală. Dacă serverul întâlnește o linie goală într-o cerere POST, atunci consideră că tot ceea ce urmează a fi corpul cererii (date transmise). Rețineți următoarele: formatul datelor din corpul solicitării POST este arbitrar. Deși CGI este formatul cel mai frecvent utilizat, nu este necesar. În plus, o solicitare POST nu necesită un corp de cerere și poate transmite date și prin intermediul unui URL.

Pe lângă formatul CGI, uneori, așa-numitul format CGI este folosit pentru a transfera cantități mari de informații (de exemplu, fișiere). format multipart (formatul datelor transmise este determinat de parametrul Content-Type):

Browserele moderne includ instrumente pentru dezvoltatorii web pentru a obține unele informații despre solicitările de postare trimise. Dacă trebuie să vă uitați doar la antetele câtorva solicitări, utilizarea acestora va fi mai ușoară și mai rapidă decât alte metode.

Dacă utilizați Firefox, puteți utiliza consola sa web. Afișează antetele cererii și conținutul transmis cookie-uri. Pentru a-l lansa, deschideți meniul browserului, faceți clic pe „Web Development” și selectați „Web Console”. În panoul care apare, activați butonul „Rețea”. Introduceți numele metodei – postare – în câmpul de filtrare. În funcție de obiectivele dvs., faceți clic pe butonul de formular care trimite solicitarea dorită sau reîmprospătați pagina. Solicitarea trimisă va fi afișată în consolă. Faceți clic pe el pentru a vedea mai multe detalii.

Browser Google Chrome are instrumente puternice de depanare. Pentru a le folosi, faceți clic pe pictograma cheie, apoi extindeți elementul „Personalizați și gestionați Google Chrome”. Selectați Instrumente și lansați Instrumente pentru dezvoltatori. În bara de instrumente, selectați fila Rețea și trimiteți solicitarea. Găsiți cererea dorită în listă și faceți clic pe ea pentru a studia detaliile.

Browserul Opera are instrumente de dezvoltare încorporate pentru Opera Dragonfly. Pentru a le lansa, faceți clic dreapta pe pagina dorită și selectați meniul contextual"Inspectează elementul." Accesați fila Rețea din Instrumentele pentru dezvoltatori și trimiteți solicitarea dvs. Găsiți-l în listă și extindeți-l pentru a examina antetele serverului și răspunsurile.

Internet Explorer 9 conține un kit numit F12 Developer Tools care oferă informatii detaliate conform cererilor completate. Acestea sunt lansate prin apăsarea butonului F12 sau folosind meniul „Service”, care conține articolul cu același nume. Pentru a vizualiza cererea, accesați fila „Rețea”. Găsiți o anumită interogare în rezumat și faceți dublu clic pentru a extinde detaliile.

Browserele Chrome și Internet Explorer 9 conțin instrumente încorporate care vă permit să examinați în detaliu o solicitare post trimisă. Pentru informații complete, folosiți-le sau Firefox cu pluginul Firebug instalat. Este foarte convenabil pentru examinarea frecventă a interogărilor, de exemplu, la depanarea site-urilor web.

Dacă doriți să priviți o solicitare trimisă de un alt program decât browserul, utilizați depanatorul HTTP Fiddler. Funcționează ca un server proxy și interceptează solicitările de la orice program și oferă, de asemenea, informații foarte detaliate despre anteturile și conținutul acestora.