Relazione di Ambra Giovannini Ferrara – 02/12/2005 HTTP e HTTP/TLS Relazione di Ambra Giovannini Ferrara – 02/12/2005

Presentazione (1/2) HTTP Introduzione Notazioni e grammatica Parametri Storia Terminologia Funzionamento generale Notazioni e grammatica Parametri Messaggi Richiesta Risposta Entità Connessioni Metodi

Presentazione (2/2) HTTP HTTP/TLS Status code Autenticazione Negoziazione dei contenuti Caching Header Considerazioni sulla sicurezza HTTP/TLS Introduzione Inizializzazione della connessione Chiusura della connessione Porte URI

HTTP Introduzione

Estratto Hypertext Transfer Protocol (HTTP)  protocollo di livello applicazione per i sistemi distribuiti. Generico Stateless Negoziazione della rappresentazione dei dati indipendenza dai diversi sistemi indipendenza dai tipi di dati

Storia Prima versione: HTTP/0.9 Seconda versione: HTTP/1.0 trasferire righe di dati attraverso Internet Seconda versione: HTTP/1.0 possibilità di avere messaggi in formato MIME-like (metainformazioni sui dati trasferiti) Terza versione: HTTP/1.1 regole più rigorose sul formato (es.: l’ordine in cui elencare i parametri)

Terminologia (1/3) Messaggio: unità base in una comunicazione HTTP, formato da una sequenza strutturata di informazioni Richiesta: un messaggio HTTP di richiesta Risposta: un messaggio HTTP di risposta Risorsa: un oggetto, o un servizio di rete, che può essere identificato da un URI Entità: l’informazione trasferita come payload di una richiesta o di una risposta. Nei campi dell’header si tratta di metainformazioni, mentre nel body si tratta del contenuto del messaggio. First-hand: una risposta è first-hand se arriva direttamente dal server. Expiration time esplicito: il tempo, definito dal server di origine, dopo cui l’entità in cache non può essere più considerata valida. Expiration time euristico: il tempo di scadenza assegnato dalla cache quando non esiste un expiration time esplicito.

Terminologia (2/3) Age: il tempo trascorso da quando una risposta è stata spedita, o convalidata, dall’origin server (assegnato dal client). Freshness lifetime: il lasso di tempo tra la generazione della risposta e l’expiration time. Fresh: una risposta è fresh se la sua age è minore del suo freshness lifetime. Stale: una risposta è stale se la sua age è maggiore del suo freshness lifetime. Semanticamente trasparente: una cache si comporta in un modo "semanticamente trasparente" quando fornisce al client esattamente la stessa risposta che avrebbe ricevuto dall’origin server. Validator: un elemento del protocollo che è usato per scoprire se un’entità in cache è equivalente all’originale. Inbound: “che viaggia verso l’origin server”. Outbound: “che viaggia verso l’user agent”.

Terminologia (3/3) Proxy: nodo di Internet compreso di software di gestione che si interpone fra l'host dell'utente e il resto della rete. Funzionamento: appena riceve una richiesta tipo URL cerca il file nella sua cache locale. Se trova il documento associato a quell'URL lo invia al browser che lo ha richiesto altrimenti lo preleva dal sito associato a quell'URL. Gateway: un server che funge da intermediario per qualche altro server; diversamente dal proxy, un gateway riceve le richieste come se esso stesso fosse l’origin server; il client non sa che sta comunicando con un gateway. Tunnel: un programma intermedio che funge da collegamento cieco fra due connessioni. Una volta attivo non viene considerato parte della comunicazione HTTP, benché possa essere iniziato da una richiesta HTTP. Un tunnel cessa di esistere quando entrambe le estremità della connessione sono chiuse.

Funzionamento (1/2) L’HTTP è un protocollo di richiesta/risposta. Un client spedisce al server una richiesta contenente: request method URI versione informazioni sul client Il server risponde con: una linea di stato (versione, codice di successo o di errore) informazioni sul server metainformazioni sull’entità corpo dell’entità Livello di trasporto  affidabile (es: TCP/IP)

Funzionamento (2/2) Catena della richiesta Catena della risposta UA O v Catena della richiesta Catena della risposta UA O v C B A Catena della richiesta Catena della risposta UA O v C B A UA: user agent O: origin server V: connessione A, B, C: server intermedi (es:proxy)

Notazioni e grammatica HTTP Notazioni e grammatica

Argomenti BNF (Backus-Naur Form) (1/2) nome = definizione Il nome di una regola è semplicemente il nome in se ed è separato dalla sua definizione dal carattere di uguale. Alcune regole di base sono in maiuscolo. “” Le virgolette circondano il testo letterale. regola1 | regola2 Gli elementi separati dalla barra sono alternative. (regola1 regola2 ) Gli elementi chiusi tra parentesi sono trattare come un singolo elemento. *regola Il carattere * che precede un elemento indica ripetizione. La forma completa è <n>*<m>element, che indica almeno n elementi ed al massimo m. I valori di default sono 0 ed infinito.

Argomenti BNF (Backus-Naur Form) (2/2) [regola] Le parentesi quadre includono gli elementi opzionali. N regola Specifica ripetizione: esattamente n occorrenze dell’elemento <n>(elemento) è equivalente a <n>*<n>(elemento) # regola Definisce una lista di elementi. La forma completa è <n>#<n>(elemento), che indica almeno n elementi ed al massimo m, ognuno separato da una o più virgole e opzionalmente da una linea bianca I valori di default sono 0 ed infinito. Quando si usa questo costrutto, gli elementi null sono permessi, ma non contribuiscono al conteggio degli elementi presenti. ; commento Il punto e virgola identifica l’inizio di un commento che si estende fino a fine linea.

HTTP Parametri

Versione HTTP Schema di numerazione <maggiore>.<minore> <minore>: incrementato quando nuove caratteristiche non modificano l’algoritmo generale di parsing del messaggio <maggiore>: incrementato quando cambia sostanzialmente il formato del messaggio La versione HTTP è indicata nella prima linea del messaggio nel seguente modo: HTTP-Version = “HTTP” “/” 1*digit.1*digit

Uniform Resource Identifiers (URI) Stringhe che identificano - tramite il nome, la locazione o altro - una risorsa. Possono essere rappresentati in forma assoluta o relativa. Limiti sulla lunghezza dell’URI: no (possibile problema) Lo schema che definisce un URL http è il seguente: http_URL = "http:" "//" host [ ":" port ] [abs_path ["?" query]] Confrontare gli URI, regole: case-sensitive (consigliato) campo porta vuoto = porta di default = 80 nel compare host-name deve essere case-sensitive campo abs_path vuoto = /

Formato di Date e Time (1/2) Data/ora Le applicazioni HTTP hanno storicamente premesso 3 formati per la rappresentazione date/time: Sun, 06 Nov 1994 08:49:37 GMT (preferpreferito nell’Internet standard, lunghezza fissa) Sunday, 06-Nov-94 08:49:37 GMT (usato ma obsoleto) Sun Nov 6 08:49:37 1994 Client e server HTTP/1.1 devono accettare tutti e tre i formati, per ragioni di compatibilità Non è richiesto che usino lo stesso formato durante le comunicazioni. Tutti i date/time HTTP devono essere rappresentati in Greenwich Mean Time (GMT) = UTC (Coordinated Universal Time). Campo HTTP-date è case sensitive

