URI (UNIFORM RESOURCE IDENTIFIERS)

Gli URI sono sistemi di indirizzamento sul web costituiti da stringhe di caratteri ASCII che identificano le risorse
presenti sul web. Questo meccanismo rappresenta uno standard della IETF, un’organizzazione che si occupa di
definire gli standard da usare su internet.
Nella forma generale, la stringa di un URI è divisa in due parti:
<protocollo> : <parte-dipende-dal-protocollo>
Gli URI si dividono in due gruppi:
 URL (Uniform Resource Locators): una stringa che descrive il metodo primario per accedere a
specifiche risorse effettivamente accessibili (es. pagina web, documento). Sono costituiti da:
- protocollo (http o https)
- //
- nome del server o indirizzo IP dove risiede la risorsa
- indirizzo della risorsa nella radice del server Web
 URN (Uniform Resource Names): una stinga che non descrive il metodo per accedere a risorse le quali,
inoltre potrebbero non essere effettivamente accessibili (es. ISBN, ISSN).

I protocolli principali sono:

 http/https
 ftp: utilizzato per il trasferimento dati
 mailto: relativo a indirizzo email
 file: relativo a file

HTTP/1.0 (HYPERTEXT TRANSFER PROTOCOL)

L’HTTP/1.0, la prima versione di HTTP, rappresenta un protocollo di livello applicativo.
Il dialogo tra un server ed un client in HTTP/1.0 è basato su scambi di messaggi, chiamate transazioni: Il client
apre una connessione di rete con il server, sulla qual invia un messaggio di richiesta HTTP. Il server, riceve tale
richiesta, la elabora e fornisce una risposta. La connessione viene chiusa.
Caratteristiche:
 Rappresenta un protocollo molto costoso perché apre una connessione per ogni transazione.
 è privo di stato (stateless): non si ha una correlazione tra le diverse transazioni che avvengono tra
stesso client e stesso server. La mancanza di stato influenza in modo determinate la scrittura delle
applicazioni vista la necessità di mantenere le informazioni sullo stato.
Problemi di HTTP/1.0:
 lentezza e congestione nelle concessioni vista l’apertura di una nuova per ogni richiesta;
 un solo server Web per ciascun IP;
 limiti nel maccanismo di autorizzazione;
 limiti nel controllo dei meccanismi di caching.

LE TRANSAZIONI
La transazione nasce con la richiesta del client attraverso un URI nel browser che può essere specificato
esplicitamente o provenire da un collegamento selezionato dall’utente. Nel dettaglio:
I operazione - risoluzione del nome: il client utilizza il servizio DNS per risolvere il nome in IP;
II operazione - viene richiesta una connessione di rete al numero IP e alla porta specificata;
III operazione - ottenuta la connessione, il browser invia una richiesta HTTP al server specificando
l’operazione da effettuare sulla risorsa richiesta e il nome della risorsa;
 IV operazione - il server riceve e gestisce la richiesta e, infine, fornisce la risposta.
Le richieste HTTP raramente risultano essere isolate: quando andiamo a consultare un sito, all’interno della
pagina HTML troviamo, oltre al testo, anche altre risorse come immagini, file di fogli di stile, file javascript.
Tutte queste risorse sono separate dalla pagina HTML, quindi il browser quando elabora la richiesta, si
accorge che non è in grado di mostrare la pagina completa se non ottiene anche le altre risorse.
In seguito quindi alla singola richiesta di pagina web si aprono quindi diverse richieste per ottenere le diverse
risorse che sono immerse in questa pagina HTML.

I MESSAGGI
La struttura generale dei messaggi di richieste e di risposta è composta da:
<linea iniziale> il cui contenuto cambia in base al tipo di messaggio:
 messaggio di richiesta – contiene l’operazione da effettuare sulla risorsa e
l’indirizzo della risorsa stessa;
 messaggio di risposta – contiene l’esito dell’operazione richiesta.
<intestazioni HTTP> in cui vanno specificate altre informazioni relative alla richiesta o alla risposta
<linea vuota>
<corpo del messaggio> cambia in base al tipo di messaggio:
 messaggio di richiesta – è vuoto o contiene i paramenti che inviamo nella
richiesta;
 messaggio di risposta – contiene la risposta (la risorsa).

I MESSAGGI DI RICHIESTA
La linea iniziale dei messaggi di richiesta è costituita da:
<metodo> - nome del metodo che definisce operazione che viene effettuata sulla risorsa
<URI> - l’indirizzo relativo della risorsa sul server
HTTP/1.0 - una stringa che chiarisce la versione del protocollo utilizzata
I METODI
Esistono diversi metodi, i principali sono:
GET – metodo standard utilizzato per effettuare richieste di risorse
 La richiesta avviene specificando l’URI di tale risorsa con eventuali parametri – coppie parametro =
valor – sparati da “&”
 mentre il corpo rimane vuoto
 ? – separa i parametri dall’indirizzo della risorsa
