HTTP Protocolul pe care fiecare dezvoltator Web trebuie să îl cunoască - Partea 1

HTTP este un protocol Hypertext Transfer Protocol. Este un protocol apatrid, fără aplicație, pentru comunicarea între sistemele distribuite și este fundamentul web-ului modern. În calitate de dezvoltator web, trebuie să avem o înțelegere puternică a acestui protocol.

Să analizăm acest protocol puternic prin intermediul obiectivului unui dezvoltator web. Vom aborda acest subiect în două părți. În această primă intrare, vom acoperi elementele de bază și vom sublinia diferitele antete de solicitare și de răspuns. În articolul următor, vom examina anumite fragmente de HTTP - și anume cache-ul, gestionarea conexiunilor și autentificarea.

Deși voi menționa câteva detalii legate de anteturi, este mai bine să consultați în schimb RFC (RFC 2616) pentru o acoperire în profunzime. Voi îndrepta anumite părți ale RFC în tot articolul.

Căutați o soluție rapidă?

Dacă întâmpinați probleme cu o eroare HTTP în WordPress pe care aveți nevoie să o rezolvați, puteți să o comandați o eroare de eroare HTTP Express pe Envato Studio și să remediați eroarea într-o singură zi pentru doar 50 USD.

Baze de date HTTP

HTTP permite comunicarea între o varietate de gazde și clienți și acceptă un amestec de configurații de rețea.

Pentru a face acest lucru posibil, acesta presupune foarte puțin despre un anumit sistem și nu menține stat între diferitele schimburi de mesaje.

Acest lucru face HTTP a apatrid protocol. Comunicarea are loc, de obicei, prin TCP / IP, dar se poate utiliza orice transport de încredere. Portul implicit pentru TCP / IP este 80, dar pot fi utilizate și alte porturi.

Capacele personalizate pot fi, de asemenea, create și trimise de client.

Comunicarea dintre o gazdă și un client are loc, prin intermediul unui a cerere / răspuns pereche. Clientul inițiază un mesaj de solicitare HTTP, care este retratat printr-un mesaj de răspuns HTTP. Vom analiza această pereche de mesaje fundamentale în secțiunea următoare.

Versiunea curentă a protocolului este HTTP / 1.1, care adaugă câteva caracteristici suplimentare versiunii anterioare 1.0. Cel mai important dintre acestea, în opinia mea, include conexiuni persistente, codul de transfer chunked și grafice de cache cu granulație fină. Vom contacta pe scurt aceste caracteristici în acest articol; o acoperire aprofundată va fi furnizată în partea a doua.

URL-uri

În centrul comunicațiilor web se află mesajul de solicitare, care este trimis prin Locatori de resurse uniforme (URL-uri). Sunt sigur că deja sunteți familiarizat cu adresele URL, dar, din motive de exhaustivitate, îl voi include aici. Adresele URL au o structură simplă care constă din următoarele componente:

Protocolul este tipic http, dar poate fi, de asemenea https pentru comunicații sigure. Portul implicit este 80, dar se poate seta în mod explicit, așa cum este ilustrat în imaginea de mai sus. Calea de resurse este calea locală la resursele de pe server.

verbele

Există, de asemenea, proxy-uri de depanare web, cum ar fi Lăutar pe Windows și Windows Charles Proxy pentru OSX.

Adresele URL dezvăluie identitatea gazdei particulare cu care dorim să comunicăm, dar acțiunea care trebuie efectuată pe gazdă este specificată prin verbale HTTP. Desigur, există mai multe acțiuni pe care un client ar dori să le îndeplinească gazda. HTTP sa formalizat pe câteva care capturează esențialele care sunt universal aplicabile pentru toate tipurile de aplicații.

Aceste verbe de cerere sunt:

OBȚINE: aduce o resursă existentă. Adresa URL conține toate informațiile necesare serverului pentru a localiza și a restitui resursa.
POST: crea o nouă resursă. Cererile POST poartă, de obicei, un volum util care specifică datele pentru noua resursă.
A PUNE: Actualizați o resursă existentă. Sarcina utilă poate conține datele actualizate pentru resursă.
ȘTERGE: șterge o resursă existentă.

Cele patru verbe de mai sus sunt cele mai populare, iar cele mai multe instrumente și cadre expun în mod explicit aceste verbe de cerere. A PUNE și ȘTERGE sunt considerate uneori versiuni specializate ale POST verbul și pot fi ambalate ca POST cererile cu sarcina utilă care conține acțiunea exactă: crea, Actualizați sau șterge.

Există câteva verbe mai puțin folosite, pe care HTTP le suportă și:

CAP: aceasta este similară cu GET, dar fără corpul mesajului. Se utilizează pentru a prelua anteturile de server pentru o anumită resursă, în general pentru a verifica dacă resursa sa schimbat, prin intermediul timestampurilor.
URMĂ: utilizat pentru a recupera hops-ul pe care o solicită pentru a rută călătoria de pe server. Fiecare proxy intermediar sau gateway ar injecta numele său IP sau DNS în Prin intermediul antetul câmpului. Aceasta poate fi utilizată în scopuri de diagnosticare.
OPȚIUNI: utilizat pentru a prelua capabilitățile serverului. Pe partea clientului, acesta poate fi folosit pentru a modifica cererea pe baza suportului pe care serverul îl poate suporta.

Coduri de stare

Cu URL-uri și verbe, clientul poate iniția cereri către server. În schimb, serverul răspunde cu codurile de stare și încărcăturile de mesaje. Codul de stare este important și îi spune clientului să interpreteze răspunsul serverului. Specificația HTTP definește anumite intervale de numere pentru anumite tipuri de răspunsuri:

1xx: Mesaje informative

Toți clienții HTTP / 1.1 sunt obligați să accepte Transfer-Encoding antet.

Această clasă de coduri a fost introdusă în HTTP / 1.1 și este pur provizorie. Serverul poate trimite a Așteptați: 100-continuați mesaj, spunând clientului să continue trimiterea restului solicitării sau să ignore dacă a trimis-o deja. Clienții HTTP / 1.0 ar trebui să ignore acest antet.

2xx: Succes

Acest lucru îi spune clientului că cererea a fost procesată cu succes. Cel mai comun cod este 200 OK. Pentru o OBȚINE solicită, serverul trimite resursa în corpul mesajului. Există și alte coduri mai puțin utilizate:

202 Acceptat: solicitarea a fost acceptată, dar poate să nu includă resursa în răspuns. Acest lucru este util pentru procesarea asincronă pe partea serverului. Serverul poate alege să trimită informații pentru monitorizare.
204 Nu există conținut: în răspuns nu există un corp de mesaj.
205 Resetare conținut: indică clientului să reseteze vizualizarea documentului.
206 Conținut parțial: indică faptul că răspunsul conține numai conținut parțial. Anteturile suplimentare indică informații exacte privind intervalul și conținutul exact.

3xx: Redirecționare

404 indică faptul că resursa este nevalidă și nu există pe server.

Acest lucru presupune ca clientul să ia măsuri suplimentare. Cel mai obișnuit caz de utilizare este sări la o altă adresă URL pentru a prelua resursa.

301 Mută permanent: resursa este acum localizată la o nouă adresă URL.
303 Consultați Altele: resursa este temporar localizată la o nouă adresă URL. Locație răspunsul antetului conține adresa URL temporară.
304 Modificat: serverul a stabilit că resursa nu sa schimbat și clientul ar trebui să utilizeze copia în memoria cache. Aceasta se bazează pe faptul că clientul trimite ETag (Enttity Tag), care este un hash al conținutului. Serverul compară acest lucru cu calculul propriu ETag pentru a verifica modificările.

