Identificatorul URL nu a fost trimis. URI uniform de identificare a resursei

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. ÎN documentatie tehnica termenul URL nu mai este folosit.

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 trimite 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.

Terminația schemei este urmată de numele serverului sau adresa IP în notație zecimală punctată, de exemplu www.globalknowledge.net.

După numele serverului sau adresa IP este un număr de port care identifică conexiunea la aplicație specifică 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

O schemă de fișiere este utilizată pentru a accesa fișiere local sau pe partajări de rețea, care pot fi denumite conform convenției de denumire universală ( 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 capabilități de navigare ierarhică informații text despre conținut, în care FTP era superior. 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 de port specificat pentru un 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 număr de port diferit, proprietatea Autoritate afișează și 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ă	O cale 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 obișnuită în FTP și, dacă este specificat un utilizator non-anonim, cum ar fi 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, o cale UNC, o adresă de loopback sau dacă numărul de port implicit este utilizat pentru un anumit protocol. Aceste proprietăți sunt IsFile, IsUnc, IsLoopback și, respectiv, IsDefaultPort.

1.4. URI Uniform Resource Identifier

Pentru a înțelege pe deplin modul în care documentele HTML interacționează, navigați între pagini și unde computerul utilizatorului primește în general date atunci când lucrați cu rețeaua, trebuie să luați în considerare cum și ce este accesat folosind Rețeaua globală.

Multe tipuri de resurse găzduite pe Internet, fie că sunt documente HTML, grafice sau fișiere de arhivă, sunt cel mai adesea fișiere de pe hard disk-ul unui computer (server) conectat la rețea. Fiecare resursă este asociată cu o valoare care poate fi utilizată pentru a-și determina locația în mod unic - un identificator universal de resursă sau URI (Universal Resource Identifier). URI-urile sunt utilizate pe scară largă atât atunci când utilizatorul accesează independent o resursă (când, de exemplu, utilizatorul introduce URI-ul în bara de adrese a browserului), cât și atunci când navighează între pagini web. URI-urile sunt, de asemenea, folosite într-un document HTML pentru a spune browserului unde să găsească resurse (cum ar fi imagini) utilizate în documentul în sine.

Notă

Notația URL este adesea folosită în literatură. Trebuie remarcat faptul că un URI este un concept mai general care include o adresă URL: orice URL este un identificator uniform de resurse și este supus acelorași reguli ca un URI.

Un URI de resursă constă din trei părți: numele mecanismului de accesare a resursei, numele de domeniu al computerului și calea fișierului a resursei. Pentru a ilustra acest lucru, luați în considerare un exemplu:

Aici puteți vedea că pentru a accesa resursa, care în acest caz este un document HTML, se folosește protocolul HTTP (Hyper Text Transfer Protocol). Resursa este stocată pe un computer cu numele de domeniu somesite.com în fișierul ex_1.html aflat în folderul /info/examples.

URI-urile se pot referi și la părți ale documentelor HTML, de exemplu:

Folosind acest URI, puteți accesa o porțiune a documentului HTML numită descriere (vom acoperi cum să creați nume pentru fragmentele de document HTML în Capitolul 5).

URI-urile vă permit, de asemenea, să vă referiți la resurse din același computer. Aceasta specifică calea relativă a resursei. De exemplu, pentru a face referire la fișierul /info/files/file1.jpg dintr-un document HTML aflat în folderul /info/examples, trebuie doar să specificați URI-ul /files/file1.jpg. În documentele HTML, folosind astfel de legături, sunt indicate căile imaginilor și ale altor obiecte utilizate în documente, dar nu stocate direct în acestea.

În general, URI-urile sunt considerate fără majuscule. Cu toate acestea, pentru a fi pe deplin siguri de interpretarea corectă a URI-ului, fiți totuși atenți la cazul caracterelor din URI de hyperlinkuri, imagini etc. Acest lucru este util pentru eliminarea unor astfel de situații când, de exemplu, când site-ul rulează pe un computer Windows, toate hyperlinkurile funcționează, dar când site-urile sunt plasate pe UNIX, serverul refuză să funcționeze (în UNIX, numele fișierelor sunt sensibile la majuscule).

URI uniform de identificare a resursei. URI-urile sunt cunoscute sub mai multe nume: adrese WWW, identificatori uniformi de documente, identificatori uniformi de resurse, URI-uri și, în sfârșit, ca o combinație de localizatori uniformi de resurse, URL-uri și nume de resurse uniforme, URN-uri. HTTP definește o adresă URL pur și simplu ca un șir cu un format specific care identifică o resursă după nume, locație sau orice altă caracteristică. 3.2.1 Sintaxă generală. URI-urile în HTTP pot fi reprezentate în formă absolută URI absolută sau relativ la un URI subiacent cunoscut URI relativ, în funcție de contextul utilizării lor. Cele două forme diferă prin faptul că URI-urile absolute încep întotdeauna cu numele schemei urmat de două puncte.

URI absoluteURI relativeURI fragment absoluteURI schema uchar reserved relativeURI net path cale abs cale cale rel cale net net loc abs cale cale abs cale rel cale rel cale cale parametri? cale de interogare fsegment segment fsegment 1 pchar segment pchar params param param param pchar schema 1 ALPHA DIGIT net loc pchar ? interogare uchar rezervat fragment uchar rezervat pchar uchar uchar nerezervat evadare nerezervat ALPHA DIGIT sigur extra national evadare HEX HEX rezervat ? extra sigur nesigur CTL SP național orice OCTET, cu excepția octeților ALPHA, DIGIT, rezervat, suplimentar, sigur și nesigur Detaliile complete despre sintaxa URL și semantica sunt conținute în RFC 1738 și RFC 1808. Notația normală Beckus-Naur include caractere naționale nepermise în mod obișnuit URL-uri definite de RFC 1738, deoarece serverele HTTP permit utilizarea unui set de not caractere rezervate, și, prin urmare, proxy-urile HTTP pot primi solicitări URI care nu sunt conforme cu RFC 1738. Protocolul HTTP nu impune nicio restricție privind lungimile URI. Serverele trebuie să gestioneze orice URI de resursă de orice lungime pe care o deservesc și trebuie să gestioneze URI-uri cu lungime nelimitată dacă servesc servere bazate pe GET care pot genera un astfel de URI. Serverul TREBUIE să returneze codul de stare 414 Request URI Too Long, Request-URI Too Long, dacă URI-ul este mai lung decât îl poate gestiona serverul.

Serverele ar trebui să acorde atenție URI-urilor care depășesc 255 de octeți, deoarece este posibil ca unii clienți sau proxy mai vechi să nu suporte corect aceste lungimi. 3.2.2 URL HTTP. Schema Http este utilizată pentru a accesa resursele rețelei folosind protocolul HTTP. Această secțiune definește sintaxa și semantica definite de schemă pentru adresele URL HTTP. http URL http host port abs path host un nume de domeniu valid al mașinii sau o adresă IP în formă zecimală punctată, așa cum este definit în secțiunea 2.1 din RFC 1123 port DIGIT Dacă portul este gol sau nu este specificat, este utilizat portul 80 este găzduit pe server, în așteptarea conexiunilor TCP pe cel specificat port, computerul gazdă și URI-ul resursei solicitate - cale abs. Utilizarea adreselor IP în URL-uri ar trebui evitată în măsura posibilului, conform RFC 1900. Dacă calea abs nu este prezentă în adresa URL, aceasta trebuie tratată ca atare atunci când se calculează URI-ul de solicitare solicitat al resursei. 3.2.3

Sfârșitul lucrării -

Acest subiect aparține secțiunii:

Protocolul HTTP 1.1

Prin definiție, RFC 1945 HTTP 1.0 a fost o îmbunătățire a acestui protocol, permițând un format de mesaj asemănător MIME care conține metainformații despre mesajele transmise a RFC-urilor legate de problemele discutate în această lucrare este prezentată în secțiunea Bibliografie. 1.1..

Dacă aveți nevoie de material suplimentar pe această temă, sau nu ați găsit ceea ce căutați, vă recomandăm să utilizați căutarea în baza noastră de date de lucrări:

Ce vom face cu materialul primit:

Dacă acest material ți-a fost util, îl poți salva pe pagina ta de pe rețelele sociale:

Tweet

Toate subiectele din această secțiune:

Terminologie
Terminologie. Conexiune de conectare. Un canal de nivel de transport virtual stabilit între două programe în scopul comunicării. Modulul principal de comunicare HTTP, constând din structural

Parametrii protocolului
Parametrii protocolului. Versiunea HTTP.HTTP utilizează schema de numerotare majoră. minor, pentru a indica versiunea protocolului. Strategia de versiune a protocolului este menită să permită trimiterea

comparație UR
Comparația UR. I. Atunci când compară două URI-uri pentru a decide dacă se potrivesc sau nu, clientul TREBUIE să utilizeze o comparație octet-cu-octet care ține cont de majuscule și minuscule a acelor URI, cu

Data completă
Data completă. Aplicațiile HTTP au permis istoric trei formate diferite pentru reprezentarea datei Duminica, 06 Noiembrie 1994 08 49 37 GMT RFC 822, astfel cum a fost modificat prin RFC 1123 Duminică, 06-Nov-94 08 49 37 GMT

Tabelele de coduri seturi de caractere
Tabelele de coduri seturi de caractere. HTTP folosește aceeași definiție a termenului set de caractere care este definită pentru MIME Termenul set de caractere este folosit pentru a se referi la o metodă care utilizează

Codificarea conținutului
Codificare conținut de conținut codificări. Valoarea de codificare a conținutului indică ce transformare de codificare a fost sau va fi aplicată obiectului. Se utilizează codificarea conținutului

Transfer coduri
Transfer coduri. Valorile de codificare de transfer sunt utilizate pentru a indica conversia de codificare care a fost sau ar trebui să fie aplicată organismului-entitate în scopul

Tipuri media
Tipuri media. HTTP utilizează MediaTypes Internet Internet Tipuri media în câmpurile de antet Content-Type și Accept pentru a oferi date deschise și extensibile și tastare de tip. tip media t

Canonizare și valori predefinite ale textului
Canonizare și semnificații predefinite tastați text. Tipurile media de internet sunt înregistrate în formă canonică. În general, corpul obiectului transmis prin mesajul HTTP trebuie să fie reprezentat de

Tipuri cu mai multe părți
Tipuri cu mai multe părți. MIME oferă un număr de tipuri de mai multe părți - formând un pachet de unul sau mai multe obiecte în corpul unui singur mesaj. Toate tipurile multipart utilizează o sintaxă comună, o

Jetoane de produs
Jetoane de produs. Tokenurile de produs sunt folosite pentru a permite aplicațiilor de comunicații să se identifice după numele și versiunea software-ului.

Valori de calitate
Valori de calitate. HTTP folosește numere scurte în virgulă mobilă pentru a indica importanța relativă a greutăților diferiților parametri specificați. Greutatea este o substanță normalizată

Etichete de limbă
Etichete de limbă. O etichetă de limbă identifică limbajul natural vorbit, scris sau folosit în alt mod de oameni pentru a face schimb de informații cu alte persoane. Limbajele mașinii sunt

Etichete de entitate
Etichete de entitate. Etichetele obiectelor sunt folosite pentru a compara două sau mai multe obiecte din aceeași resursă solicitată. HTTP 1.1 utilizează etichete de entitate în câmpurile antetului ETag

Unități de gamă
Unități de gamă. HTTP 1.1 permite unui client să solicite doar o parte dintr-un obiect. HTTP 1.1 utilizează unități de interval în câmpurile antet Range și Content-Rang

Tipuri de mesaje
Tipuri de mesaje. Mesajele HTTP sunt împărțite în solicitări client către server și răspunsuri server către client. Mesaj HTTP Răspuns la cerere Mesaje HTTP 1.1 Mesajele de solicitare și răspuns utilizează un format generic

Antetele mesajelor
Antetele mesajelor. Câmpurile de antet HTTP, care includ câmpurile antet general, antet cerere, antet răspuns și antet entity-h

Conținutul mesajului
Conținutul mesajului. Corpul mesajului HTTP, dacă este prezent, este utilizat pentru a transmite corpul obiectului asociat cu cererea sau răspunsul. Corpul mesajului mesaj-corp este diferit de corpul despre

Lungimea mesajului
Lungimea mesajului. Când un mesaj-corp este prezent într-un mesaj, lungimea acelui corp este determinată de una dintre următoarele metode, în ordinea de prioritate 1. Orice mesaj de răspuns care nu este

Metoda Metoda
Metoda Metoda. Indicatorul de metodă specifică metoda care trebuie aplicată resursei identificate de URI-ul de solicitare URI solicitat. Metoda este sensibilă la majuscule. Metodă OPȚIUNI GET HEAD PO

Cod de stare și frază explicativă
Cod de stare și frază explicativă. Elementul Status-Code este un cod întreg de trei biți pentru rezultatul unei încercări de a înțelege și executa cererea. Aceste coduri sunt complet definite în secțiune

Conexiuni persistente
Conexiuni persistente. Ţintă. Înainte ca conexiunile persistente să fie introduse în protocol, a fost stabilită o conexiune TCP separată pentru fiecare solicitare URL, ceea ce a crescut încărcarea HTTP de la

Discuție Negociere
Discuție Negociere. Serverul HTTP 1.1 are dreptul de a presupune că clientul HTTP 1.1 nu acceptă o conexiune persistentă dacă antetul de conexiune trimis în cerere conține simbolul de conectare.

Conducte
Prelucrare transportoare Conducte. Client care sprijină conexiuni persistente poate efectua procesarea pipeline a cererilor, adică trimite mai multe cereri fără a aștepta un răspuns la fiecare

Consideratii practice
Consideratii practice. Serverele au de obicei o anumită valoare de timeout după care nu vor accepta o conexiune inactivă. Serverele proxy îi pot seta valoarea mai mare

Cerințe de mesagerie
Cerințe pentru transmiterea mesajelor. Cerințe generale- Serverele HTTP 1.1 ar trebui să accepte conexiuni persistente și să utilizeze mecanisme de control al fluxului date TCP pentru a reduce temporar

Metode sigure
Metode sigure. Programatorii ar trebui să înțeleagă că software-ul reprezintă utilizatorul atunci când interacționează cu Internetul, iar programul ar trebui să informeze utilizatorul despre orice activitate.

Definirea codurilor de stare
Definiția status codes. Fiecare cod de stare descris mai jos include o descriere a metodei sau metodelor pe care le poate urma și metainformațiile necesare în răspuns. 10.1 1xx - Informare

Acces autentificare
Acces autentificare. Pentru a stabili autenticitatea Acces HTTP oferă un mecanism simplu provocare-răspuns care poate fi utilizat de

Schema de autentificare de bază
Schema de autentificare de bază. Schema de autentificare de bază se bazează pe faptul că agentul utilizator trebuie să-și dovedească identitatea folosind un identificator.

Memorarea în cache în HTTP
Memorarea în cache în HTTP. HTTP este utilizat de obicei pentru sistemele de informații distribuite, a căror eficiență poate fi îmbunătățită prin utilizarea răspunsurilor stocate în cache. Protocolul HTTP 1.1 include p

Corectitudinea memoriei cache
Corectitudinea memoriei cache. O memorie cache validă trebuie să răspundă la o interogare cu cel mai recent răspuns de potrivire a interogării stocat de cache, care îndeplinește una dintre următoarele condiții: 1. A fost transmis

Mecanisme de control al memoriei cache
Mecanisme de control al memoriei cache. Principalele mecanisme de cache din HTTP 1.1 sunt timpul de expirare specificat de server și directivele implicite ale validatorului

Avertismente explicite ale agentului utilizator
Avertismente explicite ale agentului utilizator. Mulți agenți de utilizator le permit utilizatorilor să suprascrie mecanismele de bază de stocare în cache. De exemplu, agentul utilizator poate permite

Excepții de la reguli și avertismente
Excepții de la reguli și avertismente. În unele cazuri, operatorul de cache îl poate configura să returneze răspunsuri expirate chiar dacă acestea nu sunt solicitate de client.

Comportament controlat de client
Comportament controlat de client. În timp ce serverul original și, într-o măsură mai mică, cache-urile intermediare, cu contribuția lor la vârsta de răspuns, sunt sursa principală de informații despre învechire.

Model de uzură
Model de uzură. Depreciere specificată de server. Memorarea în cache HTTP funcționează cel mai bine atunci când memoria cache poate evita complet solicitările către serverul original. Mecanismul primar și

Învechirea euristică
Învechirea euristică. Deoarece serverele de origine nu specifică întotdeauna un timp de expirare explicit, cache-urile HTTP atribuie de obicei timpi de expirare euristic folosind algoritmi care

Calculul vârstei
Calculul vârstei. Pentru a ști dacă un obiect conținut în cache este proaspăt, memoria cache trebuie să știe dacă vârsta lui depășește perioada de prospețime. Gazde care folosesc HTTP și în special gazde

Calculul uzurii
Calculul uzurii. Pentru a decide dacă un răspuns este proaspăt sau expirat, trebuie să comparăm durata de viață cu vârsta sa. Vârsta este calculată utilizând algoritmul descris în secțiunea 13.2.3

Etapele dezvoltării tradiției isihaste
Etapele dezvoltării tradiției isihaste. Tradiția isihastă din greacă. termen - pace, tăcere - o anumită școală de practică spirituală, în curs de dezvoltare din secolul al IV-lea. până azi. 7 În această lungă călătorie odată

URI (Identificator uniform de resurse) - identificator de resursă unificat (uniform). URI este un șir de caractere care vă permite să identificați orice resursă: document, imagine, fișier, serviciu, casetă 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 acelei 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 utilizat 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 nouă versiune a URI a fost definită în 1998 în RFC 2396, moment în care 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 adresele URL. 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 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 destinat să rezolve 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 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

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 dintr-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 resursa 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 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. 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ă se utilizează a acestui șablon analizați, de exemplu, acest 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;

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) lor, 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 motoare 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 nivel al treilea 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 pe World Wide Web sau tehnologiile web.

