Administrare server open source

Platforma de hosting cu software liber, gratuit, open source.

Serverul web Apache ofera webmasterilor posibilitatea de a modifica headerele HTTP utilizand modulul mod_headers. Modulul e folosit pentru a specifica valori pentru unele headere, cum ar fi Cache-Control, sau pentru a seta headere personalizate. De asemenea Apache ofera si o metoda de a seta timpul de viata in cache a unei resurse – imagine, text, script css extern etc. Timpul de expirare e setat folosind modulul mod_expires.

In mod implicit un browser stie sa citeasca headerele transmise de mod_headers si mod_expires si sa isi formeze un cache in functie de valorile primite. In mod implicit cache-ul este foarte mic sau chiar zero. Folosind mod_headers si mod_expires putem determina browserul sa pastreze unele resurse pentr mai mult timp. De exemplu, in cazul imaginilor putem pune ca timp de expirare o saptamana pentru ca, pe majoritatea site-urilor, imaginile nu sunt inlocuite decat foarte rar iar daca imaginile vor fi preluate din cache la urmatoarea accesare a site-ului, pe langa o viteza de incarcare considerabil imbunatatita, solicitarea serverului web va scadea ceea ce in cazul site-urilor cu trafic mare se simte.

Modulul mod_headers ne este de ajutor in cazul cache-ului daca rescriem headerul „Cache-Control” setandu-i o valoare in functie de tipul resursei. De exemplu, daca dorim ca imaginile sa fie tinute in cache timp de o saptamana iar fisierele .txt si .css doar trei ore putem folosi urmatoarele linii in fisierul .htaccess:

<ifmodule mod_headers.c>
    # O saptamana pentru imagini
    <filesmatch ".(jpg|jpeg|png|gif|swf)$">
        Header set Cache-Control "max-age=604800, public"
    </filesmatch>
 
    # 3 ore pentru texte
    <filesmatch ".(txt|js|css)$">
        Header set Cache-Control "max-age=10800"
    </filesmatch>
</ifmodule>

In cazul mod_expires, inainte de a modifica timpul de expirare, trebuie sa pornim modulul adica sa folosim directiva „ExpiresActive On”. Dupa ce am pornit modulul putem seta timpul de expirare ca in cazul de mai sus:

<ifmodule mod_expires.c>
    ExpiresActive On
    ExpiresDefault A0
 
    # O saptamana
    <filesmatch ".(jpg|jpeg|png|gif|swf)$">
        ExpiresDefault A604800
    </filesmatch>
 
    # 3 ore
    <filesmatch ".(txt|js|css)$">
        ExpiresDefault A10800
    </filesmatch>
</ifmodule>

Dupa ce am setat cele doua texte oferite ca exemplu in fisierul .htaccess toate imaginile vor fi tinute in cache-ul browserului timp de o saptamana iar fisierele .txt, .css si .js timp de trei ore.

Modulul mod_expires este ceva mai complex decat l-am prezentat in liniile de mai sus. Pentru mai multe detalii se poate citi pagina de manual de pe site-ul apache.

Apache

