jblog » Apache

Autenticazione HTTP “basic” su server Apache

Giacomo — Mon, 11 Jan 2010 05:00:01 +0000

Ogni applicazione viene progettata e sviluppata con uno o più sistemi di autenticazione e sicurezza. Pensiamo al login di un sito web, al controllo degli utenti o alla gestione dei permessi.

L’autenticazione HTTP permette di implementare un controllo degli accessi basato su username e password, semplice da realizzare, stabile e sicuro.

PRO. Questo tipo di autenticazione offre un più rigido controllo sugli utenti e una maggiore stabilità rispetto al classico login. Il controllo degli utenti è molto rigido in quanto è l’amministratore a inserire nuove coppie di username e password, al contrario della procedura di registrazione durante la quale sono gli utenti a inserire i dati. Riguardo la stabilità, il discorso è molto simile a quello che si fa con i cms: un modulo Apache scritto e controllato da centinaia di sviluppatori è assai meno probabile che fallisca rispetto alle procedure di login scritte da un team ristretto di programmatori.

CONTRO. Il primo limite sta proprio nel fatto che per inserire un nuovo utente bisogna andare a scrivere “a mano” i dati per l’autenticazione, problema comunque risolvibile con uno script che accede al file dei dati per l’autenticazione, nel caso si voglia una procedura di registrazione automatizzata. Un altro limite è la difficoltà di gestire l’utente connesso, ad esempio, per avere un’area personale o per memorizzare i prodotti del carrello, tutte cose facilmente realizzabili nel caso di un login con database.

AUTENTICAZIONE HTTP con PHP » http://php.net/manual/en/features.http-auth.php

ATTENZIONE. Potrebbe succedere che in locale l’autenticazione HTTP non funzioni. Invece di perdere tempo inutilmente provala direttamente sul tuo spazio web, magari in una directory di test. A me è successo così! Per saperne di più segui questa discussione sul forum di html.it che, tutt’ora non ha risposte .

SOMMARIO

Un buon motivo per l’autenticazione HTTP: Una delle tante situazioni che ti dovrebbe far capire il senso dell’autenticazione HTTP.
Le diverse autenticazioni HTTP: La differenza fra le diverse autenticazioni.
Un esempio veloce: Esempio facile da capire per introdurre l’argomento.
Le direttive Apache: Una panoramica sulle direttive Apache che servono per implementare l’autenticazione HTTP, in modo da comprendere meglio cosa stiamo facendo.
Ottenere il percorso assoluto: Conoscere il percorso assoluto del server è necessario per impostare correttamente il file .htaccess.
Il file delle password: .htpasswd: Il file che contiene le coppie “username:password”.
Il file dei gruppi di utenti: .htgroup: Il file (opzionale) in cui impostare i gruppi di utenti.
Autenticazione HTTP in pratica: Come proteggere i file
Come proteggere una directory
Una nota sulle prestazioni
Creare eccezioni
Personalizza la pagina di errore “401 Authorization Required”: Come personalizzare la pagina di errore che appare quando non si inseriscono i dati corretti.

Note sull’articolo

Data la complessità degli argomenti trattati cerco di dare il giusto supporto anche agli sviluppatori che si sono avvicinati da poco all’uso del server Apache. Infatti per buona parte dell’articolo vengono fornite tutte quelle conoscenze di base richieste per una buona comprensione dell’autenticazione HTTP al fine di evitare un semplice copia-incolla che difficilmente porterà ai risultati sperati.

Se le direttive e il funzionamento del server Apache ti sono familiari puoi benissimo andare direttamente a vedere come implementare l’autenticazione HTTP iniziando a leggere dal paragrafo “Autenticazione HTTP in pratica“.

Un buon motivo per l’autenticazione HTTP

Pensa a un grosso sito ecommerce. Questo sarà diviso almeno in 4 aree: publica, utenti, gestione, amministrazione.

Nell’area pubblica potranno accedervi tutti, nell’area utenti solo gli utenti registrati, nell’area gestione solo gli addetti alle normali mansioni, come la moderazione dei commenti sui prodotti, e nell’area amministrazione solo pochi amministratori che, tra gli altri, avranno il compito di aggiungere nuovi amministratori e gestirne i permessi. Data la delicatezza dell’area amministrazione è necessario proteggerla il più possibile.

Ed è qui che entra in gioco l’autenticazione HTTP, che verrà implementata per creare una ulteriore barriera prima di accedere alla pagina login. In questo modo per accedere all’area amministrazione sarà necessario inserire due diverse coppie di username e password, con il conseguente rafforzamento della sicurezza.

Naturalmente, questo è solo uno dei tanti motivi per sfruttare l’autenticazione HTTP per rendere più sicuro il proprio sito.

Le diverse autenticazioni HTTP

Su un server Apache si possono implementare almeno 3 tipi di autenticazione HTTP.

Base. Utilizza dei file di testo per l’autenticazione. Il modulo necessario è mod_auth.c, ed è considerato uno dei moduli di base. In ogni caso dai un’occhiata ai servizi del tuo provider oppure alle informazioni php, con la funzione phpinfo().

DBM. Utilizza dei file di tipo DBM per l’elenco di username e password. Il modulo necessario è mod_auth_dbm.c.

Digest. Basata sull’algoritmo di hashing md5. Il modulo necessario è mod_auth_digest.c. Questo modulo è ancora in fase di test e alcune funzioni non sono ancora correttamente implementate.