În primul rând, trebuie să înțelegeți conceptele de bază ale tehnologiilor web: site web și pagină 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 când este transmis către o imprimantă, ceea ce este fundamental contrar ideologiei adoptate de 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 populare procesor de cuvinte Cuvânt.

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 care 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 Extensible Markup Language (XML). 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șta electronică (e-mail, e-mail, din poșta electronică engleză) - tehnologie și serviciile pe care le oferă pentru trimiterea și primirea e-mailuri(numite „litere” 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, trebuie să utilizați un server sau un serviciu unde există un 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 antetele 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 cu mai mulți utilizatori.

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 corespondență - este componenta principală a sistemului de transmisie Poștă pe internet, care reprezintă acest computer de rețea pentru sistemul de e-mail din 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, de asemenea, oferă clientului posibilitatea de a căuta șiruri în mesaje e-mail pe serverul propriu-zis.

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ția 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 curentă pe serverul de e-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-l în propriul folder de pe desktop.

9.2. Lucrul cu un profesor:

Dacă întâmpinați dificultăți sau faceți greșeli, contactați profesorul 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.

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) (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 primește 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

cale 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 o anumită pagină într-un director specificat

http://example.com:81/script.php #conectați-vă la un 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 #conexiune 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.

Pe Wikipedia în limba rusă, vedeți în fiecare zi exemple de codificare URL, deoarece limba rusă folosește caractere chirilice. De exemplu, o linie ca:

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

codificat în 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 sunt supuse acestei transformări, cu excepția latină de bază, atunci o adresă URL cu cuvinte în marea majoritate a limbilor (cu excepția engleză, italiană, latină) 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 utilizate 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 arborele serverului 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 - protocol de transfer hipertext, protocol nivel inalt(ș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 - tipic protocol 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 în funcție de diferiți parametri: format, codificare, limbă etc. Este datorită capacității de a specifica metoda de codificare a unui mesaj. că clientul și serverul pot face schimb de date binare, deși acest protocol este 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 în cadrul tehnologiei La nivel mondial 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 pagină 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 document 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 așa-numitul „ pagina principala", 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 sunteți liber să plasați 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 aplicații interactive lansate de pe site-ul dvs., precum și câteva directoare de servicii necesare funcționării normale a serverului. În etapa inițială, pur și simplu nu ar trebui să le acordați atenție. Uneori, în același director în care este stocat index.html, există o serie de fișiere suplimentare: not_found.html - un document care este afișat dacă serverul http nu a putut găsi fișierul solicitat de utilizator, forbidden.html - afișat ca un mesaj de eroare, dacă accesul la documentul solicitat este interzis și, în final, robots.txt - un fișier care descrie în mod specific regulile de indexare a site-ului dvs. de către motoarele de căutare.

În cele mai multe cazuri, și mai ales la publicarea unei pagini de start pe serverele care furnizează hosting gratuit, accesul la directoarele de servicii și 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, către care puteți transfera fișierele necesare folosind un software special, încărcându-le automat în directorul alocat site-ului dumneavoastră. Î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 programelor de 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 acestora trebuie scrise cu litere mici și întotdeauna cu caractere latine, pentru a evita erorile. . 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 ale clientului și serverului 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 în 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 și codificarea datelor text. De exemplu: charset=windows-1251 charset=koi8-rus Content-Length - lungimea conținutului răspunsului în octeți (dimensiunea fișierului). Ultima modificare - data și ora ultima schimbare document.
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-Încă 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ă ID-ul resursei solicitat indică un document (de exemplu, un document text, imagine grafică, video), apoi serverul returnează conținutul acestui 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 menită să reducă încărcarea inutilă a rețelei, 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 următoarele funcții într-un mod general:

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 procesul de prelucrare;

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 nu returnează 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ă dintre metodele POST și PUT este valoarea diferită a ID-ului 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 clientului 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. A Reason-Phrase este un scurt descriere text codul 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 localizat versiuni rusești Serverele HTTP înlocuiesc aceste expresii cu unele 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 ale serverului
	Server intern Eroare	Internal Server Error
	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 ale unui server Web este de a oferi acces la o parte a sistemului de fișiere local. Pentru a face acest lucru, în setările serverului este specificat un anumit director, care este directorul rădăcină pentru acest server. Pentru a publica un document, adică pentru a-l pune la dispoziția utilizatorilor care au „vizitat” acest server (conectat la acesta prin 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 permisiunilor unui anumit utilizator, puteți controla accesul la resursele Web.

Să luăm în considerare cel mai simplu Exemplu HTTP- cerere. Dacă introducem adresa http://yandex.ru în fereastra de adrese a browserului, browserul va determina adresa IP a serverului yandex.ru și o va trimite la portul 80 Solicitare HTTP:

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 protocolului 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 solicitare 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.

cerere GET poate conține date trimise de la client la 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 asupra 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 trimitere a formularului cerere solicitată 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.

ÎN browser Opera există instrumente încorporate pentru dezvoltatorii Opera Dragonfly. Pentru a le lansa, faceți clic dreapta pe pagina dorită și selectați elementul de meniu contextual „Inspectați elementul”. Accesați fila Rețea din Instrumentele pentru dezvoltatori și trimiteți solicitarea. 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 mesajele trimise cerere postîn fiecare detaliu. 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.