Formato di Date e Time (2/2) Data/Ora Schema: HTTP-date = rfc1123-date | rfc850-date | asctime-date rfc1123-date = wkday "," SP date1 SP time SP "GMT" rfc850-date = weekday "," SP date2 SP time SP "GMT" asctime-date = wkday SP date3 SP time SP 4DIGIT date1 = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982) date2 = 2DIGIT "-" month "-" 2DIGIT ; day-month-year (e.g., 02-Jun-82) date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) ; month day (e.g., Jun 2) time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun" weekday = "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday" | "Saturday" | "Sunday" month = "Jan" | "Feb" | "Mar" | "Apr"| "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" Delta seconds Alcune header HTTP premettono di specificare il valore del tempo come il numero intero di secondi, in rappresentazione decimale, trascorso da quando il messaggio è stato ricevuto. delta-seconds = 1*DIGIT

Character Sets ( / character encoding) Impiegato per riferirsi al metodo utilizzato per convertire una sequenza di byte ad una sequenza di caratteri Identificati mediante token case sensitive Schema: charset = token

Content Codings Indica quale decodifica deve essere applicata all’entità L’IANA (Internet Assigned Numbers Authority) ha registrato i valori dei token di content coding. Inizialmente i token erano solo i seguenti: gzip: per le entità prodotte dal programma di compressione “gzip”; compress: per le entità prodotte dai più comuni programmi di compressione sotto UNIX; deflate: per il formato “zlib”; identity: valore di default utilizzato quando non ci sono trasformazioni. Nuovi token dovrebbero essere registrati Case-sensitive Schema: content-coding = token

Transfer Codings (1/2) Utilizzato per indicare quale trasformazione di codifica è stata, può, o dovrebbe applicata all’corpo dell’entità per assicurare un trasporto sicuro L’IANA ha registrato i valori dei token di transfer-coding. Inizialmente i token erano solo i seguenti: chunked identity gzip compress deflate Nuovi token dovrebbero essere registrati. Schema: transfer-coding = "chunked" | transfer-extension transfer-extension = token *( ";" parameter ) I parametri sono espressi nella forma attributo/valore: parameter = attribute "=" value attribute = token value = token | quoted-string Case sensitive. Un server che riceve un transfer-coding che non riconosce ritorna l’errore 501 (Unimplemented) e chiude la connessione.

Transfer Codings (2/2) Chunked transfer coding Modifica il corpo del messaggio per trasferirlo in una serie di chunk, ognuno con il proprio indicatore di lunghezza, seguito opzionalmente da campi di entity-header. Campi chunk: Chunked-Body = *chunk last-chunk trailer CRLF chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*("0") [ chunk-extension ] CRLF chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) trailer = *(entity-header CRLF) Content coding  si riferisce all’entità originale Transfer coding  proprietà del messaggio

Media Types (1/2) Fornisce estensibilità alle tipologie dei dati e la negoziazione dei tipi. L’IANA (Internet Assigned Numbers Authority) ha registrato i valori dei token di media-type. Tipo, sottotipo, nomi dei parametri: case-sensitive Valori dei parametri case-sensitive: si/no Schemi: media-type = type "/" subtype *( ";" parameter ) type = token subtype = token Un’entità trasferita mediante messaggio HTTP deve essere rappresentata nell’appropriata forma canonica prima della trasmissione, eccetto per il tipo text.

Media Types (2/2) Multipart Types L’estensione MIME permette di incapsulare più entità con diverse tipologie all’interno di un singolo message-body Tutti i tipi multipart hanno la medesima sintassi, e devono includere specifici parametri come parte dei valori di media-type In generale, HTTP tratta i multipart message-body nello stesso modo degli altri media type: come payload. L’unica eccezione è il tipo multipart/byteranges che è interpretato da alcuni meccanismi di caching HTTP.

Product tokens Utilizzati per permettere alle applicazioni in comunicazione di identificarsi tramite il nome del software e la versione Formato: product = token ["/" product-version] product-version = token

Quality Values Indica l’importanza dei parametri negoziabili Numeri “floating point” Il “peso” di un parametro è indicato da un numero reale compreso tra 0 (minimo) ed 1 (massimo) Se un parametro ha il quality value posto a 0, il contenuto di questo parametro è “not acceptable” per il client HTTP Schema: qvalue = ("0" [ "." 0*3DIGIT ]) | ("1" [ "." 0*3("0")])