Un esempio veloce

Per darti l’idea di quello che dobbiamo fare ti faccio un esempio veloce.

File .htaccess

AuthType Basic
AuthName "Restricted Files" #messaggio personalizzato
AuthUserFile /percorso-assoluto/.htpasswd
Require valid-user

N.B. non ho scritto il vero percorso assoluto per questioni di sicurezza. Credo che il mio provider non vorrebbe che lo sventolassi in giro!

File .htpasswd

admin:86dGPOHvD26i2
admin2:165491czyZTp2
admin3:29p7hc19vPpm6

dove username e password della prima riga sono “admin”.

Demo

Se non ti basta lo screenshot puoi provarlo andando su http://test.jblog.it/http_auth_base/ (username e password sono entrambe “admin”).

Le direttive Apache

Le direttive principali per implementare l’autenticazione HTTP.

AuthType. Imposta il tipo di autenticazione: basic o digest.

AuthName. Messaggio o descrizione personalizzata; utile per dare indicazioni.

AuthUserFile. File degli username e delle password, generalmente chiamato .htpasswd.

AuthGroupFile. File dei gruppi di utenti.

Require. Filtra gli utenti abilitati all’accesso. Generalmente si utilizza valid-user per indicare che l’accesso è permesso a tutti gli utenti validi, ad esempio quelli che inseriscono credenziali valide. Alternativamente si possono utilizzare user e group seguiti rispettivamente da una lista di utenti o di gruppi, separati da spazi.

Satisfy. Gestisce la politica degli accessi. Funziona solo se sono utilizzate contemporaneamente le direttive Allow e Require. Con All fa in modo che entrambe le condizioni siano verificate per convalidare l’accesso, invece con Any basta che sia verificata solo una delle condizioni.

Ottenere il percorso assoluto

Per collegare il file delle password (.htpasswd) e dei gruppi al file .htaccess non ci si può limitare al percorso relativo, ma è necessario il percorso assoluto. Per internderci, il percorso assoluto è quello che sul nostro pc inizia con “C:/…”.

Uno dei modi per ottenere il percorso assoluto del server è quello di creare ed eseguire il seguente script php:

dove la variabile $_SERVER['DOCUMENT_ROOT'] contiene il percorso assoluto della directory in cui si trovano i file del tuo sito.

Se non sei pratico/a di php segui queste istruzioni

Rinomina lo script in “doc_root.php”
Caricalo nella directory principale del tuo sito
Eseguilo scrivendo http://www.tuosito.com/doc_root.php
Copia e conserva il testo fornito in output, cioè il percorso assoluto

ATTENZIONE. Ti accorgerai anche tu che il percorso ottenuto dallo script php non è completo. Basterà guardare alla fine per osservare l’assenza del nome della directory in cui si trova il file .htpasswd. Quasi sempre è necessario completare il percorso assoluto scrivendo manualmente la directory in cui si trova il file .htpasswd. Un po’ di pazienza e tutto funzionerà a dovere!

Il file delle password: .htpasswd

Il file .htpasswd deve contenere la lista di username e password che verranno utilizzati per l’autenticazione (vedi l’esempio in basso).

Il nome del file. Il file dei dati di autenticazione puoi rinominarlo a tuo piacimento; non è obbligatorio chiamarlo “.htpasswd”. Tuttavia è consigliabile rispettare il modello “.htxxxxxx”, cioè farlo iniziare sempre con “.ht” cambiando solo il resto. Esempi validi: “.htpassword”, “.ht_dati_accesso”.

Criptare le password. Al contrario dell’username, che viene scritto “in chiaro”, la password deve essere criptata. Fortunatamente su internet si possono trovare molti siti che si occupano non solo di criptare la password ma anche di impostare il file .htpasswd.

Strumenti utili per .htpasswd

http://www.htaccesstools.com/htpasswd-generator/
http://www.wmtips.com/tools/htpasswd-generator/
http://www.4webhelp.net/us/password.php
http://www.clockwatchers.com/htaccess_tool.html
http://htmlfixit.com/cgi-bin/tools/htaccess/index.pl
http://tools.dynamicdrive.com/password/
http://www.softspecialist.com/i/htaccess-password-generator-htpasswd-encryption-tool.htm

Per iniziare. Se non ti va o non riesci a utilizzare questi tools puoi iniziare subito con questi dati: admin:86dGPOHvD26i2, dove username e password sono entrambi admin.

Scrivere il file .htpasswd. Per creare un file .htpasswd è necessario seguire solo 2 semplici regole:

username e password devono essere separate dai due punti “:”
inserire una coppia : per riga

Esempio di file .htpasswd

admin:86dGPOHvD26i2
admin2:165491czyZTp2
admin3:29p7hc19vPpm6

Per una maggior sicurezza sulla documentazione Apache viene consigliato di inserire i file .htpasswd all’esterno della directory principale del sito in modo da renderli totalmente inaccessibili dall’esterno, ad esempio tramite browser. Purtroppo non sempre è possibile inserire dei file all’esterno della directory principale, soprattutto se hai un hosting di base.

Il file dei gruppi di utenti: .htgroup