4xx: Eroare de client

Aceste coduri sunt utilizate atunci când serverul crede că clientul este vina, fie prin solicitarea unei resurse nevalide, fie prin solicitarea rea. Cel mai popular cod din această clasă este 404 Nu a fost gasit, despre care cred că toată lumea se va identifica. 404 indică faptul că resursa este nevalidă și nu există pe server. Celelalte coduri din această clasă includ:

400 Cerere defectă: solicitarea a fost defectată.
401 Neautorizat: solicitarea cere autentificarea. Clientul poate repeta solicitarea cu Autorizare antet. Dacă clientul a inclus deja Autorizare header, atunci acreditările au fost greșite.
403 Interzis: serverul a refuzat accesul la resursă.
405 Metoda nu este permisă: verbul HTTP invalid utilizat în linia de solicitare sau serverul nu acceptă verbul respectiv.
409 Conflict: serverul nu a putut finaliza solicitarea, deoarece clientul încearcă să modifice o resursă care este mai nouă decât marca de timp a clientului. Conflictele apar mai ales pentru cererile PUT în timpul editărilor colaborative pe o resursă.

5xx: eroare de server

Această clasă de coduri este utilizată pentru a indica o eroare a serverului în timpul procesării cererii. Cel mai frecvent utilizat cod de eroare este 500 Eroare internă a server-ului. Ceilalți din această clasă sunt:

501 Neaplicat: serverul nu suportă încă funcționalitatea solicitată.
503 Serviciu Indisponibil: acest lucru se poate întâmpla dacă un sistem intern pe server nu a reușit sau serverul este supraîncărcat. În mod obișnuit, serverul nu va răspunde și cererea va fi expirată.

Formatele mesajelor de solicitare și de răspuns

Până acum, am văzut asta URL-uri, verbe și coduri de stare alcătuiesc piesele fundamentale ale unei perechi de solicitări / răspunsuri HTTP.

Să analizăm acum conținutul acestor mesaje. Specificația HTTP afirmă că un mesaj de solicitare sau de răspuns are următoarea structură generică:

mesajul =  * () CRLF []  = Linia de solicitare Stare-Line  = Field-Name ':' Field-Value

Este obligatoriu să plasați o nouă linie între antetele mesajului și corp. Mesajul poate conține una sau mai multe antete, dintre care în mare parte se clasifică:

anteturile generale: care se aplică atât pentru mesajele de solicitare, cât și pentru cele de răspuns.
solicitați antete specifice.
răspuns specific.
anteturile entităților.

Corpul mesajului poate conține datele complete ale entității sau poate fi fragmentat dacă codificarea codată (Transfer-codare: chunked) este folosit. Toți clienții HTTP / 1.1 sunt obligați să accepte Transfer-Encoding antet.

Anteturile generale

Există câteva antete (anteturi generale) care sunt partajate atât de mesajele de solicitare, cât și de răspuns:

general-header = Cache-Control | Conexiune | Data | Pragma | Trailer | Transfer-codare | Upgrade Via | Avertizare

Am văzut deja câteva dintre aceste titluri Prin intermediul și Transfer-Encoding. Vom acoperi Cache-Control și Conexiune în partea a doua.

Codul de stare este important și îi spune clientului să interpreteze răspunsul serverului.

Prin intermediul antetul este utilizat într-un mesaj TRACE și actualizat de toate proxy-urile și gateway-urile intermitente
Pragma este considerat un antet personalizat și poate fi folosit pentru a include anteturi specifice implementării. Cea mai frecvent folosită pragma-directivă este Pragma: nu-cache, care este cu adevărat Cache-Control: nu-cache sub HTTP / 1.1. Aceasta va fi inclusă în partea 2 a articolului.
Data câmpul antet este utilizat pentru a marca marcajul temporal mesajul de solicitare / răspuns
Modernizare este folosit pentru a schimba protocoalele și pentru a permite o tranziție lină către un protocol mai nou.
Transfer-Encoding este utilizat în general pentru a rupe răspunsul în părți mai mici cu Transfer-codare: chunked valoare. Acesta este un antet nou în HTTP / 1.1 și permite streaming de răspuns la client în loc de o sarcină utilă mare.