Language Tags Identifica un linguaggio normalmente parlato, scritto o comunque condiviso dagli umani Utilizzato campi Accept-Language e Content-Language. Lo spazio dei nomi dei language tags è amministrato dall’IANA. Tag case-insensitive Un language tag è composto da una più parti: un language tag opzionalmente una serie di subtags Formato: language-tag = primary-tag *( "-" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHA

Entity Tags Usati per comparare 2 o più entità che sono state richieste ad una stessa risorsa Utilizzati nei campi: ETag If-Match If-None-Match If-Range Formato: entity-tag = [ weak ] opaque-tag weak = "W/" opaque-tag = quoted-string

Range Units Premette ad un client di specificare nella richiesta che solo una parte dell’entità sia inclusa nella risposta Utilizzati nei campi: Range Content-Range L’unica range unit definita dall’HTTP/1.1 è “bytes”. Schema: range-unit = bytes-unit | other-range-unit bytes-unit = "bytes" other-range-unit = token

HTTP Messaggi

Tipi di messaggio HTTP-message = Request | Response Richieste da un client verso un server Risposte di un server verso un client Usano un formato di messaggio generico per trasferire le entità. generic-message = start-line *(message-header CRLF) CRLF [ message-body ] start-line = Request-Line | Status-Line

Headers del messaggio (1/2) general-header (applicabili ad entrambi i tipi di messaggio, ma non all’entità trasferita) Esempi: general-header = Cache-Control | Connection | Date | Pragma | Trailer | Transfer-Encoding | Upgrade | Via | Warning request-header response-header entity-header Formato generico Il nome del campo è case-insensitive

Headers del messaggio (2/2) Il formato più comune è il seguente: message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string> Ordine degli header non è significativo Sono permessi più header con lo stesso nome di campo, e vengono interpretati come una lista di possibili valori; l’ordine in cui sono ricevuti è significante, perché si intendono elencati partendo dal valore principale.

Corpo del messaggio Utilizzato per trasportare l’entità associata alla richiesta/risposta Il message body si differenzia dall’entity body solo quando è presente transfer-coding Il formato è il seguente: message-body = entity-body | <entity-body encoded as per Transfer-Encoding>

Lunghezza del messaggio La transfer-length di un messaggio è la lunghezza del message body, dopo che è stato applicato, se richiesto, transfer-codings

HTTP Richiesta

Richiesta: formato generale Metodo URL Versione sp cr lf Header: Valore Request = Request-Line *((general-header | request-header | entity-header) CRLF) CRLF [ message-body ]

Request Line Method Request-URI Request-Line = Method SP Request-URI SP HTTP-Version CRLF Method Indica quale metodo deve essere applicato alla risorsa richiesta. Method = "OPTIONS" | "GET" | "HEAD"| "POST" | "PUT" | "DELETE" | "TRACE" | "CONNECT" | extension-method extension-method = token Case-sensitive. Possibili errori ritornati dal server. 405 (Method Not Allowed) 501 (Not Implemented) Request-URI Identifica la risorsa a cui applicare la richiesta. Request-URI = "*" | absoluteURI | abs_path | authority (“*” significa che la richiesta non è applicabile a particolari risorse.)

Header di una richiesta Permettono al client di passare ulteriori informazioni sulla richiesta e su se stesso al server request-header = Accept | Accept-Charset | Accept-Encoding | Accept-Language | Authorization | Expect | From | Host | If-Match | If-Modified-Since | If-None-Match | If-Range | If-Unmodified-Since | Max-Forwards | Proxy-Authorization | Range | Referer | TE | User-Agent

HTTP Risposta

Risposta: formato generale Versione Status code Frase sp cr lf Header: Valore Response = Status-Line *((general-header | response-header | entity-header)CRLF) CRLF [ message-body ]

Status Line Contiene le informazioni sulla versione del protocollo, seguita da uno status code e dalla frase associata Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Status Code e Frase Esplicativa (1/2) Lo status-code è un intero di 3 cifre (destinato all’interpretazione automatica) che indica se e come il server ha capito la richiesta La frase è una descrizione testuale (destinata all’utente) dello status-code, solitamente standard La prima cifra dello status-code definisce la classe della risposta; le altre 2 non hanno un ruolo nella “categorizzazione”. Ci sono 5 valori permessi per la prima cifra: 1xx: Informational - Request received, continuing process 2xx: Success - The action was successfully received understood, and accepted 3xx: Redirection - Further action must be taken in order to complete the request 4xx: Client Error - The request contains bad syntax or cannot be fulfilled 5xx: Server Error - The server failed to fulfill an apparently valid request Gli status code HTTP sono estensibili. Alle applicazioni non è richiesto, sebbene sia raccomandato, capire il significato di tutti gli status code registrati, ma comunque ne devono capire la classe.

Status Code e Frase Esplicativa (2/2) "100" ; Continue | "101" ; Switching Protocols | "200" ; OK | "201" ; Created | "202" ; Accepted | "203" ; Non-Authoritative Information | "204" ; No Content | "205" ; Reset Content | "206" ; Partial Content | "300" ; Multiple Choices | "301" ; Moved Permanently | "302" ; Found | "303" ; See Other | "304" ; Not Modified | "305" ; Use Proxy | "307" ; Temporary Redirect | "400" ; Bad Request | "401" ; Unauthorized | "402" ; Payment Required | "403" ; Forbidden | "404" ; Not Found | "405" ; Method Not Allowed | "406" ; Not Acceptable | "407" ; Proxy Authentication Required | "408" ; Request Time-out | "409" ; Conflict | "410" ; Gone | "411" ; Length Required | "412" ; Precondition Failed | "413" ; Request Entity Too Large | "414" ; Request-URI Too Large | "415" ; Unsupported Media Type | "416" ; Requested range not satisfiable | "417" ; Expectation Failed | "500" ; Internal Server Error | "501" ; Not Implemented | "502" ; Bad Gateway | "503" ; Service Unavailable | "504" ; Gateway Time-out | "505" ; HTTP Version not supported | extension-code extension-code = 3DIGIT Reason-Phrase = *<TEXT, excluding CR, LF>

Header di una risposta Permettono al server di passare ulteriori informazioni sulla risposta che non possono essere messe nella status-line response-header = Accept-Ranges | Age | ETag | Location | Proxy-Authenticate | Retry-After | Server | Vary | WWW-Authenticate

HTTP Entità

Entità Richieste e risposte trasferiscono entità Consiste di: campi entity-header campo entity-body (opz.)

Entity Headers Specificano le metainformazioni sull’enity-body o, se il body non è presente, sulla risorsa identificata dalla richiesta entity-header = Allow | Content-Encoding | Content-Language | Content-Length | Content-Location | Content-MD5 | Content-Range | Content-Type | Expires | Last-Modified | extension-header extension-header = message-header Alcune metainformazioni sono obbligatorie, altre opzionali extension-header Permette di aggiungere campi entity-header senza modifiche al protocollo Problemi di interpretazione  campi ignoranti

Entity Body Spedito con richieste/risposte HTTP è in un formato codificato definito nei campi di header. Presente in un messaggio solo quando il message-body è presente. Type Il tipo di dati del body è determinato tramite gli header Content-Type e Content-Encoding, che definiscono 2 livelli di decodifica: entity-body := Content-Encoding( Content-Type( data ) ) Content-type: specifica di che tipo sia l’oggetto presente nel corpo dell’entità. Content-encoding: può essere usato per indicare codifiche aggiuntive applicate ai dati. Se non incluso (sconsigliato) dedurre il tipo dei dati ispezionando il contenuto oppure il nome del file che identifica la risorsa. Entity-length La lunghezza message-body del prima che siano state applicate le codifiche per il trasferimento.

HTTP Connessioni

Connessioni Non Persistenti vs Connessioni Persistenti Connessioni non persistenti: ciascuna connessione TCP veniva chiusa subito dopo che il server aveva inviato l’oggetto richiesto e non rimaneva disponibile per altri oggetti: ciascuna connessione TCP trasportava esattamente un messaggio di richiesta ed uno di risposta Connessioni persistenti: una singola connessione TCP per trasportare più oggetti Di default in HTTP/1.1 Vantaggi: Meno connessioni TCP aperte/chiuse  meno tempo di elaborazione CPU, meno tempo per allocare la memoria Richieste e risposte HTTP possono essere messe in pipeline (mandare multiple richieste senza attendere la risposta) Meno pacchetti inviati  meno congestione La latenza tra richieste successive è ridotta In caso di errori HTTP, non occorre chiudere la connessione TCP.

Passaggi della connessione Instaurazione (1/2) Server Client { RTT Richiesta del file Ricezione completa del file } Tempo di trasmissione del file Handshake a tre vie del TCP

Passaggi della connessione Chiusura (2/2) Server Client FIN ACK Chiusura standard del TCP I server solitamente hanno un time-out per chiudere le connessioni inattive. Quando un client o un server vanno in time-out, dovrebbero comunicarlo all’altro lato della connessione, in modo che questa venga chiusa correttamente. Un client, un server od un proxy possono chiudere la connessione di trasporto in qualsiasi momento. Il server non può chiudere una connessione durante la trasmissione di una risposta.

HTTP Metodi

Metodi Sicuri Metodi Idempotenti Sicuri: non provocano azioni inaspettate Get Head Idempotenti: ripetendo la stessa richiesta più volte, l’effetto è quello di una richiesta ripetuta una sola volta. Put Delete Implicitamente idempotenti: non hanno side-effect Option Trace È possibile che una sequenza di richieste idempotenti sia non idempotente.

Options Usato per richiedere informazioni sulle opzioni di comunicazione attivabili in una catena richiesta/risposta Informazioni non cacheable. Se request-URI = “*” opzioni applicabili ad una qualsiasi risorsa Se request-URI  “*” opzioni applicabili alla specifica risorsa Header Max-Forwards  definire la lunghezza massima della catena. Se Max-Forwards  0 Inoltro della richiesta Max-Forwards = Max-Forwards -1 Se Max-Forwards = 0 No inoltro della richiesta

Get Usato per richiedere la risorsa identificata dal Request-URI Se Request-URI = processo che produce dati  entità = dati risultanti get condizionale  l’entità richiesta deve essere trasferita solo se rispetta le condizioni indicate nei campi aggiuntivi Cache  permette di ridurre l’uso della rete Cambia la semantica del metodo get parziale  richiede che solo una parte dell’entità sia trasferita Ridurre l’uso della rete.

Head Risposta  meta-informazioni degli header Utilizzato per: testare la validità dei link l’accessibilità le modifiche

Post Usato per inviare dati al server Permette di uniformare in un unico metodo le seguenti funzioni: inviare un messaggio a gruppi (newsgroup, mailing list); inviare ad un processo i dati raccolti con un form; fare operazioni di append su un database. La risposta a questo metodo non può essere messa in cache.

Put Permette lo store di un’entità nella direcory indicata dal request-URI. Se il request-URI si riferisce ad una risorsa già esistente, la nuova entità viene considerata come una modifica alla risorsa già presente sul server. Se il request-URI non punta ad una risorsa esistente, viene inserita la nuova entità. La risposta a questo metodo non può essere messa in cache Il server risponde con 200 (ok) se la risorsa è stata modifica, con 201 (created) se la risorsa viene aggiunta

Delete Permette di richiedere all’origin server di cancellare la risorsa identificata dal Request-URI La risposta a questo metodo non può essere messa in cache. Le possibili risposte del server sono 3: 200 (ok): se la richiesta è stata eseguita con successo 202 (accepted): se la richiesta è arrivata ma non è ancora stata eseguita nessuna azione 204 (no content): se la richiesta è stata eseguita e la risposta non include nessuna entità

Trace Permette al client di esaminare la catena attraversata dal messaggio, per ricavare informazioni di test o diagnostiche. La risposta a questo metodo non può essere messa in cache.

Connect Riservato per quando un proxy può dinamicamente diventare un tunnel

HTTP Status code

Informazione (1xx) Questa classe di status code indica una risposta provvisoria, che consiste solo della linea di stato e degli headers opzionali. Il client dovrebbe sempre essere prono ad accettare uno o più stati 1xx prima della risposta regolare; uno stato 1xx inaspettato deve essere ignorato dal client. Il proxy deve inoltrare una risposta 1xx, purché non sia caduta la connessione tra il client ed il proxy e purché non abbia richiesto esso stesso la generazione della risposta 1xx. 100 Continue È usato per informare il client che la parte iniziale della richiesta è stata correttamente ricevuta dal server. 101 Switching Protocols È usato per cambiare il protocollo di livello applicazione usato durante una connessione.

Successo (2xx) (1/2) Questa classe di status code indica che la richiesta del client è stata ricevuta con successo, capita ed accettata. 200 OK La richiesta è riuscita. L’informazione ritornata con la risposta dipende dal metodo usato nella richiesta, esempi: get: un’entità corrispondente a quella richiesta è stata spedita nella risposta head: i campi di header corrispondenti a quelli della risorsa richiesta sono stati spediti nella risposta, senza il message-body post: un’entità che descrive o contiene il risultato di un’azione trace: un’entità che contiene il messaggio di richiesta così come è stato ricevuto dal server 201 Created La richiesta è stata soddisfatta e corrisponde ad una nuova risorsa creata. 202 Accepted La richiesta è stata accettata, ma non ancora processata completamente. Lo scopo è di permettere richieste asincrone.

Successo (2xx) (2/2) 203 Non-Authoritative Information 204 No Content Le metainformazioni ritornate negli header non sono il set definitivo disponibile dall’origin server, ma sono raccolte localmente o copiate su una terza parte. Il set può essere un subset o un superset della versione originale. 204 No Content Il server ha soddisfatto la richiesta, ma non c’è bisogno di ritornare un entity-body. La risposta può includere metainformazioni nuove od aggiornate negli header. 205 Reset Content Il server ha soddisfatto la richiesta e l’user agent dovrebbe fare un reset della visione del documento che ha causato l’invio della richiesta. Questo permette, ad esempio, di far inserire input all’utente per poi cancellarlo dal form quando i dati vengono correttamente processati. 206 Partial Content Il server ha soddisfatto la richiesta di un get parziale. La risposta deve includere gli header: Content-Range, Date, ETag e/o content-Location, Expires, Cache-Control, Vary.

Redirezione (3xx) (1/2) Questa classe di status code indica quali azioni future deve eseguire l’user agent per soddisfare le richieste 300 Multiple Choices La risorsa richiesta corrisponde ad una qualsiasi delle rappresentazioni disponibili, ognuna con una specifica locazione; l’utente, o lo user agent, possono scegliere la preferita e reindirizzare la richiesta alla locazione specifica. Il corpo della risposta dovrebbe contenere una lista delle caratteristiche e delle locazioni delle risorse, in modo che possa essere scelta la più appropriata. Questa risposta può essere messa in cache. 301 Moved Permanently La risorsa richiesta è stata assegnata permanentemente ad un nuovo URI. La richiesta può essere rigirata automaticamente se si tratta di get o header, altrimenti deve essere richiesta conferma all’utente. 302 Found La risorsa richiesta risiede temporaneamente sotto un altro URI. La richiesta può essere rigirata automaticamente se si tratta di get o header, altrimenti deve essere richiesta conferma all’utente.

Redirezione (3xx) (2/2) 303 See Other 304 Not Modified 305 Use Proxy La risorsa richiesta può essere travata sotto un altro URI. Non è una redirezione definitiva, ma solo momentanea. La risposta non può essere messa in cache. 304 Not Modified Il server dovrebbe rispondere con questo status code ad un get condizionale quando la risorsa richiesta non è stata modificata rispetto alla copia presente sul client. 305 Use Proxy Si deve accedere alla risorsa richiesta tramite un proxy. 306 Unused Lo status code 306 era usato in precedenti versioni di HTTP, non è più utilizzato, e il codice è riservato. 307 Temporary Redirect La risorsa richiesta risiede temporaneamente sotto un URI diverso.

Client Error (4xx) (1/4) Questa classe di status code è utilizzata quando sembra che il client abbia sbagliato. Eccetto quando risponde ad una richiesta head, il server dovrebbe includere un’entità contenente spiegazioni sull’errore, specificando se si tratta di una condizione temporanea o permanente. 400 Bad Request La richiesta non viene capita dal server a causa di sintassi errata. 402 Payment Required Questo codice è riservato per usi futuri. 403 Forbidden Il server capisce la richiesta, ma rifiuta di soddisfarla. Il server può includere le motivazioni del rifiuto nel corpo dell’entità; se il server non vuole dare queste informazioni, può rispondere anche con lo status code 404. 404 Not Found Il server non ha trovato la risorsa richiesta. Questo status code è anche usato quando nessun altro status code di risposta è applicabile. 405 Method Not Allowed Il metodo specificato nella linea di richiesta non è permesso per la risorsa identificata dall’URI. La risposta deve includere la lista dei metodi permessi per la risorsa richiesta. 406 Not Acceptable La risorsa richiesta può solo generare in risposta entità che hanno caratteristiche differenti da quelle accettate dal client, specificate negli headers.

Client Error (4xx) (2/4) 407 Proxy Authentication Required Questo codice indica che il client deve autenticarsi con il proxy. Il proxy deve rispondere con un messaggio contenente l’header Proxy-Authenticate; il client può ripetere la richiesta inserendo l’header Proxy-Authorization. 408 Request Timeout Il client non ha prodotto nessuna richiesta nell’arco di tempo in cui il server era disposto ad aspettare. 409 Conflict La richiesta non può essere completata per via di un conflitto con lo stato corrente della risorsa. Questo codice è permesso solo in quelle situazioni in cui ci si aspetta che l’utente sia in grado di risolvere il conflitto. La risposta dovrebbe includere nel body informazioni per permettere all’utente di identificare la sorgente del conflitto. 410 Gone La risorsa richiesta non è più presente sul server e non ne è conosciuta la nuova locazione. Questa condizione deve essere considerata permanente. Se il server non riesce a determinare se la condizione è permanente, può anche rispondere con 404 (Not Found). 411 Length Required Il server rifiuta di rifiutare la richiesta perché non è definito il campo Content-Length.

Client Error (4xx) (3/4) 412 Precondition Failed Le pre-condizioni impostate in uno o più headers sono valutate false. 413 Request Entity Too large Il server rifiuta di processare la richiesta perché l’entità richiesta è più grande di quella che vuole o può processare. Il server può chiudere la connessione per prevenire l’invio di altre richieste analoghe. Se la condizione è temporanea, il server dovrebbe includere nella risposta l’header Retry-After, che indica dopo quanto tempo il client può riprovare a sottomettere la stessa richiesta. 414 Request-URI Too Long Il server si rifiuta di servire la richiesta perché il request-URI è più lungo di quello che può interpretare. 415 Unsupported Media Type Il server si rifiuta di servire la richiesta perché l’entità della richiesta è in un formato non supportato dalla risorsa richiesta. 416 Requested Range Not Satisfiable Un server dovrebbe ritornare questo status code se una richiesta contiene l’header Range ed il valore specificato supera il valore possibile. 417 Expectation Failed Le aspettative richieste nell’header Expect non possono essere fornite dal server.

Client Error (4xx) (4/4) 401 Unauthorized La richiesta necessita di autenticazione dell’utente. La risposta deve includere un header WWW-Authenticate. Il client può ripetere la richiesta inserendo l’header Authorization. Se la richiesta include già le credenziali di autorizzazione, lo status code 401 indica che le credenziali non sono state accettate. Richiesta Authorization presente? si Credenziali ok? Risposta no 401 Unauthorized WWW-Authenticate

Server Error (5xx) Questa classe di status code è utilizzata quando il server è consapevole di un suo errore, oppure è incapace di processare una richiesta. Eccetto che in risposta ad una richiesta di head, il server dovrebbe includere nella risposta un’entità contenente la spiegazione sulla situazione di errore, specificando se è temporanea o permanente. L’user agent dovrebbe mostrare l’entità ricevuta all’utente. 500 Internal Server Error Il server ha riscontrato una condizione inaspettata che non gli permette di soddisfare la richiesta. 501 Not Implemented Il server non supporta le funzionalità richieste per soddisfare la richiesta. 502 Bad Gateway Il server, mentre funge da gateway o da proxy, riceve un risposta invalida dal server a cui ha chiesto di soddisfare la richiesta. 503 Service unavailable Il server non riesce a processare la richiesta per overloading temporaneo o per manutenzione. Se il server conosce la durata temporale di questa condizione, può comunicarla al client tramite l’header Retry-After. 504 Gateway Timeout Il server, mentre funge da gateway o da proxy, non riceve tempestivamente (prima del timeout) la risposta dal server di cui ha bisogno per completare la richiesta (es: origin server, dns, ...) 505 HTTP Version Not Supported Il server non supporta la versione del protocollo HTTP usata in una richiesta.

Negoziazione dei contenuti HTTP Negoziazione dei contenuti

Cos’è Negoziazione dei contenuti: il processo di selezione della “miglior” rappresentazione da spedire in risposta, quando ci sono rappresentazioni multiple 3 tipi di negoziazione: server-driven client-driven (o agent-driven) server-driven + client-driven  Negoziazione trasparente

Server-driven (1/2) Client Alg. di scelta Server

Server-driven (2/2) Selezione: Conviene: Svantaggi: fatta da un algoritmo situato sul server in base alla disponibilità della rappresentazione su alcuni header della richiesta Conviene: quando è difficile descrivere l’algoritmo di scelta allo user agent quando il server desidera scegliere subito la copia migliore, per evitare successive richieste Svantaggi: difficile per il server determinare il “migliore” per ogni utente complicato l’algoritmo di scelta utilizzando rappresentazioni diverse per utenti multipli, non si sfruttano le bene le cache Per abilitare la negoziazione server-driven sono disponibili i seguenti headers: Accept-Charset, Accept-Encoding, Accept-Language, User-Agent, vary (utilizzato per indicare ulteriori parametri che il server può utilizzare nella scelta).

Client-driven (1/2) Richiesta Lista di risorse disponibili Server Alg. di scelta Client Richiesta Lista di risorse disponibili Richiesta URI specifico Entità

Client-driven (2/2) La selezione (automatica o manuale) Vantaggiosa: è compiuta dall’agent-driven, dopo aver ricevuto una risposta iniziale dall’origin server basata su una lista di rappresentazioni disponibili (ognuna identificata da un proprio URI, inclusa negli headers o nel body della risposta) Vantaggiosa: quando il server non è in grado di determinare le capacità dello user agent Svantaggio: c’è bisogno di una seconda risposta prima di ottenere l’entità desiderata

Negoziazione trasparente Combinazione Server-Driven Agent-Driven Vantaggio Distribuire il carico di lavoro

HTTP Caching

Caching Le performance di un sistema distribuito possono essere notevolmente incrementate usando le cache eliminando la necessità di spedire la richiesta eliminando la necessità di spedire la risposta diminuendo il carico della rete Correttezza della cache risposta più recente risposta coerente con quella presente sull’origin server Warnings Una cache può ritornare nella risposta una copia scaduta, aggiungendo l’header warning, in modo da permettere al client di compiere le azioni appropriate. Cache-control Mechanisms Permette a client / server di trasmettere direttive sulla cache Se vi sono conflitti tra gli header, viene applicata l’azione più restrittiva.

Expiration Model Validation Model Server-Specified Expiration Meccanismo primario di espirazione: fornito dal server tramite un expiration time esplicito (heaeder Expires, direttive di cache control) Si indica per quanto tempo può essere considerata valida la copia in cache, senza bisogno di contattare l’origin server per la convalida. Heuristic Expiration Se l’orgin server non assegna un expiration time esplicito, le cache tipicamente assegnano alla copia locale un expiration time euristico. Validation model Quando una cache ha una copia non più valida, prima di inviarla in risposta deve validarla con l’origin server. Last-Modified Dates Header Last-Modified: un copia è considerata valida se l’entità non è stata modificata dopo questa data. Weak e Strong Validators Strong validator: per ogni cambiamento dell’entità originale, la cache deve essere aggiornata (Modalità più utlizzata) Weak validator: la cache viene aggiornata solo in presenza di cambiamenti semanticamente significanti.

Caching Note Response cacheability Costruzione di risposte dalla cache con l’intera copia presente in cache combinando parti memorizzate in cache con parti nuove Caches shared e non-shared Non-shared: accessibili solo da un singolo utente Shared: accessibili a tutti Risposte incomplete Invalidazione non garantita Cache Replacement History list Non è richiesto a questo meccanismo di visualizzare la “versione valida” della risorsa, anzi, deve mostrare all’utente quello che ha visto quando la risorsa è stata ricevuta precedentemente Non è applicato nessun meccanismo di expiration time.

HTTP Header

Accept Utilizzato per indicare quali media types sono accettabili nella risposta Accept = "Accept" ":" #( media-range [ accept-params ] ) media-range = ( "*/*" | ( type "/" "*" ) | ( type "/" subtype ) ) *( ";" parameter ) accept-params = ";" "q" "=" qvalue *( accept-extension ) accept-extension = ";" token [ "=" ( token | quoted-string ) ] Esempio: Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5 Se non è presente l’header Accept, significa che ogni media types è accettato. Se è presente l’header Accept e il server non riesce a soddisfare la richiesta, quest’ultimo risponde con lo status code 406 (not acceptable).

Accept-Charset Utilizzato per indicare quali character set sono accettabili nella risposta Accept-Charset = "Accept-Charset" ":" 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] ) Esempio: Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 Se non è presente l’header Accept-charset, significa che ogni character set è accettato. Se è presente l’header Accept-charset e il server non riesce a soddisfare la richiesta, quest’ultimo risponde con lo status code 406 (not acceptable).

