Il progetto di riscrittura delle URL, conosciuto come mod_rewrite nacque in seguito ad una particolare necessità: quella di rendere digeribili gli indirizzi web ai motori di ricerca. Già nel 1999 PHP faceva la sua, timida, comparsa e le pagine web dinamiche iniziavano ad essere sempre maggiormente apprezzate. Con il corso del tempo passare indirizzi, mediante GET, diventava quasi una necessità in quanto tale variabili erano intercettate, processate e restituite sotto forma di output generato all'utente.

Il web dinamico, insomma, non è stato più esclusiva di poche aziende specializzate ma grazie alla crescente mole di documenti per scrivere codice in PHP anche un ragazzino avrebbe potuto avere la propria homepage dinamica.

Bello, vero? Se non fosse che l'affinità dei motori di ricerca verso le pagine dinamiche non si è migliorata parallelamente all'aumento del numero delle stesse. In altre parole gli algoritmi di ricerca ed indicizzazione delle pagine, ovvero il cuore degli spider ,non hanno tenuto il passo tagliando, di fatto, buona parte delle pagine dinamiche. Se vi sembra paradossale vi ricordo che ancora oggi, nel 2007, qualche motore di ricerca ha non pochi problemi ad indicizzare pagine dinamiche. Pensiamo ad esempio ad un motore di ricerca che vede le pagine index.php e index.php?azione=mostraArticolo&ID=1 come lo stesso contenuto.

L'idea di base della riscrittura delle URL non è di per sé complicata. Quando chiamiamo una pagina il webserver Apache controlla se questa è fisicamente presente nel server o, altrimenti, effettua un check per vedere se tale pagina può essere interpretata mediante mod_rewrite. In questo modo l'indirizzo

http://www.miosito.ext/index.php?caricalapagina=personale&operazione=benvenuto&altro=nonsaprei

Poteva essere richiamata da

http://www.miosito.ext/pagina_personale_operazione_benvenuto_altro_nonsaprei.html

In pratica Apache  mediante il modulo mod_rewrite e le regole contenute nel file .htaccess (vedremo dopo che cosa è), trasformava la seconda url e richiamava, in realtà, la prima. Senza che l'utente, o il motore di ricerca, si rendesse conto di nulla.

Pregi

Utilizzare il modulo mod_rewrite ha, senza dubbio, i suoi vantaggi. Per prima cosa l'url è facilmente indicizzabile dai motori di ricerca e, nel complesso, permette di avere un sito la cui apparenza è più pulita ed ordinata. Si pensi, ad esempio, ad un sito che fornisce articoli di diverse categorie. Poterli richiamare ognuno da una propria sottodirectory è una cosa oltre che pulita funzionale perchè, ad esempio, si possono creare in modo molto facile delle sitemap. Vediamo un esempio:


Usando le url canoniche come


sarebbe stato possibile ma di certo meno efficente. Inoltre un uso di mod_rewrite corretto può mettere al riparo l'intero sito da attacchi come XSS o MySQL injection.

...e difetti.

Ogni miglioria informatica introduce alcuni aspetti secondari. Mod_rewrite non sfugge da questa regola ed ha le sue problematiche che in sintesi sono le seguenti:

• Richiesta di risorse. Prima di servire una singola pagina Apache da sempre un'occhiata al file .htaccess e processa le regole. Questo si traduce in un consumo di risorse che, in caso di siti mediamente trafficati, può essere tuttaltro che indifferente.
• Necessità di comprendere il meccanismo di mod_rewrite e approfondimento delle espressioni regolari. Comprendere il meccanismo di funzionamento del modulo e le regole da usare non è semplice. Mod_rewrite deve essere opportunamente configurato così come le regole di riscrittura, situate all'interno del file .htaccess, devono essere scritte in modo ineccepibile. Le regole, in particolare, utilizzano il sistema di espressioni regolari che può sembrare ostico all'utente alle prime armi.

• Necessità di riadattare il codice. Sebbene molti CMS forniscono in automatico supporto alla riscrittura delle url potrebbe essere necessario riscrivere parte del codice del proprio progetto per far si che si integri con le nuove url. Se, ad esempio, una funzione ritorna un link
  
  http://www.nomesito.ext/index.php?articolo=45&categoria=biochimica
  
  La stessa funzione deve essere modificata per ritornare un url differente. Chiamando un url con il vecchio indirizzo, ovvero quello mostrato sopra, fa tornare il problema della rescrittura delle url al punto di partenza
• Possibilità che lo stesso codice non funzioni in altri webserver. Questa possibilità non è del tutto remota. Pensiamo, ad esempio, al programmatore che crea una funzione che restituisce un url "friendly":
  
  http://www.nomesito.ext/articoli/biochimica/emoglobina.html
  
  Su un server IIS, che non ha supporto al mod_rewrite, tale url non è corretto in quanto non esiste la pagina emoglobina.html in /articoli/biochimica/. Per questo motivo, per evitare incompatibilità, ogni funzione o porzione di codice che genera un link dovrebbe essere messo in condizione di sapere che tipo di url generare, ovvero se crare un classico url dinamico o un url modificato. Questo ostacolo, ovviamente, può essere semplicemente aggirato usando una direttiva di configurazione ma, altrettanto intuibilmente, comporta un doppio lavoro per il programmatore