Entitate anteturi

Mesajele de solicitare și răspuns pot include, de asemenea, anteturi ale entității pentru a furniza meta-informații despre conținut (cunoscut sub numele de Organism de Mesaj sau Entitate). Aceste titluri includ:

entitate-header = Permite | Codificarea conținutului Limba conținutului Conținut-lungime Conținut-locație Conținut-MD5 | Intervalul de conținut Tip de conținut Expiră | Modificat ultima dată

Toate din Conţinut- antetele prefixate oferă informații despre structura, codificarea și mărimea corpului mesajului. Unele dintre aceste anteturi trebuie să fie prezente dacă entitatea face parte din mesaj.

expiră antetul indică o marcă de timp a expirării entității. Interesant, a "nu expiră niciodată" entitatea este trimisă cu un marcaj de timp de un an în viitor. Modificat ultima dată antetul indică ultima marcaj de modificare pentru entitate.

Capacele personalizate pot fi, de asemenea, create și trimise de client; acestea vor fi tratate ca anteturi ale entității prin protocolul HTTP.

Acesta este într-adevăr un mecanism de extensie, iar unele implementări client-server pot alege să comunice specific peste aceste antete de extensie. Deși HTTP acceptă anteturile personalizate, ceea ce se așteaptă cu adevărat sunt antetele de solicitare și de răspuns, pe care le acoperim în continuare.

Formatul solicitării

Mesajul de solicitare are aceeași structură generică ca cea de mai sus, cu excepția liniei de solicitare care arată astfel:

Linie de solicitare = Metodă SP URI SP Metodă CRLF pentru HTTP Versiune = "OPȚIUNI" | "HEAD" "GET" "POST" "PUT" | "DELETE" | "URMĂ"

SP este separatorul de spațiu între jetoane. HTTP-Version este specificată ca "HTTP / 1.1" și apoi urmată de o nouă linie. Astfel, un mesaj tipic de solicitare ar putea să arate astfel:

GET / articole / http-bază HTTP / 1.1 Host: www.articles.com Conexiune: păstrați-vii Cache-control: no-cache Pragma: no-cache Acceptați: text / html, application / xhtml + xml, application / xml; q = 0,9, * / *; q = 0,8

Rețineți linia de solicitare urmată de mai multe antete de cerere. Gazdă antetul este obligatoriu pentru clienții HTTP / 1.1. OBȚINE cererile nu au un corp de mesaj, dar POST cererile pot conține datele postului din organism.

Antetele de solicitare acționează ca modificatori ai mesajului de solicitare. Lista completă a anteturilor de cerere cunoscute nu este prea lungă și este furnizată mai jos. Antetele necunoscute sunt tratate ca câmpuri pentru antetul entității.

request-header = acceptare | Accept-Charset | Acceptați-codificare | Accept-Limba | Autorizare | Așteptați | Din | Gazdă | Dacă-Match | Dacă-Modificat-Deoarece | Dacă nu există niciun rezultat Dacă-Range | Dacă-nemodificat-Deoarece | Max-Înainte | Proxy-Autorizare Domeniu | Referer | TE | Agent utilizator

Accept antetele prefixate indică tipurile acceptate de media, limbile și seturile de caractere ale clientului. Din, Gazdă, referer și Agent utilizator identificați detalii despre clientul care a inițiat solicitarea. Dacă- antetele prefixate sunt folosite pentru a face o cerere mai condiționată, iar serverul returnează resursa numai dacă se potrivește condiția. În caz contrar, returnează a 304 Nu a fost modificat. Condiția poate fi bazată pe o marcă de timp sau pe un ETag (un hash al entității).