Accept-Encoding Utilizzato per indicare i content-codings accettabili nella risposta Accept-Encoding = "Accept-Encoding" ":" 1#(codings [ ";" "q" "=" qvalue ]) codings = ( content-coding | "*" ) Esempio: Accept-Encoding: compress;q=0.5, gzip;q=1.0 Se non è presente l’header Accept-Encoding, significa che ogni character set è accettato. Se è presente l’header Accept-Encoding e il server non riesce a soddisfare la richiesta, quest’ultimo risponde con lo status code 406 (not acceptable.

Accept-Language Utilizzato per indicare i natuarl languages preferiti per la risposta Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] ) language-range = ((1*8ALPHA *( "-" 1*8ALPHA )) | "*" ) Esempio: Accept-Language: da, en-gb;q=0.8, en;q=0.7

Accept-Ranges Permette al server di indicare quali range di richiesta accetta per una risorsa Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges acceptable-ranges = 1#range-unit | "none«  Esempio: Accept-Ranges: bytes

Age Permette al client di stimare da quanto tempo è stata generata la risorsa Age = "Age" ":" age-value age-value = delta-seconds

Allow Elenca il set di metodi supportati dalla risorsa identificata dal request-URI Allow = "Allow" ":" #Method Esempio: Allow: GET, HEAD, PUT Questo header non impedisce al client di provare altri metodi.

