Redirecționează folosind HTTPS. Timp de execuție a scriptului excesiv. Ce trebuie făcut dacă apare o eroare

Bara de adreseîn browsere de cele mai multe ori nu atrage atenția decât dacă trebuie să urmați un link copiat de undeva în clipboard. Uneori ne uităm acolo pentru a ne asigura că tranziția este corectă, mai ales în cazurile cu o redirecționare rapidă și necinstită. Dar dacă ne uităm, uneori observăm o stare neobișnuită: există un fel de lacăt atârnat, culoarea fontului este diferită și, din anumite motive, în loc de http:// obișnuit, vedem https://. Este imposibil să înțeleg imediat dacă a dispărut undeva, sau ceva în lume s-a schimbat, sau dacă memoria îmi eșuează. Să încercăm să ne dăm seama.

Definiţie

HTTP — protocolul de aplicare transmiterea de date utilizată pentru a obține informații de pe site-uri web.

HTTPS- extensie Protocolul HTTP, care acceptă criptarea prin Protocoale SSLși TLS.

Comparaţie

Diferența dintre HTTP și HTTPS este deja vizibilă din definiții. HTTPS nu este un protocol independent de transfer de date, ci HTTP cu un supliment de criptare. Aceasta este cheia și singura diferență. Dacă datele sunt transmise neprotejate prin protocolul HTTP, atunci HTTPS va furniza protecţie criptografică. Acesta este utilizat acolo unde este responsabilă autorizarea: pe site-urile sistemelor de plată, servicii postale, pe rețelele de socializare.

Dacă datele nu sunt protejate prin SSL, atunci un program interceptor lansat la momentul nepotrivit permite unui atacator să le folosească. Din punct de vedere tehnic, implementarea HTTPS este ceva mai complicată: pentru aceasta, site-ul protejat trebuie să aibă în uz un certificat de server, pe care utilizatorul îl acceptă sau nu. Acest certificat este instalat pe serverul care procesează conexiunile. Atât datele primite de client, cât și datele primite de la acesta sunt criptate. Cheile de criptare sunt folosite pentru a verifica dacă clientul corect le primește și le furnizează.

Încă un lucru diferenta tehnica— în porturile utilizate pentru acces prin protocoalele HTTP și HTTPS. Primul interacționează de obicei cu portul 80, al doilea cu portul 443. Administratorul poate deschide alte porturi în aceleași scopuri, dar acestea nu se vor potrivi niciodată.

Site-ul de concluzii

HTTP este protocolul de transfer de date în sine, HTTPS este o extensie a acestui protocol.
HTTPS este utilizat pentru comunicarea criptată.
HTTPS este, de asemenea, utilizat pentru autorizarea pe servere care necesită o atenție sporită pentru securitatea datelor.
HTTP funcționează pe portul 80, HTTPS pe portul 443.

Uneori apar situații când un browser web afișează o eroare când solicită un site. Astfel de erori au cod digitalși o descriere specifică.

(101-199) Răspunsuri informative

Astfel de răspunsuri indică faptul că o cerere de la un anumit client a fost acceptată și este procesată direct.

100 - Continuare - prima parte a cererii a fost acceptata, clientul poate continua transmiterea acesteia.
101 - Protocoale de comutare - serviciul îndeplinește anumite cerințe ale clientului și, de asemenea, comută protocoale, ceea ce corespunde datelor din câmpul antet Upgrade.

(200-299) Solicitări de succes ale clienților

În acest interval, toate solicitările clienților sunt finalizate cu succes.

