Riscrittura e ASP.NET routing degli URL IIS
Con la versione del modulo di riscrittura URL per IIS e l'inclusione del routing di ASP.NET in .NET Framework 4, ci sono state molte domande da parte degli sviluppatori ASP.NET su come queste due funzionalità sono correlate tra loro e quando si deve usare uno o l'altro. Questo documento descrive le differenze tra queste due tecnologie e fornisce indicazioni per gli sviluppatori Web su quando usare la riscrittura dell'URL IIS e quando usare ASP.NET routing.
Dal punto di vista generale, sembra che queste tecnologie forniscano funzionalità molto simili, entrambe consentono alle applicazioni Web di avere URL descrittivi e descrittivi per il motore di ricerca. Tuttavia, esistono differenze fondamentali tra queste due tecnologie che sono importanti per comprendere per prendere la decisione corretta su cosa usare per l'applicazione Web. Per comprendere queste differenze, verrà illustrato prima di tutto come funziona la riscrittura dell'URL IIS e ASP.NET il funzionamento del routing.
Riscrivere l'URL IIS
L'idea di base della riscrittura dell'URL non è un nuovo concetto. È stato introdotto nel server Web Apache circa dieci anni fa. Da allora ha dimostrato di essere uno strumento molto utile per gli amministratori del server Web e gli sviluppatori Web. Molte applicazioni popolari ospitate in Apache si basano ora sulla riscrittura dell'URL per abilitare il supporto per gli URL "puliti".
Il concetto di riscrittura dell'URL è semplice. Quando un client invia una richiesta al server Web per un URL specifico, il modulo di riscrittura dell'URL analizza l'URL richiesto e lo modifica in un URL diverso nello stesso server. Il modulo di riscrittura dell'URL viene eseguito all'inizio della pipeline di elaborazione delle richieste, modificando l'URL richiesto prima che il server Web decida quale gestore usare per elaborare la richiesta. Il gestore, scelto in base all'URL riscritto, elabora la richiesta e genera una risposta inviata al Web browser. Il client di richiesta non vede mai l'URL riscritto; per quanto riguarda il client, ha ricevuto una risposta dall'URL originale.
In termini di architettura IIS, questo processo è rappresentato dal diagramma seguente:
Il modulo di riscrittura URL è un modulo di codice nativo che si collega alla pipeline di elaborazione delle richieste nelle fasi Di pre-inizio richiesta o Inizia richiesta e quindi valuta il percorso URL richiesto usando un set di regole di riscrittura. Ogni regola di riscrittura analizza il percorso DELL'URL e, se tutte le condizioni della regola vengono soddisfatte, modifica il percorso originale in un nuovo percorso. Dopo aver valutato tutte le regole, il modulo di riscrittura URL produce un percorso URL finale usato per la richiesta tramite il resto dell'elaborazione della pipeline IIS. Ciò significa che la selezione del gestore nella pipeline IIS viene eseguita in base all'URL riscritto generato dal modulo Di riscrittura URL.
Routing di ASP.NET
ASP.NET routing è un meccanismo di invio delle richieste che consente agli sviluppatori di associare un determinato URL a un gestore che può elaborare le richieste effettuate a tale URL. Questa associazione viene eseguita registrando le "route" che definiscono quale gestore richiamare per un determinato percorso URL. Quando viene effettuata una richiesta a un server Web ASP.NET routing cerca il percorso URL richiesto nell'elenco di route registrate. Se viene trovata la route, viene richiamato il gestore corrispondente per tale route per elaborare tale richiesta.
In termini di architettura IIS e ASP.NET, questo processo è rappresentato dal diagramma seguente:
ASP.NET routing viene implementato come modulo di codice gestito che si collega alla pipeline di elaborazione delle richieste IIS nella fase di risoluzione della cache (evento PostResolveRequestCache) e nella fase del gestore mappa (evento PostMapRequestHandler). ASP.NET routing è configurato per l'esecuzione per tutte le richieste effettuate all'applicazione Web.
Durante l'evento PostResolveRequestCache, il modulo esamina una tabella di routing (una raccolta di oggetti route) per una route corrispondente al percorso URL richiesto. Se viene trovata una corrispondenza, il modulo ottiene un riferimento al gestore che corrisponde a tale route e salva il riferimento come parte del contesto HTTP corrente. Un gestore può essere qualsiasi oggetto .NET Framework che implementa l'interfaccia System.Web.IHttpHandler. Se non viene trovata alcuna route, il modulo non esegue alcuna operazione e l'URL viene elaborato normalmente (in genere corrispondendo a un file su disco).
Durante l'evento PostMapRequestHandler, il modulo verifica se il contesto HTTP contiene informazioni su un gestore. In caso affermativo, ASP.NET routing usa le informazioni per impostare la proprietà Gestore del contesto HTTP corrente. Ciò garantisce che durante la fase Execute Handler, IIS eseguirà il gestore selezionato dal modulo di routing. Se queste informazioni non sono impostate, il modulo non esegue alcuna operazione e l'URL passa per consentire a IIS di eseguire una selezione del gestore.
Differenze tra la riscrittura dell'URL IIS e il routing ASP.NET
In base alla spiegazione precedente, esistono le differenze concettuali principali seguenti tra la riscrittura dell'URL IIS e il routing ASP.NET:
- La riscrittura dell'URL viene usata per modificare i percorsi URL prima che la richiesta venga gestita dal server Web. Il modulo di riscrittura dell'URL non sa quale gestore elabora l'URL riscritto. Inoltre, il gestore di richieste effettivo potrebbe non sapere che l'URL è stato riscritto.
- ASP.NET routing viene usato per inviare una richiesta a un gestore in base al percorso URL richiesto. Anziché riscrivere l'URL, il modulo di routing conosce i gestori e seleziona il gestore che deve generare una risposta per l'URL richiesto. È possibile pensare ASP.NET routing come meccanismo avanzato di mapping dei gestori.
Oltre a queste differenze concettuali, esistono le differenze funzionali seguenti tra la riscrittura dell'URL IIS e il routing ASP.NET:
- Il modulo di riscrittura URL IIS può essere usato con qualsiasi tipo di applicazione Web, che include ASP.NET, PHP, ASP e file statici. ASP.NET routing può essere usato solo con applicazioni Web basate su .NET Framework.
- Il modulo di riscrittura URL IIS funziona nello stesso modo, indipendentemente dal fatto che la modalità della pipeline IIS integrata o classica venga usata per il pool di applicazioni. Per ASP.NET routing, è preferibile usare la modalità pipeline integrata. ASP.NET il routing può funzionare in modalità classica, ma in tal caso gli URL dell'applicazione devono includere estensioni di nome file o l'applicazione deve essere configurata per usare il mapping del gestore "*" in IIS.
- Il modulo di riscrittura URL IIS può prendere decisioni di riscrittura in base ai nomi di dominio, alle intestazioni HTTP e alle variabili del server. Per impostazione predefinita, il routing ASP.NET funziona solo con i percorsi URL e con l'intestazione HTTP-Method.
- Oltre alla riscrittura, il modulo di riscrittura URL può eseguire il reindirizzamento HTTP, inviare codici di stato personalizzati e interrompere le richieste. ASP.NET routing non esegue queste attività.
- Il modulo di riscrittura URL non è estendibile nella versione corrente. ASP.NET routing è completamente estendibile e personalizzabile.
Quale opzione è consigliabile usare?
Cosa significa che tutte queste informazioni significano se è necessario scegliere una tecnologia per abilitare URL puliti per le applicazioni Web? In questa sezione viene illustrato come fare questa scelta.
Se l'applicazione Web viene compilata usando qualsiasi elemento tranne ASP.NET, usare il modulo di riscrittura URL IIS. In caso contrario, le regole sono:
- Se si sta sviluppando una nuova applicazione Web ASP.NET che usa ASP.NET MVC o ASP.NET tecnologie Dinamico dati , usare ASP.NET routing. L'applicazione può trarre vantaggio dal supporto nativo per gli URL puliti, inclusa la generazione di URL puliti per i collegamenti nelle pagine Web. Si noti che ASP.NET routing non supporta ancora applicazioni Web Forms standard, anche se in futuro sono previsti piani per supportarlo.
- Se si dispone già di un'applicazione Web legacy ASP.NET e non si vuole modificarla, usare il modulo Di riscrittura URL. Il modulo Di riscrittura URL consente di tradurre gli URL descrittivi del motore di ricerca in un formato attualmente usato dall'applicazione. Consente inoltre di creare regole di reindirizzamento che possono essere usate per reindirizzare i crawler del motore di ricerca agli URL puliti.
In pratica, tuttavia, la scelta non deve essere né/o. Le tecnologie possono essere usate insieme e possono integrarsi tra loro. Nelle sezioni seguenti vengono descritti alcuni scenari in cui è possibile usare ASP.NET routing e la riscrittura dell'URL IIS.
Applicazione degli URL canonici per l'applicazione.
È consigliabile forzare l'uso di http://www.mysite.com/home/abouthttp://mysite.com/Home/Aboutanziché . Quando un client Web richiede un URL non conforme al formato desiderato, il client viene reindirizzato a un URL canonico. In questo scenario è possibile usare il modulo Di riscrittura URL per applicare URL canonici ed eseguire il reindirizzamento e usare ASP.NET routing per selezionare un gestore che elabora il percorso URL richiesto.
Nell'esempio seguente viene illustrata una regola di riscrittura URL che è possibile usare per questo scenario:
<rewrite>
<rules>
<rule name="Enforce canonical hostname" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" negate="true" pattern="^www\.mysite\.com$" />
</conditions>
<action type="Redirect" url="http://www.mysite.com/{R:1}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
Servizio di contenuto statico da un sito o un server diverso.
L'applicazione Web viene distribuita in più server in modo che il contenuto Web dinamico si trovi in un sito o in un server e tutto il contenuto statico si trova in un sito o in un server diverso. È possibile usare il modulo Di riscrittura URL insieme al modulo di routing della richiesta applicazione IIS per inoltrare tutte le richieste di file statici a un server diverso, mentre gestisce tutte le richieste per le pagine Web dinamiche dal server corrente. In questo modo, ASP.NET routing viene usato solo per il contenuto Web dinamico e non valuta gli URL per il contenuto statico.
Nell'esempio seguente viene illustrata una regola di riscrittura URL che è possibile usare per questo scenario:
<rewrite>
<rules>
<rule name="Forward to static file server">
<match url="^.+\.(?:jpg|bmp|gif)$" />
<action type="Rewrite" url="http://static_file_server/{R:0}" />
</rule>
</rules>
</rewrite>
Gestione dei contenuti statici.
Quando i file o le cartelle statici vengono spostati in una nuova posizione, è comunque possibile supportare gli URL precedenti per motivi di compatibilità con le versioni precedenti. In effetti, potrebbe non essere necessario che i visitatori del sito Web sappiano che i file o le cartelle sono stati spostati. In tal caso, è possibile usare il modulo di riscrittura URL per riscrivere i percorsi per i file statici, mentre tutti gli URL per le pagine Web dinamico ASP.NET vengono gestiti dal modulo di routing.
Nell'esempio seguente viene illustrata una regola di riscrittura URL che è possibile usare per questo scenario:
<rewrite>
<rules>
<rule name="Rewrite to new folder">
<match url="^Images/(.+)$" />
<action type="Rewrite" url="NewImages/{R:1}" />
</rule>
</rules>
</rewrite>
Blocco delle richieste.
Il modulo di riscrittura URL può essere usato per bloccare determinate richieste in base a vari criteri. Ad esempio, è possibile impedire a determinati crawler del sito di accedere a percorsi URL specifici nel sito Web. In questo modo, le richieste non consentite non potranno nemmeno arrivare al router ASP.NET, riducendo così il carico sul server Web.
Nell'esempio seguente viene illustrata una regola di riscrittura URL che è possibile usare per bloccare i crawler del sito indesiderati. Si noti che le richieste vengono bloccate per un determinato percorso URL in base all'intestazione HTTP dell'agente utente o in base all'indirizzo IP del client:
<rewrite>
<rules>
<rule name="Block SomeRobot" stopProcessing="true">
<match url="^folder1/folder2" />
<conditions logicalGrouping="MatchAny">
<add input="{USER_AGENT}" pattern="SomeRobot" />
<add input="{REMOTE_ADDR}" pattern="201\.45\.33\.[0-5]" />
</conditions>
<action type="AbortRequest" />
</rule>
</rules>
</rewrite>
Direzioni future
Anche se la riscrittura dell'URL IIS e ASP.NET routing ha una sovrapposizione funzionale, indirizzano scenari univoci per ogni tecnologia. A causa di ciò, queste due tecnologie continueranno a esistere ed evolversi come componenti indipendenti in IIS, con il potenziale di integrazione più stretta tra di essi. Ad esempio, ASP.NET routing può sfruttare alcuni degli strumenti avanzati forniti con il modulo Di riscrittura URL. Il modulo di riscrittura URL può essere integrato meglio con ASP.NET in termini di estendibilità per personalizzare la logica di riscrittura url.
Conclusione
La riscrittura dell'URL IIS o ASP.NET routing può essere usata per implementare scenari di manipolazione degli URL per l'applicazione Web. ASP.NET routing è una soluzione ottimizzata per ASP.NET, pertanto può essere preferibile per gli sviluppatori Web che progettano le applicazioni ASP.NET da zero e vogliono avere una struttura url pulita. La riscrittura url IIS è un meccanismo generico di manipolazione degli URL che risolve una moltitudine di scenari. In particolare, può essere usato dagli sviluppatori Web e dagli amministratori del server Web/sito per abilitare URL puliti per le applicazioni Web esistenti senza modificare il codice dell'applicazione.