Il file dei gruppi di utenti deve contenere l’elenco dei gruppi in corrispondenza dei quali si scrive la lista di username appartenenti (vedi l’esempio in basso). Questo file è direttamente collegato al file .htpasswd in quanto gli username appartenenti a ciascun gruppo sono proprio quelli scritti nel file .htpasswd.

Il nome del file. Il file dei dati di autenticazione puoi rinominarlo a tuo piacimento. Tuttavia è consigliabile rispettare il modello “.htxxxxxx”, cioè farlo iniziare sempre con “.ht” cambiando solo il resto. Esempi validi: “.htgruppi”, “.ht_lista_gruppi”. Ho preferito chiamarlo “.htgroup” per avere una maggior chiarezza nella scrittura dell’articolo.

A cosa serve? Dividere gli utenti per gruppi è necessario, ad esempio, nel caso in cui si hanno diverse aree alle quali devono accedere diversi gruppi di utenti. Inoltre è anche comodo per la direttiva Require perché invece di inserire tutti gli username si evita di “sporcare” eccessivamente il file .htaccess limitandosi a scrivere pochi gruppi.

Esempio

Nota la “pulizia” della versione 2 del file .htaccess rispetto alla versione 1. Probabilmente non ti sembrerà niente di così rivoluzionario… Pensa in grande! Pensa a una lista di 30 username per ogni gruppo!

File .htpasswd (valido per le due versioni del file .htaccess)

admin:86dGPOHvD26i2
admin2:165491czyZTp2
admin3:29p7hc19vPpm6
admin4:86dGPOHvD26i2
admin5:165491czyZTp2
admin6:29p7hc19vPpm6
admin7:86dGPOHvD26i2
admin8:165491czyZTp2
admin9:29p7hc19vPpm6

File .htaccess [versione 1] (senza dividere gli utenti in gruppi)


   AuthType Basic
   AuthName "Fai parte del gruppo 1?"
   AuthUserFile /percorso_assoluto/.htpasswd
   AuthGroupFile /percorso_assoluto/.htgroup
   Require user admin admin2 admin3 admin4 admin5



   AuthType Basic
   AuthName "Fai parte del gruppo 2?"
   AuthUserFile /percorso_assoluto/.htpasswd
   AuthGroupFile /percorso_assoluto/.htgroup
   Require user admin6 admin7 admin8 admin9

File .htaccess [versione 2] (utenti suddivisi in gruppi)


   AuthType Basic
   AuthName "Fai parte del gruppo 1?"
   AuthUserFile /percorso_assoluto/.htpasswd
   AuthGroupFile /percorso_assoluto/.htgroup
   Require group gruppo1



   AuthType Basic
   AuthName "Fai parte del gruppo 2?"
   AuthUserFile /percorso_assoluto/.htpasswd
   AuthGroupFile /percorso_assoluto/.htgroup
   Require group gruppo2

.htgroup (per il file .htaccess versione 2)

gruppo1: admin admin2 admin3 admin4 admin5
gruppo2: admin6 admin7 admin8 admin9

Demo. Per farti capire meglio di cosa sto parlando vai su http://test.jblog.it/http_auth_group/.

Per una maggior sicurezza sulla documentazione Apache viene consigliato di inserire i file .htgroup all’esterno della directory principale del sito in modo da renderli totalmente inaccessibili dall’esterno, ad esempio tramite browser. Purtroppo non sempre è possibile inserire dei file all’esterno della directory principale, soprattutto se hai un hosting di base.

Autenticazione HTTP in pratica

Come proteggere i file

Per proteggere uno o più file si possono utilizzare le direttive o .

La seconda è da preferire quando i file da proteggere si devono riconoscere tramite regex. In pratica, la direttiva deve essere utilizzata quando si devono proteggere più file con gli stessi criteri oppure quando non si è sicuri del nome, ad esempio quando non si sa se l’estensione è scritta in minuscolo o in maiuscolo.

La direttiva è da preferire solo quando il file è uno solo e si è sicuri del nome.

Uso della direttiva

# 1) protegge i file secret1.php e secret2.php
# 2) [pP][hH][pP] perchè non si è sicuri di come è scritta l'estensione

   AuthType Basic
   AuthName "Accesso alle pagine segrete..."
   AuthUserFile /percorso_assoluto/.htpasswd
   Require valid-user

Uso della direttiva


   AuthType Basic
   AuthName "Accesso alla pagina segreta..."
   AuthUserFile /percorso_assoluto/.htpasswd
   Require valid-user



   AuthType Basic
   AuthName "Accesso alla pagina segreta..."
   AuthUserFile /percorso_assoluto/.htpasswd
   Require valid-user

Come proteggere una directory

Teoricamente si dovrebbe agire come per i file, utilizzando però le direttive e .

Problema. A meno che tu non abbia accesso al file di configurazione del server o del virtual host, non è possibile farlo in quanto le direttive e NON possono essere utilizzate nel file .htaccess. A questo proposito vorrei ringraziare Enoa del forum di html.it.

Soluzione. Inserire un file .htaccess direttamente nelle directory da proteggere. Tutto qui! Ricordati di non inserire i file .htpasswd e .htgroup nella directory da proteggere.

Esempio di file .htaccess da inserire nella directory da proteggere

AuthType Basic
AuthName "Accesso alla Directory XXX..."
AuthUserFile /percorso_assoluto/.htpasswd
Require valid-user

Una nota sulle prestazioni

