Uso del routing in IIS 7 e 6

Utilizzare i meccanismi di routing risulta particolarmente semplice su IIS 7. Il web server di Windows Server 2008 è direttamente compatibile con il routing di ASP.Net MVC perchè contiene al suo interno un meccanismo di URL Rewriting in grado di gestire senza problemi gli indirizzi puliti (senza estensioni come .aspx) utilizzati da MVC. Tutti i progetti creati tramite Visual Studio funzioneranno quindi automaticamente su IIS 7 senza bisogno di configurazioni aggiuntive.

I meccanismi di routing risultano invece più complicati da implementare se si lavora con IIS 6. ASP.Net, infatti, è caricato all'interno di questa versione di IIS come modulo ISAPI, che viene interpellato dal web server soltanto nel caso di pagine con estensione .aspx, .ashx, ecc. Se un client richiede una semplice pagina HTML, quindi, il modulo ASP.Net non entrerà in esecuzione.

Lo stesso discorso vale anche per gli URL utilizzati da ASP.Net MVC in cui non compare l'estensione .aspx. I meccanismi di routing di MVC sono infatti interamente gestiti da ASP.Net, senza alcun intervento di IIS. Appare quindi evidente che se quest'ultimo non associa una determinata richiesta ad ASP.Net le regole di routing non verranno valutate, risultando in un errore di tipo 404 (pagina non trovata). Per verificare quest'ultima affermazione è sufficiente caricare la nostra galleria di immagini su IIS 6 ed aprire l'home page:

Figura 21. Errore 404 su IIS 6

Esistono diverse soluzioni al problema di cui forniamo per completezza una breve panoramica, ma una trattazione approfondita esula dagli scopi della guida.

Wildcard mapping

Possiamo configurare IIS in modo che tutte le richieste ricevute dal server siano processate da ASP.Net. In questo modo, anche in caso di URL senza estensioni, la richiesta verrebbe elaborata dal motore di ASP.Net. Il problema legato a questa soluzione riguarda principalmente il rapido deterioramento delle performance dovuto all'elaborazione aggiuntiva necessaria, soprattutto per siti di media o grande dimensione. Inoltre non sarà possibile applicare questa soluzione in ambienti hosting condivisi, dove non viene generalmente concesso accesso alla configurazione di IIS.

Aggiungere .aspx nell'URL

Visto che tutti gli URL includeranno l'estensione .aspx saranno associati automaticamente da IIS al motore di ASP.Net. Gli URL risultanti, come ad esempio /gallery.aspx/show/5, perderanno tuttavia la pulizia propria degli indirizzi senza estensione. Per implementare questa soluzione è sufficiente una piccola modifica alle regole di routing:

routes.MapRoute( "Default", 
                 "{controller}.aspx/{action}/{id}",
                 new { controller = "Home", action = "Index", id = "" }
               );

È importante sottolineare come questa soluzione funzionerà anche in ambienti di hosting condiviso.

Moduli di URL Rewriting

Rappresentano la soluzione più completa, ma comportano solitamente delle spese aggiuntive e la necessità di avere accesso al pannello di amministrazione di IIS. Questa soluzione consiste nell'utilizzo di un modulo ISAPI di terze parti (ad esempio Isapi Rewrite, a pagamento, o Ionic's ISAPI Rewrite Filter, gratuito) per IIS in grado di "ingannare" il web server facendogli credere che l'URL contenga una estensione quando invece questa non è presente, un po' come avviene automaticamente all'interno di IIS 7. I moduli di URL Rewriting funzionano in questo modo:

1. quando arriva una richiesta priva di estensioni, il modulo entra in funzione ed aggiunge l'estensione .aspx all'URL;
2. IIS vede l'estensione ed associa la richiesta ad ASP.Net;

In questo modo l'utente e i motori di ricerca otterranno URL puliti e privi di estensioni, mentre IIS a causa dell'aggiunta di .aspx passerà l'esecuzione della richiesta ad ASP.Net.