Authorization Permette ad un client di autenticarsi con il server Authorization = "Authorization" ":" credentials

Cache-Control Utilizzato per specificare le direttive che devono essere seguite dai meccanismi di cache Cache-Control = "Cache-Control" ":" 1#cache-directive cache-directive = cache-request-directive | cache-response-directive cache-request-directive = "no-cache" | "no-store" | "max-age" "=" delta-seconds | "max-stale" [ "=" delta-seconds ] | "min-fresh" "=" delta-seconds | "no-transform" | "only-if-cached" | cache-extension cache-response-directive = "public" | "private" [ "=" <"> 1#field-name <"> ] | "no-cache" [ "=" <"> 1#field-name <"> ] | "must-revalidate" | "proxy-revalidate" | "s-maxage" "=" delta-seconds cache-extension = token [ "=" ( token | quoted-string ) ]

Connection Permette al server di specificare le opzioni desiderate per una particolare connessione Connection = "Connection" ":" 1# (connection- token) connection-token = token Esempio: Connection: close

Content-Encoding Indica quali content conding opzionali sono stati applicati all’entity body, e quindi quali meccanismi di decodifica devono essere applicati, in ordine, per ottenere il media-type. Content-Encoding = "Content-Encoding" ":" 1#content-coding Esempio: Content-Encoding: gzip È primariamente usato per comprimere documenti Caratteristico dell’entità identificata dal Request-URI. Se il content-coding di un’entità in una richiesta non è accettabile dall’origin server, quest’ultimo dovrebbe rispondere con lo status code 415 (Unsupported Media Type).