POST – metodo utilizzato principalmente per inviare moduli HTML
 La richiesta avviene specificando l’URI senza individuare i parametri
 I parametri vengono specificati nel corpo del messaggio
Il metodo di richiesta viene deciso dallo sviluppatore dell’applicazione. Convenzione:
 GET viene utilizzato per richieste che non alterano lo stato dell’applicazione (es. visualizzazione)
 POST per le richieste che vanno a modificare lo stato dell’applicazione (es. inserimento,
cancellazione)
INTESTAZIONE NEI MESSAGGI DI RICHIESTA
 User-Agent: individua il tipo e la versione di browser utilizzato al fine di permettere al server di ottimizzare
la risposta al browser di utilizzo (es. User-Agent)
 If-Modified-Since: il browser comunica al server di fornire una certa risorsa solo se è stata modificata dopo
una certa data
 Authorization: permette al client di farsi riconoscere attraverso user e password
 Referer: utilizzato quando si richiede una risorsa HTTP partendo da un’altra pagina, da un collegamento

I MESSAGGI DI RISPOSTA
La linea iniziale dei messaggi di risposta è costituita da:
HTTP/1.0 – la versione del protocollo
<codice numerico> –individua l’esito della riposta
<descrizione> – descrizione del codice numerico
I CODICI NUMERICI
I codici numerici sono costituiti da tre cifre:
 1xx messaggio informativo
 2xx richiesta servita con successo
 3xx si ha una redirezione da una pagina ad un’altra
 4xx errore nel client
 5xx errore nel server

INTESTAZIONI DEI MESSAGGI DI RISPOSTA

 Content-Type: individua il tipo di contenuto (es. Content-Type: text/image/html)
 Content-Length: indica la grandezza del contenuto (es. Content-Length: 650)
 Last-Modified: individua la date a l’ora dell’ultima modifica
 Pragma: utile ad istruire il client (es. Pragma: no-cache)
 Server: individua informazioni sul server come il nome o versione (es. Server: Apache 1.3.20)
 Location: indica l’indirizzo della risorsa
 WWW-Authentificate: richiesta di autenticazione del client

Esempio metodo GET:

Richiesta: Risposta:
GET /news/index.html HTTP/1.0 HTTP/1.0 200 OK
User-Agent: Mozilla/4.0 Date: Thu, 01 Apr 2002 16:00:00
(compatible; MSIE 5.0; GMT
Windows XP) Opera 6.0 [en] Content-Type: text/html
Referer: http://www.unich.it Content-Length: 1534
<linea vuota>

HTTP/1.1
Il protocollo HTTP/1.1 è caratterizzato da:
 connessioni internet persistenti;
 la possibilità di utilizzo di host virtuali;
 miglioramento dell’autenticazione.

CONNESSIONI PERSISTENTI
Permette di poter effettuare più transazioni sulla stessa connessione.
Motivo per cui viene introdotto:
 nuova intestazione – Connection: close – che permette di richiedere la chiusura della connessione
 nuovo messaggio – Continue
Il server può comunque chiudere la connessione unilateralmente dopo un certo timeout
HOST VIRTUALI
Ad uno stesso indirizzo IP possono corrispondere nomi e server diversi motivo per cui IP e posta non bastano
più ad identificare il server.
Per questo motivo è stata introdotta una nuova intestazione del client obbligatoria:
Host – specifica del nome del server
Esempio:
Richiesta al sito 1: Richiesta al sito 2:
GET /news/index.html HTTP/1.1 GET /news/index.html HTTP/1.1
Host: cleii.unich.it Host: cleba.unich.it

AUTENTICAZIONE “DIGEST”
Le password non vengono più trasmesse in chiaro ma il server invia al client una stringa – nonce – e il browser
risponde con:
 Un nome utente
 un valore crittografato basato su: nome utente, password, URI e il nonce
Tale meccanismo risulta essere sicuramente più sicuro della versione HTTP/1.0 ma non è sicuro al 100% vista
la possibilità di intercettare la richiesta e riprodurla per accedere alle risorse protette.

HTTP/2.0
La versione HTTP/2.0 è basata su SPDY, un protocollo di Google, comunque compatibile a livello applicativo
con la versione HTTP/1.1.
In tale versione:
 il server può fare push di contenuti al client senza aspettare che questo li richieda
 è prevista una compressione degli header, al fine di rendere la trasmissione più rapida
 è prevista la possibilità di multiplexing di richieste e risposte sulla stessa connessione, così da non
dover aspettare che i messaggi arrivino in ordine

HTTPS
HTTPS è oggi la soluzione maggiormente utilizzata – Google penalizza chi non lo usa.
Rappresenta HTTP sul SSL, nonché la versione sicura di TCP.
SSL è un protocollo di trasporto dove tutti i messaggi sono crittografati su una crittografia a chiave pubblica
trasparente allo sviluppatore.