Il rewrite engine (rewrite = riscrivere, engine = macchina) è un componente del web server che permette di riscrivere o reindirizzare gli Uniform Resource Locator (URL). Il rewrite engine più conosciuto è il mod_rewrite del server Apache HTTP, ma anche gli altri web server, come nginx o lighttpd, mettono a disposizione funzioni simili.

Questo componente software è ad esempio usato in presenza dei classici URL generati dai CMS che devono essere riscritti in URL più intuitivi e quindi più user-friendly. I motivi per cui questo processo risulta necessario sono facilmente intuibili. URL tecnici come

"http://esempio.com/a/index.php?title=titolopagina"

non sono memorizzabili facilmente dagli utenti; il rewrite engine consente di rendere accessibile la stessa risorsa parallelamente su URL chiari e semplici:

"http://esempio.com/articolo/titolopagina"

Un utente può così usare questo URL per aprire la pagina corrispondente. Se arriva una richiesta dal web server, il rewrite engine riscrive automaticamente l’URL nello schema interno utilizzato dal server, quindi come "http://esempio.com/a/index.php?title=titolopagina".

Il rewrite engine genera così una sorta di livello di astrazione tra gli URL che utilizzano il progetto internamente e quelli che vengono visualizzati pubblicamente in rete. Ciò consente, indipendentemente dalle richieste tecniche interne, di mettere a disposizione uno schema di indirizzi unitario e user-friendly da mostrare all’esterno.

Internamente si può continuare ad utilizzare un indirizzo dinamico e che risponde a precisi parametri, mentre l’utente in rete accede al sito web tramite un indirizzo apparentemente statico. Ne consegue il vantaggio che gli URL presentati agli utenti rimangono validi, anche se vengono apportate modifiche interne alla gerarchia dei file.

I webmaster possono realizzare con il rewrite engine i reindirizzamenti in base a delle precise condizioni. Così è, ad esempio, possibile creare reindirizzamenti basati sull’identificazione dello User Agent o dell’indirizzo IP del client richiedente per impostare la localizzazione geografica o per visualizzare i siti ottimizzati su diversi dispositivi. Generalmente si utilizza un redirect 301 che assicura la memorizzazione di una sola versione del sito nell’indice dei motori di ricerca, malgrado coesistano delle pagine Mobile aggiuntive o diverse versioni in più lingue.

I webmaster dovrebbero invece prendere le distanze dalle pratiche di cloaking, in cui vengono visualizzate pagine specificamente ottimizzate per i crawler dei motori di ricerca al solo scopo di migliorarne il ranking.

Esempi di applicazione

Il rewrite engine mette a disposizione diversi comandi per manipolare gli URL, che si possono annotare come regole in diversi punti del web server. Così il mod_rewrite, il rewrite engine del web server Apache, può utilizzare diversi container, come una directory all’interno del file httpd.conf, di un segmento del VirtualHost o all’interno del file .htaccess. Su nginx le direttive per l’URL Rewriting sono presenti nel file di configurazione /etc/nginx/nginx.conf, mentre su lighttpd è messo a disposizione nel file /etc/lighttpd.conf nella configurazione di vHost.

Per riscrivere gli URL dinamici come "http://esempio.com/a/index.php?title=titolopagina" tramite il rewrite engine in URL statici come "http://esempio.com/articolo/titolopagina", si utilizzano diversi comandi a seconda si impostino i reindirizzamenti su un web server Apache, nginx o lighttpd.

Il rewrite engine su Apache

Per utilizzare il mod_rewrite su Apache, il rewrite engine deve essere attivato con la direttiva RewriteEngine on. A questa segue la RewriteRule, in cui sono definite le indicazioni per l’URL Rewriting servendosi di espressioni regolari (“regular expressions”, Regex):

RewriteEngine on
RewriteRule ^/articolo/(.*)$ /a/index.php?title=$1

Se tramite la RewriteRule deve essere impostato un reindirizzamento, si prendono essenzialmente in considerazione due parametri: lo schema di ricerca e lo schema di destinazione.

  • Lo schema di ricerca: questo parametro descrive gli URL che devono essere reindirizzati. Per questo viene definita una condizione precisa sotto forma di sequenza numerica. Se questa condizione viene soddisfatta, si verifica un reindirizzamento ad un URL secondo lo schema di destinazione. Nell’esempio attuale lo schema di ricerca della RewriteRule indicata nel segmento sarebbe: ^/articolo/(.*)$.
  • Lo schema di destinazione: questo parametro descrive l’URL alla quale bisogna reindirizzare. Se il reindirizzamento è impostato a livello di server, si verifica una sostituzione dell’URL completo. A livello della directory, nel file .htaccess o all’interno di quello httpd.conf viene semplicemente sostituito il percorso a partire dalla cartella attuale. Nell’esempio lo schema di destinazione comprende questo tipo di RewriteRule: /a/index.php?title=$1.