Content-Language Descrive quale linguaggio naturale è utilizzato per l’entità Content-Language = "Content-Language" ":" 1#language-tag Esempio: Content-Language: en

Content-Length Indica la dimensione dell’entity-body Content-Length = "Content-Length" ":" 1*DIGIT Esempio: Content-Length: 3495

Content-Location Indica da quali ulteriori locazioni, oltre all’URI specificato nella richiesta, l’entità è accessibile Content-Location = "Content-Location" ":"( absoluteURI | relativeURI )

Content-MD5 Digest MD5 dell’entity body Content-MD5 = "Content-MD5" ":" md5-digest md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864> Permette di controllare l’integrità del messaggio Il digest MD5 è basato sul contenuto dell’entity-body, incluso ogni content-coding applicato. Se il messaggio è stato trasferito con transfer-encoding, prima di verificare l’integrità deve essere rimossa la codifica L’HTTP permette di calcolare un digest MD5 anche per i tipi MIME Solo gli origin server o i client possono generare questo campo

Content-Range Spedito con un entity-body parziale per specificarne la posizione rispetto al totale Content-Range = "Content-Range" ":" content-range-spec content-range-spec = byte-content-range-spec byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( instance-length | "*" ) byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | "*“ instance-length = 1*DIGIT Esempio: Content-Range: bytes 21010-47021/47022 Se il server riceve una richiesta con un range non soddisfabile, risponde con lo status code 416 (Requested range not satisfiable).

Content-Type Indica il media type dell’entity-body Content-Type = "Content-Type" ":" media-type Esempio: Content-Type: text/html; charset=ISO-8859-4

Date Rappresenta data e ora in cui il messaggio è stato generato Date = "Date" ":" HTTP-date Esempio: Date: Tue, 15 Nov 1994 08:12:31 GMT Il server di origine deve sempre includere questo campo, tranne in questi casi: opzionale se si tratta di una risposta 100 (Continue) o 101 (Switching Protocols) se è impossibile, causa errori hw/sw, generare una data valida se il server non è dotato di un clock sufficientemente accurato da fornire una buona approssimazione del tempo Quando un client riceve un messaggio senza data, deve assegnargliela.

