Uno dei problemi più frequenti negli ultimi anni, da quando è stata rilasciata la versione Windows 2003 Server, è la gestione dei percorsi, fisici e virtuali, relativi ed assoluti.
Il problema, maggiormente sentito da chi era abituato a gestire applicazioni sui precedenti sistemi Windows 2000 e NT è dato principalmente dal fatto che Windows 2003 Server (che chiameremo per semplicità Win2k3) di default ha implementato una diversa politica nella gestione dei percorsi, ufficialmente per una questione di sicurezza.
Prima di comprendere meglio il problema che sembra complicare la vita a numerosi sviluppatori vediamo brevemente le principali tipologie di path (o percorsi).
Relativi e Assoluti
Partendo da un file di origine e considerando un file di destinazione un percorso può essere espresso in modo dipendente da tale file e parleremo quindi di un percorso relativo, oppure in modo indipendente dall'origine ma legato alla più alta cartella del sito, ovvero la root, e parleremo quindi di percorso assoluto.
In genere la root del sito corrisponde esattamente al dominio del sito stesso. Avremo quindi che il dominio www.miosito.com corrisponderà alla root, mentre la cartella www.miosito.com/cartella/ corrisponderà alla cartella /cartella dentro la root.
Ecco due esempi, considerando un file origine.asp e destinazione.asp nella cartella /cartella/ .
Percorso relativo
destinazione.asp
Percorso assoluto
/cartella/destinazione.asp
Come potete notare, indipendentemente da dove si trovino i due file nel percorso assoluto si fa riferimento alla root.
Il percorso deve quindi sempre cominciare con uno / e per semplicità si può immaginare che prima di questo / ci sia l'indirizzo del sito, ad esempio:
www.miosito.com/cartella/destinazione.asp
Per il momento non facciamo caso alle altre differenze, che riassumeremo in
seguito.
Altra cosa importante da definire è quindi il comportamento di questi percorsi, ovvero come vanno gestiti. Nel caso di un percorso relativo si utilizzeranno le convenzioni adottate per l'HTML, mentre nel caso degli assoluti avremo qualche piccola modifica.
Ecco un breve riassunto:
| destinazione.asp | Percorso Relativo | Percorso Assoluto |
| Stessa posizione di origine.asp | Si specifica solo il Nome_del_file
origine.asp |
Si specifica il percorso completo dalla root inserendo ciascuna cartella seguita da uno / ed infine il Nome_del_file. Il percorso deve cominciare con uno / iniziale. /cart1/cart2/NomeFile Se il file si trova nella root andrà specificato solo in Nome_del_file preceduto dal solito /. /NomeFile |
| Cartella di 1 livello inferiore a origine.asp | Si specifica la cartella seguita da uno / e dal Nome_del_file
cart/origine.asp |
|
| Cartella di 1 livello inferiore a origine.asp | Come nel caso precedente si specifica ciascuna cartella seguita da uno / ed infine il Nome_del_file
cart/[cart/]origine.asp |
|
| Cartella di 1 livello superiore a origine.asp | Si specifica la simbologia standard .. seguita da uno / e dal Nome_del_file
../origine.asp |
|
| Cartella di N livelli superiori a origine.asp | Come nel caso precedente si specifica ciascun livello superiore come uno .. seguito da uno / ed infine il Nome_del_file
../[../]origine.asp |
Come si può notare la tipologia assoluta sembra decisamente più semplice poiché ha un solo caso, ma potrebbe risultare meno intuitiva per chi è abituato da tempo ai percorsi relativi.
Come scegliere il percorso giusto
Ammesso che possiate utilizzare entrambe le forme ecco le principali caratteristiche positive.
Relativo
- È indipendente dalla root quindi se si aggiungono o si sottraggono lo stesso numero di livelli a origine e destinazione non è necessario variare alcun percorso.
- È più intuitivo da gestire.
- È maggiormente compatibile nella gestione con editor di sviluppo.
Assoluto
- È dipendente dalla root quindi può essere incluso in file in diversi livelli senza richiedere adattamenti relativi. Molto utile nel caso di percorsi comuni a database.
- Offre sul lato gestionale una maggiore sicurezza poiché non è possibile includere file sopra al livello della root senza gli appositi permessi.
Fisici e Virtuali
Potremmo definire le tipologie prima analizzate entrambe facenti parte di una categoria maggiore definibile come percorsi virtuali.
Sono virtuali quei percorsi che pur rispecchiando la reale struttura della directory non corrispondono esattamente all'intera visione della directory stessa, al contrario dei percorsi fisici che invece descrivono il percorso partendo dal singolo dispositivo di memoria.
Ecco due esempi:
Percorso virtuale
../cartella/file.asp
/dominio1/cartella/file.asp
Percorso fisico
C:wwwdominio1cartellafile.asp
Un percorso virtuale seguirà i comportamenti prima descritti, un percorso fisico è riconducibile ad un percorso assoluto con maggiori restrizioni. È infatti necessario che il percorso cominci con la specifica dell'unità di sistema seguita dal percorso completo.
Attenzione, al contrario degli altri percorsi quello fisico prevede come separatore delle cartelle un , in pieno stile dei percorsi su sistema operativo Windows.
L'istruzione Server.MapPath
In linea generale qualsiasi comando che preveda dei percorsi necessita di percorsi fisici, altrimenti il server non è in grado di comprendere a quali cartelle e file si fa riferimento, soprattutto se possono esserci strutture uguali o simili in differenti livelli.
Esistono però istruzioni che permettono di convertire automaticamente i percorsi relativi, decisamente più intuitivi per un programmatore. Una di queste istruzioni è la Server.MapPath() , usata ad esempio nei codici ASP in cui interviene l'oggetto FileSystemObject o ancora nei percorsi al database.
L'istruzione converte un percorso relativo nel suo corrispettivo fisico in base alla posizione in cui viene eseguito:
Percorso relativo di tipo assoluto
Server.MapPath("/dominio1/cartella/file.asp")
Ipotetico Percorso fisico corrispondente restituito
C:wwwdominio1cartellafile.asp
Altre istruzioni invece, tipo l'include non necessitano del Server.MapPath() poiché in grado di convertire autonomamente il percorso.
Il problema con Windows 2003
Nelle precedenti versioni 2000 (che chiameremo Win2k) e NT (WinNT) era possibile specificare una path come comunemente avviene in HTML, ossia mediante un percorso relativo dipendente quindi dalla posizione in cui ci si trovava. Per la comodità e la compatibilità assicurata con la maggior parte dei programmi di sviluppo questa era la forma più usata, nonostante tali sistemi prevedessero anche la gestione mediante percorsi assoluti.
Con l'arrivo di Win2k3 le cose sono leggermente cambiate, poiché di default è disabilitata la possibilità di definire percorsi relativi di livello superiore. Qualsiasi percorso del tipo ../percorso restituisce infatti un errore del tipo:
Active Server Pages error 'ASP 0131'
Disallowed Parent Path
/percorso/file.asp, line 70
The Include file '../altropercorso/file.aso' cannot contain '..' to indicate
the parent directory.
che riassume in modo schematico come sia vietato salire di livelli mediante la direttiva relativa prima analizzata.
Questo problema ha inizialmente mandato in paranoia non pochi sviluppatori, pensando anche ai problemi non indifferenti di convertire un grande portale da relativo a assoluto per un cambio server. Il consiglio è quindi di abituarsi fin dalle prime volte ad usare percorsi assoluti, almeno su direttive di percorsi a livelli superiori.
Il perché di questa politica di gestione è stato giustificato dal fatto che obbligando l'uso di percorsi assoluti che partono dalla root non si può includere un percorso fuori dalla root, ad esempio su una cartella di un altro dominio in un server condiviso, e questo aumenta la sicurezza del server.
Percorsi in locale e percorsi in remoto
Uno dei problemi amletici di molti utenti da quando si è forzatamente introdotto l'uso di percorsi assoluti è se testare in locale o in remoto prettamente per un problema assai frequente di percorsi funzionanti in remoto e non in locale e viceversa. Questo comportamento è da ricondurre allo stile di gestione e sviluppo del programmatore stesso. È buona norma riprodurre in locale la stessa struttura di cartelle e file del server finale, in modo da sviluppare nel modo più efficiente possibile.
Il problema è che sistemi operativi non server quali Windows 2000 e Windows XP Pro, nonostante abbiano installato IIS sono in grado di gestire un solo web alla volta che di default punta alla cartella C:intepubwwroot . Questo significa che quella directory corrisponde alla root ed ogni file inserito sarà richiamabile dal browser con http://localhost/
Esempio
C:intepubwwrootfile.asp : http://localhost/file.asp
C:intepubwwrootcartellafile.asp : http://localhost/cartella/file.asp
Ma come gestire in locale più siti?
L'usanza comune di molti programmatori è di creare dalla consolle di IIS delle directory virtuali , identificandole come web autonomi. Avremo quindi il web predefinito ed una directory virtuale per ogni siti il cui collegamento punta alla cartella dove è contenuto il sito web. Dal browser sarà sufficiente richiamare http://localhost/nomesito/. Il problema è che nonostante sia virtuale quella directory è a tutti gli effetti tale.
Un percorso assoluto /cartella/file.asp di conseguenza anche se nella cartella appartenente al sito /nomesito directory virtuale, se richiamato dal browser verrà cercato in http://localhost/cartella/file.asp ed ovviamente il webserver restituirà un errore di file non trovato, mentre in remoto tutto funzionerà correttamente perché nomesito è gestito come web e non come directory virtuale. Per farlo funzionare dovremo quindi cambiare il percorso assoluto in /nomesito/cartella/file.asp e lo vedremo funzionare in locale, ma ovviamente non in remoto. Come fare?
Le soluzioni sono 2. Strutturare il sito in modo da usare il meno possibile percorsi a livelli superiori necessariamente gestibili in modo assoluto, oppure spostare temporaneamente il contenuto del web che si desidera provare nella cartella predefinita del web, ovvero c:inetpubwwroot dove verrà interpretato esattamente come sul server remoto.