Per sua natura l’implementazione dell’autenticazione HTTP comporta un leggero peggioramento delle prestazioni. In pratica, ogni volta che si accede a dei file protetti direttamente o indirettamente (cioè all’interno di una directory protetta) il server controlla se la richiesta HTTP è autorizzata ad essere soddisfatta. In altre parole, ogni – e sottolineo ogni – richiesta HTTP è soggetta a un controllo da parte del server per verificare se questa possiede le autorizzazioni necessarie.

Quindi, prima di implementare un’autenticazione HTTP chiediti quanto influirà questo, seppur leggero, abbassamento di prestazioni.

Creare eccezioni

Nonostante ci si autentichi con successo potrebbero sorgere altri problemi. Gli script utilizzati con tecniche Ajax oppure i file XML richiamati da animazioni Flash potrebbero non essere letti in quanto la richiesta di questi file non proverrebbe dal browser con cui ci si è autenticati e il server Apache potrebbe considerarla come una richiesta non autorizzata.

Un’altra situazione per la quale è necessario creare delle eccezioni si ha quando ci sono dei file o sottodirectory ad accesso libero in una directory protetta.

Soluzione veloce

Se il sito è stato sviluppato completamente da te, non avrai grosse difficoltà ad applicare questa soluzione: ti basterà solo modificare qualche riga di codice.

Inserire i file ad accesso libero in una sottodirectory da “liberare” dalla protezione dell’autenticazione HTTP.

Crea una sottodirectory
Inserisci tutti i file e le directory da “liberare”
Inserisci in questa sottodirectory un nuovo file .htaccess con il seguente codice

Allow from All
Satisfy Any

Queste due righe disattivano l’inserimento dei dati per l’autenticazione. Con Satisfy Any si stabilisce che è sufficiente verificare una delle due condizioni tra Require (che si trova nel file .htaccess della directory superiore) e Allow. Quindi, poiché con Allow from All diciamo ad server che l’accesso è “permesso a tutti” una delle due direttive è sempre verificata.

Soluzione complessa

Se il sito è basato su un CMS o comunque non è stato sviluppato da te non è possibile spostare file e directory in quanto non sapremmo dove effettuare le modifiche al codice. Questa soluzione infatti permette di “liberare” file e directory lasciandoli tutti al loro posto.

Liberare una directory. Come per la soluzione veloce, basta inserire al suo interno un nuovo file .htaccess con il seguente codice:

Allow from All
Satisfy Any

Liberare uno o più file. Utilizzando le direttive o è possibile liberare rispettivamente uno o più files. Utilizzare per liberare dei file in base al nome esatto mentre per liberare dei file riconoscendoli tramite espressioni regolari.

Il file index.php. Generalmente se si accede a una directory senza specificare un file verremo portati sul file index.php o index.html. Se liberiamo il file index.php della directory contenente il file .htaccess principale (con le varie istruzioni per l’autenticazione HTTP) questo è soggetto a un doppio comportamento. Se accediamo alla directory (senza specificare nessun file), cioè scrivendo nel browser “http://miosito.com/directory_protetta/” ci verranno chiesti i dati per l’autenticazione. Invece se accediamo al file index.php (specificandolo nell’indirizzo), cioè scrivendo nel browser “http://miosito.com/directory_protetta/index.php” non ci vengono chiesti i dati per l’autenticazione. Non credo sia possibile risolvere questo problema.

Demo. Prova le eccezioni create per index.php e free_access.php con questo script: http://test.jblog.it/http_auth_exception/index.php. Prova anche ad accedere a http://test.jblog.it/http_auth_exception/ in cui, a differenza del primo indirizzo, ti verranno chiesti i dati per l’autenticazione.

Esempio

AuthType Basic
AuthName "Accesso alla Directory..."
AuthUserFile /percorso_assoluto/.htpasswd
Require valid-user

# Libera il file index.php

   Allow from All
   Satisfy Any


# Libera il file free_access.php

   Allow from All
   Satisfy Any

# Libera tutti i file .xml, .css e .js

   Allow from All
   Satisfy Any


# Libera i file "page1.php" e "page2.php"

   Allow from All
   Satisfy Any

Personalizza la pagina di errore “401 Authorization Required”

Come ciliegina sulla torta impostiamo una pagina personalizzata per l’errore 401 che si verifica quando non si inseriscono dei dati di autenticazione corretti.

Pagina 401 di default

Codice da inserire nel file .htaccess principale

ErrorDocument 401 /my_401.html

La mia pagina 401 personalizzata

Demo. Prova la pagina personalizzata su http://test.jblog.it/http_auth_errordoc/ (clicca su “annulla”).

Suggerimenti? Bisogno d’aiuto?

Sto imparando a mie spese che su Apache anche le cose più semplici non sono così immediate, ma bisogna sempre sbatterci un po’ la testa!

Se hai dei suggerimenti per una miglior comprensione dell’articolo, ti serve qualche chiarimento o non riesci a venire a capo di un particolare problema non esitare a contattarmi. Sarà l’occasione per imparare qualcosa di nuovo!

Crediti

Apache HTTP Server – Core » http://httpd.apache.org/docs/2.0/mod/core.html

Apache HTTP Server – mod_auth » http://httpd.apache.org/docs/2.0/mod/mod_auth.html

Apache HTTP Server – Authentication, Authorization and Access Control » http://httpd.apache.org/docs/2.0/howto/auth.html

