Scaparea de eroarea „http” la încărcarea imaginilor în WordPress. Scurtă descriere a protocolului HTTP

Î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 căi 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:

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 se stabilește o conexiune prin protocolul HTTPS, la modul în care sunt procesate cererile HTTP și la configurarea redirecționărilor 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:

1. Î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ă»;
2. Î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);
3. Î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). În ceea ce privește conținutul și structura, 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 de criptare 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ă din domeniul 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:

1. Redirecționare la nivel de server;
2. 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 ( ascultă 80; server_name example.com www.example.com; return 301 https://example.com$request_uri; ) server (ascultă 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ă. Aici sunt cateva exemple.

Pachetul Goland și net/http

Puteți utiliza http.Redirect.

Ruby pe șine

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 câteva 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.

Vizitatorii site-ului dvs. (magazin online sau alt tip de prelucrare a datelor cu caracter personal) au adesea îndoieli: pot avea încredere în această resursă?

ÎN în 1994, băieții de la Netscape Communications s-au ocupat în special de utilizatorii suspecti rețea mondialăși a venit cu un lucru magic - HTTPS.

Ce este HTTPS?

HTTPS (HyperText Transfer Protocol Secure) - extensie Protocolul HTTP, pentru a sprijini criptarea pentru a proteja și îmbunătăți securitatea datelor personale ale utilizatorilor. Spre deosebire de HTTP cu portul TCP 80, HTTPS este implicit la portul TCP 443.

Da, da, este destul de complicat și nu foarte clar..

Mai exact într-un limbaj simplu,protocolul criptează datele sensibile introduse de utilizator pe site(de exemplu, datele pașaportului, numărul cardului etc.), iar apoi aceste informații sunt transmise prin canale deschise (furnizor de internet, gazde) și merg la serviciul dorit.

De exemplu, un utilizator Sberbank.Online a trimis date către format text(text „123”) printr-un site cu https. La aceste date este atașată o cheie pe serverul expeditorului (???), care criptează datele introduse. Astfel, datele trimise nu pot fi interceptate folosind programe terțe.

Datele din protocolul HTTPS sunt transmise prin criptografic Protocoale SSL sau TLS. Acestea sunt protocoalele acceptă o conexiune criptată între server și browserul utilizatorului.

Ce cred motoarele de căutare despre https?

Google este cu siguranță în favoarea criptării traficului. Și în versiunea actualizată 56 Google Chrome site-urile sunt deja marcate ca de încredere (pe https) și nede încredere (pe http):

În același timp, este corect să rețineți că trecerea la un protocol securizat este departe de factorul principal de clasare. Cu toate acestea, nu există nicio îndoială că ponderea https va crește doar în viitor.

Cât despre Yandex - informatii oficiale nu în această chestiune, dar toate serviciile companiei au trecut deja la un protocol securizat.

Este evident că pe acest moment trecerea la un protocol securizat nu va muta site-ul dvs. în mai multe poziții în rezultatele căutării și, din punct de vedere al clasamentului, aceasta este mai degrabă o lucrare pentru viitor. Cu toate acestea, trebuie să înțelegeți asta principalul avantaj al protocolului https este securitatea datelor vizitatorilor dvs. Prin urmare, pentru a crește încrederea în site-ul dvs. și în companie în ansamblu, trecerea la un protocol securizat va fi extrem de utilă.

3 etape ale tranziției site-ului de la http la https

Pasul 1: Certificat de securitate SSL

Achiziționați și configurați un certificat de securitate (SSL) emis de o autoritate de certificare

SSL (Secure Socket Layer) este un certificat individual semnatura digitala domeniul dvs. Puteți alege oricare dintre 5 tipuri de certificate de securitate:

1. Autosemnat

Din nume este clar că orice utilizator îl poate crea pe un domeniu sau pe o adresă IP, adică. nu există nicio confirmare de la autoritatea de certificare aici, emise și semnate de către utilizator însuși.

• gratuit;
• poate fi creat de un număr nelimitat de ori;
• va fi o notificare când comutați, nu este autentică

• Are Pe termen scurt Servicii;
• este posibil ca unele browsere să nu accepte și pagina să nu se deschidă;
• nu se aplică subdomeniilor;
• nu acceptă adrese URL în chirilic.

1. Validarea domeniului

Una dintre cele mai comune certificate de nivel de intrare.

• gata în câteva ore
• potrivit pentru majoritatea site-urilor
• comun, ușor accesibil
• cost scăzut

• emis pentru un domeniu (dacă schimbați va trebui să cumpărați din nou)
• valabil de la unu la 3 ani
• date personale minime de pe site
• nu acceptă adrese URL în chirilic

La nivel de afaceri, mai sigur, certificatul este universal și este cel mai des folosit de magazinele online, site-uri de servicii și portaluri. Eliberat exclusiv entitati legale , in timpul inregistrarii se verifica domeniul si organizarea.

• nivel ridicat de protecție
• Perioada de emitere de la 3 la 10 zile lucratoare
• costul este mai scump

Certificate statut înaltpentru mediu și companii mari este folositbănci, sisteme de plată, servicii mari, agenții guvernamentale etc.

• cea mai înaltă clasă de protecție dintre certificatele SSL
• se adaugă ponderea și autoritatea resursei
• preț mare

1. Wildcsrd (subdomeniu)

Supliment pentru certificate, protecția tuturor subdomeniilor directe specificate

Pasul 2: configurarea datelor în sistemele de analiză

• Yandex.Webmaster. Este necesar să specificați noua directivă gazdă pe vechiul domeniu și să specificați oglinda principală. Unotifică motorul de căutare despre noul protocol.
• Yandex.Webmaster - Indexare - Relocare site.
• Numai după ce modificările corespunzătoare apar în Yandex.Webmaster configurarea redirecționării 301(important doar după ce apare o notificare că site-ul este disponibil pe https, configurați o redirecționare 301)
• În Google Analytics schimbați reprezentantul din http // în https

Pasul 3: Actualizați linkurile interne

Linkurile vechi, din păcate, nu vor funcționa, modifica link-urile din continut, in Stiluri CSS, în scripturi, șabloane pe https. Dacă http//site.ru va deveni https//site.ru. Există un numar mare de utilitare, plugin-uri pentru înlocuirea automată a legăturilor vechi.

Pe WP, de exemplu, puteți utiliza pluginul Velvet Blues Update URLs

Actualizarea imaginilor(daca este necesar). Vă recomandăm să introduceți atât linkurile, cât și calea către imagini fără a specifica un domeniu, dar în formatul /uplots/photo/sertifikat https)