200 - OK - procesarea cu succes a cererii clientului, iar răspunsul serverului conține toate datele solicitate.
201 - Creat - acest cod de stare poate fi folosit la schimbarea URL-ului. Pe lângă cod, serverul emite și un antet Locație, care conține toate informațiile despre locația tuturor datelor noi în mișcare.
202 - Acceptat - cererea este acceptată, dar nu este procesată imediat. Corpul de conținut al răspunsului poate conține, de asemenea, anumite informații despre tranzacție. Nu există nicio garanție că o cerere va fi acceptată, chiar dacă aceasta era valabilă la momentul admiterii.
203 - Informații non-autoritare - antetul conținutului conține informații de la care au fost obținute copie locală sau de la un terț.
204 - Fără conținut - răspunsul conține doar un antet și un cod de stare, corpul răspunsului în sine nu este dat. Când se primește un astfel de răspuns, documentul browserului nu trebuie reîmprospătat. Codul se poate întoarce după ce utilizatorul face clic pe zonele goale ale imaginii.
205 - Resetare conținut - formularul care este utilizat pentru date suplimentare de intrare este șters de browser.
206 - Conținut parțial - serverul returnează doar o parte din date. Folosit într-un răspuns la cerere când se specifică un antet Range. Serverul trebuie să indice în antetul Content-Range anumit interval, care este inclus în răspuns.

(300-399) Redirecționare

Un cod de răspuns în acest interval înseamnă că clientul trebuie să efectueze anumite acțiuni pentru a satisface cererea.

300 - Opțiuni multiple - URL-ul solicitat poate include mai multe resurse. Corpul de conținut returnat de server trebuie să conțină anumite informații despre făcând alegerea corectă resursă.
301 - Mutat permanent (resursa mutată în în mod continuu) - serverul nu mai folosește URL-ul necesar, prin urmare operația specificată în cerere nu este efectuată. Antetul Locație oferă informații despre noua locație a documentului solicitat. Solicitările ulterioare trebuie să specifice noua adresă URL.
302 - Mutat temporar (resursa este mutată temporar) - mișcare temporară a adresei URL solicitate. Antetul Locație specifică noua locație. După primirea codului de stare, clientul trebuie să rezolve cererea folosind noua adresă URL, dar apoi să o folosească doar pe cea veche.
303 - See Other (vezi altă resursă) - căutarea URL-ului solicitat se realizează prin specificarea unui alt URL, care se află în antetul Locație.
304 - Not Modified - este codul de răspuns la antetul lf-Modified-Since dacă URL-ul nu s-a schimbat. Corpul de conținut nu este prezent, așa că clientul trebuie să folosească o copie locală a acestuia.
305 - Utilizați Proxy (utilizați un server proxy) - resursa solicitată trebuie accesată printr-un server proxy, care este specificat în câmpul Locație. Acest câmp conține și adresa URL a serverului proxy necesar. Solicitarea trebuie repetată destinatarului.

(400-499) Solicitări incomplete ale clienților

Codurile de răspuns din acest interval indică faptul că solicitarea clientului este incompletă. De asemenea, poate însemna că clientul trebuie să introducă informații suplimentare.

