Overview di HTTP

RETI DI CALCOLATORI

CAPITOLO 1 – OVERVIEW DI HTTP.

1.1 HTTP: il corriere multimediale di Internet.

Miliardi di immagini, pagine web, file di testo, film, file audio, app e

molto altro viaggiano attraverso internet ogni giorno. HTTP sposta queste

informazioni velocemente, efficientemente e in modo sicuro da un web

server a dei browser web di utenti in tutto il mondo. Questo garantisce che

i dati non saranno danneggiati, così che gli utenti si possano focalizzare

sulla programmazione della propria applicazione.

1.2 Web clients and servers.

Il contenuto web vive nei server online. I web servers utilizzano il

protocollo HTTP e sono spesso chiamati HTTP servers. Questi server

immagazzinano i dati di internet e forniscono i dati quando vengono

richiesti dai clients HTTP. Questi client mandano una richiesta ai server e

questi ultimi restituiscono i dati richiesti tramite risposte HTTP. Client e

server sono le componenti base del World Wide Web. Il più comune client

HTTP è un web browser. Il server cerca di trovare l’oggetto desiderato e se

la richiesta ha successo, manda un oggetto al client tramite una risposta

HTTP, insieme all’oggetto.

1.3 Risorse.

I server web ospitano risorse web, che possono essere file statici o

programmi che generano contenuti dinamici. HTTP utilizza etichette

MIME per identificare il tipo di dato che viene trasportato. Ogni risorsa ha

un URI (Uniform Resource Identifier) che la identifica univocamente. Le

URL (Uniform Resource Locator) specificano la posizione di una risorsa

in un server, mentre le URN (Uniform Resource Name) sono nomi unici

indipendenti rappresentanti la posizione della risorsa.

1.4 Transizioni.

Una transazione HTTP consiste in un comando di richiesta (C->S) e a una

risposta (S->C). Questa comunicazione viene realizzata attraverso dei

blocchi formattati di dati chiamati HTTP messages. HTTP supporta molti

comandi di richiesta diversi, detti HTTP methods.

1.5 Messaggi.

I messaggi HTTP sono sequenze di caratteri semplici e line-oriented, facili

da leggere e scrivere per gli umani. I messaggi inviati dai client ai server

web sono chiamati request messages, mentre quelli inviati dai server ai

client sono chiamati response messages. Non ci sono altri tipi di messaggi

HTTP. I formati di richiesta e risposta HTTP sono molto simili. I messaggi

HTTP sono composti da tre parti:

• Start line: la prima riga del messaggio, che fornisce informazioni sulla

richiesta o sulla risposta;

• Header fields: la linea d’inizio può essere seguita da zero o più campi

header. Ogni campo header consiste in un nome e un valore, separati da

due punti (:);

• Body: messaggio contenente qualsiasi tipo di dato. I request bodies

trasportano dati dai client ai server web, mentre i response bodies portano

dati ai client.

1.6 Connessioni.

Si parla di TCP, Transmission Control Protocol. HTTP è un’applicazione

con struttura a strati (di protocolli). L’HTTP non si preoccupa dei dettagli

della comunicazione di rete, ma lascia i dettagli di networking al TCP/IP, il

protocollo più usato per il trasporto dati in internet. TCP provvede al

trasporto di dati senza errori e alla consegna in ordine dei dati senza

segmentazione. Il TCP/IP nasconde le debolezze hardware individuali,

lasciando i dispositivi liberi di comunicare in modo sicuro. La connessione

TCP scambia messaggi tra il client e il server senza che i dati possano

essere persi o danneggiati. Se il protocollo HTTP è strutturato basandosi su

TCP, in modo simile, TCP è basato su IP: prima che un client HTTP possa

mandare un messaggio a un server, deve stabilire una connessione TCP/IP

tra il client e il server usando il protocollo internet IP, con indirizzi e

numeri di porta. Ma come si fa a ottenere l’indirizzo IP e il numero di

porta di un server HTTP? tramite l’URL.

1.7 Versioni del protocollo.

• 0.9: Prototipo del 1991, che contiene design con difetti. Supporta solo il

metodo GET e non il MIME o gli header HTTP. È stato definito solo per

fetch semplici di oggetti HTML.

• 1.0: Prima versione largamente distribuita. Ha aggiunto numeri, header

HTTP, altri metodi per la gestione di oggetti multimediali. Ha migliorato il

supporto grafico delle pagine web, promuovendo il protocollo nel WWW;

• 1.0+: Molti client web e server web hanno velocemente aggiunto delle

caratteristiche come il supporto virtuale e il supporto della connessione del

proxy;

• 1.1: Focalizzato nel correggere difetti architetturali dell’HTTP,

specificando semantiche e introducendo significative ottimizzazioni di

performance e rimuovendo caratteristiche deboli. Include anche supporto

per più sofisticate applicazioni web. È l’attuale versione dell’HTTP;

• NG o 2.0: Prototipo per un successore architetturale del design di HTTP,

focalizzato sull’ottimizzazione significativa delle performance e un più

potente framework per l’esecuzione remota dei server;

1.8 Componenti architetturali del web.

Ci sono molte altre applicazioni web che possono interagire con internet:

• Proxies: Intermediari HTTP tra i client e i server, usati spesso per la

sicurezza;

• Gateways: Sono server speciali che fanno da intermediari per altri server,

spesso usati per convertire il traffico HTTP ad un altro protocollo;

