.Fișierele htaccess sunt folosite pentru a configura Apache, precum și o serie de alte servere web. In ciuda .htaccess
extensia de tip fișier, acestea sunt doar fișiere text care pot fi editate folosind orice editor de text. În acest articol, vom examina ceea ce sunt și cum le puteți utiliza în proiectele dvs..
Rețineți că fișierele .htaccess nu funcționează pe sistemele bazate pe Windows, deși pot fi editate și încărcate pe un server web compatibil, iar în sistemele bazate pe Linux ele sunt ascunse în mod implicit.
Pentru a lucra cu fișierele htaccess la nivel local, pentru a vedea cum funcționează și pentru a juca în general cu ei, putem folosi XAMPP (sau MAMP) pe Mac - un pachet care instalează și configurează Apache, PHP și MySQL. Pentru a edita aceste fișiere .htaccess pe Mac, ar trebui să folosim un editor de text care permite deschiderea de fișiere ascunse, cum ar fi TextWrangler.
Un fișier .htaccess urmează același format ca fișierul de configurare principal al lui Apache: httpd.conf
. Multe dintre setările care pot fi configurate utilizând fișierul de configurare principal pot fi, de asemenea, configurate împreună cu acestea, și invers.
O setare configurată într-un fișier .htaccess va suprascrie aceeași setare din fișierul de configurare principal pentru directorul care conține fișierul, precum și toate subdirectoarele sale.
Acestea sunt uneori denumite fișiere de configurare dinamice, deoarece sunt citite de server la fiecare cerere în directorul în care sunt conținute. Aceasta înseamnă că orice modificare a unui fișier .htaccess va avea efect imediat, fără a necesita repornirea serverului, spre deosebire de modificările aduse fișierului de configurare global. De asemenea, înseamnă că plătiți o ușoară performanță pentru utilizarea acestora, dar acestea pot fi utile atunci când nu aveți acces la fișierul de configurare principal al serverului.
Deci, acum știm cu toții ce fișiere .htaccess sunt, cum sunt editate și lucrate cu ele și unele dintre argumentele lor pro și contra, să ne uităm la modul în care pot fi folosite și la unele lucruri interesante pe care le pot face.
O utilizare populară a fișierelor .htaccess este de a efectua redirecționări sau de a rescrie URL-uri. Acest lucru poate ajuta SEO în urma unei schimbări a numelui de domeniu sau a unei reorganizări a structurii fișierelor sau poate face o adresă URL inestetică mult mai prietenoasă și mai memorabilă.
O redirecționare poate fi la fel de simplă:
Redirecționați 301 ^ vechi \ .html $ http: //localhost/new.html
Aceasta stabilește codul de stare HTTP la 301 (mutat permanent) și redirecționează toate cererile la old.html
în mod transparent la new.html
. Utilizăm o expresie regulată pentru a se potrivi URL-ului pentru a redirecționa, ceea ce ne oferă un grad avansat de control pentru a ne asigura că numai adresa URL corectă este potrivită pentru redirecționare, dar adaugă complexitatea configurației și administrării acesteia. Se solicită adresa URL completă a resurselor redirecționate către.
O regulă de rescriere poate fi la fel de simplă:
RewriteEngine pe RewriteRule ^ old \ .html $ new.html
În acest exemplu, oferim doar o redirecționare simplă a fișierelor dintr-un fișier în altul, care va fi de asemenea efectuată în mod transparent, fără a schimba ceea ce este afișat în bara de adrese. Prima directivă, RewriteEngine pe
, asigură pur și simplu că motorul de rescriere este activat.
Pentru a actualiza ceea ce este afișat în bara de adrese a browserului vizitatorului, putem folosi funcția R
steag la sfârșitul RewriteRule
de exemplu.
RewriteRule ^ vechi \ .html $ http: //hostname/new.html [r = 301]
r
flagul provoacă o redirecționare externă, motiv pentru care este indicată adresa URL completă (exemplu URL aici) pe noua pagină. De asemenea, putem specifica codul de stare când folosim pavilionul. Acest lucru face ca bara de adrese să fie actualizată în browser-ul vizitatorului.
Una dintre posibilele utilizări pentru rescrierea URL-urilor pe care le-am dat la începutul acestei secțiuni a fost aceea de a face URL-urile inestetice (care conțin date din șirul de interogări) mai prietenoase vizitatorilor și motoarelor de căutare. Să vedem acest lucru în acțiune acum:
RewriteRule ^ products / ([^ /] +) / ([^ /] +) / ([^ /] +) product.php? Cat = $ 1 & brand = $ 2 & prod = $ 3
Această regulă va permite vizitatorilor să utilizeze un URL de genul Produse / platane / Tehnica / sl1210, și să o transforme product.php? cat = platane &$ de 1
, $ cu 2
și $ cu 3
respectiv. [^ /]+
clasa de caractere în paranteze înseamnă potrivi orice caracter, cu excepția unei loviri înainte de 1 sau de mai multe ori.
În practică, rescrierea URL-urilor poate fi (și de obicei este) mult mai complexă și poate realiza lucruri mult mai mari decât aceasta. Rescrierea resurselor URL este mai bine explicată folosind tutoriale întregi, astfel încât nu le vom examina în detaliu aici.
Nu este bine să afișați pagina implicită 404. Multe site-uri folosesc ocazia oferită de un fișier care nu a găsit eroare de a injecta un pic de umor în site-ul lor, dar cel puțin, oamenii se așteaptă ca pagina 404 a unui site să corespundă cel puțin stilului și temei oricărei alte pagini a site-ului.
Foarte strâns legată de rescrierea adreselor URL, este ușor să difuzați o pagină de eroare personalizată în locul paginii standard 404 cu un fișier .htaccess:
ErrorDocument 404 "/404.html"
Asta e tot ce avem nevoie; ori de câte ori apare o eroare 404, este afișată pagina specificată. Putem configura paginile pentru a fi afișate și pentru multe alte erori ale serverului.
Folosind fișierele .htaccess, putem activa protecția prin parolă a oricărui fișier sau director, tuturor utilizatorilor sau pe baza unor domenii sau domenii IP. Aceasta este, după toate acestea, una dintre principalele lor utilizări. Pentru a împiedica accesul la un întreg director, am crea un simplu fișier .htaccess, care conține următorul cod:
AuthName "Este necesar un nume de utilizator și o parolă" AuthUserFile /path/to/.htpasswd Aveți nevoie de autentificare AuthType Basic
Acest fișier ar trebui apoi salvat în directorul pe care dorim să îl protejăm. AuthName
directive specifică mesajul de afișat în caseta de dialog username / password, AuthUserFile
ar trebui să fie calea către fișierul .htpasswd. necesita
directiva specifică faptul că numai utilizatorii autentificați pot accesa fișierul protejat în timp ce AuthType
este setat sa De bază
.
Pentru a proteja un anumit fișier, putem împacheta codul de mai sus într-un
care specifică fișierul protejat:
AuthName "Este necesar un nume de utilizator și o parolă" AuthUserFile /path/to/.htpasswd Aveți nevoie de autentificare AuthType Basic
De asemenea, avem nevoie de un fișier .htpasswd pentru aceste tipuri de autentificare, care conține o listă de nume de utilizator și parole criptate separate de colon, necesare pentru a accesa resursele protejate. Acest fișier ar trebui salvat într-un director care nu este accesibil pentru web. Există o serie de servicii care pot fi utilizate pentru a genera automat aceste fișiere, deoarece parola ar trebui să fie stocată în formă criptată.
O altă utilizare a fișierelor .htaccess este blocarea rapidă și ușoară a tuturor cererilor de la o adresă IP sau un agent utilizator. Pentru a bloca o anumită adresă IP, pur și simplu adăugați următoarele direcții în fișierul .htaccess:
ordonați permiteți, respingeți respingerea de la 192.168.0.1 permiteți tuturor
Ordin
directive îi spune lui Apache în ce ordine să evalueze directivele allow / deny. În acest caz, permite
este evaluat mai întâi, atunci nega
. permiteți tuturor
directiva este evaluată mai întâi (chiar dacă apare după nega
) și toate IP-urile sunt permise, atunci dacă IP-ul clientului se potrivește cu cel specificat în nega
directivă, accesul este interzis. Acest lucru permite tuturor, cu excepția IP-ului specificat. Rețineți că putem, de asemenea, să refuzăm accesul la blocuri IP întregi furnizând o IP mai scurtă, de ex. 192.168.
Pentru a respinge cererile bazate pe agentul utilizator, am putea face acest lucru:
RewriteCond% HTTP_USER_AGENT ^ OrangeSpider RewriteRule ^ (. *) $ Http: //% REMOTE_ADDR / $ [r = 301, l]
În acest exemplu, orice client cu a HTTP_USER_AGENT
șir începând cu OrangeSpider
(un bot rău) este redirecționat înapoi la adresa de la care a provenit. Expresia obișnuită corespunde oricărui singur caracter (.)
zero sau de mai multe ori (*)
și redirecționează către % REMOTE_ADDR
variabilă de mediu. L
steagul pe care l-am folosit aici instruiește Apache să trateze acest meci ca fiind ultima regulă, astfel încât nu va procesa niciun altul înainte de a efectua rescrierea.
Odată cu controlul asupra modului în care serverul răspunde anumitor solicitări, putem face lucruri și în browser-ul vizitatorului, cum ar fi forțarea IE să facă pagini utilizând un motor de randare specific. De exemplu, putem folosi mod_headers
modul, dacă este prezent, pentru a seta X-UA-Compatibil
antet:
Antet set X-UA-Compatibil "IE = Edge"
Adăugarea acestei linii la un fișier .htaccess va instrui IE să utilizeze cel mai înalt mod de redare disponibil. Așa cum sa demonstrat și în Boogleplate HTML5, putem evita și setarea acestui antet pe fișierele care nu o cer, utilizând a
Header unset X-UA-compatibil
Caching-ul este ușor de configurat și poate face încărcarea site-ului dvs. mai rapidă.
Caching-ul este ușor de configurat și poate face încărcarea site-ului dvs. mai rapidă. - Nuff a spus! Prin setarea unei date de expirare a viitorului pe termen lung asupra elementelor site-urilor care nu se schimbă foarte des, putem împiedica browserul să solicite resurse neschimbate la fiecare solicitare.
Dacă rulați site-ul dvs. prin Google PageSpeed sau YSlow de la Yahoo și primiți mesajul despre setarea antetelor de expirare de departe-viitor, acesta este modul în care îl rezolvați:
ExpiresByType image / jpg "acces plus 1 lună" ExpiresByType image / jpg "acces plus 1 lună" ExpiresByType image / jpg "acces plus 1 lună" ExpiresByType video / ogg "acces plus 1 lună de acces "ExpiresByType audio / ogg" plus 1 lună "ExpiresByType video / mp4" acces plus 1 lună "ExpiresByType video / web" acces plus 1 lună "
Puteți adăuga altele ExpiresByType
direcții pentru orice conținut care este afișat în instrumentul de performanță pe care îl utilizați sau orice altceva pe care doriți să controlați cache-ul. Prima directivă, ExpiresActiv pe
, asigură pur și simplu generarea anteturilor Expires este activată. Aceste directive depind de Apache având mod_expires modul încărcat.
Un alt avertisment pe care îl putem obține într-un verificator de performanță se referă la activarea compresiei și acest lucru este și ceva pe care îl putem rezolva pur și simplu prin actualizarea fișierului .htaccess:
FilterDeclare COMPRESS FilterProvider COMPRESS DEFLATE resp = Tip de conținut $ text / html FilterProvider COMPRESS DEFLATE resp = Tip de conținut $ text / css FilterProvider COMPRESS DEFLATE resp = Tip de conținut $ text / javascript FilterChain COMPRESS FiltruProtocol COMPRESS DEFLATE schimbare = da; byteranges = nu
Această schemă de compresie funcționează pe versiunile mai noi ale Apache (2.1+) folosind mod_filter modul. Utilizează DEZUMFLA
algoritmul de compresie pentru a comprima conținutul bazat pe tipul de conținut al răspunsului, în acest caz specificăm text / html
, text / css
și text / javascript
(care vor fi probabil tipurile de fișiere marcate în PageSpeed / Yslow oricum).
În exemplul de mai sus începem prin declararea filtrului pe care dorim să îl folosim în acest caz COMPRIMA
, folosind FilterDeclare
directivă. Apoi listați tipurile de conținut pe care dorim să le folosim. filterChain
directiva apoi instruiește serverul să construiască un lanț de filtrare bazat pe FilterProvider
directivele pe care le-am enumerat. FilterProtocol
directiva ne permite să specificăm opțiunile care se aplică lanțului de filtrare ori de câte ori este rulat, opțiunile pe care trebuie să le folosim sunt schimbare = da
(conținutul poate fi modificat de filtru (în acest caz, comprimat)) și byteranges = no
(filtrul trebuie să fie aplicat numai fișierelor complete).
În versiunile mai vechi ale Apache, mod_deflate modulul este utilizat pentru a configura compresia DEFLATE. Avem un control mai redus asupra felului în care conținutul este filtrat în acest caz, dar directivele sunt mai simple:
SetOutputFilter DEFLATE AddOutputFilterByType DEFLARE text / html text / css text / javascript
În acest caz, am setat doar algoritmul de compresie folosind SetOutputFilter
directivă și apoi specificați tipurile de conținut pe care dorim să le comprimăm folosind AddOutputFilterByType
directivă.
De obicei, serverul dvs. web va folosi unul dintre aceste module în funcție de versiunea Apache utilizată. În general, veți ști acest lucru în prealabil, dar dacă creați un fișier .htaccess generic pe care îl puteți utiliza pe o varietate de site-uri sau pe care îl puteți împărtăși altor persoane și, prin urmare, nu știți care module pot fi utilizate, este posibil să doriți să utilizați ambele blocuri de cod de mai sus
directivele astfel încât modulul corect să fie utilizat și serverul nu aruncă o eroare de 500 dacă încercăm să configuram un modul care nu este inclus. Ar trebui să știți că este, de asemenea, relativ obișnuit pentru gazde care rulează un număr mare de site-uri dintr-o singură casetă pentru a dezactiva compresia, deoarece există o mică performanță a CPU-ului pentru compresie pe server.
Am analizat unele dintre cele mai frecvente utilizări ale fișierelor .htaccess și am analizat modul în care putem realiza anumite sarcini care, în calitate de constructori / administratori de site-uri web, sunt de interes deosebit pentru noi. Ca și în cazul oricărui tutorial introductiv de această natură, subiectele pe care le-am abordat sunt prezentate ca introduceri la un anumit subiect. Există multe alte opțiuni și configurații decât am putut să le analizăm, așadar aș recomanda cu insistență citirea în continuare a oricărui subiect care prezintă un interes deosebit.