400 - Cerere greşită (cerere nevalidă) - serverul nu înțelege cererea din cauza sintaxei incorecte. Solicitarea poate fi repetată, dar numai după ce au fost făcute anumite modificări.
401 - Neautorizat (fără permisiune) - utilizatorul trebuie să-și confirme autenticitatea. Răspunsul trebuie să conțină un câmp de antet WWW-Authenticate cu o provocare care se aplică resursei solicitate. Solicitarea poate fi repetată, dar cu un câmp adecvat de antet Autorizare. Dacă acest câmp conține deja recomandări de autentificare, un cod de stare 401 indică faptul că astfel de recomandări nu sunt potrivite pentru autentificare.
402 - Plata necesară - Codul este rezervat și va fi folosit în viitor, dar nu este încă implementat în HTTP.
403 - Interzis (acces refuzat) - cererea este respinsă, astfel încât serverul nu este capabil să răspundă clientului.
404 - Nu a fost găsit(resursa nu a fost găsită) - adresa URL specificată nu mai există documentul solicitat, adică serverul nu a găsit nimic care să se potrivească cu această solicitare.
405 - Method Not Allowed - Antetul Allow indică faptul că metoda utilizată de client nu este acceptată.
406 - Nu este acceptabil - Resursa identificată poate genera doar obiecte cu o caracteristică de conținut care nu se potrivește cu anteturile de acceptare.
407 - Este necesară autentificarea proxy (este necesară înregistrarea la serverul proxy) - indică necesitatea autentificării clientului la serverul proxy. Serverul proxy returnează un câmp de antet Proxy-Authenticate care conține provocarea specifică. Solicitarea poate fi repetată, dar numai dacă este specificat un câmp de antet adecvat.
408 - Request Timeout (timpul de procesare a cererii a expirat) - cererea nu a fost finalizată de client în timp ce serverul aștepta. Cererea poate fi repetată ulterior.
409 - Conflict - Solicitarea nu poate fi procesată deoarece există un conflict cu starea resursei. Se așteaptă ca utilizatorul să rezolve conflictul și să trimită din nou cererea.
410 - Gone (resursa nu mai există) - URL-ul solicitat nu mai este disponibil pe server.
411 - Length Required (lungimea trebuie specificată) - cererea nu este acceptată de server deoarece Content-Length nu este definită. Solicitarea poate fi repetată prin specificarea lungimii corpului mesajului în câmpul antet Content-Length.
412 - Precondiție eșuată - Cererea nu este procesată de server deoarece obiectul de cerere este mult mai mare decât poate gestiona. În această situație, este posibil să închideți conexiunea. Dacă această condiție este temporară, atunci serverul specifică o oră în antetul Retry-After după care clientul poate încerca din nou.
413 - Request Entity Too Large (elementul solicitat este prea mare) - cererea nu este procesată de server din cauza dimensiunii sale uriașe.
414 - Request-URI Too Long (identificatorul de resurse din cerere este prea lung) - cererea nu este procesată de server deoarece URL-ul său este destul de lung.
415 - Unsupported Media Type (unsupported device type) - serverul a refuzat să deservească cererea deoarece resursa solicitată nu acceptă formatul obiectului de solicitare.

(500-599) Erori de server

Acest interval indică faptul că cererea va eșua cel mai probabil deoarece serverul a întâmpinat o anumită eroare.

500 - Intern Eroare de server (eroare internă server) - În timpul procesării unei cereri, una dintre componentele serverului a întâmpinat o anumită eroare de configurare.
501 - Neimplementat (funcția nu este implementată) - cererea clientului nu poate fi îndeplinită deoarece solicitarea necesită suport pentru unele funcţionalitate. Poate fi emis atunci când serverul nu poate recunoaște metoda de solicitare.
502 - Poarta proastă(defect de gateway) - serverul, când lucra ca server proxy, a primit un răspuns nevalid în lanțul de cereri de la următorul server.
503 - Serviciu indisponibil - Serviciul este temporar indisponibil, dar accesul se poate relua după un timp. Dacă serverul are anumite date, poate emite un răspuns cu antetul Retry-After.
504 - Gateway Timeout (timpul trecut prin gateway a expirat) - gateway-ul sau serverul a depășit limita de timp.
505 - Versiunea HTTP Nu este acceptat(versiunea HTTP neacceptată) - serverul nu acceptă versiunea protocolului HTTP utilizată în cerere.

În legătură cu tranziția masivă a site-urilor la HTTPS, dezvoltatorii și administratorii site-urilor s-au confruntat cu o serie de probleme noi. Una dintre ele este o redirecționare de la HTTP la HTTPS și necesitatea de a gestiona corect redirecționările către adresa canonică a site-ului pentru a evita conținutul duplicat.

HTTPS și redirecționări

Să ne uităm la un exemplu. Să presupunem că avem un site web dnsimple.com. Este canonică URL - https://dnsimple.com. Cu toate acestea, sunt patru moduri diferite, cu care vă puteți conecta la site și trebuie să vă asigurați că cu oricare dintre ele utilizatorul este redirecționat către https://dnsimple.com:

Metoda originală	Tip
http://dnsimple.com	HTTP + nu-www
https://dnsimple.com	HTTPS + nu-www
http://www.dnsimple.com	HTTP + www
https://www.dnsimple.com	HTTPS + www

Configurarea redirecționărilor htaccess de la HTTP la HTTPS este adesea o sursă de confuzie. Nu este întotdeauna clar cum să gestionați corect redirecționările de la WWW la non-WWW (sau invers) prin HTTPS și de ce este necesar un certificat SSL/TLS pentru aceasta. Pentru a configura corect aceste redirecționări, trebuie să înțelegeți principiile de bază ale procesării cererilor HTTPS.

În continuare ne vom uita la ordinea în care este stabilită conexiunea de către Protocolul HTTPS cum sunt procesate cererile HTTP și sunt configurate redirecționările cu suport HTTPS.

Flux de solicitare HTTPS

Imaginea de mai sus arată diagrama de flux cerere/răspuns HTTPS. Pentru simplitate, am împărțit toate acțiunile în trei faze:

În prima etapă, clientul și serverul convin asupra detaliilor de criptare, cum ar fi protocolul de criptare și suita de criptare. Informațiile necesare pentru a trece la o conexiune securizată apar și: chei publice, informații despre certificat etc. Această fază se numește „ SSL/TLS strângere de mână»;
În a doua etapă, clientul pregătește o cerere HTTP, o criptează și o trimite către server pentru procesare. Serverul primește o solicitare HTTP criptată, o decriptează, o procesează și emite un răspuns HTTP (răspuns);
În a treia etapă, serverul criptează răspunsul și îl trimite clientului pentru procesare. Clientul primește un răspuns HTTP criptat, îl decriptează și îl procesează ( de exemplu, browserul începe să încarce și să afișeze elemente).

Această diagramă de flux de redirecționare HTTP către HTTPS se aplică oricărei solicitări, indiferent de conținutul răspunsului HTTP.

Mai sus am scris Solicitare HTTPși răspuns HTTP pentru anumite scopuri ( rețineți că am folosit HTTP și nu HTTPS). Din punct de vedere al conținutului și structurii, este important să înțelegem că o solicitare HTTPS este o solicitare HTTP, dar transmisă printr-o conexiune securizată ( TLS/SSL).

Negocieri și redirecționări HTTPS

Una dintre cele mai frecvente greșeli la configurarea redirecționărilor HTTPS este să presupunem că nu aveți nevoie de un certificat SSL atunci când redirecționați un client de la un domeniu la altul.

Dacă te uiți la fluxul de solicitări, poți vedea că schimbul de certificate SSL și negocierea criptării sunt efectuate în prima etapă. Rețineți că în această etapă serverul nu are idee de ce pagină are nevoie clientul: clientul și serverul decid cum să interacționeze unul cu celălalt.

După finalizarea primei etape, când clientul și serverul au găsit un limbaj comun ( protocol de criptare), pot începe să comunice între ei folosind o conexiune criptată. În acest moment, clientul trimite o cerere HTTP către server, iar serverul trimite un răspuns HTTP care conține redirecționarea.

Nu uitați că o redirecționare este un răspuns HTTP cu un cod 301 (uneori 302 sau 307):

HTTP/1.1 301 Mutat permanent Server: nginx Data: Luni, 01 Aug 2016 14:41:25 GMT Locație: https://dnsimple.com/

Înainte de a realiza o redirecționare de la HTTPS la HTTP, rețineți că, dacă trebuie să creați o redirecționare pentru întregul domeniu, aveți nevoie de un certificat SSL valid pentru domeniul redirecționat. Negocierea de criptare necesită un certificat SSL și are loc înainte ca cererea să fie procesată și răspunsul de redirecționare returnat clientului.