Foto | NYkette » http://newyorkette.com/2006/03/08/a-bouncer-on-bouncers/

Ridurre le richieste HTTP (parte 1): come utilizzare la cache del browser

Giacomo — Fri, 24 Apr 2009 20:56:12 +0000

Iniziamo una lunga serie di articoli sull’ottimizzazione dei siti web in cui verranno trattate le tecniche e i suggerimenti per rendere efficiente il proprio sito web.

In questo articolo parlo della cache dei browser, come e perché gestirla. Vedrai cos’è una richiesta http, un’intestazione http e le tre tecniche principali per istruire il browser su come dovrà comportarsi con gli elementi di una pagina, cioé, quando leggerli dal server d’origine e quando caricarli dalla cache.

Cos’è una richiesta http?

Quando il browser visita un sito apre una connessione con l’host (il server che ospita il sito), composta da una richiesta e da una risposta. Supponiamo di voler visitare la pagina http://jblog.it/informazioni.html.

La richiesta http che invia il browser

GET /informazioni HTTP/1.1 Host: jblog.it User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: it Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive

La risposta http

HTTP/1.1 200 OK Date: Fri, 24 Apr 2009 10:26:08 GMT Server: Apache Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8

Le informazioni inviate e restituite potrebbero essere molte di più, ognuna ha un suo preciso significato, e possono essere controllate e gestite via codice (lato client e lato server). Sul sito del w3c puoi trovare l’elenco completo dei campi di intestazione delle connessioni http: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html.

La prima riga della richiesta: GET /informazioni HTTP/1.1

In questa riga si trovano sostanzialmente tre informazioni: il tipo della richiesta (GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE), l’indirizzo della risorsa (/informazioni) e il protocollo con cui si effettua la richiesta (HTTP/1.1).

La prima riga della risposta: HTTP/1.1 200 OK

Il codice 200 indica il successo della risposta http. Esistono vari codici numerici per indicare l’esito della risposta http. Ad esempio, il classico codice 404 indica che non è stata trovata la risorsa specificata nella richiesta http. Se ti interessa puoi trovare una lista completa su wikipedia: http://it.wikipedia.org/wiki/Elenco_dei_codici_di_stato_HTTP.

Perché bisogna ridurre le richieste http?

Il numero di richieste http dipende dal numero di elementi da caricare. Ad esempio, se in una pagina ci sono 2 immagini e 1 foglio di stile il browser effettuerà 4 richieste http (una è per il codice html della pagina).

Come avrai ben capito, la regola è “ridurre gli elementi della pagina”, o meglio “ottimizzare gli elementi di una pagina senza eliminarne nessuno”. Con “ottimizzare” non intendo “ridurre la loro dimensione”. Infatti riducendo la dimensione degli elementi avresti un miglior tempo di caricamento mantenendo lo stesso numero di richieste http.

Ottimizzare o ridurre?

Senza dubbio è importantissimo ottimizzare la qualità e le dimensioni dei componenti di una pagina, ma una singola richiesta http è molto più gravosa di qualche kbyte in più. Ecco perché ridurre le richieste http è fondamentale.

I campi di intestazione del protocollo HTTP per gestire la cache

Il protocollo HTTP 1.1 ha alcuni campi di intestazione (o header fields) che consentono di fornire alcune informazioni riguardo un file (data, ultima modifica, periodo, ecc.) e controllare la cache.

Cache-Control

Specifica le direttive che devono rispettare tutti i metodi di caching dei componenti restituiti. Le direttive di cache-control:

sovrascrivono gli algoritmi di caching di default
non possono essere specificate per una singola cache (se si utilizza un proxy o un gateway)
sono unidirezionali, cioè non implicano che la risposta abbia le stesse direttive

Alcune direttive possono essere utilizzate solo in fase di richiesta o solo in fase di risposta.

direttive di richiesta: no-cache, no-store, max-age, max-stale, min-fresh, no-transform, only-if-cached, cache-extension.
direttive di risposta: public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age, s-maxage, cache-extension.

public. La risposta può essere memorizzata in qualsiasi cache. Utile se si utilizza una cache condivisa.

private. La risposta non deve essere memorizzata nella cache condivisa.

no-cache. Evita che la risposta venga memorizzata in cache. SOLO in fase di risposta è possibile scrivere no-cache="field-name", dove field-name è il nome di un campo di intestazione che non si vuole memorizzare in cache. In pratica, quando una risposta (ad es. una pagina) viene memorizzata in cache, vengono memorizzati anche i suoi campi di intestazione. Se uno di quei campi è “Set-Cookie” e non vogliamo che venga memorizzato in cache basterà scrivere no-cache="Set-Cookie". In tal modo la pagina verrà comunque memorizzata in cache senza il campo di intestazione “Set-Cookie”. L’utilità? Dato che “Set-Cookie” crea un cookie, memorizzandolo con la pagina, quando si riutilizzerà la versione in cache verrà creato nuovamente il cookie.

no-store. Evita che la risposta venga memorizzata permanentemente nella memoria non-volatile. Questa direttiva si applica a qualsiasi tipo di cache (condivisa e non). La sua utilità consiste nel fatto che si impedisce la memorizzazione di vecchie versioni di pagine e documenti che vengono costantemente aggiornati.

