slide 1/13

Per quel che riguarda il protocollo HTTP, attualmente è molto diffusa la versione 1.0, ma è anche disponibile la versione 1.1 che, comunque, è in corso di valutazione.
Il protocollo HTTP 1.0 viene spiegato nella RFC 1945.

slide 2/13

Il protocollo HTTP va reso sicuro di fronte al fatto che la rete è pubblica. Si tratta di un protocollo intrinsecamente sicuro, diamo per scontato che sulla macchina non ci siano altri demoni attivi (telnet, FTP... ) e che sulla nostra macchina ci sia la possibilità di immettere dati solo da locale e, sempre da console locale, poterli modificare.

slide 3/13

Si può dire che l'HTTP prevede un paradigma di interazione intrinsecamente sicuro ? Tale paradigma si basa su due frasi elementari che sono quella di " request " e quella di " response ". Le due frasi vanno previste nell'ordine corretto ; prima il browser client fa una request e poi il web fornisce una risposta, formattata nel codice previsto dal protocollo HTTP e la invia al browser. Questo tipo di interazione, prodotto dall'HTTP 1.0, prevede che ad una request corrisponda una ed una sola response e che la nostra connessione TCP venga chiusa al momento dell'arrivo della response.

slide 4/13

Questo penalizza le performance, infatti, se al documento sono legate informazioni addizionali ed immagini, allora vengono ripetute connessioni TCP con negoziazione col server e ciò penalizza il flusso informativo ; si va ad aggiungere un ritardo, per il fatto che bisogna prelevare altre informazioni e ci vuole del tempo. In più è necessaria una procedura per ogni interazione col problema dell'autenticazione, oltre al fatto che lo scambio di informazioni è " stateless ", perché ad ogni interazione si riparte con una procedura bianca di partenza, cioè da capo.

slide 5/13

Nel protocollo HTTP 1.1 sono state portate tre innovazioni. Si può, con una sola connessione TCP, effettuare lo scambio di più dati; se è necessario basta rendere la connessione sicura, ma sostanzialmente non ho limiti di scambio di dati una volta effettuata l'identificazione. Possiamo effettuare trasmissioni parziali di documenti senza dover, una volta che si ripristina il collegamento, riprendere anche le informazioni già ricevute. Possiamo anche permetterci di avere dei meccanismi di autenticazione degli utenti più complessi ; per esempio non trasmettere in chiaro la nostra password al server per autenticarci ed eventualmente rispondere ad una sfida su un paradigma di cui verrà parlato in seguito.

slide 6/13

Siamo fermi alla versione 1.1, ma il " W3 consortium " sta lavorando per migliorare i punti dell'attuale HTTP ritenuti deboli. Saranno migliorate la sicurezza, un trasferimento dei pacchetti più compatto per quel che riguarda l'HTML, che ora è trasformato in codice ASCII, molto dispendioso in termini di bit trasmessi, ed altro ancora.

slide 7/13

Generalmente una " HTTP request " viaggia in chiaro e la firma è riposta accanto. Abbiamo un'intestazione che contiene un metodo per la richiesta, notifica o sostituzione delle informazioni. Nell'intestazione è possibile indicare una serie di parametri che identificano la richiesta del client e prevedere così meccanismi di autenticazione.

slide 8/13

Abbiamo tutta una serie di parametri che occupano una riga, come l'indirizzo e-mail del richiedente, il tipo dei files accettati alla risposta, oppure una linea di autenticazione.
L'authorization è un campo usato per inviare le credenziali utente. Si noti l'importanza di dividere fra autenticazione del client e quella dell'utente. La prima è l'autenticazione del software che sta girando sulla macchina client, la seconda è l'identificazione fisica della persona che si trova dietro quella macchina.

slide 9/13

Abbiamo poi altri elementi, o meglio campi, come quello che ci dà la lunghezza del body ed uno che spesso ha suscitato problemi di privacy che è quello del " cookie ", che permette di restituire al server informazioni di stato memorizzate nel file cookie.txt, residente sulla macchina client. Potrebbe essere un file che contiene particolari informazioni personali e, non essendo per forza crittate su questo file, ciò potrebbe andare contro la legge sulla privacy.

slide 10/13

Per quel che riguarda la risposta, in qualunque modo venga fornita, cioè con una connessione TCP alla volta o connessione con risposte multiple, la forma è la stessa della richiesta.

slide 11/13

Abbiamo un'intestazione con più o meno gli stessi parametri della request ed un body. Se è vero che nel caso della request può essere inserito tutto nell'intestazione ( si veda il caso della richiesta get ), nel caso della risposta ci deve essere un body per poter visualizzare qualcosa sul browser.
Necessita sapere, se si va a programmare in Perl o si opera sul protocollo, che una riga fra intestazione e corpo deve essere lasciata intenzionalmente bianca. Se ci dimentichiamo questo, il browser non è in grado di capire dove finisce l'intestazione e comincia il body.
La domanda che nasce ora è se le informazioni , sempre presenti nella response, possono essere tradotte in un formato crittografico grazie all'HTTP. La risposta è no, perchè l'HTTP prevede nelle due versioni, per default, la possibilità di avere informazioni crittografate nel body e trasformarle in un qualunque formato MIME. Per cui, esistendo tipi MIME " encripted " , come visto nel TCP, è possibile avere elementi crittografici, ma trasmessi nel body. Caso mai si tratta di un file che era stato precedentemente crittografato ; non c'è crittografia al momento che il server spedisce la risposta al browser. In pratica è il gestore del server che ha crittato il file e lo ha inserito nel file-system. Ciò richiede naturalmente una comprensione da parte del browser del tipo di crittografia usato.
Questo metodo di trasporto di files crittografati può sostituire un server FTP pubblico. Se il nostro browser ha una parte plug-in aggiuntiva, è possibile, una volta ricevuta la response, aprire il file on-line, altrimenti questo sarà salvato su disco e dopo si provvederà alla sua apertura.
Fra i parametri della response, si sottolinea il parametro www-authenticate, che forza un meccanismo di autenticazione. Il server forza tale meccanismo per certe specifiche risorse. Cioè il server dice al client che è necessaria una specifica di autenticazione per accedere a determinate operazioni.
Nelle prossime due slide si vede in quali casi si trova il corpo nel metodo get, nel metodo post ed in quello headD, cioè se contiene dati o no. I primi due sono i metodi più utilizzati.

slide 12/13

Nel caso in cui request o response contengano dati, è necessaria l'indicazione del content-lenght per capire quando il body è concluso.

slide 13/13

Di fondamentale importanza è capire quali dati vengono generati per trasmettere un file e ciò è contenuto nel codice. Se una codifica cambia le dimensioni di un blocco che devo spedire, devo essere in grado di stabilire la dimensione finale che spedisco ; a maggior ragione, se la codifica è " On the fly " , cioè avviene nel momento in cui spedisco, devo già sapere la dimensione finale del blocco, da quando spedisco i primi pacchetti.