Share
HTTP este protocolul care ne permite să cumpărăm cuptoare cu microunde de la Amazon.com, să ne reunim cu un vechi prieten într-un chat pe Facebook și să vedem videoclipuri amuzante pe YouTube. HTTP este protocolul din spatele World Wide Web. Permite unui server web de la un centru de date din Statele Unite să transmită informații într-o cafenea pe Internet din Australia, unde un elev tânăr poate citi o pagină web care descrie dinastia Ming din China.
În această carte vom analiza HTTP din perspectiva dezvoltatorului de software. Având o înțelegere solidă a HTTP vă poate ajuta să scrieți mai bune aplicații web și servicii web. De asemenea, vă poate ajuta să depanați aplicațiile și serviciile atunci când lucrurile nu merg bine. Vom acoperi toate elementele de bază, inclusiv resursele, mesajele, conexiunile și securitatea în legătură cu HTTP.
Vom începe prin a privi resursele.
Poate că cea mai cunoscută parte a web-ului este adresa HTTP. Când vreau să găsesc o rețetă pentru un fel de mâncare cu broccoli, care este aproape niciodată, aș putea să-mi deschid browserul și să intru în http://food.com în bara de adrese pentru a merge la site-ul food.com și pentru a căuta rețete. Browserul meu intelege aceasta sintaxa si stie ca trebuie sa faca o cerere HTTP catre un server numit food.com. Vom vorbi mai târziu despre ce înseamnă "a face o solicitare HTTP" și despre toate detaliile legate de rețea. Pentru moment, vrem doar să ne concentrăm pe adresa: http://food.com.
Adresa http://food.com este ceea ce numim o adresă URL - un localizator de resurse uniform. Acesta reprezintă o resursă specifică pe web. În acest caz, resursa este pagina de pornire a site-ului food.com. Resursele sunt lucrurile pe care vreau să le interacționez pe web. Imaginile, paginile, fișierele și videoclipurile sunt toate resurse.
Există miliarde, dacă nu trilioane, de locuri pentru a merge pe Internet - cu alte cuvinte, există miliarde de resurse. Fiecare resursă va avea o adresă URL pe care o pot folosi pentru ao găsi. http://news.google.com este un loc diferit de http://news.yahoo.com. Acestea sunt două nume diferite, două companii diferite, două site-uri diferite și, prin urmare, două adrese URL diferite. Desigur, în interiorul aceluiași site vor fi diferite adrese URL. http://food.com/recipe/broccoli-salad-10733/ este adresa URL a unei pagini cu o rețetă de salată de broccoli, în timp ce http://food.com/recipe/grilled-cauliflower-19710/ este încă la food.com, dar este o resursă diferită care descrie o rețetă de conopidă.
Putem rupe ultima adresă URL în trei părți:
Accentsconagua
http, partea în fața : //, este ceea ce noi numim Schema de adrese URL. Schema descrie Cum pentru a accesa o anumită resursă, iar în acest caz îi spune browserului să utilizeze protocolul de transfer de hipertext. Mai târziu vom examina și o schemă diferită, HTTPS, care este protocolul HTTP securizat. S-ar putea să aveți și alte scheme, cum ar fi FTP pentru protocolul de transfer de fișiere și mailto pentru adresele de e-mail. Totul după : // va fi specific unei anumite scheme. Deci, o adresă HTTP legală poate să nu fie o adresă legală pentru mailto - cele două nu sunt într-adevăr interschimbabile (ceea ce are sens deoarece descrie diferite tipuri de resurse).
food.com este gazdă. Acest nume de gazdă indică browserului numele computerului care găzduiește resursa. Computerul va utiliza sistemul de nume de domeniu (DNS) pentru a traduce food.com într-o adresă de rețea, iar apoi va ști exact unde să trimită cererea pentru resursă. De asemenea, puteți specifica partea gazdă a unei adrese URL utilizând o adresă IP./ Reteta / gratar-conopida-19710 / este Calea URL. Gazda food.com ar trebui să recunoască resursa specifică solicitată de această cale și să răspundă corespunzător.Uneori, o adresă URL va indica un fișier din sistemul de fișiere sau din hard disk al gazdei. De exemplu, adresa URL http://food.com/logo.jpg ar putea indica o imagine care într-adevăr există pe serverul food.com. Cu toate acestea, resursele pot fi și dinamice. Adresa URL http://food.com/recipes/brocolli probabil nu se referă la un fișier real pe serverul food.com. În schimb, un tip de aplicație rulează pe gazda food.com, care va prelua această solicitare și va construi o resursă utilizând conținutul dintr-o bază de date. Aplicația ar putea fi construită utilizând ASP.NET, PHP, Perl, Ruby on Rails sau o altă tehnologie web care știe cum să răspundă la cererile primite prin crearea HTML-ului pentru afișarea unui browser.
De fapt, în aceste zile multe site-uri încearcă să evita având orice nume de fișier real în adresa lor URL. Pentru început, numele fișierelor sunt de obicei asociate cu o tehnologie specifică, cum ar fi .aspx pentru tehnologia ASP.NET a Microsoft. Multe adrese URL vor depăși tehnologia utilizată pentru a le găzdui și a le servi. În al doilea rând, multe site-uri doresc să plaseze cuvintele cheie într-un URL (cum ar fi / Reteta / broccoli / în URL-ul pentru o rețetă broccoli). Având aceste cuvinte cheie în URL-ul este o formă de optimizare a motorului de căutare (SEO), care va clasifica resursa mai mare în rezultatele motorului de căutare. Cuvinte cheie descriptive, nu nume de fișiere, sunt importante pentru adresele URL în aceste zile.
Unele resurse vor determina browserul să descarce resurse suplimentare. Pagina de pornire a food.com va include imagini, fișiere JavaScript, CSS și alte resurse care se vor combina pentru a prezenta "pagina de pornire" a food.com.
food.com home page Acum, când știm despre scheme de adrese URL, gazde și căi, să analizăm și o adresă URL cu un număr de port:
http://food.com:80/recipes/broccoli/
Numărul 80 reprezintă numarul portului gazda utilizează pentru a asculta cererile HTTP. Numărul portului implicit pentru HTTP este portul 80, deci, în general, vedeți acest număr de port omis de la o adresă URL. Trebuie doar să specificați un număr de port dacă serverul asculta pe un port diferit de portul 80, care de obicei se întâmplă numai în medii de testare, depanare sau dezvoltare. Să ne uităm la o altă adresă URL.
http://www.bing.com/search?q=broccoli
Totul după ? (semnul întrebării) este cunoscut sub numele de întrebare. Interogarea, numită și șir de interogare, conține informații pentru utilizarea sau interpretarea site-ului Web de destinație. Nu există un standard formal pentru modul în care ar trebui să pară șirul de interogare, deoarece este punct de vedere tehnic al aplicației să interpreteze valorile pe care le găsește, dar veți vedea că majoritatea șirurilor de interogări utilizate pentru a transmite perechi de nume-valoare în formular nume1 = valoare1 & nume2 = valoare2.
De exemplu:
http://foo.com?first=Scott&last=Allen
Există două perechi de nume-valoare în acest exemplu. Prima pereche are numele "first" și valoarea "Scott". A doua pereche are numele "last" cu valoarea "Allen". În URL-ul nostru anterior (http://www.bing.com/search?q=broccoli), motorul de căutare Bing va vedea numele "q" asociat cu valoarea "broccoli". Se pare că motorul Bing caută o valoare "q" de utilizat ca termen de căutare. Ne putem gândi la adresa URL ca URL pentru resursa care reprezintă rezultatele căutării Bing pentru broccoli.
În cele din urmă, încă o adresă URL:
http://server.com?recipe=broccoli#ingredients
Partea după semnul # este cunoscută sub numele de fragment. Fragmentul este diferit de celelalte piese pe care le-am analizat până acum, deoarece spre deosebire de calea URL și șirul de interogare, fragmentul nu este procesat de server. Fragmentul este utilizat numai pe client și identifică o anumită secțiune a unei resurse. În mod specific, fragmentul este folosit în mod obișnuit pentru a identifica un element HTML specific într-o pagină cu ID-ul elementului.
Navigatoarele web vor alinia în mod obișnuit afișarea inițială a unei pagini web astfel încât partea superioară a elementului identificat de fragment să fie în partea de sus a ecranului. De exemplu, adresa URL http://odetocode.com/Blogs/scott/archive/2011/11/29/programming-windows-8-the-sublime-to-the-strange.aspx#feedback are valoarea fragmentului "feedback". Dacă urmați adresa URL, browserul dvs. web ar trebui să deruleze în jos în jos pentru a afișa secțiunea de feedback a unei anumite postări pe blog pe blogul meu. Browserul dvs. a preluat întreaga resursă (postarea pe blog), dar a focalizat atenția asupra unei anumite zone - secțiunea de feedback. Vă puteți imagina codul HTML pentru postarea de blog care arată în felul următor (cu întregul conținut de text fiind omis):
......
Clientul se asigură că elementul cu codul "feedback" este în partea de sus.
Dacă am pus împreună tot ceea ce am învățat până acum, știm că o adresă URL este împărțită în următoarele bucăți:
: // : / ? #
Toți dezvoltatorii de software care lucrează cu webul ar trebui să fie conștienți de problemele de codificare a caracterelor cu adrese URL. Documentele oficiale care descriu adresele URL merg la mari lungimi pentru ca URL-urile să fie cât mai utilizabile și mai interoperabile posibil. O adresă URL ar trebui să fie la fel de ușor de comunicat prin e-mail, deoarece este de a imprima pe un autocolant și se aplică pe un Ford Windstar din 2001. Din acest motiv, standardele Internet definesc nesigure pentru adrese URL. De exemplu, caracterul spațial este considerat nesigur, deoarece caracterele spațiului pot să apară sau să dispară în mod eronat atunci când o adresă URL este în formă tipărită (este un spațiu sau două spații pe cartea dvs. de vizită?).
Alte caractere nesigure includ semnul numeric (#), deoarece este folosit pentru a delimita un fragment și cartea (^) deoarece nu este întotdeauna transmisă corect prin toate dispozitivele de rețea. De fapt, RFC 3986 ("legea" pentru adrese URL) definește caracterele sigure pentru URL-uri ca fiind caractere alfanumerice din US-ASCII, plus câteva caractere speciale precum colon (:) și marcajul slash (/.
Din fericire, puteți transmite în continuare caractere nesigure într-o adresă URL, dar toate caracterele nesigure trebuie să fie codate în procente (codificate aka URL). % 20 este codarea pentru un caracter spațiu (unde 20 este valoarea hexazecimală pentru caracterul spațial US-ASCII).
De exemplu, să presupunem că doriți să creați adresa URL pentru un fișier numit "^ my resume.txt" pe someserver.com. Adresa URL legală, codată ar arăta astfel:
http://someserver.com/%5Emy%20resume.txt
Ambele caractere ^ și spațiu au fost codate procentual. Cele mai multe cadre de aplicații web vor furniza un API pentru codarea URL ușoară. Pe partea de server, ar trebui să executați URL-urile dvs. create dinamic printr-un API de codificare doar în cazul în care unul dintre caracterele nesigure apare în URL.
Până acum, ne-am concentrat pe URL-uri și am simplificat orice altceva. Dar ce înseamnă atunci când introducem o adresă URL în browser? În mod obișnuit înseamnă că dorim să recuperăm sau să vedem o anumită resursă. Există o cantitate extraordinară de materiale pentru a fi vizualizate pe web și mai târziu vom vedea și cum HTTP ne permite să creăm, să ștergem și să actualizăm resursele. Deocamdată, vom rămâne concentrați asupra recuperării.
Nu am fost foarte specifici cu privire la tipurile de resurse pe care dorim să le recuperăm. Există mii de tipuri diferite de resurse pe paginile web, documente hipertext, documente XML, video, audio, aplicații executabile, documente Microsoft Word și nenumărate altele.
Pentru ca o gazdă să poată servi în mod corespunzător o resursă și pentru ca un client să afișeze corect o resursă, părțile implicate trebuie să fie specifice și precise cu privire la tipul de resursă. Resursa este o imagine? Resursa este un film? Nu vrem ca browserele noastre web să încerce să redăm o imagine PNG ca text și nu am vrea să încerce interpretarea hipertextului ca imagine.
Când o gazdă răspunde la o solicitare HTTP, returnează o resursă și specifică și tipul de conținut (cunoscută și ca media) a resurselor. Vom vedea detaliile despre modul în care tipul de conținut apare într-un mesaj HTTP în capitolul următor.
Pentru a specifica tipurile de conținut, HTTP se bazează pe standardele MIME (Multipurpose Internet Extensions). Deși MIME a fost inițial conceput pentru comunicații prin e-mail, HTTP utilizează standarde MIME în același scop, și anume să eticheteze conținutul astfel încât clientul să știe ce conține conținutul.
De exemplu, atunci când un client solicită o pagină web HTML, gazda poate răspunde la cererea HTTP cu unele coduri HTML pe care le etichetează ca "text / html""text"parte este tipul principal de mass-media, și"html"este subtipul media. Când răspundeți la solicitarea unei imagini, gazda va eticheta resursa cu un tip de conținut"image / jpeg"pentru fișierele JPG,"image / gif"pentru fișierele GIF sau"image / png"pentru fișierele PNG. Aceste tipuri de conținut sunt tipuri standard MIME și sunt literalmente ceea ce va apărea în răspunsul HTTP.
S-ar putea să credeți că un browser se va baza pe extensia de fișier pentru a determina tipul de conținut al unei resurse primite. De exemplu, dacă browserul meu cere "frog.jpg", ar trebui să trateze resursa ca fișier JPG, dar să trateze "frog.gif" ca fișier GIF. Cu toate acestea, pentru majoritatea browserelor, extensia de fișiere este ultimul loc în care va trece pentru a determina tipul real de conținut.
Extensiile de fișiere pot fi înșelătoare și doar pentru că am solicitat un fișier JPG nu înseamnă că serverul trebuie să răspundă cu date codificate în format JPG. Microsoft documentează Internet Explorer (IE) ca fiind primul care caută eticheta tipului de conținut specificată de gazdă. Dacă gazda nu furnizează un tip de conținut, IE va scana apoi primele 200 octeți ai răspunsului încercând să ghicească tipul de conținut. În cele din urmă, dacă IE nu găsește un tip de conținut și nu poate ghici tipul de conținut, acesta va cădea înapoi în extensia de fișier utilizată în solicitarea resursei. Acesta este motivul pentru care eticheta tipului de conținut este importantă, dar este departe de unicul motiv.
Deși avem tendința să credem că HTTP este ceva folosit pentru a servi pagini web, se pare că specificația HTTP descrie un protocol flexibil, generic pentru mutarea informațiilor de înaltă fidelitate. O parte din misiunea de a muta informații în jurul este de a asigura că toate părțile implicate știu cum să interpreteze informațiile, și de aceea setările de tip media sunt importante.
Cu toate acestea, tipurile de media nu sunt doar pentru gazde. Clienții pot juca un rol în ce tip de media revine o gazdă prin participarea la o negociere de tip conținut.
O resursă identificată de o singură adresă URL poate avea reprezentări multiple. Luați, de exemplu, rețeta broccoli pe care am menționat-o mai devreme. Reteta unică poate avea reprezentări în diferite limbi (engleză, franceză și germană). Rețeta poate avea chiar reprezentări în diferite formate (HTML, PDF și text simplu). Totul este aceeași resursă și aceeași rețetă, dar reprezentări diferite.
Întrebarea evidentă este: Ce reprezentare ar trebui să selecteze serverul? Răspunsul este în mecanismul de negociere a conținutului descris de specificația HTTP. Atunci când un client efectuează o solicitare HTTP către o adresă URL, clientul poate specifica tipurile de suport pe care le acceptă. Tipurile de suport media nu sunt doar pentru gazdă pentru a eticheta resursele de ieșire, dar și pentru clienți pentru a specifica tipul de suport pe care vor să-l consume.
Clientul specifică ce va accepta în mesajul de solicitare de ieșire. Din nou, vom vedea detaliile acestui mesaj în următoarea sesiune, dar imaginați-vă o solicitare http://food.com/ spunând că va accepta o reprezentare în limba germană. Depinde de server să încerce să îndeplinească cererea. Gazda ar putea trimite o resursă textuală care este încă în limba engleză, ceea ce va dezamăgi probabil un utilizator vorbitor de limbă germană, dar acesta este motivul pentru care îl numim negociere de conținut și nu conținut ultimatum.
Browserele web sunt părți sofisticate de software care pot face față multor tipuri diferite de reprezentări ale resurselor. Negocierea de conținut este un lucru pe care un utilizator nu-l va interesa niciodată, dar pentru dezvoltatorii de software (în special pentru dezvoltatorii de servicii web) negocierea conținutului face parte din ceea ce face ca HTTP să fie mare. O bucată de cod scrise în JavaScript poate face o cerere către server și poate cere o reprezentare JSON. O bucată de cod scrise în C ++ poate face o cerere către server și poate cere o reprezentare XML. În ambele cazuri, dacă gazda poate satisface cererea, informațiile vor ajunge la client într-un format ideal pentru parsare și consum.
În acest moment, am ajuns până la capăt, fără a intra în detalii cu privire la ceea ce arată un mesaj HTTP. Am aflat despre adresele URL, codificarea adreselor URL și tipurile de conținut. Este timpul să vedem cum arată aceste specificații de tip de conținut în timp ce călătoresc prin fir.