Harta site-ului, dosar. Verificăm dacă este specificat doar protocolul https.

Rezuma:

Pentru a îmbunătăți încrederea utilizatorilor și a motoarelor de căutare în site-ul dvs. prin mutarea domeniului dvs. la https, trebuie să implementați din punct de vedere tehnic trei lucruri:

1. Obțineți și configurați un certificat de securitate (SSL) adecvat pentru site-ul dvs.
2. A clarifica motoare de căutare că site-ul dvs. și-a schimbat adresa (mutat de la http la https).
3. Efectuați optimizarea internă a site-ului ținând cont de noul nume de domeniu.

Întâmpinați probleme la mutarea de la http la https? Sau vrei sa le eviti? Comandați un audit SEO de la noi și vă vom ajuta să vă schimbați domeniul.

Abonați-vă și urmăriți lansarea de noi articole în nostru

ÎN retea globala escrocii și hackerii încearcă să fure informații personale în fiecare zi. În trecut, phishingul era considerată cea mai populară metodă de furt. Atacatorul înlocuiește site-ul inițial, iar datele de la utilizator cad în mâinile acestuia (parole, numere de card, mesaje personale etc.). Pentru a rezolva această problemă, am creat o conexiune HTTPS securizată. Prin urmare, administratorii site-ului sunt adesea preocupați de întrebarea cum să creeze și să configureze o conexiune https securizată.

și de ce este nevoie

