[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]

Capitolo 259.   URI

Un URI (Uniform resource identifier) è un indirizzo espresso attraverso una stringa di caratteri per identificare una risorsa fisica o astratta. La risorsa in questione è un'entità e la sua collocazione non si trova necessariamente all'interno di una rete. In pratica, il concetto di URI incorpora i concetti di URL (Uniform resource locator) e di URN (Uniform resource name).

Un URL identifica una risorsa rappresentando il metodo di accesso a questa; un URN identifica la risorsa attraverso un nome, che deve essere unico a livello globale e deve persistere anche quando la risorsa cessa di esistere o diventa inaccessibile.

259.1   Trascrivibilità

L'esigenza primaria degli indirizzi URI è la loro «trascrivibilità». Con questo termine si vuole fare riferimento alla facilità con la quale questi devono poter essere trascritti, sia a livello meccanico, sia a livello umano. In pratica:

Dal momento che ci deve essere la possibilità di rappresentare un URI all'interno di parentesi di qualsiasi tipo, i caratteri corrispondenti a queste parentesi non possono essere utilizzati letteralmente all'interno di un indirizzo del genere. Le parentesi in questione sono quelle tonde, quadre, graffe e angolari: (, ), [, ], {, }, <, >.

259.2   Sintassi

La sintassi di un URI è piuttosto complessa, perché dipende molto dal contesto a cui si applica. Non è il caso si entrare troppo nel dettaglio; piuttosto è meglio apprendere la logica della cosa.

schema:parte_successiva_dipendente_dallo_schema

Quello che si vede è il modello di prima approssimazione di un indirizzo URI assoluto (verrà trattato in seguito il concetto di URI relativo). In questa prima fase si distinguono due parti, separate da due punti verticali (:), dove prima appare un nome che definisce uno «schema» e poi continua con una stringa che va interpretata in base alle regole specifiche di quello schema.

La sintassi di un URI non stabilisce a priori quale sia la forma che deve avere la stringa che segue i due punti; tuttavia, è frequente l'utilizzo di URI secondo i modelli seguenti:

schema://autorità[percorso[?interrogazione]]

schema:/percorso

Convenzionalmente, quando una risorsa viene individuata attraverso un URI che per sua natura contiene un'informazione gerarchica, la separazione tra i vari livelli di questa gerarchia avviene utilizzando una barra obliqua normale (/). Si tratta evidentemente di una tecnica ereditata dal file system Unix; tuttavia, ciò resta indipendente dal fatto che la risorsa in questione risieda fisicamente all'interno di un file system o meno.

La figura 259.1 mostra alcuni esempi a proposito di URI composti secondo i modelli più frequenti.

Figura 259.1. Esempi di URI comuni. 

http://www.brot.dg/esempi/indice.html
 |          |     \_________________/
 |          |              |
schema   autorità       percorso

file:///home/tizio/indice.html
 |     \_____________________/
 |                |
schema        percorso

urn:isbn:88-256-0223-5
 |     | \___________/
 |     |       |
schema NID    NSS

Nella figura si vede anche un caso particolare, riferito a un URN di tipo ISBN (International standard book number). Lo schema di un URN è sempre urn:; a questo segue l'indicazione di un NID (Namespace identifier), ovvero un identificatore che qualifica l'informazione successiva; infine si inserisce l'informazione, definita NSS (Namespace specific string), ovvero ciò che va inteso nel contesto stabilito dal NID. L'esempio che appare nella figura fa riferimento al numero ISBN 88-256-0223-5, esprimendolo in forma di URN.

259.2.1   Accesso a un servente attraverso la rete

Quando l'indirizzo URI si riferisce a un servizio offerto attraverso la rete, la struttura di ciò che è stato definito come «autorità» si articola in modo particolare:

[utente[:parola_d'ordine]@]host[:porta]

In questo modo si può specificare il nominativo utente per l'accesso alla risorsa, eventualmente anche la parola d'ordine (benché ciò sia decisamente sconsigliabile per motivi di sicurezza), quindi il nodo che offre il servizio e infine la porta del servizio.

Il nodo può essere indicato per nome, attraverso il nome di dominio, oppure attraverso il numero IPv4. Purtroppo non è stato definito un modo per indicare un numero IPv6, dal momento che la sua forma renderebbe impossibile l'interpretazione corretta dell'indirizzo.

Se si omettono le informazioni riferite all'utente, vuol dire che queste non sono necessarie, oppure che esistono dei valori predefiniti per questo; per quanto riguarda la porta del servizio, se questa non viene indicata si fa riferimento sempre al suo valore predefinito. Naturalmente, è stabilito dal servente quali siano i valori predefiniti.

259.2.2   Riferimento agli URI

Per sua natura, l'indirizzo URI è un riferimento a una risorsa. In generale vanno considerate anche due circostanze particolari: il riferimento a un frammento della risorsa e l'indicazione di URI relativi.

Un URI relativo è un indirizzo ridotto che parte da un punto di partenza conosciuto. Il principio deriva dal concetto di percorso relativo all'interno di un file system. In generale, un URI relativo può essere indicato omettendo tutta la parte iniziale che si possa determinare altrimenti.

Di fronte a un URI che contenga un'informazione sul percorso in forma gerarchica, è abbastanza facile intendere cosa sia la base di riferimento per gli URI relativi: basta togliere dall'indirizzo attuale tutto quello che segue l'ultima barra obliqua. Per esempio, per il documento

http://www.brot.dg/esempi/articolo.html

l'URI di base è

http://www.brot.dg/esempi/

per cui, il riferimento a figure/foto.jpg richiama effettivamente l'URI

http://www.brot.dg/esempi/figure/foto.jpg

Il percorso di un URI relativo può essere indicato anche con una barra obliqua iniziale, ma in questo caso si farà riferimento a un percorso assoluto nell'ambito dell'URI. Continuando con l'esempio precedente, il riferimento a /nuovo/documento.html richiama effettivamente l'URI

http://www.brot.dg/nuovo/documento.html

In presenza di un percorso relativo, è possibile utilizzare anche i simboli . e .., con lo stesso significato che hanno nel file system Unix: il primo rappresenta la posizione corrente e il secondo quella precedente.

È importante osservare che il riferimento alla stringa nulla indica implicitamente lo stesso URI iniziale.

Il problema degli URI relativi non è così semplice come è stato descritto. In realtà vanno prese in considerazione altre cose, come per esempio la possibilità che il tipo di risorsa (di solito in un documento HTML) possa incorporare l'informazione esplicita di un URI di base.

Quando il tipo di risorsa lo consente, è possibile aggiungere all'URI l'indicazione di un frammento particolare. Questa parte aggiuntiva la si riconosce perché è preceduta dal simbolo #:

http://www.brot.dg/esempi/articolo.html#commento

L'esempio mostra il riferimento al frammento #commento nell'ambito dell'URI http://www.brot.dg/esempi/articolo.html. Dal momento che la stringa nulla fa riferimento alla risorsa attuale, i riferimenti interni alla stessa risorsa sono indicati facilmente attraverso il solo frammento:

#commento

L'esempio mostra un riferimento relativo al frammento #commento della risorsa corrente.

259.2.3   Esempi

Frequentemente, il nome dello schema dell'indirizzo URI corrisponde al nome del protocollo necessario per raggiungere la risorsa relativa. I più comuni sono:

Quando si vuole fare riferimento a un file locale senza utilizzare alcun protocollo particolare, si può indicare anche lo schema file, ma in questo caso ci sono delle particolarità che verranno mostrate dagli esempi.

259.3   Limitazioni nell'uso dei caratteri

Ogni componente di un URI ha delle regole proprie nell'uso dei caratteri, dal momento che alcuni di questi hanno significati speciali. Purtroppo le regole in questione sono tante e la cosa migliore che si può fare è quella di usare il buon senso, riservando la lettura della documentazione specifica ai casi in cui è indispensabile chiarire il problema nel dettaglio (RFC 2396).

In generale non è ammissibile l'uso dello spazio. Infatti, considerato il principio di trascrivibilità degli URI, lo spazio dovrebbe essere inteso solo come una necessità legata al tipo di trascrizione utilizzata. Per il resto, se la propria lingua lo consente, sarebbe bene limitarsi all'uso delle lettere dell'alfabeto latino (maiuscole e minuscole, ma senza accenti), le cifre numeriche e alcuni simboli: @, *, _, - e il punto (.). Gli altri simboli possono creare problemi di trascrivibilità o avere significati particolari (basta pensare alle barre oblique e ai due punti verticali).

Quando un simbolo particolare non può essere utilizzato in modo letterale nel contesto in cui lo si vuole inserire, può essere indicato attraverso una notazione speciale: %hh. La sigla hh rappresenta una coppia di cifre esadecimali. A questa regola fa eccezione lo spazio che viene codificato normalmente con il segno +, ma non in tutte le occasioni (di solito solo nelle stringhe di richiesta).

Generalmente, per gli indirizzi URI normali non c'è la necessità di preoccuparsi di questo problema, anche la tilde può essere utilizzata letteralmente nell'indicazione dei percorsi. La tabella 259.1 mostra l'elenco di alcune corrispondenze tra simboli particolari e la codifica alternativa utilizzabile negli URI.

Tabella 259.1. Alcune corrispondenze tra simboli particolari e codifica alternativa utilizzabile negli URI.

Carattere Codifica corrispondente
% %25
& %26
+ %2B
/ %2F
= %3D

In linea di principio, un URI dovrebbe essere realizzato in modo da non dover utilizzare questa tecnica di protezione per i caratteri «speciali». La situazione più probabile in cui è necessario utilizzare questo procedimento è riferito alle stringhe di interrogazione.

259.4   Verifica della validità nel tempo con Urichk

Un punto debole delle pubblicazioni ipertestuali è la rapidità con cui le informazioni vengono spostate o eliminate dalla rete. In questo senso, un riferimento a un URI è spesso qualcosa di provvisorio, che andrebbe verificato frequentemente.

Per attenuare questo problema esiste Urichk, (1) ovvero un programma molto semplice che è in grado di verificare la validità di indirizzi HTTP e FTP contenuti in un documento.

Il suo funzionamento è molto semplice: legge un file ed estrae da questo i riferimenti di tipo HTTP e FTP; quindi si avvale di altri programmi per la verifica di questi indirizzi.

urichk --input-type=tipo file_da_analizzare rapporto_errori

Come si vede dal modello sintattico, si deve definire il tipo del file in ingresso, per sapere come estrapolare l'informazione nel modo corretto; inoltre, dopo l'indicazione del file da scandire, si aggiunge il nome di un altro file che serve per annotare i riferimenti che sembrano non essere più validi.

Il file che viene generato (l'ultimo argomento) è di tipo HTML, in modo da poter riprovare facilmente gli indirizzi che sembrano errati. Infatti, Urichk riporta gli errori, ma non è in grado di distinguere se la risorsa a cui si fa riferimento è realmente scomparsa o se si tratta si una situazione transitoria (come un servizio FTP sovraccarico). Evidentemente, la valutazione finale non può essere decisa automaticamente.

Tabella 259.2. Parole chiave usate con l'opzione --input-type per distinguere il tipo di file indicato in ingresso.

Tipo Descrizione
standard Si tratta di un file di testo normale.
html|sgml Si tratta di un file SGML tipico.
texi|texinfo Si tratta di un sorgente Texinfo.

L'esempio seguente mostra il caso dell'analisi del file prova.html:

$ urichk --input-type=html prova.html rapporto.html

L'elaborazione richiede che sia disponibile l'accesso alla rete esterna (altrimenti tutti gli URI risulteranno errati) e anche molto tempo. Le varie richieste di connessione, eseguite per verificare gli indirizzi, avvengono in modo indipendente, attraverso degli eseguibili controllati da urichk. In questo senso, il file del rapporto viene scritto in modo disgiunto da questi sotto-programmi. In generale, quando termina di funzionare l'eseguibile principale, urichk, anche gli altri eseguibili dovrebbero avere terminato il loro lavoro.

Urichk dipende dalla disponibilità di altri programmi: Wget per il controllo degli URI di tipo HTTP; ImageMagick, precisamente l'eseguibile xtp, per il controllo degli URI di tipo FTP.(2)

259.4.1   Installare Urichk

Urichk si compone di tre programmi Perl: urichk (il programma frontale), urichk-ftp e urichk-http. Se l'interprete Perl si trova in una posizione diversa da quella tipica per un sistema GNU/Linux, ovvero /usr/bin/perl, basta modificare la prima parte di questi file:

#!/usr/bin/perl
#...

Questi eseguibili devono poi essere collocati in una posizione conveniente, precisamente dove possono essere avviati senza bisogno di indicare il percorso. In pratica, in una delle directory previste nella variabile di ambiente PATH.

Urichk utilizza Gettext, attraverso il modulo Perl-gettext. Per installare la traduzione italiana dei messaggi, occorre procedere nel modo seguente:

$ msgfmt -vvvv -o urichk.mo it.po

Il file it.po è contenuto nel pacchetto di distribuzione di Urichk, mentre il file urichk.mo deve essere creato come mostrato. Questo file, va poi installato nella directory adatta, che probabilmente è /usr/share/locale/it/LC_MESSAGES/.

Infine, occorre ricordare che Urichk non è autonomo nella verifica degli indirizzi. Per questo dipende da Wget e ImageMagick come è già stato descritto.

259.5   Verifica degli URI con Checkbot

Checkbot (3) è un programma Perl molto semplice da utilizzare, per controllare la validità degli indirizzi contenuti in una pagina HTML locale o remota. Il suo utilizzo è molto semplice e il rapporto che si ottiene è molto dettagliato, consentendo una comprensione chiara del tipo di errore che impedisce di raggiungere qualche indirizzo URI. Tutto viene gestito attraverso un eseguibile unico denominato checkbot:

checkbot [opzioni] [uri_iniziale...]

Nella situazione più semplice, si utilizza Checkbot specificando un solo indirizzo URI iniziale da scandire: se si tratta di una pagina HTML, vengono analizzati tutti i riferimenti contenuti al suo interno. Per esempio così:

$ checkbot file:///home/tizio/prova.html

Come si vede, è opportuno indicare sempre il riferimento alla pagina da scandire utilizzando un URI, anche se si tratta di un file locale.

Leggendo la pagina di manuale checkbot(1), si possono trovare tante opzioni per questo programma. Tuttavia, il suo funzionamento normale non richiede nulla, salvo forse la necessità di indicare un proxy indispensabile per raggiungere la rete esterna (con l'opzione --proxy uri).

Se non si indica nulla di diverso attraverso le opzioni della riga di comando, la scansione genera il file checkbot.html e un altro file il cui nome rispetta il modello checkbot-nodo.html. Il primo di questi due è un riepilogo dell'esito della scansione, mentre il secondo elenca dettagliatamente gli URI per i quali c'è stato qualche problema. Comunque, si raggiunge il secondo attraverso un riferimento ipertestuale presente nel primo.

259.6   Riferimenti

Appunti di informatica libera 2003.01.01 --- Copyright © 2000-2003 Daniele Giacomini -- daniele @ swlibero.org

1) Urichk   GNU GPL

2) Alcune edizioni di Urichk, al posto di utilizzare il programma xtp di ImageMagick potrebbero avvalersi si Curl. Infatti, a volte crea degli strani problemi.

3) Checkbot   stesse condizioni di Perl

Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome uri.html

[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]