HTTP


1. Preparazione dell'ambiente

cURL. Per eseguire le chiamate HTTP utilizzeremo l'utility cURL disponibile per numerose piattaforme che consente il trasferimento di file su una moltitudine di protocolli di trasporto (http, ftp, ...). con la possibilità di specificare una serie di opzioni per definizione di header,redirezione dell'output, codifica dei parametri etc... ( Manuale cURL )

2. Cosa è l'HTTP

HTTP è l'acronimo di HyperText Transfer Protocol (protocollo di trasferimento di un ipertesto). Usato come principale sistema per la trasmissione di informazioni sul web. È il protocollo standard tramite il quale i server Web rispondono alle richieste dei client. Il protocollo HTTP è basato su un modello richiesta/risposta, quindi ad ogni messaggio di richiesta è associato un messaggio di risposta, anche vuoto. Per demistificare l'idea che http sia un protocollo di comunicazione utilizzabile solo dai browser, è utile fare un po di pratica nell'interazione con i server web, usando strumenti alternativi al browser.

Proviamo ad simulare la richiesta che normalmente facciamo tramite browser per visualizzare la pagina principale del corso utilizzando cURL

curl -v http://www.link.it/lai/jsp
[Nota] Nota

-v : esegue il comando aumentando l'output prodotto