ETag Fornisce il valore dell’entity tag per la variante richiesta ETag = "ETag" ":" entity-tag Può essere utilizzato per confrontare entità ricevute dalla stessa risorsa Esempi: ETag: "xyzzy" ETag: W/"xyzzy" ETag: ""

Expect Utilizzato per indicare quale particolare comportamento del server è richiesto dal client Expect = "Expect" ":" 1#expectation expectation = "100-continue" | expectation-extension expectation-extension = token [ "=" ( token | quoted- string ) *expect-params ] expect-params = ";" token [ "=" ( token | quoted- string ) ] Un server che non capisce, o è in capace di soddisfare la richiesta, deve rispondere con 417 (Expectation Failed)

Expires Indica la data/ora dopo cui la risposta deve essere considerata scaduta Expires = "Expires" ":" HTTP-date Esempio: Expires: Thu, 01 Dec 1994 16:00:00 GMT

From Dovrebbe contenere un indirizzo e-mail From = "From" ":" mailbox Esempio: From: webmaster@w3.org

Host Specifica l’host e la porta della risorsa che ha generato la richiesta Host = "Host" ":" host [ ":" port ] Esempio: Host: www.w3.org Se il numero di porta non è specificato, viene utilizzato il numero di default per il servizio richiesto

If-Match Un client che ha precedentemente ottenuto da una risorsa una o più entità, può verificare se una di queste è quella corrente, includendo in quest’header una lista degli entity tag associati If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) Esempi: If-Match: "xyzzy" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: * È utilizzato in richieste condizionali Se nessuno degli entity tag corrisponde, il server deve rispondere con 412 (Precondition Failed)

If-Modified-Since Rende un metodo condizionale: se l’entità richiesta non è stata modificata dal tempo specificato in questo campo (304, not modified), non deve essere rispedita al client If-Modified-Since = "If-Modified-Since" ":" HTTP-date Esempio: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

If-None-Match Un client che ha precedentemente ottenuto da una risorsa una o più entità, può verificare se nessuna di queste è quella corrente, includendo in quest’header una lista degli entity tag associati If-None-Match = "If-None-Match" ":" ( "*" | 1#entity- tag ) Esempi: If-None-Match: "xyzzy" If-None-Match: W/"xyzzy" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: * Rende un metodo condizionale

If-Range Se un client ha una copia parziale di un’entità nella sua cache, e vorrebbe avere una copia aggiornata dell’intera entità, può utilizzare questo campo con un GET condizionale If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) Se la condizione fallisce (la parte è stata modificata), il client dovrà inoltrare una seconda richiesta.

If-Unmodified-Since Se la risorsa non è stata modifica dalla data indicata in questo campo, il server dovrebbe elaborare la richiesta If-Unmodified-Since = "If-Unmodified- Since" ":" HTTP-date Esempio: If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT Rende un metodo condizionale.

Last-Modified Indica data e ora dell’ultima modifica apportata alla risorsa Last-Modified = "Last-Modified" ":" HTTP-date Esempio: Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

Location Utilizzato per re-indirizzare il richiedente ad un altro Request-URI Location = "Location" ":" absoluteURI Esempio: Location:http://www.w3.org/pub/WWW/People.html

Max-Forwards Fornisce un meccanismo per limitare il numero di proxy o gateway che possono inoltrare la richiesta Max-Forwards = "Max-Forwards" ":" 1*DIGIT Quando un proxy/gateway riceve una richiesta con questo campo, deve decrementarne il valore. Quando un proxy/gateway riceve una richiesta con questo campo pari a 0, non può inoltrare la richiesta

Pragma Utilizzato per includere specifiche direttive di implementazione che devono essere applicate ad ogni ricevente lungo la catena Pragma = "Pragma" ":" 1#pragma-directive pragma-directive = "no-cache" | extension- pragma extension-pragma = token [ "=" ( token | quoted-string ) ] Specifica comportamenti opzionali

Proxy-Authenticate Il campo valore corrisponde allo schema di autenticazione ed ai parametri utilizzabili Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge Deve essere incluso come parte di una risposta 407 (Proxy Authentication Required) Questa autenticazione è applicabile solo alla connessione corrente e non deve essere trasmessa al client

Proxy-Authorization Permette ad un client di identificarsi con un proxy Proxy-Authorization = "Proxy-Authorization" ":" credentials Quando nella catena sono presenti proxy multipli, questo campo viene consumato dal primo proxy della catena che si aspetta di ricevere credenziali

Range Byte Ranges Le entità in messaggi HTTP sono rappresentate come sequenze di byte ranges-specifier = byte-ranges-specifier byte-ranges-specifier = bytes-unit "=" byte-range-set byte-range-set = 1#(byte-range-spec|suffix-byte-range-spec) byte-range-spec = first-byte-pos "-" [last-byte-pos] first-byte-pos = 1*DIGIT last-byte-pos = 1*DIGIT suffix-byte-range-spec = "-" suffix-length suffix-length = 1*DIGIT Range Retrieval Requests I metodi di richiesta possono riferirsi, grazie a questo campo, ad una o più parti dell’entità Range = "Range" ":" ranges-specifier

Referer Permette al client di specificare, per beneficio del server, l’indirizzo della risorsa da cui ha ottenuto il request-URI Referer = "Referer" ":" ( absoluteURI | relativeURI ) Esempio: Referer: http://www.w3.org/hypertext/DataS/Ov.html

Retry-After Utilizzato in una risposta 503 (Service Unavailable) indica per quanto tempo approssimativamente il servizio non sarà disponibile Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) Esempi: Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: 120

Server Contiene informazioni sul software usato dall’origin server Server = "Server" ":" 1*(product | comment) Esempio: Server: CERN/3.0 libwww/2.17 Un proxy non deve modificare questo campo Può contenere token multipli, elencati nell’ordine con cui maggiormente identificano l’applicazione

TE Indica quali transfer-codings saranno accettata nella risposta TE = "TE" ":" #( t-codings ) t-codings = "trailers" | ( transfer-extension [ accept-params ] )

Trailer Indica quale set di header è presente nel trailer di un messaggio codificato con chunked transfer-coding Trailer = "Trailer" ":" 1#field-name

Transfer-Encoding Indica quali tipi di trasformazioni sono state applicate al message-body Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding È una proprietà del messaggio e non dell’entità

Upgrade Permette al client di specificare quali protocolli di comunicazione aggiuntivi supporta (ad es. una nuova versione di HTTP) e quali gli piacerebbe usare Upgrade = "Upgrade" ":" 1#product Esempio: Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

User-Agent Contiene informazioni sul software usato dal client User-Agent = "User-Agent" ":" 1*(product | comment) Esempio: User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Può contenere token multipli, elencati nell’ordine con cui maggiormente identificano l’applicazione

