La prossima versione di IIS, la 7, si preannuncia come un grosso passo in avanti rispetto alle versioni attuali, soprattutto in chiave di estendibilità e funzionalità presenti.

Se è vero che IIS 6 è attualmente il più sicuro web server sul mercato (e l'invidiabile record di nessun bug di sicurezza in oltre due anni e mezzo di presenza sul mercato ne è una palese testimonianza), l'area in cui IIS 7 andrà ad incidere più significativamente è quella del consolidamento delle funzionalità e quindi, di riflesso, della riduzione dei costi di esercizio di un'applicazione web.

Se dovessimo fare un gioco e trovare tre termini per descrivere IIS 7, molto probabilmente sarebbero:

• estendibile;
• facilmente configurabile;
• sicuro.

Estendibilità e configurazioni senza compromessi

L'area in cui IIS 7 è un'autentica innovazione rispetto alla precedenti versioni (anche della versione 6 che in questa direzione segna comunque notevoli passi avanti) è sicuramente quella dell'estendibilità.

IIS 6, attualmente, si basa su un modello di configurazione che dipende da un file XML, il probabilmente già noto metabase, le cui informazioni all'interno sono modificabili solo attraverso il tool di amministrazione (a meno di non rischiare, molto facilmente, di compromettere la configurazione del server) dal solo amministratore (e quindi non sulla base di ogni singolo gestore di sito web).
Questo vuol dire molto semplicemente che con IIS 6, se si vuole migrare un'applicazione da un server all'altro, si deve, con buona pace del vostro sistemista, impostare nuovamente tutta la configurazione in modo che rifletta permessi, pagine di errore custom, filtri ISAPI e quant'altro sia stato personalizzato. Questa operazione molte volte porta ad un'enorme perdita di tempo e soprattutto ad una configurazione che non sempre è identica alla precedente.
Inoltre, anche se il metabase è facilmente migrabile, dato che è un file XML, per sua stessa natura contiene tutte le informazioni dei siti presenti sul server e quindi spesso si è costretti a dover procedere all'esportazione e relativa importazione manuale dei singoli siti web oggetto dello spostamento.

IIS 7 si comporta in modo diverso. Se siete già pratici di ASP.NET, sapete che molte delle impostazioni di configurazione di una applicazione web sono salvate in un solo file, chiamato web.config, che ha un parente superiore, che agisce a livello di configurazione di sistema, il machine.config. Questo paradigma rende possibile il deployment dell'applicazione semplicemente copiando tutti i file di cui è composta, ovvero pagine, immagini e risorse esterne ed ovviamente il web.config stesso.

IIS 7 abbraccia quest'idea, prevedendo due file di configurazione, entrambi basati su XML e completamente modificabili sia manualmente, sia attraverso tool di sviluppo, sia attraverso le solite API, come WMI (Windows Management Instrumentation). Questi file di configurazione sono il web.config, per ogni singola applicazione, e l'applicationHosting.config per l'intero IIS 7.

Dunque, per spostare un'applicazione in IIS 7, ad esempio dalla macchina di testing a quella di produzione, è sufficiente copiare tutti i file per ritrovarsi con l'esatta configurazione (come IP bloccati, pagine di default, estensioni speciali) che è stata creata sulla macchina di sviluppo. Il vantaggio è che basta banalmente fare la copia fisica di tutti i file per ritrovarsi pronti a partire. In questo scenario, come si può notare, il lavoro vero e proprio degli amministratori si limita al fine-tuning ed alla messa in sicurezza del server web, mentre per gli sviluppatori web il deployment con XCopy diventa una realtà a tutti gli effetti.

Un modello unificato

Il modello di estendibilità delle funzionalità utilizzato da IIS, sin dalla versione 3, è quello noto con il nome di ISAPI Filter. Non si tratta d'altro che di oggetti COM che vengono installati sul server e che si registrano nella pipeline della richiesta/risposta, in modo da intercettare determinati eventi. Concettualmente ricordano molto da vicino gli HttpHandler e gli HttpModule di ASP.NET, che hanno però il vantaggio di essere facilmente realizzabili, dato che sono scritti in managed code, ed ancora più facilmente registrabili (basta copiare il file che li contiene e fare una piccola modifica al web.config). Lo stesso engine di ASP.NET utilizza questa tecnica per alcune funzionalità, come la FormsAuthentication o i meccanismi di OutputCache, che sono basati proprio su HttpModule.

IIS 7, oltre ad unificare la fase di autenticazione, include direttamente nel core del web server il supporto per gli HttpModule. Questo vuol dire che è possibile definire HttpModule, come quello di autenticazione, che agiscano su qualsiasi tipo di contenuto che venga servito dalla pipeline del server, dato che di fatto gli HttpModule vengono elevati al rango degli ISAPI Filter (cosa che in IIS 6 non è assolutamente possibile).

Per capirci meglio, con IIS 7 è possibile proteggere anche contenuti non mappati direttamente sul motore di ASP.NET, come file ASP, PHP piuttosto che ZIP, semplicemente perché ASP.NET è dentro IIS 7 e quindi tutte le funzionalità fornite esternamente al core sono implementate attraverso HttpModule.

Nell'installazione di default di IIS 7 ci sono diversi moduli (modules) di default, come ad esempio ASPNET, ASP, defaultPage, serverSideIncludesModule. Come il nome stesso suggerisce, questi moduli non sono altro che estensioni che possono essere aggiunte al web server, per dotarlo di una possibile caratteristica aggiuntiva, come può appunto essere il supporto per ASP.NET, piuttosto che un HttpModule che si occupi di fornire la pagina di default.

Proprio come è possibile in un'applicazione ASP.NET aggiungere o eliminare HttpModule, così è possibile fare lo stesso in IIS 7, sfruttando sempre il web.config:

<configuration>
    <system.webServer>
        <modules>
            <remove name="HttpLoggingModule" />
        </modules>
        <serverFeatures>
            <remove name="Cgi" />
        </serverFeatures>
    </system.webServer>
</configuration>

In questo esempio abbiamo rimosso le funzionalità di logging e disattivato il supporto per CGI.

La possibilità di "componentizzare" IIS permette l'ottimizzazione del sistema stesso, dato che è possibile rimuovere le funzionalità che non si utilizzano (come l'autenticazione Windows, piuttosto che il supporto per CGI). Tra l'altro questo approccio consente anche di ridurre la superficie di attacco del web server, rendendo il sistema più sicuro dato che presenta meno funzionalità non utilizzate esposte verso l'esterno.