s-maxage. Specifica il periodo (in secondi) dopo il quale devono essere aggiornate le risposte nella cache condivisa. Questa direttiva sovrascrive la direttiva max-age e il campo di intestazione expires.

max-age. Indica che il client è disposto ad accettare una risposta con un periodo (in secondi) maggiore di quello specificato. Se non è specificata la direttiva max-stale, il client non accetterà una risposta datata.

min-fresh. Indica che il client è disposto ad accettare una risposta che sia aggiornata almeno a un dato periodo (in secondi).

max-stale. Indica che il client è disposto ad accettare una risposta che supera la sua scadenza di un certo numero di secondi.

only-if-cached. Consente di caricare un contenuto solo se in cache è presente una sua versione, altrimenti non viene restituita alcuna risposta. Questa direttiva è utile nelle reti particolarmente lente.

must-revalidate. Poichè una cache può essere configurata in modo che ignori il tempo di scadenza di una risposta, questa direttiva consente di forzare l’aggiornamento di una risposta già memorizzata in cache. Questa direttiva viene sempre rispettata dal browser.

proxy-revalidate. Ha gli stessi effetti di must-revalidate, ma solo sulla cache condivisa.

no-transform. Evita che una cache intermedia (ad es. di un proxy) manipoli la risposta per risparmiare risorse. Infatti può succedere che un proxy comprima un’immagine per risparmiare spazio. Questa direttiva è utile nel caso di immagini da trasmettere fedelmente (ad es. in campo medico) in cui ogni pixel deve rimanere al suo posto.

Expires

Indica una data (con l’ora) a partire dalla quale la risposta memorizzata in cache deve essere considerata “vecchia”, quindi essere aggiornata.

La data deve essere espressa in un preciso formato definito dal protocollo HTTP. Ad esempio: Tue, 03 Nov 2007 17:30:00 GMT.

Expires: Tue, 03 Nov 2007 17:30:00 GMT

Pragma

Indica che la risposta non deve essere memorizzata in cache. L’unica direttiva è appunto “no-cache”.

In pratica esegue la stessa funzione di cache-control=”no-cache”, ma è necessario utilizzarla per mantenere la compatibilità con la versione 1.0 del protocollo HTTP.

Pragma: no-cache

ETag

Gli ETag o Entity Tag rappresentano un modo semplice ed efficiente per determinare se la risposta nella cache corrisponde a quella che si trova nel server di origine. Concretamente un ETag non è altro che una stringa che identifica univocamente una risposta memorizzata in cache.

Com’è composta la stringa? Non ha dei valori predefiniti ma deve essere creata in base a dei valori che potrebbero identificare la versione di una risposta. Generalmente si preferisce identificare le risposte in base alla data dell’ultima modifica e alla dimensione. Queste due informazioni vengono compresse in modo da formare un’unica stringa di dimensioni contenute, ad esempio utilizzando algoritmi di hashing come md5.

Gli svantaggi. L’unico svantaggio è che il formato e il valore di un ETag cambia da server a server. Se un determinato file risiede su più server nella stessa directory, con identiche dimensioni, permessi, timestamp, a seconda del server da cui si legge. La soluzione consiste nel creare il valore dell’ETag con un semplice script lato-server. In pratica, per avere dei benefici dagli ETag è necessario gestirli completamente con degli script lato-server, altrimenti è meglio non utilizzarli. Ecco un esempio di script.

ETag: "0401g4ff812fgk12gqg2g4j7"

Last-Modified

Rappresenta la data e l’ora dell’ultima modifica del file sul server d’origine nella forma, ad esempio, Tue, 03 Nov 2007 17:30:00 GMT.

Questo campo di intestazione è utile soprattutto nelle pagine dinamiche in cui vengono stampati dei dati ricavati da un database, o nei file creati dinamicamente (ad es. un foglio di stile che ne unisce 5 per evitare di avere 5 richieste http).

If-Match

Fornisce un metodo efficiente per controllare se la risposta ottenuta corrisponde a quella memorizzata in cache, utilizzando gli ETag, ed eventualmente aggiornarla. Viene anche usata per evitare modifiche accidentali sull’errata versione di una risorsa.

If-Match:* oppure If-Match:0401g4ff812fgk12gqg2g4j7

Nel primo caso, il carattere “*” è un carattere speciale e il campo fa corrispondere tutti i componenti di una risposta.

Nel secondo caso, il campo di intestazione fa corrispondere l’ETag con la stringa specificata.

If-None-Match

Fornisce un metodo efficiente per controllare se la risposta ottenuta corrisponde a quella memorizzata in cache, utilizzando gli ETag, ed eventualmente aggiornarla.

Al contrario di If-Match non si deve avere la corrispondenza con l’ETag confrontato o con il carattere “*”.

If-None-Match:* oppure If-Match:0401g4ff812fgk12gqg2g4j7

If-Modified-Since

Fornisce un metodo automatico per aggiornare la versione in cache di una risposta che non è stata modificata da una certa data (e ora) nel formato: Tue, 03 Nov 2007 17:30:00 GMT. Se la risposta è stata modificata a partire dalla data specificata si effettua l'aggiornamento della versione in cache, altrimenti viene restituita la versione memorizzata in cache.

If-Modified-Since: Sat, 12 Oct 2008 20:12:00 GMT

If-Unmodified-Since