12 Responses so far.

  1. SuperCroco says:

    Am adaugat si eu setarile acestea in .htaccess. E cert ca-l folosesc doar pentru .swf si .jpg, dar chiar se observa diferenta de incarcare.

  2. andrei says:

    Salut Sergiu

    După ultima discuţie, am început să citesc despre .htaccess, încercând să-mi reamintesc unele unele lucruri, dar şi să învăţ altele noi. Articolul de faţă este excelent, dovadă că şi un „neofit” ca mine l-a înţeles, însă ar fi câteva întrebări.

    1. În cazul meu, un blog cu sute de poze, nu există riscul ca acest cache să afecteze în vreun fel server-ul ? Cache-ul „se scade” din spaţiul alocat exclusiv mie (în acest caz n-ar fi probleme), sau este unul comun ?

    2. Dacă eu modific din poze sau instalez vreun update ce conţine un nou css sau js, pot să apară erori ? Se poate forţa reactualizarea, sau noul fişier va fi citit doar după 3 ore.

    Ştiu că problemele ridicate pot să pară uşor puerile, poate chiar sunt, dar acolo unde sunt sigur de ceva, prefer să întreb.

    P.S. Nu ştiu dacă e primul comentariu pe acest blog, aşa pare, iar atunci felicitările mele. Mi se pare mai uşor de accesat decât forumul.

  3. Sergiu says:

    Salut, Andrei! Si merci pentru apreciere!

    1. Cacheul despre care e vorba in articol se refera strict la client. Browserul care il folosesti isi face un cache propriu in care salveaza anumite fisiere pentru a nu fi cazul sa le ceara din nou serverului. Dupa ce se salveaza in cacheul browserului o imagine, acesta va verifica timpul de expirare inainte de a o cere din nou. Daca timpul de expirare nu e depasit, resursa nu va mai fi ceruta de pe server – ceea ce duce la o incarcare rapida, trafic scazut etc. In cazul de fata serverul nu e afectat in niciun mod pentru ca intreaga sarcina o preia clientul/vizitatorul.

    2. Din server nu poti forta reactualizarea, dar vizitatorul poate forta cererea resurselor daca tine apasata tasta F5 in timp ce apasa butonul de refresh. Cand fortezi refreshul cu F5 cacheul local este ignorat si suprascris daca e cazul.

    Eu prefer de obicei sa imi programez modificarile in asa fel incat sa nu deranjez cacheul. Daca stiu ca in trei ore urmeaza sa modific niste imagini, dezactivez cacheul si il reactivez doar dupa ce am incarcat versiunile noi. Astfel vizitatorilor vechi le expira cacheul iar cei noi nu sunt instruiti sa faca cache. Dupa ce urc resursele noi vor fi cerute si servite instant, impreuna cu headerele care apar dupa reactivare.

    Nu-ti fa griji de intrebari. Sunt intr-adevar chestii simple, dar daca nu esti obisnuit sa stai cu nasu’ intre headerele transmise/primite e normal sa te uiti putin ciudat prima data. Dupa ce modifici de cateva ori directivele nu vei mai avea nicio nelamurire 😉

    Un mic sfat daca folosesti Firefox. Instaleaza Live HTTP Headers si urmareste headerele care se schimba cand ceri imaginile. Joaca-te cu diferite valori pentru expirarea cacheului. Uita-te in mod deosebit la „Last-Modified”, „Expires” si „Cache-Control”.

  4. andrei says:

    Îţi mulţumesc frumos pentru răspunsuri 🙂 Setările în cauză favorizează aşadar utilizatorii frecvenţi, sau cei care revin pe site-ul respectiv. Începe să se facă lumină…

    Am instalat Live HTTP Headers, asta pe o versiune portabilă de Firefox, dat fiind faptul că, din nou, compatibilitatea cu 3.6 se lasă aşteptată (ca şi la Page Speed) şi încep să mă joc pe un domeniu de test.

    P.S. Nu ştiu dacă s-a abordat deja subiectul, sau cel puţin eu n-am găsit, însă ar fi extrem de interesante nişte exemple despre cum se poate proteja un site folosind .htaccess. Există unele materiale, de exemplu hxxp://www.wprecipes.com/protect-your-wordpress-blog-using-htaccess, însă explicaţiile oferite par „subţirele”.

  5. Sergiu Tot says:

    Am vazut ca se cauta astfel de articole, dar nu prea ma incanta pentru ca trebuie inteles mecanismul din spate inainte de a pune niste reguli in .htaccess. Momentan am scris un articol, Protectie la RFI, XSS si SQL Injection cu mod_security, care ar putea sa iti fie de folos. Mai am in plan cateva asemanatoare. Daca spui ca te intereseaza, trebuie sa ma pun pe treaba 😉

  6. andrei says:

    Salut
    N-am apucat să-ţi povestesc. Am făcut modificările, m-am jucat cu diferite valori pentru „max-age” şi în final, pentru momentul în care aveam de schimbat poze, am mers pe varianta cu cele 3 ore (dar fără să mai dezactivez cache-ul), urmând ca apoi să cresc intervalul la o lună întreagă (max-age=2419200). M-am lămurit şi care sunt diferenţele cu „A” şi „M”, sau de ce pozele din gravatar stau în cache doar 5 minute (max-age=300).

    Tot legat de recomandări, am găsit că pentru fişierele txt, js, css, ar fi de preferat Cache-Control: private, cu toate că şansele să intervină în discuţie acel proxy sunt destul de mici. Bine că Page Speed rulează într-un final şi pe Firefox 3.6.

    Următoarea oprire: gzip şi apoi să vedem ce se poate face legat de recomandarea „serve static content from a cookieless domain”.

    Îţi mulţumesc frumos pentru informaţii 😀

  7. Sergiu Tot says:

    Bine ca te-ai prins 😀

    Pentru gzip cel mai simplu e sa folosesti mod_deflate. Are o sintaxa simpla si isi face bine treaba. Pentru „Cookieless domain” vezi cum te descurci. Eu am doua domenii care nu folosesc cookie si le folosesc doar pentru asta. Daca nu ai vreun domeniu care sa-l folosesti pentru asta da un semn de viata si o rezolvam cumva 😉

  8. Victor says:

    Eu am toate setarile astea intr-un singur plugin, si anume: w3-total-cache

  9. Claudiu says:

    Cookieless domain 🙁 Cum se poate face?

  10. Sergiu Tot says:

    By default orice domeniu e cookieless. Problema apare cand incerci sa faci asta pe un subdomeniu. Aplicatiile care folosesc cookie-uri (sau indirect, sisteme de monitorizare si statistici) seteaza cookie-uri pe domeniul principal (exemplu.ro, nu http://www.exemplu.ro).

    Daca vrei sa fi „cookieless” fie nu folosesti niciun cookie setat pe domeniul principal, fie pastrezi informatiile pe un domeniu curat, folosit doar pentru stocare.

  11. Claudiu says:

    Am inteles… dar este vreo modalitate de „curatare” a unui domeniu?

  12. Victor says:

    @Claudiu pai scoti toate scripturile care folosesc cookies. Vezi Live Headers addon pt firefox, iti arata informatii despre cookies, in majoritatea cazurilor vei descoperi ce program produce acel cookie.