Dacă lucrurile s-ar fi întâmplat altfel, redirecționarea ar fi fost procesată înainte de a verifica certificatul SSL. Clientul și serverul ar fi apoi forțați să comunice folosind o conexiune HTTP obișnuită, care nu este criptată.

Dacă trebuie să redirecționați un client de pe orice pagină a domeniului https://www.example.com către alta, aveți nevoie de un certificat SSL valid instalat pe server, care se aplică întregului domeniu www.example.com.

De exemplu, pentru a redirecționa un client de la https://www.example.com la https://example.com, trebuie să aveți un certificat care să acopere ambele sau două certificate separate ( pentru fiecare gazdă respectiv).

Strategii de redirecționare HTTPS

Am analizat modul în care o redirecționare de la HTTP la HTTPS este procesată prin htaccess după negocierea SSL / TLS. De asemenea, am aflat că pentru a redirecționa clienții de pe un site sau pagină către HTTPS, aveți nevoie de un certificat SSL valid care să acopere ambele domenii. În continuare, voi vorbi despre strategiile generale pentru configurarea redirecționărilor HTTPS.

Există două tipuri de configurare a redirecționărilor cu HTTPS:

Redirecționare la nivel de server;
Redirecționare la nivel de aplicație.

Termenul server se referă la orice server care se află în fața unei aplicații web și procesează o solicitare HTTP de intrare. De exemplu, un server front-end, un server de echilibrare a încărcăturii sau o singură aplicație.

Termenul de aplicație desemnează o aplicație web, care poate fi fie la fel de simplă ca un script PHP, fie mai complexă, cum ar fi o aplicație Unicorn pe server care interpretează Ruby on Rails.

Efectuarea redirecționărilor HTTPS la nivel de server

Este de preferat să efectuați redirecționări HTTPS la nivel de server. În acest caz, serverul pe care este instalat certificatul SSL acceptă cererea HTTP criptată și returnează un răspuns de redirecționare HTTP criptat conform parametrilor de configurare, fără a se conecta la serverul de aplicație sau a executa codul aplicației.

Această abordare este mai rapidă deoarece serverul poate gestiona redirecționarea fără a interacționa cu aplicația. În același timp, configurația serverului este mai puțin flexibilă decât ceea ce se poate face folosind un limbaj de programare cu drepturi depline.
Redirecționarea htaccess HTTP către HTTPS la nivel de server este utilizată pentru redirecționarea în bloc. De exemplu, o redirecționare de la WWW la o versiune non-WWW a unui domeniu cu HTTPS (sau invers).

Următorul fragment de cod este un exemplu de configurație Nginx care setează o redirecționare de la http://example.com, http://www.example.com și https://www.example.com la https://example.com :