== Info: About to connect() to www.link.it port 80 (#0)
== Info:   Trying 79.125.2.221...
== Info: connected
== Info: Connected to www.link.it (79.125.2.221) port 80 (#0)
> GET http://www.link.it/lai/jsp HTTP/1.1
> User-Agent: curl/7.24.0
> Host: www.link.it
> Accept: */*
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 302 Moved Temporarily
< Location: http://www.link.it/isi/jsp/
< Content-Length: 0
< Proxy-Connection: keep-alive
< 
* Connection #0 to host www.link.it left intact
* Closing connection #0

2.1. Richiesta HTTP

Analizziamo come è strutturata una richiesta HTTP

GET http://www.link.it/lai/jsp HTTP/1.1
Host: www.link.it
User-agent: curl/7.24.0
Accept: */*

La prima è la linea di richiesta: è composta dal metodo, URI della risorsa e versione del protocollo. Il metodo di richiesta, per la versione 1.1, può essere uno dei seguenti:

  • GET : è usato per ottenere il contenuto della risorsa indicata nell'URI (come può essere il contenuto di una pagina HTML)

  • POST : è usato di norma per inviare informazioni al server (ad esempio i dati di un form)

  • HEAD : funziona come il metodo GET , ma nella risposta vengono specificati solo gli header e non il corpo del messaggio.

  • PUT : questo metodo richiede che il contenuto del messaggio venga memorizzato nella posizione specificata dalla URI

  • DELETE : richiede la cancellazione della risorssa specificata nella URI.

  • TRACE : fa eseguire l'echo del messaggio

  • OPTIONS : richiede al server di fornire informazioni sulle opzioni di comunicazione disponibili per la risorsa specificata.

  • CONNECT : indica al proxy di assumere il comportamento di tunnel

l'URI sta per Uniform Resource Identifier ed indica l'oggetto della richiesta (ad esempio la pagina web che si intende ottenere). I metodi HTTP più comuni sono GET, HEAD e POST.

Le linee successive a quella di richiesta sono gli header http. Gli header sono nella forma:

[nome]: [valore]

Di seguito sono riportati alcuni header di uso comune per il messaggio di richiesta. Per una lista completa rimandiamo alle specifiche del W3C .

Header Descrizione Esempio
Accept Mime Type accettati nella riosposta Accept: text/plain
Authorization Credenziali per l'autenticazione Authorization: Basic QWxhZGRpbcGVuIHNlc2FtZQ==
Connection Tipo di connessione che il client preferisce Connection: Close
Host Domain name dell'host per il virtual hosting Host: www.link.it

Tabella 1. Header HTTP di richiesta


2.2. Risposta HTTP

La richiesta che abbiamo inviato in precedenza ritorna una risposta simile alla seguente:

HTTP/1.0 302 Moved Temporarily
Location: http://www.link.it/isi/jsp/
Content-Length: 0
Content-Type: text/plain; charset=UTF-8

La prima linea indica la versione del protocollo HTTP, il codice di stato e la Reason Phrase. Il codice di stato è un numero a tre cifre classificabile come segue:

  • 200~299 Successo

  • 300~399 Redirezione

  • 400~499 Errore del Client

  • 500~599 Errore del Server

Vediamo alcuni esempi di codice di stato che un server può inviare. Per la lista completa rimandiamo al sito del W3C.

  • 200: OK; operazione completata con successo

  • 302: redirezione a una nuova URL; la URL originale è stata spostata. Non si tratta di un errore, i browser compatibili cercheranno la nuova pagina.

  • 304: usa una copia locale; i browser compatibili mandano una informazione su "last­modified" della copia della pagina in cache. Il server può rispondere con il codice 304 invece di mandare di nuovo la pagina in modo che il client utilizzi quella che risiede in cache.

  • 401: non autorizzato. L’utente ha richiesto un documento ma non ha fornito uno username o una password validi.

  • 403: Vietato, l’accesso alla URL è vietato.

  • 404: Non trovato; il documento non è disponibile sul server.

  • 500: Server error; si è verificato un errore interno del server.

A seguire la linea di risposta ci sono gli header (opzionali, come per la richiesta) che forniscono utili informazioni sui dati contenuti nel body (tipo, lunghezza), sul server che l'ha costruita, sul file richiesto (data di ultima modifica). Come per gli header di richiesta, segue una lista non esaustiva degli header più comunemente utilizzati:

Header Descrizione Esempio
Allow Metodi di richiesta accettati dal server Allow: GET, HEAD
Content-Lentgth Dimensione dei dati in bytes Content-Length: 258
Content-Type Mime type del contenuto della risposta Content-Type: text/html;
Date Data e ora dell'invio della risposta Date: Tue, 15 Nov 1994 08:12:31 GMT
Exprires Data di scadenza del documento Expires: Tue, 15 Nov 1994 08:12:31 GMT
Last-Modified Data dell'ultima modifica effettuata sulla risorsa Last-Modified: Tue, 15 Nov 1994 08:12:31 GMT
Location Url di redirezione Location:http://isi.link.it/isi.html
Server Contiene informazioni sul server Server:Apache/1.3.29 (Unix) PHP/4.3.4
WWW-Authenticate Contiene informazioni per l'accesso in caso di errore 401 WWW-Authenticate: Basic realm="link-it"

Tabella 2. Header HTTP piu frequenti


Dopo gli headers c'è una linea vuota a separare i dati (opzionali, come per la Richiesta). Questi possono essere in qualsiasi formato, anche binario, come specificato nell'header Content­Type.

3. Esercizi su HTTP

Primo Esercizio

Provare ad accedere tramite curl ai siti www.w3c.org e wwww.google.com usando i seguenti comandi:

curl -v -o w3c.html www.w3.org

curl -v -o google.html -d q=Android -G --user-agent Mozilla www.google.it/search

In output potete analizzare il tracciato delle richieste e delle risposte HTTP, mentre nei file w3c.html e google.html troverete i contenuti della risposta.

Provare ora a modificare il comando curl per eliminare dalle richieste l'header "Host", consultando la documentazione di curl per capire come fare. I risultati ottenuti dalle due richieste saranno diversi. Individuare quale dei due siti si comporta correttamente analizzando la documentazione dell'RFC HTTP.

Secondo Esercizio

Provare ora ad effettuare con curl il download del file accessibile alla URI "http://www.link.it/isilogo.gif"

Analizzando la documentazione dell'Header Range dell'RFC HTTP, individuare una modalità per scaricare il file in 3 diversi tronconi: isilogo.gif.1 di 10.000 byte, isilogo.gif.2 di 7.000 byte e isilogo.gif.3 di 649 byte.

Terzo Esercizio

Effettuare una ricerca tramite browser sul sito di eBay della keyword Android

Analizzando la risposta del sito ebay, replicare correttamente la stessa richiesta fatta dal browser, usando le opzioni '-d' e '-G' del comando curl.

Footer BGFooter BG
Tito Flagella - © 2007-2015