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, ținând cont de experiența de adresare și identificare a e-mailului, Gopher, WAIS, telnet, ftp etc. - URL, Uniform Resource Locator.
URI(Uniform Resource Identifier) (RFC 2396, august 1998) este un șir de caractere compact utilizat pentru a identifica o resursă abstractă sau fizică. O resursă este înțeleasă ca orice obiect care aparține unui anumit spațiu. Include și suprascrie adrese URL definite anterior (RFC 1738 / RFC 1808) și URN-uri (RFC 2141, RFC 2611).
URI-ul este conceput pentru a identifica în mod unic orice resursă.
Unele subseturi de URI-uri:
URNĂ(Nume uniform al resursei) - Un URI privat „urn:” cu un subset al „spațiului de nume” care trebuie să fie unic și imuabil chiar și atunci când resursa nu mai există sau nu este disponibilă.
Se presupune că, de exemplu, browserul știe unde să caute această resursă.
Sintaxă:
urn: namespace: data1.data2, more-data, unde namespace definește modul în care sunt utilizate datele după al doilea „:”.
Exemplu de URN:
urnă: ISBN: 0-395-36341-6
ISBN - clasificator tematic pentru edituri
0-395-36341-6 - un număr specific al subiectului unei cărți sau reviste
La primirea URN-ului, programul client apelează la ISBN (directorul „Topical Classifier for Publishers” de pe Internet). Și primește o decriptare 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).
Exemplu de URN care indică o imagine de disc Adobe Photoshop v8.0 pe rețeaua edonkey:
urnă: ed2k: // | fișier | AdobePhotoshopv8.0.iso | 940769280 | | /
ed2k - indică rețeaua
Adobe Photoshop v8.0.iso - numele fișierului
940769280 - dimensiunea în octeți
- identificatorul fișierului (calculat folosind o funcție hash)
Localizator uniform de resurse URL:
Url(Uniform Resource Locator, RFC 1738) este un localizator de resurse unificat (locator), o modalitate standardizată de înregistrare a adresei unei resurse pe WWW și pe Internet. URL-ul are o structură flexibilă și extensibilă pentru a indica locația resurselor în rețea cât mai natural posibil, care identifică o resursă după modul în care este accesată (de exemplu, „locația sa în rețea”) în loc să o identifice după nume sau alte atribute ale resursa respectivă.
Exemple de adrese URL:
http://www.ipm.kstu.ru/index.php
ftp://www.ipm.kstu.ru/
Un set limitat de caractere ASCII este folosit pentru a reprezenta adresa.
Forma generală adresele pot fi reprezentate 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 a acesteia.
Port- portul gazdă pentru conexiune
calea completă către resursă - clarificarea informațiilor despre locația resursei (depinde de protocol).
Exemple de adrese URL:
http://example.com # cerere pentru pagina de pornire implicită
http://www.example.com/site/map.html # solicitați o anumită pagină într-un anumit director
http://example.com:81/script.php # conectați-vă la un port non-standard
http://example.org/script.php?key=value # cerere cu transmiterea parametrilor către script
ftp: // utilizator: [email protected]# conectați-vă la serverul ftp cu autorizare
http://192.168.0.1/example/www # conectați-vă la adresa de rețea
fișier: ///srv/www/htdocs/index.html # deschide fișierul local
gopher: //example.com/1 # conectați-vă la serverul gopher
URL - Localizatorii uniformi de resurse descriu în mod explicit cum să ajungeți la un obiect.
Apariția URL-urilor este 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 puțin decât în ASCII: scrisori, numere și doar câteva semne de punctuație-.
Dacă vrem să folosim caractere chirilice sau hieroglife sau, să zicem, caractere specifice ale limbii franceze în URL, atunci caracterele de care avem nevoie trebuie să fie recodate într-un mod special.
Pe Wikipedia în limba rusă, trebuie să vedeți în fiecare zi exemple de codificare URL, deoarece limba rusă folosește caractere chirilice. De exemplu, o linie ca aceasta:
http://ru.wikipedia.org/wiki/Microcredit
URL codificat 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, iar 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
k → D0 și BA →% D0% BA
p → D1 și 80 →% D1% 80 etc.
Fiecare astfel de cod de octet hexazecimal este precedat de un semn de procente (%) conform specificației URL - de unde termenul englezesc „percent-encoding”, care denotă modul în care sunt codificate caracterele în URL-uri și URI.
Deoarece literele tuturor alfabetelor, cu excepția alfabetului latin de bază, suferă o astfel de transformare, adresa URL cu cuvinte în marea majoritate a limbilor (cu excepția engleză, italiană, latină) poate deveni imposibil de citit pentru o persoană.
Toate acestea sunt în conflict cu principiul internaționalismului, proclamat de toate organizațiile de conducere de pe Internet, inclusiv W3C și ISOC. Această problemă este destinată să fie rezolvată prin standardul IRI (International Resource Identifier) – identificatori internaționali de resurse în care ar fi posibilă utilizarea fără probleme a caracterelor Unicode și care, prin urmare, nu ar încălca drepturile altor limbi.
Alte scheme de adrese URL
Schema HTTP.
Schema specifică identificatorul său, adresa mașinii, portul TCP, calea în directorul serverului, variabilele și valorile acestora, 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. În mod implicit, port = 80.
Exemple:
http://ipm.kstu.ru/internet/index.php
Acesta este cel mai frecvent tip de URI utilizat în documentele WWW. Numele schemei (http) este urmat de o cale constând din adresa de domeniu a mașinii și adresa completă a documentului HTML din arborele serverului HTTP.
Adresa IP poate fi folosită și ca adresă a mașinii:
http://195.208.44.20/internet/index.php
Dacă serverul HTTP rulează pe un alt port TCP decât 80, 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 nume de variabile, iar „valoare1” și „valoare2” sunt valorile acestora.
Schema FTP
Această schemă vă permite să abordaț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.
Exemple: ftp://ipm.kstu.ru/students/name/
Pentru a specifica un nume de utilizator și o parolă, trebuie să le scrieți astfel:
ftp: // nume: [email protected]: //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 destinată trimiterii de corespondență.
Sintaxă:
mailto: [
mailto - numele schemei
e-mail-1 (
utilizator - nume de utilizator
gazdă - nume de gazdă
e-mail-2 - a doua adresă de e-mail
interogare (<имя-поля-заголовка>=<значение>{&<имя-поля-заголовка>=<значение>) - șir de interogare
mailto: [email protected]
În această schemă, câmpurile și valorile lor sunt transmise:
mailto: [email protected] subiect = Subject_Email & body = Text_which_will_be_inserted_in_the_mail
Adresa destinatarului poate fi scrisă și ca valoare a câmpului către:
mailto: [email protected] subiect = Subject_Email & body = Text_which_will_be_inserted_in_the_mail
Ce este HTTP?
Primul document (dar nu standardul) este RFC1945 (Hypertext Transfer Protocol - HTTP / 1.0 T. Berners-Lee, R. Fielding, H. Frystyk mai 1996)
Cea mai recentă versiune este 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, stratul de aplicație). Folosit de serviciul WWW pentru a transfera pagini Web.
HTTP (HyperText Transfer Protocol, RFC 2616, versiunea actuală este HTTP / 1.1) este un protocol de transfer hipertext. Acest protocol a fost inițial destinat schimbului de documente hipertext, acum capabilitățile sale au fost extinse semnificativ (în special, a fost adăugat 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 modul de reprezentare a aceleiași resurse în diferiți parametri: format, codificare, limbă etc. Datorită capacității de a specifica metoda de codificare a mesajului, clientul și serverul pot face schimb de date binare, deși acest protocol este text.
HTTP este un protocol de nivel de aplicație, dar este folosit și ca „transport” pentru alte protocoale de aplicație precum SOAP, XML-RPC, WebDAV.
Protocolul HTTP definește o modalitate de interacțiune cerere-răspuns între un program client și un program server în cadrul tehnologiei World Rețeaua largă.
Pentru a încărca o pagină web într-un browser client, acesta trimite o solicitare către un program special instalat pe computerul server, numit server http și procesează datele primite de la acesta. În acest caz, funcția browser este de a cere serverului o anumită pagină, obțineți-l și afișați-l pe ecranul utilizatorului. Serverul, pe de altă parte, 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 a fost refuzat 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 este în interiorul fișierului solicitat, doar îl transferă în browser, iar toată munca de structurare și afișare a informațiilor primite este deja preluată
Căutarea paginii solicitate se efectuează într-un director specific, care este alocat pe computerul server pentru acest site - un link către acest director este prezent în adresa introdusă de utilizator. În cazul în care se face referire nu la un anumit document, ci la site-ul în ansamblu, serverul http înlocuiește automat așa-numitul „ Pagină de start", 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ă desemnat pentru găzduirea site-ului dvs. sau, dacă este specificat altfel, î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 pentru munca normala Server. Î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 poate găsi fișierul solicitat de utilizator, forbidden.html - este afișat ca un mesaj de eroare, dacă accesul la documentul solicitat este refuzat și, în sfârșit, robots.txt este 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 când publică o pagină de pornire pe servere care oferă găzduire gratuită, utilizatorilor li se interzice accesul la directoarele de servicii și la folderul CGI-BIN; modificarea conținutului fișierelor not_found și forbidden.html este, de asemenea, imposibilă. Acest lucru ar trebui să fie 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 pune fișiere într-una dintre folderele de servicii... În unele cazuri, vi se poate interzice crearea de directoare imbricate pe server, atunci utilizatorul va trebui să se mulțumească cu un singur director alocat nevoilor dumneavoastră.
Din tot 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 doar dacă încărcarea fișierelor pe server este implementată pe baza protocolului HTTP folosind scripturi CGI speciale incluse. în interfața web a serverului. Î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 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 programelor de server (în special, Apache pentru platformele compatibile cu UNIX) fac diferența între litere mici și majuscule, astfel încât toate numele fișierelor și extensiile lor trebuie scrise cu litere mici și întotdeauna în latină, pentru a evita erorile. Acesta din urmă se datorează diferențelor de procesare a codificărilor în limba rusă, tipice pentru anumite servere.
Lucrarea peste protocolul HTTP este după cum urmează: programul client stabilește o conexiune TCP cu serverul (numărul standard de port este 80) și îi emite o solicitare HTTP. Serverul procesează această solicitare și emite un răspuns HTTP către client.
Comunicarea dintre client și serverul Web se realizează prin schimbul de mesaje. Mesajele HTTP sunt împărțite în solicitări de la client la server și răspunsuri de la server la client.
Mesajele de solicitare și răspuns au un format comun. Ambele tipuri de mesaje arată astfel: mai întâi vine linia de început, apoi eventual unul sau mai multe câmpuri de antet, numite și simplu antete, apoi linie goală(adică un șir format din caracterele CR și LF) care indică sfârșitul câmpurilor de antet ș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
Formatul liniei inițiale a clientului și a serverului este diferit și va fi discutat mai jos. Există patru tipuri de titluri:
Anteturi generale (general-headers), care pot fi prezente atât în cerere, cât și în răspuns;
Anteturi de solicitare, care pot fi prezente doar într-o cerere;
Antete de răspuns, care pot fi prezente doar într-un răspuns;
Anteturile de entitate care se referă la corpul unui mesaj și descriu conținutul acestuia.
Fiecare titlu constă dintr-un titlu, două puncte „:” și o valoare. Cele mai importante titluri sunt prezentate în Tabelul 1.
tabelul 1
Antetele protocolului HTTP
| Titlu | Programare |
| Anteturile obiectelor | |
| Permite | Enumeră 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 tipul de conținut, browserul interpretează răspunsul ca o pagină HTML, 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 / simplu - text simplu (similar cu „Notepad”); imagine / jpeg - imagine în format JPEG; imagine / gif - la fel, în format GIF; De asemenea, poate trece codificarea datelor text. De exemplu: set de caractere = windows-1251 set de caractere = koi8-rus Lungimea conținutului - lungimea conținutului răspunsului în octeți (dimensiunea fișierului). Ultima modificare - data și ora la care documentul a fost modificat ultima dată. |
| ETag | O etichetă unică de resurse pe server care vă permite să comparați resurse |
| Expiră | Data și ora la care va fi modificată resursa de pe server și trebuie să fie preluată din nou |
| Modificat ultima dată | Data și ora ultimei modificări a conținutului |
| Antete de răspuns | |
| Vârstă | Numărul de secunde după care să reîncercați solicitarea pentru a obține conținut nou |
| Locație | URI-ul resursei de consultat pentru a obține conținutul |
| Reîncercați-După | Data și ora sau numărul de secunde după care solicitarea trebuie repetată pentru a primi un răspuns cu succes |
| Server | Numele software-ului server care a răspuns |
| Antete de solicitare | |
| Accept | O listă de tipuri de conținut acceptate de browser în ordinea preferințelor pentru acest browser, de exemplu: Accept: imagine / gif, imagine / x-xbitmap, imagine / jpeg, imagine / pjpeg, application / vnd.ms-excel, application / msword , application / vnd. ms-powerpoint, * / * Acest lucru este evident necesar pentru cazul în care serverul poate servi 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 se solicită 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 „numele de cod” al browserului, de exemplu: Mozilla / 4.0 (compatibil; MSIE 5.0; Windows 95; DigExt) |
| Anteturi generale | |
| Conexiune | Conexiune - poate fi Keep-Alive și aproape. Keep-Alive înseamnă că după emitere a 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 într-o singură conexiune la server. Odată setat, modul Keep-Alive este menținut până la prima eroare sau până când este indicat în mod explicit în următoarea solicitare Connection: close. close - conexiunea este închisă după ce răspunde la această solicitare. |
| Data | Data și ora formării mesajului |
| Pragma | Comenzi specifice implementării pentru conținutul transferat |
| Transfer-Codare | Metoda de codificare a mesajelor pentru transmitere |
În unele anteturi, valoarea este data și ora. Acestea trebuie să fie î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 codificarea specificată în antetul obiectului Content-Encoding.
Un mesaj de solicitare de la client la server constă dintr-o linie de solicitare, anteturi (general, cerere, obiect) și, eventual, un corp de mesaj.
Linia de solicitare începe cu o metodă, 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 spune că clientul dorește să obțină conținutul resursei. 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 acceptă pentru resursa solicitată. Această metodă permite clientului să definească opțiuni și/sau cerințe asociate cu resursa, sau capabilitățile serverului, fără a întreprinde nicio acțiune asupra resursei sau a iniția o descărcare.
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 resursei solicitate este un asterisc ("*"), atunci cererea OPȚIUNI este destinată să se adreseze serverului în întregime.
Dacă identificatorul resursei solicitate nu este un asterisc, atunci solicitarea OPȚIUNI se aplică opțiunilor disponibile la conectarea la resursa specificată.
Metoda GET vă permite să obțineți orice informație legată de resursa solicitată. În majoritatea cazurilor, dacă identificatorul resursei solicitate indică un document (de exemplu, document text, imagine grafică, video), atunci 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, și nu 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). V acest din urmă caz numele folderului poate fi specificat fie cu simbolul „/” la sfârșit, fie fără acesta. Dacă acest simbol este absent la sfârșitul identificatorului, serverul emite unul dintre răspunsuri cu redirecționare (cu codurile de stare 301 sau 302).
Distingeți î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 condiționată GET solicită transferul unui obiect numai dacă îndeplinește condițiile descrise în anteturile date. Metoda GET condiționată este concepută să scadă descărcare inutilă rețea, deoarece vă permite să nu descărcați pentru a doua oară datele deja salvate de client.
Se face, de asemenea, o distincție între „GET parțial”, în care mesajul de solicitare include un antet de cerere Range. Un GET parțial solicită transferul doar a unei părți a obiectului. Metoda GET parțială este concepută pentru a reduce încărcarea inutilă a rețelei, solicitând doar o parte a obiectului când cealaltă parte a fost deja descărcată de client. Valoarea antetului Range este intervalul de octeți de primiț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 HTTP ale răspunsului la o solicitare HEAD sunt identice cu informațiile furnizate în răspunsul la o solicitare GET. Această metodă poate fi folosită pentru a obține informații despre obiectul de solicitare fără a redirecționa direct corpul obiectului. Metoda HEAD este adesea folosită pentru a testa legăturile hipertext.
Pentru o cerere se folosește metoda POST, în care serverul adresat primește datele incluse în corpul mesajului (obiectul) cererii ș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:
Adnotarea resurselor existente;
Postarea unui mesaj pe un buletin electronic (BBS), grupuri de știri, liste de corespondență sau un grup similar de articole;
Trecerea unui bloc de date, cum ar fi rezultatul unei intrări într-un formular, unui 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 indicată de ID-ul resursei solicitate. Alături de metoda GET, metoda POST este utilizată la construirea aplicațiilor CGI. Browserul poate forma cereri cu metoda POST la trimiterea formularelor. Pentru aceasta, elementul FORM document HTML care conține formularul trebuie să aibă un atribut METHOD cu o valoare POST.
O acțiune POST poate efectua o acțiune pe server și nu transmite niciun conținut ca rezultat. Î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 a fost creată pe server, răspunsul conține un cod de stare 201 (Creat) și include antetul de răspuns Locație.
Corpul mesajului, care este transmis într-o cerere cu metoda PUT, este salvat pe server, iar identificatorul resursei solicitate va fi identificatorul documentului salvat. Dacă identificatorul resursei solicitate indică o resursă deja existentă, atunci obiectul inclus în corpul mesajului este tratat ca o versiune modificată a resursei aflate pe server. Dacă este creată o nouă resursă, atunci serverul informează agentul utilizator despre aceasta cu un răspuns cu un cod de stare 201 (Creat).
Diferența fundamentală dintre metodele POST și PUT este sens diferit identificatorul resursei solicitate. URI-ul din cererea POST identifică resursa care se ocupă de obiectul inclus în corpul mesajului. Această resursă poate fi o aplicație care primește date. În schimb, URI-ul în cerere PUT identifică obiectul inclus în cerere ca corp de mesaj, adică agentul utilizator atribuie URI-ul dat resursei incluse.
Metoda DELETE cere serverului să șteargă o resursă care are identificatorul solicitat. O solicitare cu această metodă poate fi respinsă de server dacă utilizatorul nu are permisiunea de a șterge resursa solicitată.
Metoda TRACE este utilizată pentru a returna cererea trimisă la nivel de protocol HTTP. Receptorul cererii (server web) trimite mesajul primit înapoi către client ca corpul unui obiect de răspuns cu un cod de stare 200 (OK). O solicitare 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ă folosească acele date pentru testare sau diagnosticare.
Dacă solicitarea are succes, atunci 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. Acesta constă dintr-o versiune a 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) al rezultatului înțelegerii și satisfacerii cererii. Reason-Phrase este o scurtă descriere textuală a codului de stare. Codul de stare este pentru procesarea software-ului, iar fraza explicativă este pentru utilizatori.
Prima cifră a codului de stare identifică clasa răspunsului. Ultimele două cifre nu au un rol specific în clasificare. Există 5 valori 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 - Solicitarea are o eroare de sintaxă sau nu a putut fi finalizată.
5xx: coduri de eroare server - serverul nu poate îndeplini o solicitare validă.
Expresiile de motiv pentru fiecare cod de stare sunt listate în RFC 2068 și sunt recomandate, dar pot fi înlocuite cu 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 listează codurile de răspuns ale serverului HTTP.
masa 2
Codurile de răspuns ale serverului HTTP
| Codul | Expresie explicativă conform RFC 2068 | Expresie explicativă echivalentă în rusă |
| 1xx: coduri de informații | ||
| Continua | Continua | |
| 2xx: coduri de succes | ||
| O.K | O.K | |
| Creată | Creat de | |
| 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 coruptă | |
| Neautorizat | Neautorizat | |
| Nu a fost gasit | Nu a fost gasit | |
| metoda nepermisa | Metoda nu este permisă | |
| 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 | Eroare internă Server | |
| Neimplementat | Neimplementat | |
| Serviciu Indisponibil | Serviciul nu este disponibil | |
| Versiunea HTTP nu este acceptată | Versiune HTTP neacceptată |
Bara de stare este urmată de anteturi (general, răspuns și obiect) și eventual corpul mesajului.
Unul dintre funcții esențiale un server web trebuie să ofere 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 rădăcina pentru acest server. A publica un document, adică a-l realiza disponibile utilizatorilor care a „vizitat” acest server (după ce a făcut o conexiune cu acesta prin protocolul HTTP), trebuie să copiați acest document în directorul rădăcină al serverului web sau într-unul dintre subdirectoarele acestuia. La conectarea prin protocolul HTTP, pe server este creat un proces cu drepturi de utilizator, care, de regulă, nu există în realitate, ci este creat special pentru a vizualiza resursele serverului. Prin configurarea drepturilor și a permisiunilor acestui utilizator, puteți controla accesul la resursele Web.
Să ne uităm la cel mai simplu exemplu de solicitare HTTP. Dacă în fereastra de adrese a browserului introducem adresa http://yandex.ru, atunci 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, aplicație / vnd.ms-excel, aplicație / msword, aplicație / vnd.ms-powerpoint, * / *
Accept-Limba: ru
Cookie: yandexuid = 2464977781018373381
User-Agent: Mozilla / 4.0 (compatibil; MSIE 5.5; Windows 98)
Gazdă: yandex.ru
Referer: narod.ru
Conexiune proxy: Keep-Alive
Solicitarea este trimisă necriptată forma text... Cea mai importantă parte a cererii se află în prima linie: acesta este tipul cererii (GET), adresa URL a documentului solicitat (http://yandex.ru) și versiunea protocolului HTTP (HTTP / 1.0). ). Următorii sunt parametrii de solicitare. Fiecare linie corespunde unui parametru. Linia începe cu numele parametrului, urmat de două puncte și valoarea parametrului.
Accept este tipul de date pe care browserul le poate accepta (codat MIME).
Accept-Language este limba preferată în care browserul dorește să accepte date. User-Agent - tipul 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 discul local al clientului când a vizitat ultima dată această gazdă).
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 gazdei narod.ru.
Setul de parametri de interogare nu este fix. Pe lângă cei de mai sus, pot exista și alți parametri.
Cei mai interesanți parametri sunt referer și cookie. Acești parametri sunt utilizați în principal pentru autentificarea utilizatorului pe server.
cerere GET poate conține date transmise de client către server. Acestea sunt transmise direct prin URL folosind protocolul CGI. Datele sunt separate de adresa URL printr-un „?” și sunt conectate cu semnul „&”:
OBȚINE
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 adresa URL. În astfel de scopuri, există un alt tip de solicitare: o cerere POST. O solicitare POST este foarte asemănătoare cu o solicitare GET, cu singura diferență că datele din cererea POST sunt transmise separat de antetul cererii în sine:
Corpul cererii trebuie separat de antet printr-o linie goală. Dacă serverul întâlnește un șir gol într-o solicitare POST, atunci tot ceea ce urmează are în vedere corpul cererii (date transmise). Rețineți următoarele: formatul datelor din corpul solicitării POST este arbitrar. Deși formatul CGI este cel mai frecvent utilizat, nu este necesar. În plus, o solicitare POST nu necesită un corp de solicitare și poate, de asemenea, transfera date printr-o adresă URL.
Pe lângă formatul CGI, uneori așa-numitul. format multipart (formatul datelor transmise este determinat de parametrul Content-Type):
Browsere moderne conțin instrumente pentru dezvoltatorii web pentru a obține câteva informații despre solicitările de postare trimise. Dacă trebuie să vă uitați la antetele doar pentru câteva 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ă anteturile solicitărilor și conținutul cookie-urilor transmise. Pentru a-l lansa, deschideți meniul browserului, faceți clic pe elementul „Web Development” și selectați „Web Console”. În panoul care apare, activați butonul „Rețea”. Introduceți numele metodei - postați î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. Consola afișează cererea trimisă. Faceți clic pe el cu mouse-ul pentru a vedea mai multe detalii.
Browser Google Chrome are instrumente puternice de depanare. Pentru a le utiliza, faceți clic pe pictograma cu imaginea unei chei, apoi deschideți elementul „Configuraț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 necesară î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 necesară și selectați elementul de meniu contextual „Inspectați element”. Accesați fila Rețea Instrumente 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ă informații detaliate despre solicitările executate. Acestea sunt pornite 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 interogarea dată în rezumat și faceți dublu clic pentru a extinde detaliile.
Browsere Chromeși Internet Explorer 9 conțin instrumente încorporate care vă permit să examinați o solicitare de post trimisă în detaliu. Pentru detalii complete, folosește-le sau Firefox cu plugin instalat Firebug. Este foarte util pentru examinarea frecventă a interogărilor, de exemplu, la depanarea site-urilor.
Dacă doriți să vedeți o solicitare trimisă de un alt program decât un browser, utilizați depanatorul HTTP Fiddler. Funcționează ca un server proxy și interceptează cererile de la orice program și oferă, de asemenea, informații foarte detaliate despre anteturile și conținutul acestora.
Un URI (Uniform Resource Identifier) este un șir compact de caractere folosit pentru a identifica o resursă abstractă sau fizică. O resursă este înțeleasă ca orice obiect care aparține unui anumit spațiu. Necesitatea unui URI a fost înțeleasă de dezvoltatorii WWW încă de la începutul sistemului, de atunci trebuia să se combine într-un singur mediu informaţional înseamnă folosirea diferitelor metode de identificare a resurselor informaţionale. A fost dezvoltată o specificație care includea apeluri către FTP, Gopher, WAIS, Usenet, E-mail, Prospero, Telnet, X.500 și, desigur, HTTP (WWW). Ca urmare, a fost elaborată o specificație universală care permite extinderea listei de resurse adresabile datorită apariției de noi scheme.
Unde sunt folosite URI-urile sunt link-uri hipertext care sunt scrise în etichete și ... Graficele încorporate sunt, de asemenea, adresate prin specificația URI în etichete și
Apariția URN-urilor provine din dorința de a aborda porțiuni MIME ale unui mesaj de e-mail. Principii de construire a unei adrese WWW. URI s-a bazat pe următoarele principii:
· Extensibilitate - Noile scheme de adresare ar trebui să se potrivească cu ușurință în sintaxa URI existentă.
· Completitudine - ori de câte ori este posibil, oricare dintre schemele existente ar trebui descrisă folosind un URI.
· Lizibilitate - adresa trebuia să fie ușor de citit de către utilizator, ceea ce este în general tipic pentru tehnologia WWW - documentele, împreună cu linkurile, pot fi dezvoltate într-un editor de text obișnuit.
Înainte de a analiza diferitele scheme de reprezentare a adresei, iată un exemplu de URI simplu:
http://polyn.net.kiae.su/polyn/index.html
Colonele sunt precedate de identificatorul schemei de adrese - „http”. Acest nume este separat prin două puncte de restul URI-ului, care se numește cale. În acest caz, calea constă din adresa de domeniu a mașinii pe care este instalat serverul HTTP și calea de la rădăcina arborelui server la fișierul „index.html”. Pe lângă notația URI completă prezentată mai sus, există una simplificată. Se presupune că, în momentul în care este utilizată, au fost deja definiți mulți parametri ai adresei resursei (protocol, adresa mașinii în rețea, unele elemente de cale). În astfel de ipoteze, autorul paginilor hipertext poate indica doar adresa relativă a resursei, adică. o adresă relativă la anumite resurse subiacente.
Un URL (Uniform Resource Locator) este un subset de scheme URI care identifică o resursă după modul în care este accesată (de exemplu, „locația sa pe web”), mai degrabă decât să o identifice după numele sau alte atribute ale acelei resurse. URL-ul descrie în mod explicit cum să ajungeți la obiect.
Sintaxă:
schema = "http" | „Ftp” | „Gopher” | „Mailto” | „Știri” | „Telnet” | „Fișier” | „Bărbat” | „Informații” | „Ce este” | „Ldap” | „Wais” | ...- numele schemei
schema – specific – parte- depinde de schema. Valorile hexazecimale pot fi utilizate în partea specifică schemei sub forma:% 5f. Octeții neprintabili trebuie să fie codificați: 00-1F, 7F, 80-FF.
Exemple de adrese URL:
Http://www.ipm.kstu.ru/index.php
Ftp://www.ipm.kstu.ru/
URN (Uniform Resource Name) este un URI privat „urn:” cu un subset al „namespace” care trebuie să fie unic și imuabil chiar și atunci când resursa nu mai există sau este inaccesibilă.
Se presupune că, de exemplu, browserul știe unde să caute această resursă.
Sintaxă: urn: namespace: data1.data2, mai mult – date unde spațiul de nume definește modul în care sunt utilizate datele după al doilea „:”.
Exemplu de URN:
urnă: ISBN: 0–395–36341–6
ISBN - clasificator tematic pentru editori,
0–395–36341–6 - un număr specific al subiectului unei cărți sau reviste
La primirea URN-ului, programul client apelează la ISBN (directorul „Topical Classifier for Publishers” de pe Internet). Și primește o decriptare a numărului subiectului „0-395-36341-6” (de exemplu: „chimie cuantică”). URN este relativ nou, HTML nu este inclus în versiunile curente și serviciile de directoare nu sunt încă dezvoltate, așa că URN nu este la fel de răspândit ca URL.
Scheme de adresare a resurselor de internet
Există 3 scheme pentru adresarea resurselor de pe Internet. Schema specifică identificatorul său, adresa mașinii, portul TCP, calea în directorul serverului, variabilele și valorile acestora, eticheta.
Schema HTTP... Acesta este aspectul de bază pentru WWW. Schema conține identificatorul său, adresa mașinii, portul TCP, calea în directorul serverului, criteriul de căutare și eticheta.
Sintaxă: http: // [
http- numele circuitului
utilizator- Nume de utilizator
parola- Parolă de utilizator
gazdă- numele gazdei
port- numarul portului
url – cale- calea către fișier și fișierul în sine
interogare (<имя–поля>=<значение>{&<имя–поля>=<значение>) - șir de interogare
În mod implicit, port = 80.
Iată câteva exemple de URI-uri pentru schema HTTP:
http://polyn.net.kiae.su/polyn/manifest.html
Acesta este cel mai frecvent tip de URI utilizat în documentele WWW. Numele schemei (http) este urmat de o cale constând din adresa de domeniu a mașinii și adresa completă a documentului HTML din arborele serverului HTTP.
Adresa IP poate fi folosită și ca adresă a mașinii:
http://144.206.160.40/risk/risk.html
Dacă serverul HTTP rulează pe un alt port TCP decât 80, acest lucru se reflectă în adresa:
http://144.206.130.137:8080/altai/index.html
http://polyn.net.kiae.su/altai/volume4 .html # primul
Schema FTP... Această schemă permite ca arhivele de fișiere FTP să fie adresate din programele client World Wide Web. În acest caz, programul trebuie să accepte protocolul FTP. În această schemă, este posibil să specificați nu numai numele schemei, adresa arhivei FTP, ci și ID-ul utilizatorului și chiar parola acestuia.
Sintaxă: ftp: // [
ftp- numele circuitului
utilizator- Nume de utilizator
parola- Parolă de utilizator
gazdă- numele gazdei
port- numarul portului
url – cale- calea către fișier și fișierul în sine
Implicit, port = 21, utilizator = anonim, parola = adresa de e-mail.
Această schemă este folosită cel mai adesea pentru a accesa arhivele FTP publice:
ftp://polyn.net.kiae.su/pub/0index.txt
În acest caz, se înregistrează un link către arhiva „polyn.net.kiae.su” cu identificatorul „anonim” sau „ftp” (acces anonim). Dacă este necesar să specificați ID-ul utilizatorului și parola acestuia, atunci puteți face acest lucru în fața adresei mașinii:
ftp: // nimeni: [email protected]/ utilizatori / local / pub
În acest caz, acești parametri sunt separați de adresa mașinii prin simbolul @ și unul de celălalt prin două puncte.
schema TELNET... Această schemă este utilizată pentru a accesa resursa în modul terminal la distanță. De obicei, clientul invocă un program suplimentar la telnet. Când utilizați această schemă, trebuie să specificați un ID de utilizator, o parolă este permisă.
Sintaxă: telnet: // [
telnet- numele circuitului
utilizator- Nume de utilizator
parola- Parolă de utilizator
gazdă- numele gazdei
port- numarul portului
În mod implicit, port = 23.
Exemplu: telnet: // nume: [email protected]
În realitate, accesul se realizează la resurse publice, iar identificatorul și parola sunt în general cunoscute, de exemplu, pot fi găsite în bazele de date Hytelnet.
telnet: // invitat: [email protected]
După cum puteți vedea din exemplele de mai sus, specificația adresei de resursă URI este destul de generală și vă permite să identificați practic orice resursă de pe Internet. În acest caz, numărul de resurse poate fi extins prin crearea de noi scheme.
Serviciu WWW
Serviciul WWW (World Wide Web) - conceput pentru schimbul de informații hipertext, construit după schema „client-server”. Browserul (Internet Explorer, Opera ...) este un client multi-protocol și interpret HTML. Și ca interpret tipic, clientul îndeplinește diferite funcții în funcție de comenzi (etichete). Gama acestor funcții include nu numai plasarea textului pe ecran, ci și schimbul de informații cu serverul pe măsură ce textul HTML primit este analizat, ceea ce apare cel mai clar la afișarea imaginilor grafice încorporate în text.
Serverul HTTP (Apache, IIS...) se ocupă de solicitările clientului de a obține fișierul. La început, serviciul WWW se baza pe trei standarde:
· HTML (HyperText Markup Lan – guage) - limbaj de marcare hipertext a documentelor;
· URL (Universal Resource Locator) - o modalitate universală de a aborda resursele din rețea;
· HTTP (HyperText Transfer Protocol) - un protocol pentru schimbul de informații hipertext.
Schema de operare a serverului WWW
Un server WWW este o parte a unui intranet global sau care permite utilizatorilor rețelei să acceseze documentele hipertext aflate pe acest server. Pentru a interacționa cu serverul WWW, un utilizator de rețea trebuie să folosească un software specializat - un browser (din browserul englezesc) - un vizualizator.
Să aruncăm o privire mai atentă asupra schemei de operare a serverului WWW:
1. Utilizatorul rețelei lansează un browser, ale cărui funcții includ:
· Stabilirea conexiunii cu serverul;
· Obținerea documentului solicitat;
· Afisarea documentului primit;
· Răspuns la acțiunile utilizatorului - acces la un document nou. După pornirea browserului, la comanda utilizatorului, sau automat stabilește o conexiune cu serverul WWW specificat și îi trimite o solicitare pentru a primi documentul specificat.
2. Serverul WWW caută documentul solicitat și returnează rezultatele în browser.
3. Browserul, după ce a primit documentul, îl afișează utilizatorului și așteaptă reacția acestuia. Opțiuni posibile:
· Introducerea adresei unui nou document;
· Imprimare, căutare, alte operațiuni asupra documentului curent;
· Activarea (apăsarea) unor zone speciale ale documentului primit, numite link-uri și asociate cu adresa noului document. În primul și al treilea caz, există o contestație pentru un nou document.
URI (Identificator uniform de resurse) este un identificator de resursă unificat (uniform). URI este un șir de caractere care vă permite să identificați orice resursă: 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-ului . Un URI oferă o modalitate simplă și extensibilă de a identifica resursele. Extensibilitatea URI înseamnă că mai multe scheme de identificare există deja într-un URI și mai multe vor fi create în viitor.
Relația dintre URI, URL și URN
Diagrama Venn care arată subseturile schemei URI: URL și URN.
URI-ul este fie un URL, 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 (respectiv, într-un context specific), dar nu indică locația acesteia. De exemplu, urna URN: ISBN: 0-395-36341-1 este un URI care indică o resursă (carte) 0-395-36341-1 în spațiul de nume ISBN, dar spre deosebire de o adresă URL, URN-ul nu indică locația respectivei resurse: nu spune în ce magazin o puteți cumpăra sau pe ce site web să o descărcați.
Deoarece URI-ul 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, la Geneva, Elveția, între zidurile Consiliului European pentru Cercetare Nucleară, omul de știință britanic Tim Berners-Lee a inventat URL-ul de localizare a locației resurselor. Deoarece URL-ul este cel mai frecvent utilizat subset de URI, 1990 este considerat a fi anul nașterii URI-urilor. Dar, strict vorbind, conceptul de URI a fost documentat abia în iunie 1994 în RFC 1630.
Noua versiune a URI a fost definită în 1998 în RFC 2396, în același timp cuvântul universalîn titlu a fost schimbat în Uniformă.
Defecte
URL-ul a fost o inovație fundamentală pe Internet, așa că principiile URI au fost documentate pentru a asigura compatibilitatea deplină a URL-ului. De aici provine marele dezavantaj al URI-urilor, moștenirea de la URL-uri. Într-un URI, ca și într-un URL, poate fi folosit doar un set limitat de caractere latine și semne de punctuație (chiar mai puțin decât în ASCII). Cu alte cuvinte, dacă dorim să folosim caractere chirilice, sau hieroglife, sau, să zicem, caractere franceze specifice, în URI, 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 aceasta:
https://ru.wikipedia.org/wiki/Cyrillic
URL codificat 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 alfabetului latin folosit în engleză, suferă o astfel de transformare, 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 gravă cu principiul internaționalismului, proclamat de toate organizațiile de conducere ale Internetului, inclusiv W3C și ISOC. Această problemă este destinată a fi rezolvată prin standardul IRI (ing. Identificator de resurse internaționalizate) - identificatori internaționali de resurse în care ar fi posibilă utilizarea fără probleme a caracterelor Unicode și care nu ar încălca drepturile altor limbi. La fel, creatorul URI-ului, Tim Berners-Lee, a spus că sistemul de nume de domenii care stă la baza URL-urilor este o decizie 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ă 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, atunci când sunt combinate cu date într-o componentă neierarhică Anchetă, servesc la identificarea resursei în domeniul de aplicare al schemei URI. De obicei ierarhic-parte conține calea către resursă (și, eventual, în fața acesteia, adresa serverului pe care se află) sau identificatorul resursei (în cazul URN).
Anchetă
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ă prin referirea la resursa primară și prin specificarea informațiilor suplimentare. O resursă secundară identificabilă poate fi o parte sau un subset al resursei primare, o reprezentare a acesteia sau o altă resursă definită sau descrisă de o astfel de resursă.
Analizarea structurii URI-ului. Pentru așa-numita „parsare” a URI-urilor (ing. analizare), adică pentru a descompune URI-urile în părțile lor constitutive și identificarea lor ulterioară, este cel mai convenabil să folosiți sistemul de expresii regulate, care este acum disponibil în aproape toate limbajele de programare moderne. Următorul model este recomandat pentru analizarea URI-urilor în RFC 3986:
Acest model include 9 grupuri indicate mai sus prin numere (pentru mai multe informații despre modele și grupuri, consultați Expresii regulate), care analizează cel mai complet și mai precis o structură URI tipică, unde:
- grupa 2 - schema,
- grupa 4 - sursa,
- grupa 5 - cale,
- grupa 7 - cerere,
- grupa 9 - fragment.
Astfel, dacă, folosind acest șablon, analizăm, de exemplu, un astfel de URI tipic:
http://www.ics.uci.edu/pub/ietf/uri/#Related
atunci cele 9 grupuri de șabloane de mai sus vor da următoarele rezultate:
- http:
- //www.ics.uci.edu
- www.ics.uci.edu
- / pub / ietf / uri /
- nici un rezultat
- nici un rezultat
- #Legate de
- Legate de
Exemple de URI-uri:
URI absolute
- https://ru.wikipedia.org/wiki/URI
- ftp://ftp.is.co.za/rfc/rfc1808.txt
- fișier: // C: \ UserName.HostName \ Projects \ Wikipedia_Articles \ URI.xml
- fișier: /// C: /file.wsdl
- fișier: ///Users/John/Documents/Projects/Web/MyWebsite/about.html
- ldap: /// c = GB? objectClass? unu
- mailto: [email protected]
- înghiţitură: [email protected]
- știri: comp.infosystems.www.servers.unix
- date: text / simplu; set de caractere = iso-8859-7,% be% be% be
- tel: + 1-816-555-1212
- telnet: //192.0.2.16: 80 /
- urnă: oază: nume: specificație: 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 / către / resource.txt
- ../../../resource.txt
- resource.txt
- /resource.txt#frag01
- # frag01
[șir gol] - este echivalent cu analizarea identificatorului de către parser cu rezultatul [șir gol], adică linkul duce la obiectul implicit din schema implicită
serviciu DNS
DNS înseamnă Domain Name System. 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, de asemenea, 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 DNS.
Unice sunt, de asemenea, adresele care sunt indicate pe plicuri la livrarea scrisorilor prin poștă obișnuită. 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, ele 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 ierarhiei.
- Distribuirea stocării informațiilor... Fiecare nod al rețelei 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 poate stocați unele date în afara zonei lor 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 activitatea nodurilor de nivel inferior, fie delega(transferă-le) în alte noduri.
- Rezervare... Pentru stocarea și întreținerea nodurilor (zonelor) acestora sunt (de obicei) mai multe servere, separate atât fizic, cât și logic, ceea ce asigură siguranța datelor și continuarea lucrului chiar și în cazul unei defecțiuni a unuia dintre noduri.
Niveluri de domeniu. Există trei niveluri de domenii.
Domenii primul 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. Prin intermediul acestora, 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 anumit scop. De exemplu: .com - pentru organizații comerciale, .info - pentru site-uri informaționale, .tv - pentru companii de televiziune etc. Aceste domenii pot fi folosite pentru a determina focalizarea specifică a site-ului. Deși, să spun adevărul, în ultimul timp sunt din ce în ce mai folosite în orice fel și de multe ori nu respectă scopul lor.
Domeniile de primul nivel nu pot fi folosite ca adresă a site-ului dvs. Acestea servesc la crearea de domenii al doilea nivel , prin urmare, pe oricare dintre domeniile de nivel întâi, puteți înregistra un domeniu de nivel al doilea. Un domeniu de nivel al doilea este format din următoarele elemente: www.nume_site.domeniu de prim nivel. De exemplu: www.webmastermix.ru. Este recomandat să folosiți nume de domenii de nivel al doilea pentru adresa site-ului. Ele sunt cel mai bine citite și amintite de oameni, precum și 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 ... Sunt create pe baza domeniilor de nivel al doilea. Domeniul de nivel al treilea arată astfel: www.forum.webmastermix.ru. După ce ați înregistrat un domeniu de nivel al doilea, puteți crea în mod independent pe baza acestuia câte domenii de nivel al treilea 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 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 unitatea logică minimă a World Wide Web, care este un document care este 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). Uneori, este folosit necorespunzător pentru a controla modul în care conținutul paginilor web este afișat pe un ecran de monitor sau atunci când iese către o imprimantă, ceea ce contrazice fundamental ideologia adoptată pe World Wide Web.
Orez. 3. Tehnologii web
Foile de stil în cascadă (CSS) au scopul de a controla afișarea conținutului pe paginile web. CSS este similar în multe privințe cu stilurile folosite în procesorul de text popular, 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 JavaScript este ECMAScript.
HTML, CSS, JavaScript sunt limbi cu care puteți crea orice site web complex. Dar acesta este doar suport lingvistic, în timp ce în browsere documentele sunt reprezentate ca o colecție de obiecte, multe dintre acestea fiind modelul de obiect al browserului (BOM). Modelul obiect al browserului este unic pentru fiecare model și, prin urmare, apar probleme la construirea aplicațiilor între browsere. Prin urmare, Web Consortium a propus Document Object Model (DOM), care este modalitatea standard de reprezentare a paginilor web folosind o colecție de obiecte.
Sintaxa HTML modern este descrisă folosind Extensible Markup Language. XML vă va permite să vă creați propriile limbaje de marcare similare cu HTML sub formă de DTD. Există multe astfel de limbaje: pentru reprezentarea formulelor matematice și chimice, cunoștințe etc.
După cum puteți vedea din cele de mai sus, toate tehnologiile web sunt strâns interconectate. Înțelegerea acestui fapt va facilita înțelegerea scopului unui anumit mecanism utilizat pentru a crea aplicații web.
Poșta electronică (e-mail, e-mail, din engleză. Poșta electronică) este o tehnologie și serviciile pe care le furnizează pentru trimiterea și primirea de mesaje electronice (numite „scrisori” sau „e-mailuri”) printr-o rețea de calculatoare distribuită. Principala diferență față de alte sisteme de mesagerie 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ă de copii ale scrisorii către mai mulți destinatari, redirecționarea scrisorii primite la o altă adresă, utilizarea numelor logice în loc de adrese (numerice sau nume de domenii), creați mai multe subsecțiuni ale căsuței poștale pentru tot felul de corespondență, includeți fișiere text în litere, utilizați sistemul „reflectori 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, este necesar să indicați adresa căsuței poștale. Cutia poștală a unui abonat de e-mail este o zonă de pe hard disk-ul unui server de e-mail rezervată utilizatorului.
Dezvoltarea tehnologiei Internet a dus la apariția protocoalelor moderne de mesagerie, care oferă oportunități mari de procesare a scrisorilor, o varietate de servicii și ușurință în utilizare. Deci, de exemplu, protocolul SMTP, care funcționează pe principiul client-server, este conceput pentru a trimite mesaje de la un computer către destinatar. De obicei, accesul la serverul SMTP nu este protejat prin parolă, astfel încât orice server cunoscut din rețea poate fi folosit 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 serverul sau serviciul în care există contul. Aceste servere folosesc protocoalele POP și IMAP, care diferă prin modul în care stochează mesajele.
În conformitate cu protocolul POP3, mesajele care sosesc 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 permanentă la rețea. Mesajele primite de adresă sunt stocate și pe server, dar, spre deosebire de POP3, la verificarea e-mailului, vor fi descărcate mai întâi doar antetele mesajelor. Scrisoarea în sine poate fi citită după selectarea antetului 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 inutile de timp.
Există mai multe protocoale pentru primirea și transferul de corespondență între sisteme multi-utilizator.
O scurtă descriere a unora dintre ele:
1) SMTP (Simple Mail Transfer Protocol) este un protocol de rețea conceput pentru transmiterea de e-mail în rețele TCP/IP, iar transmiterea trebuie neapărat inițiată de sistemul de transmitere însuși.
MTA (Mail Transfer Agent) - agentul de transfer de e-mail - este componenta principală a sistemului de transfer de e-mail 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, dezvoltate pentru a livra corespondență unui utilizator de pe un server central de e-mail, a le șterge de pe acesta și pentru a identifica un utilizator după nume/parolă. POP include SMTP, care este folosit pentru a transfera e-mailuri de la un utilizator. Mesajele de e-mail pot fi primite sub formă de antete, fără a primi întregul mesaj.
După stabilirea conexiunii, protocolul POP3 trece prin trei stări consecutive
- Autorizare clientul trece prin procedura de autentificare
- Tranzacția client primește informații despre starea cutiei poștale, acceptă și șterge e-mail.
- Actualizarea serverului ș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ă, de asemenea, clientului posibilitatea de a căuta șiruri în mesajele de e-mail pe serverul însuși.
o IMAP2 - folosit în cazuri rare.
o IMAP3 - soluție incompatibilă, neutilizată.
o IMAP2bis - o extensie IMAP2 care permite serverelor să analizeze mesajele în mesaje MIME (Multipurpose Internet Mail Extensions), încă în uz.
o IMAP4 este un IMAP2bis reelaborat și îmbunătățit care poate fi folosit oriunde.
o IMAP4rev1 - Extinde IMAP cu o gamă largă de caracteristici, inclusiv cele utilizate de DMSP (Distributed Mail System for Personal Computers).
4) ACAP (Application Configuration Access Protocol) - un protocol dezvoltat pentru a funcționa cu IMAP4; adaugă posibilitatea de a căuta abonament și abonament la panouri de mesaje, cutii poștale și este folosit pentru a căuta agende.
5) DMSP (sau PCMAIL) este un protocol de primire/trimitere de corespondență, a cărui particularitate este că utilizatorul poate avea mai mult de o stație de lucru în utilizare. 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 tot felul de informații prin e-mail, inclusiv text în alte limbi decât engleza, pentru care se folosesc codificări de caractere altele decât ASCII, precum și conținut binar de 8 biți, cum ar fi imagini, muzică, filme și programe.
Muncă independentă.
Rulați exemplul dat în text (fișă) și salvați-l în propriul folder de pe desktop.
9.2. Lucrul cu un profesor:
În caz de dificultăți sau acțiuni eronate, contactați profesorul pentru a corecta erorile.
Până la sfârșitul lecției, arătați profesorului un raport despre munca efectuată și obțineți un credit pentru această muncă.
9.3. Controlul nivelului inițial și final de cunoștințe:
Testarea pe computer .
Informații similare.
URI Uniform Resource Identifier. URI-urile sunt cunoscute sub multe dintre denumirile adrese WWW, identificatori universali de documente, 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 formatat care identifică o resursă după nume, locație sau orice altă caracteristică. 3.2.1 Sintaxă generală. URI-urile în HTTP pot fi prezentate în formă absolută URI-uri absolute sau URI-uri relative relativ la un URI de bază cunoscut, în funcție de contextul utilizării lor. Diferența dintre cele două forme este că URI-urile absolute încep întotdeauna cu un nume de schemă colonizat prin două puncte.
URI absoluteURI relativeURI fragment absoluteURI schema uchar rezervat relativeURI net path abs path rel path net path net loc abs path abs path rel path 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 național 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ă Backus-Naur include caractere naționale care nu sunt permise în adrese URL valide definite de RFC 1738, deoarece serverele HTTP permit unui set de caractere nerezervate să reprezinte porțiunea de cale rel a adreselor și, prin urmare, proxy-urile HTTP pot primi solicitări URI care nu respectă RFC 1738. Protocolul HTTP nu impune orice restricții privind lungimile URI... Serverele trebuie să gestioneze URI-urile oricărei resurse, de orice lungime, pe care le deservesc și trebuie să gestioneze URI-urile de lungime nelimitată dacă servesc servere bazate pe GET care pot genera un astfel de URI. Serverul TREBUIE să returneze un cod de stare 414 al URI-ului de solicitare Prea lung, URI-ului de solicitare Prea lung 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 notație 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. Aceasta înseamnă că portul identificat resursa este găzduită pe server, în așteptarea conexiunilor TCP pe portul, gazda specificate și URI-ul resursei solicitate este calea abs. Utilizarea adreselor IP în URL-uri ar trebui evitată pe cât posibil prin RFC 1900. Dacă calea abs nu este prezentă în adresa URL, TREBUIE tratată ca atunci când se calculează URI de solicitare a resursei solicitate. 3.2.3
Sfârșitul lucrării -
Acest subiect aparține secțiunii:
Protocolul HTTP 1.1
Conform RFC 1945, HTTP 1.0 a fost o îmbunătățire a acestui protocol, a permis un format MIME al mesajelor care conțineau meta-informații despre cele transmise, dar HTTP 1.0 nu a ținut cont de particularitățile lucrului cu cele ierarhice. .. 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 lucrări:
Ce vom face cu materialul primit:
Dacă acest material s-a dovedit a fi util pentru dvs., îl puteți salva pe pagina dvs. de pe rețelele sociale:
| Tweet |
Toate subiectele din această secțiune:
Terminologie
Terminologie. Conexiune de conectare. Canal virtual stratul de transport, stabilit între două programe în scopul transmiterii mesajului de comunicare. Modulul principal de comunicare HTTP, constând din structural
Parametrii protocolului
Parametrii protocolului. Versiunea HTTP.HTTP folosește o schemă majoră de numerotare. minor pentru a indica versiunea protocolului. Strategia de versiune a protocolului este concepută pentru a permite trimiterea
comparație UR
Comparația UR. I. 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 acestor URI, cu
Data completă
Data completă. Aplicațiile HTTP au permis, în trecut, trei formate diferite pentru reprezentarea datelor orei soarelui, 06 noiembrie 1994 08 49 37 GMT RFC 822 modificat în RFC 1123 duminică, 06 noiembrie 94 08 49 37 GMT
Seturi de caractere
Seturi de caractere. HTTP folosește aceeași definiție a termenului tabelul de coduri care este definit pentru MIME Termenul carte de coduri este folosit pentru a se referi la o metodă care utilizează
Codări de conținut
Codificarea conținutului Codificarea conținutului. 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 Coding Transfer Coding. Valorile de codificare de transfer sunt folosite pentru a indica o transformare de codificare care a fost sau ar trebui să fie aplicată corpului entității pentru a
Tipuri media
Tipuri media Tipuri media. HTTP utilizează Internet Media Types î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 tipului de text
Canonizare și valori predefinite ale tipului de text. Tipurile media de internet sunt înregistrate în formă canonică. V caz general corpul obiectului transmis prin mesajul HTTP trebuie 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 care formează un pachet de unul sau mai multe obiecte în corpul unui singur mesaj. Toate tipurile multipart au o sintaxă comună, o
Jetoane de produs
Jetoane de produs. Markerii de produs sunt utilizați pentru a permite aplicațiilor de comunicare să se identifice cu 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ății diferiților parametri negociați. Greutatea este o substanță normalizată
Etichete de limbă Etichete de limbă
Etichete de limbă Etichete de limbă. Eticheta de limbă identifică o limbă 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 obiect în câmpurile antet ETag
Unități de gamă Unități de gamă
Unități de gamă Unități de gamă. HTTP 1.1 permite unui client să solicite doar o parte a unui 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 de la client la server și răspunsuri de la server la client. Mesaj HTTP Răspuns la cerere Mesaje HTTP 1.1 Mesajele de solicitare și răspuns utilizează format generic
Antetele posturilor
Antetele posturilor. Câmpuri de antet HTTP, care includ câmpuri antet general, antet cerere, antet răspuns și antet entity-h
Conținutul mesajului
Corpul mesajului. Corpul mesajului HTTP, dacă este prezent, este utilizat pentru a transmite corpul obiectului asociat cu cererea sau răspunsul. Corpul mesajului-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ă prin una dintre următoarele metode, în ordinea de prioritate 1. Orice mesaj de răspuns care nu ar trebui să
Metoda Metoda
Metoda Metoda. Indicatorul de metodă specifică metoda de aplicat resursei identificate de Request-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 din trei cifre pentru rezultatul unei încercări de a înțelege și executa o solicitare. Aceste coduri sunt complet definite în secțiune
Conexiuni persistente
Conexiuni persistente. Ţintă. Înainte de introducerea conexiunilor persistente, a fost setat un URL separat pentru fiecare solicitare URL. Conexiune TCP, care a crescut încărcarea pe HTTP de atunci
Discuție Negociere
Discuție Negociere. Un server HTTP 1.1 poate presupune că un client HTTP 1.1 nu acceptă o conexiune persistentă dacă antetul Conexiune trimis în cerere conține simbolul de conectare
Conveior Procesare Conducte
Prelucrare transportoare Conducte. Client care sprijină conexiuni persistenteștie să canalizeze cererile, adică să trimită 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 expirare după care nu mențin o conexiune inactivă. Proxy-urile o pot seta mai sus
Cerințe pentru transferul mesajelor
Cerințe pentru transmiterea mesajelor. Cerințe generale- Serverele HTTP 1.1 TREBUIE să mențină conexiuni persistente și să utilizeze mecanisme de control al fluxului TCP pentru a reduce temporar
Metode sigure
Metode sigure. Programatorii ar trebui să înțeleagă că software-ul, atunci când interacționează cu Internetul, reprezintă utilizatorul, iar programul ar trebui să informeze utilizatorul cu privire la orice acțiune
Definiția status codes
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 autentifica accesul, HTTP oferă un mecanism simplu de 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 ID.
Memorarea în cache HTTP
Memorarea în cache HTTP. HTTP este folosit în mod obișnuit pentru distribuție sisteme de informare care performanță poate fi îmbunătățită prin utilizarea răspunsurilor stocate în cache. Protocolul HTTP 1.1 include p
Corectitudinea memoriei cache
Corectitudinea memoriei cache. Cache corect trebuie să răspundă la cerere cu cel mai actualizat răspuns, corespunzător solicitării, stocat de cache-ul care îndeplinește una dintre următoarele condiții 1. A fost valabil
Mecanisme de control al memoriei cache
Mecanisme de control al memoriei cache. Mecanismele de bază ale memoriei cache din timpul de expirare și validatorul specificat de server HTTP 1.1 sunt directive implicite
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, un agent utilizator ar putea permite p
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 de origine și, într-o măsură mai mică, cache-urile intermediare și contribuția lor la vârsta răspunsului sunt sursa principală de informații despre învechire.
Model de uzură
Modelul deprecierii. uzura, specificat de server... Memorarea în cache HTTP funcționează cel mai bine atunci când cache-urile pot evita complet solicitările către serverul de origine. Mecanismul primar și
Învechirea euristică
Învechirea euristică. Deoarece serverele de origine nu oferă întotdeauna timpi de expirare expliciți, cache-urile HTTP atribuie de obicei timpi de expirare euristic folosind algoritmi care sunt utilizați
Calcularea vârstei
Calcularea vârstei. Pentru a ști dacă un obiect din cache este proaspăt, cache-ul trebuie să știe dacă este mai vechi decât data de prospețime. Gazde care folosesc HTTP, în special hos
Calculul uzurii
Calculul învechirii. Pentru a decide dacă un răspuns este proaspăt sau întârziat, trebuie să comparăm durata de viață a acestuia cu vârsta. Vârsta se calculează 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 timpuri