server ( listen 80; server_name example.com www.example.com; return 301 https://example.com$request_uri; ) server ( listen 443 ssl; server_name example.com www.example.com; # ssl configuration ssl on; certificat_ssl /path/to/certificate.crt;

Implementarea unei redirecționări la nivel de server este de preferat, dar nu este întotdeauna fezabilă, deoarece este posibil să nu aveți acces la configurația serverului. Acest lucru se referă gazduire virtuala sau platforme precum Heroku, Azure sau Google Platform.

Efectuarea unei redirecționări HTTPS la nivel de aplicație

Când nu aveți acces la configurația serverului sau logica de redirecționare este mai complexă, trebuie să gestionați redirecționarea HTTP către HTTPS la nivel de aplicație.

Această abordare este puțin mai lentă deoarece serverul trebuie să accepte cererea, să proceseze codul aplicației ( sau interacționează cu serverul de aplicații) și returnați răspunsul.

Modul în care se realizează redirecționarea la nivel de aplicație depinde de limbajul de programare și de stiva utilizată. Iată câteva exemple.

Pachetul Goland și net/http

Puteți utiliza http.Redirect.

Ruby on Rails

Puteți configura o redirecționare la nivel de router, utilizați un intermediar software Rack sau metoda redirect_to din interiorul controlerului:

constrângeri (gazdă: /www.example.com/) primesc „*”, către: redirecționare(„https://example.com”) end

PHP

Utilizați funcția de antet pentru a trimite antetul de redirecționare HTTP:

În unele cazuri, aceasta este singura abordare posibilă. De exemplu, dacă trebuie să redirecționați clienții de pe WWW către o versiune non-WWW a domeniului, de la HTTPS la Heroku sau Azure (sau invers), atunci va trebui să specificați ambele domenii într-o singură aplicație, să instalați un certificat și să procesați redirecționarea la nivel de aplicație prin condiții.

Modalități alternative de a efectua o redirecționare HTTPS

Sunt mai multe moduri alternative redirecționare de la HTTP la HTTPS.

În unele situații, nu există acces la configurația serverului, iar platforma pe care este găzduit site-ul nu permite utilizarea unui limbaj de programare. Un exemplu tipic este Amazon S3 pentru găzduirea site-urilor statice. În acest caz, trebuie să aflați dacă platforma oferă parametri de redirecționare HTTPS pe care îi puteți configura.

O altă opțiune este să utilizați o aplicație de redirecționare autonomă, independentă. De exemplu, dacă trebuie să redirecționați clienții de la https://alpha.com la https://beta.com. Apoi, pentru domeniul alpha.com în ca DNS puteți specifica un alt serviciu sau server care găzduiește beta.com. De asemenea, puteți configura o redirecționare la nivel de server sau puteți instala o aplicație care va acționa ca redirector. În acest caz, aveți nevoie și de un certificat valid pentru alpha.com, care va fi instalat acolo unde trebuie efectuată redirecționarea.

HTTP (HyperText Transfer Protocol) a fost dezvoltat ca bază În toată lumea Web.

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

Structura cererii HTTP

O solicitare HTTP constă dintr-un antet de cerere și un corp de cerere, separate printr-o linie goală. Corpul cererii poate lipsi.

Antetul cererii este format din linia principală (prima) a cererii și liniile ulterioare care clarifică cererea în linia principală. Este posibil să lipsească și rândurile ulterioare.

Interogarea pe linia principală constă din trei părți, separate prin spații:

Metodă(cu alte cuvinte, comanda HTTP):

OBŢINE- cerere document. Metoda cea mai des folosită; în HTTP/0.9, spun ei, el a fost singurul.

CAP- cerere titlu document. Diferă de GET prin faptul că este returnat doar antetul cererii cu informații despre document. Documentul în sine nu este emis.

POST- această metodă este folosită pentru a transfera date către scripturi CGI. Datele în sine apar în rândurile ulterioare ale cererii sub formă de parametri.

PUNE- plasați documentul pe server. Din cate stiu eu, este rar folosit. O cerere cu această metodă are un corp în care este transmis documentul în sine.

Resursă- acesta este calea spre fisier specific pe serverul pe care clientul dorește să-l primească (sau plasează - pentru metoda PUT). Dacă resursa este pur și simplu un fișier de citit, serverul trebuie să îl returneze în corpul răspunsului pentru această solicitare. Dacă aceasta este calea către un script CGI, atunci serverul rulează scriptul și returnează rezultatul execuției acestuia. Apropo, datorită acestei unificări de resurse, clientul este practic indiferent la ceea ce reprezintă pe server.

Versiunea protocolului-versiunea protocolului HTTP cu care funcționează programul client.

Deci, o cerere HTTP simplă ar putea arăta astfel:

Aceasta solicită fișierul rădăcină din directorul rădăcină al serverului web.

Rânduri după linia principală cererile au următorul format:

Parametru: valoare.

Așa sunt setați parametrii de solicitare. Acest lucru este opțional toate liniile de după linia de interogare principală pot lipsi; în acest caz, serverul acceptă valoarea lor implicit sau pe baza rezultatelor solicitării anterioare (când lucrează în modul Keep-Alive).

Voi enumera câțiva dintre cei mai des utilizați parametrii de solicitare HTTP:

Conexiune(conexiune) - poate lua valorile Keep-Alive and close. Keep-Alive înseamnă că după emiterea acestui document, conexiunea la server nu este întreruptă și pot fi emise mai multe solicitări. Majoritatea browserelor funcționează în modul Keep-Alive, deoarece vă permite să „descărcați” o pagină html și imagini pentru aceasta într-o singură conexiune la server. Odată setat, modul Keep-Alive este menținut până la prima eroare sau până la următoarea solicitare Connection: close este specificată în mod explicit.
close ("închidere") - conexiunea este închisă după ce răspunde la această solicitare.

User-Agent- valoarea este „codul” browserului, de exemplu:

Mozilla/4.0 (compatibil; MSIE 5.0; Windows 95; DigExt)

Accepta- o listă de tipuri de conținut acceptate de browser în ordinea preferințelor pentru un anumit browser, de exemplu pentru IE5:

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 scoate același document în formate diferite.

Valoarea acestui parametru este folosită în principal de scripturile CGI pentru a genera un răspuns adaptat pentru un anumit browser.

Referitor- URL de la care ați ajuns la această resursă.

Gazdă- numele gazdei de la care se solicită resursa. Util dacă serverul are mai multe servere virtuale sub aceeași adresă IP. În acest caz, numele server virtual determinat de acest domeniu.

Accept-Limba- limbaj suportat. Semnificativ pentru un server care poate servi același document în versiuni lingvistice diferite.

Format de răspuns HTTP

Formatul răspunsului este foarte asemănător cu formatul cererii: are, de asemenea, un antet și un corp separate printr-o linie goală.

Antetul constă, de asemenea, dintr-o linie principală și linii de parametri, dar formatul liniei principale este diferit de cel al antetului cererii.

Șirul de interogare principal este format din 3 câmpuri separate prin spații:

Versiunea protocolului- similar cu parametrul de cerere corespunzător.

Cod de eroare- denumirea de cod a „succesului” cererii. Codul 200 înseamnă „totul este normal” (OK).

Descrierea verbală a erorii- „descifrarea” codului anterior. De exemplu, pentru 200 este OK, pentru 500 - Server intern Eroare.

Cei mai comuni parametri de răspuns http:

Conexiune- similar cu parametrul de cerere corespunzător.
Dacă serverul nu acceptă Keep-Alive (există), atunci valoarea Connection din răspuns este întotdeauna apropiată.

Prin urmare, în opinia mea, tactica corectă de browser este următoarea:
1. emite Conexiune: Keep-Alive în cerere;
2. Starea conexiunii poate fi evaluată după câmpul Conexiune din răspuns.

Tip de conținut("tipul de conținut") - conține o desemnare a tipului de conținut al răspunsului.

În funcție de valoarea Content-Type, browserul interpretează răspunsul ca o pagină HTML, imagine gif sau jpeg, ca fișier pentru a fi salvat pe disc, sau orice altceva, și ia măsurile corespunzătoare. Valoarea Content-Type pentru browser este aceeași cu valoarea extensiei de fișier pentru Windows.

Unele tipuri de conținut:

text/html - text în format HTML (pagina web);
text/plain - text simplu (similar cu Notepad);
imagine/jpeg - imagine în format JPEG;
imagine/gif - la fel, în format GIF;
application/octet-stream - un flux de „octeți” (adică doar octeți) pentru a scrie pe disc.

De fapt, există mult mai multe tipuri de conținut.

Conținut-Lungime(„lungimea conținutului”) - lungimea conținutului răspunsului în octeți.

Ultima modificare("Modificat ultima dată") - data ultima schimbare document.

Eroarea 500 înseamnă că serverul site-ului web pe care încercați să îl accesați a suferit o defecțiune internă a sistemului. Rezultă că fie proprietarii site-ului, fie furnizorul de internet îl pot repara. Dar există încă unele acțiuni din partea utilizatorului obișnuit care pot afecta și remedia eroarea HTTP ERROR 500.

Codul de stare HTTP 500 înseamnă că există o problemă cu configurația serverului web sau înseamnă că una dintre componentele importante pur și simplu a eșuat. Cu această eroare, tot software-ul este operațional, dar are critici probleme interne, care provoacă un conflict în accesarea serverului și, de asemenea, îl împiedică să funcționeze corect.

Apariția erorii 500 în browser poate fi cauzată de din diferite motive. Prin urmare, enumeram mai jos toate modalitățile de a o elimina:

Eroare 500 browser Google Chrome

Cauzele ERORII HTTP 500

Unul dintre motive este instalare incorectă drepturi de acces la scripturi, motiv pentru care sunt blocate. Drepturile pot fi configurate pentru orice utilizator, deși acest lucru nu este recomandat din motive de securitate. Pentru a configura drepturile, puteți utiliza manager de fișiere FileZilla de la dezvoltatorul browserului FireFox.

În primul rând, trebuie să acordați atenție setărilor drepturilor de acces. Fiecare tip de element trebuie să i se acorde atenție separat. Pentru fișiere, valoarea trebuie specificată - 644, pentru foldere - 755 și pentru scripturi - 600. Este recomandabil ca o singură persoană să creeze un cont și să nu permită nimănui să obțină astfel de drepturi.

Setări pentru drepturile de acces

Durata exorbitantă a execuției scriptului

Pe lângă limitările de rulare impuse de limbaj Programare PHP, astfel de restricții sunt impuse scenariului și din exterior sisteme server. Eroarea apare de obicei într-un moment în care scriptul nu și-a finalizat activitatea într-un timp limitat. În acest caz, lucrarea sa va fi finalizată neterminată.

Pentru a evita eroarea HTTP ERROR 500 și pentru a accelera scriptul, puteți utiliza servicii speciale pentru a optimiza performanța secțiunilor lente ale scriptului. Când utilizați VPS sau servere dedicate, puteți modifica timpul de expirare a serverului. Astfel de manipulări nu pot fi efectuate folosind găzduirea virtuală decât dacă se obține un acord de la suportul tehnic.

Probleme cu fișierul .htaccess

Sintaxă acest dosar are o anumită structură care nu poate fi schimbată sau încălcată. Dacă una dintre directivele sale are erori, atunci acest lucru va duce cu siguranță la eroare HTTP EROARE 500. Este posibil ca directiva să nu aibă erori sau conflicte de fișiere, dar nu este acceptată.

Găsiți acest fișier „.htaccess” în rădăcina site-ului. Apoi copiați-l în alt loc pentru a nu-l pierde. Acum eliminați-l de pe site. Dacă totul cade la locul său, atunci problema este în acest fișier. În acest caz, luați fișierul din noua distribuție a CMS (Content Management System).

File.htaccess

Puteți vizualiza informații despre erorile de server. Toate sunt înscrise dosar special sub numele – „error.log”. Prin deschiderea acestuia, puteți găsi informații despre care dintre directivele dvs. este în conflict. De exemplu, „Comanda nevalidă „Prive” ne spune că directiva „Preț” conține o greșeală de scriere, corectarea „v” la „c” va rezolva această problemă.

Codul are nevoie de mai multă memorie

Sistemul de gazduire virtuala controleaza strict memoria alocata pentru nevoi diverse scripturi si programe. În acest fel, serverele previn supraîncărcarea memoriei. Când din anumite motive eronate codul începe să consume mai multa memorie Apare eroarea 500.

Memorie pentru scripturi

Pentru a repara problema asemanatoare, trebuie să identificați erorile din cod care fac ca acesta să nu funcționeze corect. Dacă totul este în regulă cu codul, contactați asistența tehnică. Memoria poate fi mărită dacă este necesar plătind suplimentar pentru a extinde planul tarifar.