Fornisce un metodo automatico per aggiornare la versione in cache di una risposta che non è stata modificata da una certa data (e ora) nel formato: Tue, 03 Nov 2007 17:30:00 GMT. Se la risposta NON è stata modificata a partire dalla data specificata si effettua l'aggiornamento della versione in cache, altrimenti viene restituita la versione memorizzata in cache.

If-Unmodified-Since: Sat, 12 Oct 2008 20:12:00 GMT

If-Range

Se la versione in cache di una risposta è parziale, questo campo di intestazione permette di ottenere solo la parte mancante. La condizione fallisce se la risorsa richiesta è stata modificata. In questo caso sarà effettuata una seconda richiesta per ottenere una risposta completa che aggiorni la versione memorizzata in cache.

If-Range: Sat, 12 Oct 2008 20:12:00 GMT

If-Range: 0401g4ff812fgk12gqg2g4j7

Nel primo caso si confronta la data dell’ultima modifica, mentre nel secondo caso si confronta la stringa dell’ETag.

Come utilizzare i campi di intestazione

In questo paragrafo non troverai una ricetta pronta per gestire la cache perché non so quali sono le tue esigenze. Leggi attentamente il paragrafo precedente per decidere le operazioni da effettuare in ogni pagina e risorsa del tuo sito.

Il mio consiglio è quello di analizzare i contenuti delle tue pagine (attuali e futuri) e decidere se memorizzare in cache una particolare risorsa, come gestire la versione della cache, il tempo di validità, ecc.

Se nel paragrafo precedente alcuni punti sono spiegati male, manca qualcosa o ci sono errori fammelo sapere e correggerò tutto al più presto.

Ci sono tre metodi per impostare i campi di intestazione:

impostando il tag
all’interno del proprio codice lato-server (php, asp, cgi, ecc.)
configurando il web server Apache tramite il file .htaccess o il file principale httpd.conf

1. Impostare i tag

Sicuramente conoscerai già il tag . Probabilmente l’avrai utilizzato per inserire description e keywords nelle tue pagine web, per migliorare l’indicizzazione del tuo sito da parte dei motori di ricerca.

Per ogni campo di intestazione che decidi di utilizzare devi:

creare un tag con gli attributi “http-equiv” e “content”
scrivere il nome del campo nell’attributo ”http-equiv”, rispettando le lettere maiuscole e minuscole
scrivere il valore del campo nell’attributo “content”

Esempi

2. Il codice lato-server

Ogni linguaggio di programmazione ha la sua funzione per inviare un campo di intestazione.

Al momento l’unico linguaggio che conosco è PHP, con cui basterà scrivere header("Cache-Control: no-cache"); .

I campi di intestazione vanno scritti prima di qualsiasi output sulla pagina, altrimenti si verifica un errore che in sostanza dice “impossibile modificare l’intestazione – gli header sono stati già inviati”.

Tutto qui? In teoria non ci sarebbe altro… Posso solo aggiungere delle situazioni in cui diventa fondamentale utilizzare la funzione header.

Combinare più fogli di stile

Per diminuire le richieste http è una buona abitudine combinare più fogli di stile in uno solo. Si potrebbe fare manualmente, ma se in futuro vorrai effettuare delle modifiche dovrai modificare i singoli file e ricombinarli oppure modificare il file grande con la difficoltà di aver a che fare con centinaia di righe di codice.

Il metodo è quello di creare un file .css in cui inserire uno script php che permetta di stampare al suo interno tutti i file .css da te specificati. Dovrai inoltre impostare Apache affinché processi i file .css come file .php .

Per file dinamici di questo tipo sarà necessario richiamare più volte la funzione header all’inizio del file in modo da inviare i campi di intestazione riguardanti la gestione della cache.

Questo argomento farà parte del prossimo articolo su come combinare e ottimizzare immagini, css e script.

Ecco un semplice script php.

< ?
$files = array("css1.css","css2.css");
$mtime = 0;
$this_mtime = 0;
ob_start();
foreach($files as $file)
{
	if(file_exists($file))
	{
		include($file); /* includo il file */
		$this_mtime = filemtime($file); /* leggo la data dell'ultima modifica */
		if($mtime < $this_mtime) $mtime=$this_mtime;
	}
}
$lenght = ob_get_length(); /* lunghezza del contenuto */
$content = ob_get_contents(); /* il contenuto nella variabile $content da stampare successivamente */ ob_end_clean();

/* Headers */
header("Content-Type: text/css");
header("Last-Modified: ".date("D, d M Y H:i:s",$mtime)." GMT");
header("Content-Length",$lenght);
header("ETag: ".md5("compressed.css".$lenght.$mtime)); /* il file si chiama compressed.css */
header("Cache-Control: max-age=345600");

/* Stampo il contenuto */
echo $content;
?>

per calcolare l’ultima modifica da inviare nel campo di intestazione “Last-Modified” sarà quella del file che è stato modificato più recentemente
nell’ETag inserisco anche il nome del file per aumentare l’univocità dell’ETag

Come ultima operazione inserire nel file .htaccess la riga:

AddHandler application/x-httpd-php .css

Questa riga fa in modo che Apache processi i file css come file php.

Pagine dinamiche e database

Quando una pagina “dinamica” ha sempre gli stessi dati per diversi giorni è importante fare in modo che un utente, a partire dalla seconda visita, non ricarichi una nuova versione di quella pagina ma legga la versione memorizzata in cache.