Înainte de a vă muta site-ul la o conexiune HTTPS, ar trebui să înțelegeți ce este și cum funcționează. HTTPS este o versiune securizată a protocolului HTTP (Hypertext transmite datele necesare pentru ca paginile să funcționeze (numele browserului, rezoluția ecranului, prezența Cookie-urilor etc.).

HTTP este folosit de dezvoltatori pentru a trimite și primi variabile fără acest protocol, site-urile web nu vor putea funcționa. Toate fișierele transferate prin HTTP puteau fi interceptate anterior cu ușurință folosind un site web fals (phishing).

Anterior, parolele, datele de conectare, numerele cardurilor, mesajele secrete și alte lucruri erau furate folosind o metodă similară. Informații importante. Pentru a proteja utilizatorii de phishing, au fost inventate certificate SSL, iar autenticitatea lor a fost verificată înainte de a face schimb de informații.

HTTPS trebuie utilizat pe site-urile bancare sau magazine online. Dacă aceste resurse nu sunt disponibile, browserul va refuza conexiunea și va fi afișat un avertisment de pericol. Ca urmare, site-ul va pierde încrederea utilizatorilor săi.

Ce este un certificat SSL/TLS

Principala inovație în HTTPS este utilizarea obligatorie a unui certificat SSL digital. Acesta este un fișier în care sunt stocate toate informațiile (adresa IP a serverului, țara site-ului, e-mailul proprietarului etc.). Documentul digital este criptat pe serverul site-ului și pe serverul autorității de certificare (GoDaddy, Comodo etc.). La fiecare conexiune, aceste fișiere sunt comparate, iar dacă sunt aceleași, conexiunea continuă. În caz contrar, apare un avertisment de securitate.

Mulți cititori nu știu cum să facă o conexiune https securizată. Primul pas este să obțineți un certificat SSL de la o autoritate de încredere. Exista tipuri diferite aceste documente:

• DV - confirmați doar domeniul (pentru site-uri și bloguri mici).
• OV - domeniul și organizarea sunt verificate.
• EV - verificare extinsă (va apărea dungă verdeși o blocare în browser).

Opțiunea EV este considerată cea mai preferată pentru magazine și bănci. Urmează clarificări suplimentare sub forma:

• SGC (suporta browsere mai vechi).
• Wildcard (suport pentru subdomeniu).
• SAN (domenii alternative într-un singur certificat).
• IDN (suport domenii nationale www).

Pentru majoritatea site-urilor, este suficient să utilizați un certificat DV SSL. Este ieftin și garantează protecție împotriva phishingului.

Cum se transferă un site la o conexiune securizată

Din ce în ce mai mulți proprietari afaceri online Sunt interesat de cum să creez o conexiune https securizată. Pentru a face acest lucru, va trebui să faceți câteva modificări codul programului pagini. Cel mai important lucru este să scrieți o regulă suplimentară în fișierul .htaccess. Stochează cod pentru configurarea serverului web Apache.

Majoritatea furnizorilor de găzduire vă permit să configurați un certificat SSL pentru server prin intermediul panoului de control. Consultați furnizorul dvs. de servicii pentru detalii despre cum să faceți acest lucru. Întregul proces de traducere a site-ului web poate fi împărțit în următoarele etape:

1. Obținerea unui certificat SSL.
2. Instalarea unui certificat pe server.
3. Modificarea linkurilor interne ale site-ului.
4. Configurarea redirecționării către portul 301.
5. Schimbarea gazdelor în robots.txt.

Dacă utilizați găzduiri plătite, cum ar fi beget, atunci contactați serviciul de asistență cu un certificat și toate acțiunile ulterioare vor fi efectuate de lucrătorii de servicii. Cel mai dificil pas în a răspunde la întrebarea cum să faci conexiune https, este o setare, deoarece majoritatea scripturilor nu ajută.

Obținerea unui certificat și instalarea acestuia pe server

Acum că ne-am dat seama teoretic cum să facem o conexiune https, să trecem la acțiune. Primul pas este să obțineți un certificat SSL de la unul dintre centrele de încredere. Pe Internet puteți găsi multe opțiuni diferite în diferite gama de prețuri. În prezent, a primi document gratuit sunt 2 centre:

• WoSign.
• Startssl.

Alte servicii necesită plată. Suma depinde de tipul de certificat și de acesta caracteristici suplimentare(multi-domeniu, suport pentru browsere mai vechi etc.). Autorități de certificare:

• Reg.ru.
• Hai tăticu.
• Gazdă.
• Symantec.
• Comodo.
• GlobalSign.
• Thawte.

În plus, unii furnizori de găzduire oferă utilizatorilor lor certificate SSL la achiziționarea unui anumit plan tarifar. Site-ul web de certificare descrie în detaliu acțiunile necesare. Dar întreaga procedură constă din următorii pași:

• generarea unei cereri CSR;
• completarea e-mailului site-ului (admin@[adresa site-ului]);
• completarea informațiilor despre proprietarul domeniului (pentru documentele EV și OV).

Solicitarea CSR include date generale pentru verificare (organizație, oraș, regiune, țară). După completarea informațiilor, utilizatorul primește 2 coduri ( Cheia secretăși codul CSR), asigurați-vă că le salvați în document separat. Trimite acest cod pentru a primi un certificat SSL și pentru a aștepta ca acesta să fie emis de la centru.

Acum accesați site-ul web de găzduire și găsiți secțiunea „Certificat SSL” sau contactați asistența. Va trebui să furnizați informații despre codul CSR, cheie privată si certificat. Nu uitați să activați suportul SSL în panoul dvs. de găzduire.

Cum se creează permanent o conexiune https

După plasarea fișierului pe server, trebuie să efectuați configurarea internă a site-ului. Va trebui să configurați o redirecționare și să schimbați totul link-uri interne de la absolut la relativ.

Adică, în loc de http://site.ru/img/bg.png instalați: //site.ru/img/bg.png.

Trebuie să eliminăm HTTP din numele linkurilor. Dacă aveți dubii, sunați la un programator WEB sau un freelancer, acesta îl va configura rapid. Puteți căuta link-uri prin editorul de cod în fiecare fișier sau puteți găsi toate informațiile prin căutarea în PhpMyAdmin.

După configurarea legăturilor, trebuie să informați motoarele de căutare despre schimbare. Deschideți fișierul robots.txt și în linia Gazdă: înlocuiți HTTP cu HTTPS.

În loc de http://example.ru, introduceți: https://example.ru.

După modificarea fișierului de căutare, configurați automat Înainte actiunile urmatoare verifica disponibilitatea site-ului la Protocolul HTTPS e. Dacă toate acțiunile anterioare au fost efectuate corect, atunci nu ar trebui să apară erori.

Pentru a redirecționa automat către conexiune sigură lipiți acest script în fișierul .htacess, îi ajută pe unii:

RewriteEngine activat

RewriteCond %(HTTP:X-Forwarded-Proto) !https

RewriteRule ^ https://%(HTTP_HOST)%(REQUEST_URI)

Dar, în majoritatea cazurilor, această metodă nu funcționează. În aceste situații, contactați administratorul dvs. de găzduire, el va putea face setări corecte. Redirecționarea va începe să funcționeze după repornirea serverului, de obicei în 24 de ore.

În plus, va trebui să modificați setările din panoul de webmasteri Yandex sau Google. În secțiunea de setări de indexare, va trebui să mergeți la elementul oglindă principal și să instalați HTTPS. În plus, va trebui să transferați:

• sitemap.xml;
• excepții URL;
• geolocalizare;
• link-uri Disawov Tool pentru Google.

După aceasta, trebuie doar să așteptați ca reindexarea să se termine. În această perioadă, activitatea pe site va scădea, dar apoi totul se va stabiliza.

conexiune în WordPress

Blogurile și portalurile moderne rulează în mare parte pe WordPress pentru a trece la https, vor trebui să efectueze aceiași pași (obține un certificat, schimbă link-uri etc.); Dar au un set de plugin-uri încorporate care vor efectua toate acțiunile pentru proprietar:

• redirecționare HTTPS ușoară;
• HTTPS (SSL).

Primul înlocuiește link-urile, iar al doilea vă permite să specificați un certificat SSL. De asemenea, accesați Setări->General. Aici trebuie să schimbați adresa URL și să specificați protocolul HTTPS. Asigurați-vă că paginile vechi au și o conexiune sigură. După modificarea legăturilor, configurați redirecționarea și modificați fișierul robots.txt.

Nu ar trebui să mai existe întrebări despre cum să faceți o conexiune https pe un site web. Pe majoritatea site-urilor de găzduire, pentru a activa modul de protecție, trebuie doar să scrieți la asistența tehnică. Ei vor numi un specialist, iar el va face el însuși configurarea.

HTTP (HyperText Transfer Protocol) a fost dezvoltat ca bază La nivel mondial Web.

Protocolul HTTP funcționează după cum urmează: programul client stabilește o conexiune TCP cu serverul ( Cameră 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 solicitare ș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ă 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.

A 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 urmatorul 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.

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

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

Accept- 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 unui 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 în regulă” (OK).

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

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 Connection: Keep-Alive în cerere;
2. Starea conexiunii poate fi evaluată după câmpul Conexiune din răspuns.

Tipul 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ă mai multe tipuri de conținut.

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

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

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ă unele informații despre selectarea corectă a resursei.
• 301 - Mutat permanent (resursa mutată în bază permanentă) - 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 invalida) - 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 resursă 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 Eroare internă a server-ului ( 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 sunt acceptate(versiunea HTTP neacceptată) - serverul nu acceptă versiunea protocolului HTTP utilizată în cerere.