Formatul răspunsului

Formatul de răspuns este similar cu mesajul de solicitare, cu excepția liniei de stare și a anteturilor. Linia de stare are următoarea structură:

Stare-Linie = HTTP-Versiunea SP Stare-Cod SP Motivul-Phrase CRLF

Versiunea HTTP este trimisă ca HTTP / 1.1
Codul de stare este unul dintre numeroasele stări discutate mai devreme.
Expresia-frază este o versiune citită de om a codului de stare.

O linie de stare tipică pentru un răspuns de succes ar putea arăta astfel:

HTTP / 1.1 200 OK

Anteturile de răspuns sunt, de asemenea, destul de limitate, iar setul complet este prezentat mai jos:

 raspuns-header = Accept-Ranges | Varsta | ETag | Locație | Proxy-Authenticate | Reîncercați-după | Server | Vary | WWW-autentificaþi

Vârstă este ora în secunde de la generarea mesajului pe server.
ETag este hash-ul MD5 al entității și a folosit pentru a verifica modificările.
Locație este utilizat atunci când trimiteți o redirecționare și conține noua adresă URL.
Server identifică serverul care generează mesajul.

A fost o mulțime de teorii până la acest punct, așa că nu te voi învinui pentru ochii somnoleți. În secțiunile următoare vom deveni mai practice și vom face un sondaj al instrumentelor, cadrelor și bibliotecilor.

Instrumente pentru a vizualiza traficul HTTP

Există un număr de instrumente disponibile pentru a monitoriza comunicarea HTTP. Aici, enumerăm câteva dintre cele mai populare instrumente.

Fără îndoială, Inspector Chrome / Webkit este un favorit printre dezvoltatorii web:

Există, de asemenea, proxy-uri de depanare web, cum ar fi Lăutar pe Windows și Windows Charles Proxy pentru OSX. Colegul meu, Rey Bango, a scris un articol excelent pe această temă.

Pentru linia de comandă, avem utilitare precum curl, tcpdump și tshark pentru monitorizarea traficului HTTP.

Folosirea HTTP în Cadre Web și Biblioteci

Acum, că am analizat mesajele de solicitare / răspuns, este timpul să aflăm cum bibliotecile și cadrele expun acest lucru sub forma unui API. Vom folosi ExpressJS pentru nod, Ruby on Rails, și jQuery Ajax ca exemplele noastre.

ExpressJS

Dacă construiți servere web în NodeJS, există șanse mari să fi considerat ExpressJS. ExpressJS a fost inițial inspirată de un cadru Ruby Web, numit Sinatra. Așa cum era de așteptat, API este, de asemenea, influențat în mod egal.

Deoarece avem de-a face cu un cadru de server, există două sarcini primare atunci când se ocupă cu mesaje HTTP:

Citiți fragmente de adrese URL și antete de solicitare.
Scrieți anteturile și corpul de răspuns

Înțelegerea HTTP este crucială pentru a avea o interfață curată, simplă și RESTful între două puncte finale.

ExpressJS oferă un API simplu pentru a face exact acest lucru. Nu vom acoperi detaliile API-ului. În schimb, vom oferi legături către documentația detaliată privind ghidurile ExpressJS. Metodele din API sunt explicite în cele mai multe cazuri. O eșantionare a API-ului referitor la cerere este mai jos:

req.body: obțineți organismul de solicitare.
req.query: obțineți fragmentul de interogare al adresei URL.
req.originalUrl
req.host: citește Gazdă antetul câmpului.
req.accepts: citește tipurile acceptabile MIME de pe partea clientului.
req.get OR req.header: citiți orice câmp de antet trecut ca argument.

Pe calea către client, ExpressJS oferă următorul API de răspuns:

res.status: setați un cod de stare explicit.
res.set: setați un antet de răspuns specific.
res.send: trimiteți HTML, JSON sau un flux octet.
res.sendFile: transferați un fișier clientului.
res.render: face un șablon de vizualizare expres.
res.redirect: redirecționați către un alt traseu. Express adaugă automat codul de redirecționare implicit de 302.

Ruby on Rails

Mesajele de solicitare și de răspuns sunt în mare parte aceleași, cu excepția antetelor primelor linii și a mesajelor.

În modulele Rails, modulele ActionController și ActionDispatch furnizează API-ul pentru gestionarea mesajelor de solicitare și răspuns.

ActionController oferă un API la nivel înalt pentru a citi adresa URL a solicitării, pentru a face ieșirea și pentru a redirecționa către un alt punct final. Un punct final (traseul aka) este tratat ca metodă de acțiune. Cele mai multe informații de context necesare într-o metodă de acțiune sunt furnizate prin intermediul cerere, raspuns și params obiecte.

params: permite accesul la parametrii URL și la datele POST.
cerere: conține informații despre client, anteturi și adresa URL.
răspuns: utilizat pentru a seta anteturile și codurile de stare.
rendere: face vizualizări prin extinderea șabloanelor.
redirect_to: redirecționați către o altă metodă de acțiune sau URL.

ActionDispatch oferă acces cu granulație fină la mesajele de solicitare / răspuns, prin ActionDispatch :: Cerere și ActionDispatch :: Răspuns clase. Acesta expune un set de metode de interogare pentru a verifica tipul de solicitare (obține?(), post?(), cap?(), local?()). Cererile de anteturi pot fi accesate direct prin request.headers () metodă.

Pe partea de răspuns, oferă metode de setare cookie-uri (), locație = () și status = (). Dacă vă simțiți aventuros, puteți de asemenea să setați corp = () și ocolind sistemul de redare Rails.

jQuery Ajax

Deoarece jQuery este în primul rând o bibliotecă bazată pe client, API-ul său Ajax oferă opusul unui cadru de tip server. Cu alte cuvinte, vă permite să citit mesaje de răspuns și modifica solicitați mesaje. jQuery expune un simplu API prin jQuery.ajax (setări):

Prin trecerea a setări obiect cu beforeSend callback, putem modifica antetele de cerere. Callback-ul primește obiectul jqXHR (jQuery XMLHttpRequest) care expune o metodă, numită setRequestHeader () pentru a seta anteturile.

$ .ajax (url: 'http://www.articles.com/latest', tip: 'GET', înainteSend: funcția (jqXHR) jqXHR.setRequestHeader ('Accepts-Language', 'en-US, en '););

Obiectul jqXHR poate fi, de asemenea, folosit pentru a citi anteturile de răspuns cu jqXHR.getResponseHeader ().
Dacă doriți să efectuați acțiuni specifice pentru diferite coduri de stare, puteți utiliza funcția statusCode suna inapoi:

$ .ajax (statusCode: 404: function () alertă ("pagina nu a fost găsită"););

rezumat

Așa că ne sumară turul rapid al protocolului HTTP.

Am examinat structura URL-ului, verbele și codurile de stare: cei trei piloni ai comunicării HTTP.

Mesajele de solicitare și de răspuns sunt în mare parte aceleași, cu excepția antetelor primelor linii și a mesajelor. În cele din urmă, am analizat modul în care puteți modifica antetele de solicitare și de răspuns în cadre și biblioteci web.

Înțelegerea HTTP este crucială pentru a avea o interfață curată, simplă și RESTful între două puncte finale. Pe o scară mai largă, aceasta ajută, de asemenea, la proiectarea infrastructurii de rețea și la oferirea unei experiențe extraordinare utilizatorilor finali.

În partea a doua, vom examina manipularea conexiunilor, autentificarea și cache-ul! Ne vedem atunci.

Referințe

Specificația HTTP
HTTP ghidul definitiv

Cod