Nei cms, come in Wordpress, c’è una netta separazione fra template e codice. In alcuni non è possibile creare un template per una singola pagina per altri, come Wordpress, si. Tuttavia, secondo me, è totalmente inutile creare un template per scrivere solo i tag e avere una gestione personalizzata della cache per quella pagina. Per questo motivo conviene inviare i campi di intestazione all’interno del codice.

Una prima idea è quella di definire delle condizioni per cui dei record restituiti dal database devono essere considerati “vecchi”, e in base a queste ed altre condizioni inviare gli opportuni valori dei campi di intestazione.

3. Configurare il web server Apache

Per gestire la cache con Apache è necessario caricare i moduli mod_expires e mod_headers.

Caricare i moduli

cerca e apri il file httpd.conf
individua la lunga lista di “mod_…”
individua le righe con “mod_expires” e “mod_header”
elimina (se c’è) il carattere “#” che si trova prima del nome dei moduli che vuoi attivare
riavvia il server Apache

A questo punto, nel file .htaccess bisogna definire le regole che consentono di gestire la cache a seconda del tipo o estensione dei file richiesti durante le connessioni http.

Il modulo mod_expires

Per conoscere meglio questo modulo ti consiglio di andare a leggere la guida ufficiale di Apache (in inglese): http://httpd.apache.org/docs/2.2/mod/mod_expires.html.

Il modulo mod_headers

Per conoscere meglio questo modulo ti consiglio di andare a leggere la guida ufficiale di Apache (in inglese): http://httpd.apache.org/docs/2.2/mod/mod_headers.html.

Gestione della cache in base all’estensione

ExpiresActive On
ExpiresDefault A300

	Expires A86400


	Expires A2592000

la prima riga (ExpiresActive) attiva il modulo “mod_expires”
la seconda riga (ExpiresDefault) imposta un valore di default del campo di intestazione “Expires” pari a 300 secondi
il primo blocco fa in modo che tutti i file html abbiano il campo di intestazione “Expires” con il valore 86400 secondi
il secondo blocco fa in modo che tutti i file gif, jpg, png, js, css abbiano il campo di intestazione “Expires” con il valore 2592000 secondi
la lettera A indica che il valore viene impostato dopo l’accesso al file, mentre la lettera M imposterebbe il valore dopo la modifica al file

Svantaggi. Spesso capita che alcuni file, benché siano dello stesso tipo, abbiano estensioni diverse. Ad esempio, le immagini con una compressione Jpeg possono avere l’estensione jpg oppure jpeg. Quindi se capitasse un file jpeg non si avrebbe la corrispondenza.

Gestione della cache in base al tipo MIME

Per assicurarci di individuare tutti i file di un certo tipo è necessario leggere il loro tipo MIME.

ExpiresActive On
ExpiresDefault A300
ExpiresByType text/css "access plus 1 day"
ExpiresByType text/javascript "access plus 3 days"
ExpiresByType image/png "access plus 2 months"

Forzare l’aggiornamento dei componenti

Se si utilizzano dei componenti che devono essere sempre aggiornati spesso non basta scrivere i campi di intestazione "Cache-Control: no-cache" e "Pragma: no-cache". Esistono infatti prove documentate sul fatto che a volte questi campi vengono ignorati dai browser.

Quando utilizzavo un script captcha notavo che non si aggiornava l’immagine, il che era davvero un problema in quanto se l’utente sbagliava il codice doveva ricaricarsi la pagina con una nuova immagine.

La soluzione consiste nello scrivere l’indirizzo dell’immagine con un elemento dipendente dal tempo. Quindi, invece di scrivere:

si cambierà l’indirizzo in:
" alt="La mia immagine" />
dove la funzione time() restituisce data e ora attuali in numeri interi (ad es. 11022103710).

Nel caso si utilizzi l’immagine come sfondo, anziché scrivere:

si dovrà modificare l’indirizzo in:

Uno dei possibili svantaggi sta nel fatto che non tutti i file possono essere processati con il compilatore php. Se vuoi che un file .js (javascript) o .css (foglio di stile) venga processato come un file php basterà aggiungere al file .htaccess le seguenti righe:

AddHandler application/x-httpd-php .css AddHandler application/x-httpd-php .js

Per concludere, scrivendo questo articolo ho scoperto un mondo riguardo la cache e la sua gestione, ed ho capito che gestire adeguatamente la cache permette di ottimizzare notevolmente il caricamento delle pagine di un sito web.

Come utilizzavi la cache fino ad oggi? Ti limitavi a scrivere i tre tag o avevi già pensato di iniziare a utilizzare la cache più seriamente? Ti sembra importante o è solo una mia impressione? L’articolo è scritto bene o manca qualcosa?

Non perdere il prossimo articolo: “Ridurre le richieste HTTP (parte 2): combinare e ottimizzare immagini, script e css”.

Crediti

Libro. Creare siti web ad alte prestazioni: http://www.tecnichenuove.com/libri/creare_siti…
Guida ufficiale di Apache: http://httpd.apache.org/docs/2.2/
Use Server Cache Control to Improve Performance: http://websiteoptimization.com/speed/tweak/cache/
Foto1: http://www.flickr.com/photos/aureusbay/297387489/
Foto2: http://www.flickr.com/photos/thingsarebetterwithaparrott/1054908626/
Foto3: http://www.flickr.com/photos/galopoulos/567890941/