• Tunnels: Proxies speciali che ciecamente, quindi senza controllo,

consentono le comunicazioni. Sono usati per dati non-HTTP, come oggetti

criptati;

• Agents: Client web semi-intelligenti che automatizzano le richieste

HTTP. CAPITOLO 2 – URL E RISORSE.

2.1 Navigare tra le risorse di internet.

Le URL sono le locazioni delle risorse che il browser ha bisogno per

trovare le informazioni. Di solito, sono il punto d’accesso all’HTTP e ad

altri protocolli. Le URL sono un sottoinsieme di una classe generale di

identificatori di risorse chiamate URI (Uniform Resource Identifier). Le

URI sono un concetto generale che comprende due sottocategorie: URL e

URN. Le URL identificano la risorsa descrivendo dove quest’ultima è

allocata, mentre le URN identificano le risorse dal nome. Usando le URL,

le applicazioni hanno accesso a molte risorse in modo uniforme da

un’unica interfaccia.

2.2 Sintassi delle URL.

Le URL provvedono al significato di locazione di una risorsa in internet,

ma queste risorse possono avere accesso da diversi schemi e le sintassi

delle URL variano da schema a schema.

2.3 Shortcut URL.

I client web usano alcune shortcut delle URL. Le URL relative sono

convenienti, ma incomplete. Per avere tutte le informazioni bisogna

implementarle in un’altra URL, chiamata base. Il primo passo per la

conversione è trovare la base URL, che serve come punto di riferimento

per la URL relativa. Per decomporre una URL, si segmentano tutti i suoi

componenti. Una volta segmentate la base e la URL relativa nei rispettivi

componenti, si può sfruttare un algoritmo di conversione per terminare il

processo. Alcuni browser provano a espandere automaticamente le URL, e

questo fa sì che l’utente, usando una shortcut, non debba completare la

URL.

• Hostname expansion: Il browser spesso espande il nome dell’host mentre

lo si digita, ma questo potrebbe causare problemi per altre applicazioni

HTTP come i proxy;

• History expansion: Il browser immagazzina la cronologia delle URL

visitate nel passato e, mentre si digita, avviene un’autocompilazione.

2.4 Caratteri speciali nelle URL.

Il design delle URL è stato implementato in modo tale che queste ultime

fossero portabili, che uniformassero il nome di tutte le risorse di internet e

che si potesse trasmettere in modo sicuro attraverso ogni protocollo di

internet. Per trasmissione sicura si intende l’assenza di rischio di perdita di

informazione. Per rappresentare alcuni caratteri non presenti e rendere

complete le URL, è stato inventato uno schema di codifica per

rappresentare caratteri in una URL che non sono sicuri. Sostanzialmente la

codifica rappresenta il carattere non sicuro come una notazione escape,

cioè con un % seguito dal suo codice ASCII in esadecimale.

CAPITOLO 3 – MESSAGGI IN HTTP. (2-3-7)

3.1 Flusso dei messaggi.

I messaggi HTTP sono rappresentati da blocchi di dati tra le applicazioni

HTTP. L’inizio dei blocchi di dati è un testo di meta-informazioni che

descrive il contenuto e il significato del messaggio, seguito da dati

opzionali. Questi messaggi fluiscono tra i client, server e proxy. I termini

”inbound” (entrata), ”outbound” (uscita), ”upstream” (a monte) e

”downstream” (a valle) descrivono la direzione dei messaggi. Il mittente di

ogni messaggio si trova a monte rispetto al destinatario.

3.2 Le parti di un messaggio.

I messaggi HTTP sono semplici blocchi di dati formattati. Ogni messaggio

contiene una richiesta di un client o una risposta di un server, e sono

costituiti da tre parti: una linea iniziale che descrive il messaggio, un

blocco di intestazioni contenente attributi e un corpo opzionale contenente

i dati. La linea iniziale e le intestazioni sono caratteri ASCII, in righe, che

terminano con una sequenza di fine riga, ”CRLF”. Il corpo dell’entità o

corpo del messaggio è un blocco opzionale di dati, che a differenza della

linea iniziale e delle intestazioni può contenere testo o dati binari. Tutti i

messaggi HTTP rientrano in due tipi: di richiesta e di risposta. I messaggi

di richiesta richiedono un’azione da un server web, i messaggi di risposta

portano i risultati di una richiesta a un client. Sia le richieste che le risposte

hanno la stessa struttura. Ecco una breve descrizione per le varie parti:

• Method: L’azione che il client vuole che sia eseguita sulla risorsa, dal

server. È una parola GET, HEAD o POST;

• Request-URL: Un URL completo che identifica la risorsa richiesta;

• Version: La versione di HTTP utilizzata dal messaggio;

• Status code: Un numero a tre cifre che descrive ciò che è successo

durante la richiesta;

• Reason-phrase: Versione leggibile dall’essere umano del codice di stato

numerico;

• Headers: Zero o più intestazioni;

• Entity-body: Il corpo dell’entità contenente un blocco di dati arbitrari.

I codici di stato HTTP indicano al client l'esito di una richiesta e sono presenti

nella linea iniziale delle risposte, con un codice numerico per i programmi e una

frase leggibile per gli utenti. Sono suddivisi in classi: 200-299 per il successo,

300-399 per redirezioni, 400-499 per errori del client e 500-599 per errori del

server.

La specifica HTTP definisce diversi campi di intestazione. Le applicazioni

sono anche libere di inventare i propri campi intestazione personalizza