Vary Indica il set di request-header che determinano completamente se è permesso l’uso di una risposta messa precedentemente in cache, senza rivalidazione Vary = "Vary" ":" ( "*" | 1#field-name )

Via Deve essere usato dai gateway e dai proxy per indicare i protocolli e i riceventi intermedi della catena Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) received-protocol = [ protocol-name "/" ] protocol-version protocol-name = token protocol-version = token received-by = ( host [ ":" port ] ) | pseudonym pseudonym = token

Warning Utilizzato per trasportare ulteriori informazioni sullo stato di un messaggio Warning = "Warning" ":" 1#warning-value warning-value = warn-code SP warn-agent SP warn-text [SP warn-date] warn-code = 3DIGIT warn-agent = ( host [ ":" port ] ) | pseudonym ; the name or pseudonym of the server adding ; the Warning header, for use in debugging warn-text = quoted-string warn-date = <"> HTTP-date <"> È permessa la presenza di più warning Codici: 110 Response is stale 111 Revalidation failed 112 Disconnected operation 113 Heuristic expiration 199 Miscellaneous warning 214 Transformation applied 299 Miscellaneous persistent warning

WWW-Authenticate Il valore di questo campo indica lo schema di autenticazione applicabile WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge Deve essere incluso in un messaggio di risposta 401 (Unauthorized)

Considerazioni sulla sicurezza HTTP Considerazioni sulla sicurezza

Informazioni personali Client HTTP: conoscenza di un gran numero di informazioni personali Esempi: nome dell’utente e-mail password prevenire la diffusione di queste informazioni Implementatori di interfacce: stare molto attenti Storia piccoli errori o incomprensioni (tra l’interfaccia e l’utente) portano a gravi problemi di sicurezza e/o di privacy

Informazioni personali Abuso di informazioni server log dati sull’utente e sulle sue richieste informazioni confidenziali in alcuni paesi sono regolate da specifiche leggi Le persone che usano il protocollo HTTP per raccogliere dati responsabili della privatezza di questi dati non devono distribuire il materiale senza permesso

Informazioni personali Trasferimento di informazioni sensibili HTTP non può regolare il contenuto dei dati che trasferisce Non c’è nessun metodo per determinare a priori la sensibilità di particolari tipi di informazioni in determinati contesti. Le applicazioni dovrebbero sopperire a questa mancanza, fornendo maggior controllo. Esempi: versione di un software  macchina più vulnerabile header referer solitamente indica URI privato  pubblicazione sarebbe inappropriata informazioni nel header from  in conflitto con l’interesse di privacy dell’utente Header Accept può rivelare informazioni sull’utente al server a cui accede Esempio: Accept-Language. Soluzioni: non mandare le informazioni mandare solo informazioni selezionate (adeguate interfacce di scelta) servirsi di un proxy per filtrarle

Bugs di sicurezza Attacchi basati su file e path name Gli origin server dovrebbero ritornare i file richiesti, stando attenti a ritornare solo le risorse decise dall’amministratore del server DNS spoofing I client che usano i DNS rischiano attacchi di sicurezza basati su una deliberata falsa-associazione tra indirizzo IP e nome del DNS Credenziali di autenticazione I client HTTP tipicamente re-inviano le informazioni di autenticazione per un tempo indefinito. I server HTTP/1.1 non hanno nessun metodo per scartare le credenziali Proxies e caching Per la loro natura i proxy sono “men-in-the-middle”, conosco informazioni legate alla sicurezza, e quindi rappresentano un’opportunità per degli attacchi. Le cache aumentano questo problema Soluzione parziale: crittografia Attacchi denial of service

HTTP/TLS Introduzione

Estratto L’uso sempre maggiore di HTTP per applicazioni sensibili ha richiesto di applicare misure di sicurezza TLS per rendere sicure le connessioni HTTP sulla rete Internet La pratica corrente è quella di utilizzare HTTP sopra SSL (il predecessore di TSL), distinguendo il traffico sicuro da quello insicuro utilizzando differenti porte del server Concettualmente, HTTP/TLS è molto semplice: basta utilizzare HTTP sopra TLS come HTTP su TCP.

Inizializzazione della connessione HTTP/TLS Inizializzazione della connessione

Inizializzazione connessione L’agente dell’utente che funge da HTTP client, agisce anche come TLS client L’agente dell’utente inizia una connessione con il server sulla porta appropriata e spedisce un TLS ClientHello per cominciare l’handshake TLS Dopo aver finito l’handshake TLS il client può inviare la prima richiesta HTTP

Chiusura della connessione HTTP/TLS Chiusura della connessione

Chiusura connessione (1/3) Quando avviene uno scambio di alert di chiusura valido, l’implementazione può assumere che non saranno più ricevuti dati su quella connessione Un’implementazione può anche chiudere la connessione senza aspettare l’alert di risposta, generando così una “chiusura incompleta”. Questo dovrebbe essere fatto solo quando un’applicazione sa di aver ricevuto tutti i dati del messaggio Chiusura prematura: un’implementazione che riceve una chiusura di connessione senza prima aver ricevuto un alert valido di chiusura

Chiusura connessione (2/3) Comportamento del client HTTP usa la chiusura della connessione come segnale di “fine dati”  l’implementazione del client deve trattare ogni chiusura prematura come un errore ed i dati ricevuti come potenzialmente troncati Due casi in particolare sono degni di nota: Una risposta HTTP senza header Content-Length chiusura della connessione fine dei dati chiusura prematura dovuta ad un attacco Una risposta HTTP con un header Content-Length valido chiusa prima che tutti i dati siano stati letti. server ha sbagliato il calcolo della lunghezza un attacco ha troncato la connessione Quando si incontra una chiusura prematura un client dovrebbe trattare come completate le richieste per cui ha ricevuto tanti dati quanti quelli specificati nel header Content-Length Un client deve spedire un alert di chiusura prima di chiudere la connessione Un client che non si aspetta di ricevere altri dati può chiudere la connessione senza aspettare l’alert di chiusura del server  chiusura incompleta lato server

Chisura connessione (3/3) Comportamento del server Il server deve attendere di iniziare uno scambio di alert di chiusura con il client prima di chiudere la connessione Un server può chiudere la connessione senza aspettare l’alert di chiusura del client  chiusura incompleta lato client

HTTP/TLS Porte

Numero di porta Il primo dato che un server HTTP si aspetta di ricevere da un client è l’header Request-Line Il primo dato che un server TLS (o HTTP/TLS server) si aspetta di ricevere da un client è il ClientHello Di conseguenza, la pratica comune è di far girare HTTP e TLS su porte separate per distinguere il protocollo utilizzato Quando HTTP/TLS gira sopra una connessione TCP/IP, la porta di default è la 443 Questo non preclude che HTTP/TLS possa esistere sopra altri protocolli di trasporto (TLS si aspetta una connessione affidabile)

HTTP/TLS URI

Formato degli URI Gli URI HTTP/TLS sono differenziati da quelli HTTP utilizzando come identificativo del protocollo “https” al posto di “http”

RIFERIMENTI

Riferimenti RFC 2616 - Hypertext Transfer Protocol - HTTP/1.1 RFC 2818 (rfc2818) - HTTP Over TLS Internet e reti di calcolatori - McGraw-Hill – II ed.