La tabella qui sotto mostra una spiegazione delle espressioni regolari usate nell’esempio:

Espressioni regolari Spiegazione
^ Indica l’inizio di una stringa.
$ Segna la fine di una stringa.
(.*) Un segnaposto per una sequenza numerica qualsiasi in un URL. Le parentesi salvano la sequenza numerica in una variabile.
$1 Una variabile che consente di accedere ai valori memorizzati temporaneamente, salvati utilizzando le parentesi.

La RewriteRule ^/articolo/(.*)$ /a/index.php?title=$1 definisce così la regola che tutti gli URL che cominciano con la stringa /articolo/(.*) vengono riscritti nello schema di URL dinamico con questo segmento /a/index.php?title=$1, dove $1 sta per la sequenza numerica che corrisponde al segnaposto (.*). Se un utente inserisce un URL statico nel browser come "http://esempio.com/articolo/titolopagina" il web server lo riscrive, basandosi sul mod_rewrite interno e invisibile agli utenti, nell’URL dinamico "http://esempio.com/a/index.php?title=titolopagina". Il segnaposto (.*) e la variabile $1 corrispondono in questo caso alla sequenza numerica “titolopagina“.   Se l’URL Rewriting deve essere collegato a opzioni specifiche, che regolano il comportamento del mod_rewrite, si annotano tra parentesi quadre dopo la RewriteRule e sono separate da virgole, qualora siano presenti più opzioni. In questo modo si possono realizzare anche reindirizzamenti esterni tramite codici di stato HTTP. La tabella seguente mostra una selezione di opzioni per la RewriteRule, mentre una lista completa si trova sul sito ufficiale di Apache Software Foundation.

Opzione Flag Funzione
Redirect R La flag [R] indica al web server di eseguire un reindirizzamento esterno tramite codice di stato 302. Se dovesse venir inviato un altro codice, viene aggiunta alla flag il simbolo uguale (ad esempio [R=301]).
Forbidden F La flag [F] indica al web server di inviare al browser il codice di stato 403 (Forbidden).
Gone G La flag [G] indica al web server di inviare al browser il codice di stato 410 (Gone) e segnala che il sito richiesto non è più presente all’indirizzo inserito.
Last L La flag [L] indica al web server di non eseguire altri comandi dopo la RewriteRule attuale.
Nocase NC Questa flag indica che, quando si verifica se un URL rispetta le condizioni per il rewriting, non si presta attenzione alle lettere maiuscole o minuscole.
Chain C La flag [C] indica di considerare la RewriteRule successiva, solo se si verifica la condizione attuale.

Basandosi su un‘opzione simile, si può realizzare un reindirizzamento esterno tramite un codice di stato HTTP nel modo seguente:

RewriteEngine On
RewriteRule ^vecchiapagina.html$ /nuovapagina.html [R=301]

Oltre alle RewriteRules si possono definire anche le RewriteConds, con le quali i webmaster stabiliscono le condizioni aggiuntive da soddisfare affinché avvenga l’URL Rewriting.

La sintassi di una RewriteCond possiede la struttura mostrata di seguito e viene annotata prima della RewriteRule: 

RewriteCond TESTSTRING CONDITION

La teststring contiene solitamente le variabili server, che sono definite dal simbolo della percentuale e da parentesi graffe, per esempio %{HTTP_HOST}. La tabella seguente mostra una selezione di variabili server.

Variabile server Spiegazione
HTTP_USER_AGENT Si riferisce al client che viene utilizzato per accedere al server. La variabile viene solitamente utilizzata per mettere a disposizione dei diversi browser il corrispondente sito ottimizzato.
HTTP_HOST Si riferisce ai nomi host, che possono comprendere valori come dominio.com, sottodominio.dominio.com o l’indirizzo IP.
SERVER_PORT Si riferisce alle porte richieste (ad esempio 80 per quella HTTP o 443 per quella HTTPS). La variabile consente ai webmaster di reindirizzare i visitatori su una connessione sicura.
REMOTE_ADDR Si riferisce all’indirizzo IP del web server dell’utente che richiede la pagina. Questa variabile viene anche usata per bloccare gli attacchi spam.

