Dopo gli articoli dedicati al protocollo HTTP, al ciclo HTTP request/response, e al ruolo del Web Server, è il momento di approfondire due concetti estremamente importanti che determinano l'interazione tra il client/browser e i percorsi di navigazione (le URL) utilizzati per raggiungere le pagine del World Wide Web: URL Rewrite e HTTP Redirect.
Come avremo modo di vedere in questo articolo si tratta di due tecniche che vengono solitamente gestite allo stesso modo dal web server (tipicamente tramite un modulo dedicato) ma che in realtà sono molto diverse tra loro, sia nel modo di influenzare la navigazione del browser che nell'utilizzo che se ne fa all'atto pratico: allo stesso modo, si tratta di due strumenti che qualsiasi Web Administrator deve conoscere, così da poterli utilizzare nel modo e nel momento più opportuno.
URL Rewrite
Cominciamo dunque con l'URL Rewrite: in estrema sintesi, si tratta di una tecnica che consente al web server di "riscrivere" internamente il percorso indicato dalla HTTP request in modo da puntare a un percorso differente. Il percorso "riscritto" può riguardare un file statico (come un'immagine), un file dinamico (come una pagina php), una cartella, o qualsiasi altra cosa che il web server possa gestire in modo nativo o avvalendosi di handler, moduli, interfacce CGI, etc.
La “riscrittura” del percorso è stabilita da un set di regole che è possibile impostare nel file di configurazione del Web Server: nella maggior parte dei casi ciascuna di queste regole si compone di tre elementi:
- un percorso di origine, ovvero quello presente nella HTTP request;
- un percorso di destinazione, ovvero quello “riscritto” internamente in modo da puntare a una destinazione differente;
- alcune opzioni di configurazione, tipicamente impostate tramite l’inserimento di uno o più flag, che consentono di specificare alcuni aspetti di come la regola deve essere applicata.
Ad esempio, la seguente regola di rewrite su Apache (utilizzando il modulo mod_rewrite):
RewriteRule ^wp-content/(.+) /files/$1 [NC,L]
Farà in modo che tutti i path presenti nelle HTTP Request che iniziano con /wp-content/ vengano “riscritti” come se invece comincino con /files/: in altre parole, saranno “cercati” nel filesystem all’interno della cartella /files/.
Osservando la sintassi della regola, possiamo vedere come essa si componga dei tre elementi fondamentali che abbiamo elencato poco fa:
- il percorso di origine: ^wp-content/(.+)
- il percorso di dstinazione: /files/$1
- le opzioni di configurazione: [NC,L]
I flag [NC,L] specificati nel terzo elemento della RewriteRule servono per determinare il comportamento tenuto da Apache relativamente a quella determinata regola. Nello specifico:
- NC: questo flag, se presente, rende la regola case-insensitive (ovvero, ignora il casing): in altre parole, se il pattern di ricerca presente nella request è presente con un casing diverso da quello utilizzato (es. /WP-CONTENT/ ), grazie al flag NC la regola sarà comunque considerata valida (match). Poiché Apache è un software nato su Linux, è case-sensitive di default.
- L: se questo flag è presente, se la URL presente nella request viene considerata valida per questa regola (match), non sarà applicata nessuna altra regola successiva a questa request: in altre parole, non saranno applicate altre RewriteRule.
Le regole di rewrite hanno un'importanza fondamentale nell'ottica del ruolo svolto dal web server, poiché consentono di controllare in che modo quest'ultimo andrà a processare le URL (e relativi path) inviate dalle HTTP Request.
Lo schema è riassumibile nel seguente modo:
- CLIENT/BROWSER >
- HTTP Request (con relativa URL) >
- Web Server (con eventuali regole di rewrite) >
- Percorso vero e proprio (FileSystem, server-side script, etc.) >
- Web Server (con eventuali regole di rewrite) >
- HTTP Request (con relativa URL) >
Le regole di rewrite possono essere utilizzate per una pluralità di funzioni, tra cui anche quella di impedire ai client/browser di eseguire determinati percorsi.
Ad esempio, la regola seguente impedisce al Web Server di eseguire il file wp-admin/install.php ai client, così da impedire a questi ultimi di reinstallare WordPress (che si suppone essere stato già installato in precedenza):
RewriteRule ^wp-admin/install\.php$ - [F]
Un'altra cosa fondamentale da comprendere è che le regole di rewrite, a meno che non implichino un redirect, non modificano la URL richiesta dal client/browser tramite la sua HTTP Request: in altre parole, il client/browser non avrà idea dei ragionamenti effettuati dal server (ovvero delle regole impostate ed applicate) per gestire la URL richiesta: dal suo punto di vista la URL resta quella indicata nella fase iniziale, anche se poi il server la gestisce attraverso una o più regola che ne cambiano totalmente l’ubicazione effettiva. Se si vuole fare in modo che il client venga “reindirizzato” a una URL diversa, invece di un rewrite occorre utilizzare un HTTP Redirect.
HTTP Redirect
A differenza dell'URL Rewrite, che (come detto) si “limita” ad applicare delle regole lato web server, senza informare il client, l'HTTP Redirect ha lo scopo di “reindirizzare” il client su una URL diversa da quella inizialmente chiamata.
Per comprendere la differenza osserviamo la seguente regola HTTP Redirect:
RewriteRule ^wp-content/(.+) /files/$1 [NC,L, R]
Come si può vedere la regola di cui sopra è quasi identica alla precedente, con una sola differenza. L’utilizzo del flag R. Tale flag rende la regola un Redirect, ovvero reindirizza il client alla “nuova” destinazione definita tramite la regola stessa. In altre parole, il client che effettua una request specificando la seguente URL:
- https://www.ryadel.com/wp-content/file.jpg
Sarà “reindirizzato” a una URL diversa, ovvero la seguente:
- https://www.ryadel.com/files/file.jpg
La differenza sostanziale tra URL Rewrite e HTTP Redirect è che il Rewrite elabora la HTTP request inviata dal client, sia pure “riscrivendone” internamente il percorso, mentre il Redirect risponde con una HTTP response che ha il compito di reindirizzare il client su una nuova URL: in altre parole, forza il client a effettuare una ulteriore HTTP request, alla quale l’oggetto del redirect (il server web stesso o un altro server web) risponderà con una seconda HTTP response. Ovviamente, anche questa seconda response potrebbe a sua volta essere un redirect, spingendo il client a effettuare una terza HTTP request… e così via, fino a quando non viene comunicata una URL in grado di fornire una response “terminale” (ovvero diversa da un redirect).
Redirect URL
La URL di destinazione del redirect è specificata mediante il Response Header Location, che ha il seguente formato:
- Location: <url>
Il redirect può essere effettuato su una URL relativa, che sarà quindi con tutta probabilità gestita dal medesimo web server:
- Location: /index.html
Oppure da una URL assoluta, che potrà essere gestita dal medesimo web server o da un altro a seconda del puntamento del dominio di destinazione:
- Location: https://www.google.com/
Redirect Status Code
Per convenzione, le HTTP response che determinano un redirect presentano uno Status Code appartenente alla classe 30x, la quale identifica i reindirizzamenti. I più comuni sono:
- 301 - Permanent. Quando il server risponde con questo Status Code indica che il redirect è considerato “permanente”, ovvero che la URL specificata dal client con la sua prima HTTP request è stata sostituita con la URL di destinazione del redirect a titolo definitivo. In conseguenza di questo Status Code molti client/browser effettuano un “caching” delle HTTP Response che presentano questo Status Code, così da reindirizzare autonomamente e automaticamente eventuali request future analoghe senza bisogno di interrogare nuovamente il server, dando per scontato che si riceverà sempre e comunque la stessa HTTP response (e il medesimo redirect).
- 302 - Found. Quando il server risponde con questo Status Code indica che il redirect è considerato “temporaneo”, ovvero che la URL specificata dal client con la sua prima HTTP request è stata sostituita con la URL di destinazione del redirect a titolo provvisorio. A differenza dello Status Code 301 - Permanent, questa HTTP response non viene messa in cache dai client/browser in quanto la risposta del server potrebbe variare nel corso del tempo.
Conclusione
Per il momento è tutto: ci auguriamo che la nostra panoramica generale su URL Rewrite e HTTP Redirect possa essere utile ai webmaster e agli amministratori di sistema che cercano indicazioni su come funzionano queste due tecniche fondamentali. Per una trattazione più dettagliata, comprensivo anche di alcuni esempi pratici di utilizzo, vi consigliamo di leggere l'articolo URL Rewrite e HTTP Redirect - Utilizzi Pratici.