L’esempio seguente indica una RewriteCond, che collega una RewriteRule successiva all’indirizzo IP dell’utente che richiede la pagina:

RewriteCond %{REMOTE_ADDR} 173.45.68.79

L’URL Rewriting su nginx

Anche il web server nginx supporta già di suo l’URL Rewriting, realizzato sempre servendosi di espressioni regolari. Per riscrivere gli URL, viene aggiunto il comando rewriting corrispondente nella sintassi nginx in un blocco { [...] } nel file di configurazione del web server /etc/nginx/nginx.conf:

location /articolo {
 rewrite ^/articolo/(.*)$ /index.php?title=$1 last;
}

 Con location/articolo i webmaster stabiliscono che l’URL Rewriting si riferisce alla sottocartella articolo. Le espressioni regolari per il rewriting corrispondono a quelle in uso sul web server Apache e vengono introdotte dal comando rewrite. La flag last indica che il rewriting deve avvenire internamente e senza reindirizzamento. In alternativa sono messe a disposizione le flag per un reindirizzamento temporaneo o permanente:

Flag Spiegazione
last Gli URL vengono riscritti internamente e non si verifica alcun reindirizzamento.
redirect L’utente viene reindirizzato temporaneamente al nuovo URL tramite Redirect 302.
permanent L’utente viene reindirizzato permanentemente al nuovo URL tramite Redirect 301.

Se non viene impostata alcuna flag, il web server nginx restituisce automaticamente il codice HTTP di errore 500.

Il rewrite su lighttpd

Nel web server lighttpd si realizza l’URL Rewriting grazie alla funzione url.rewrite-TYPE. Al segnaposto TYPE corrispondono diversi tipi di configurazione per il rewriting:

Tipi di configurazione per il rewriting Spiegazione
url.rewrite-once L‘URL Rewriting avviene una sola volta. Se è stato trovato lo schema di ricerca e riscritto l’URL secondo lo schema di destinazione, non si verificano altri reindirizzamenti.
url.rewrite-repeat Al contrario di url.rewrite-once, con url.rewrite-repeat possono verificarsi altri reindirizzamenti dopo il primo.

La sintassi riprende essenzialmente il classico schema, in quanto anche su lighttpd ricorrono le stesse espressioni regolari come sul web server Apache: 

url.rewrite-once = (
 "^/articolo/(.*)$" => "/index.php?title=$1"
)

Se al posto di un reindirizzamento interno, deve avvenirne uno esterno, su lighttpd non viene utilizzato il modulo rewriting, ma un modulo di redirect, anche se gli URL attraversano prima il modulo rewrite e poi quello di redirect.

Il rewrite su Microsoft IIS

La piattaforma Microsoft Internet Information Services (IIS) non ha già a disposizione un rewrite engine, ma si può aggiungere successivamente il Modulo IIS URL Rewrite 2.0. Così anche gli utenti di Microsoft possono mettere a disposizione dei loro visitatori URL più intuitivi senza dover operare sulla gestione dei file interna. L’estensione per l’URL Rewriting, dopo essere stata scaricata, si integra direttamente nell’interfaccia IIS Manager, dove le RewritingRules vengono inserite tramite un’interfaccia utente grafica. Anche IIS URL Rewrite 2.0 utilizza espressioni regolari per definire lo schema di ricerca e di destinazione degli URL.

L‘URL Rewriting e l’ottimizzazione per i motori di ricerca

Si discute delle funzioni del mod_rewrite e delle sue corrispondenti realizzazioni negli altri sistemi di web server anche in relazione all’ottimizzazione per i motori di ricerca, in quanto gli URL classici possono essere riscritti in URL più intuitivi e user-friendly. Al centro della discussione è il fatto se gli URL user-friendly rientrino tra i fattori di ranking valutati dai motori di ricerca. Tuttavia, non ci sono ancora prove concrete di una diretta relazione, ma si presume che i webmaster traggano vantaggio da alcuni effetti indiretti. Al contrario dei parametri criptici, gli URL riscritti permettono agli utenti di capire dove porti un link. Il rewriting può essere così utilizzato per costruirsi un’immagine affidabile e in certi casi è responsabile dell’aumento del numero di click. Inoltre le parole chiave negli URL vengono evidenziati in grassetto nelle SERPs, cosa che può spingere a cliccare su quel risultato piuttosto che su un altro.

Hai trovato questo articolo utile?
Vai al menu principale