http e http/tls relazione di ambra giovannini ferrara – 02/12/2005

HTTP e HTTP/TLS

Relazione di

Ambra Giovannini

Ferrara – 02/12/2005

Presentazione (1/2)

I. HTTP Introduzione

Storia Terminologia Funzionamento generale

Notazioni e grammatica Parametri Messaggi

Richiesta Risposta

Entità Connessioni Metodi

Presentazione (2/2)

I. HTTP Status code Autenticazione Negoziazione dei contenuti Caching Header Considerazioni sulla sicurezza

II. 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 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 Ov

Catena della richiesta


UA Ov vv v

CBA

Catena della richiesta


UA Ovv

CBA

UA: user agentO: origin serverV: connessioneA, B, C: server intermedi (es:proxy)

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 | regola2Gli elementi separati dalla barra sono alternative.

(regola1 regola2 )Gli elementi chiusi tra parentesi sono trattare come un singolo elemento.

*regolaIl 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 regolaSpecifica ripetizione: esattamente n occorrenze dell’elemento<n>(elemento) è equivalente a <n>*<n>(elemento)

# regolaDefinisce 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.

; commentoIl 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-daterfc1123-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 4DIGITdate1 = 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:59wkday = "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. Schema:

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 CodingsIndica 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-extensiontransfer-extension = token *( ";" parameter )I parametri sono espressi nella forma attributo/valore:parameter = attribute "=" valueattribute = tokenvalue = 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 CRLFchunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLFchunk-size = 1*HEXlast-chunk = 1*("0") [ chunk-extension ] CRLFchunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )chunk-ext-name = tokenchunk-ext-val = token | quoted-stringchunk-data = chunk-size(OCTET)trailer = *(entity-header CRLF)

Content coding si riferisce all’entità originaleTransfer 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 = tokensubtype = 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*8ALPHAsubtag = 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-tagweak = "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-unitbytes-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 (2/2) Il formato più comune è il seguente:

message-header = field-name ":" [ field-value ]field-name = tokenfield-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

Request = Request-Line *((general-header | request-header | entity-header) CRLF) CRLF [ message-body ]

Metodo URL Versionesp sp cr lf

Header: sp Valore cr lf

cr lf


Request Line

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-methodextension-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.)

HTTP

Risposta

Risposta: formato generale

Response = Status-Line *((general-header | response-header | entity-header)CRLF) CRLF [ message-body ]

Versione Status code Frasesp sp cr lf


cr lf


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.

HTTP

Entità

Entità

Richieste e risposte trasferiscono entità

Consiste di: campi entity-header campo entity-body (opz.)

Entity HeadersSpecificano 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 Persistentivs 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 connessioneInstaurazione (1/2)

Handshake a tre vie del TCP

ServerClient

{RTT

{RTT

Richiesta del file

{Ricezione completa del file

} Tempo di trasmissione del file

Passaggi della connessioneChiusura (2/2)

ServerClient

FIN

ACK

ACK

FIN

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 SicuriMetodi 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. Get Head 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


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.


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

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

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?

siCredenziali

ok?

siRisposta

no

401 Unauthorized

no

401 UnauthorizedWWW-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.

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)

ClientAlg. di sceltaServer

Server-driven (2/2) Selezione:

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)

ServerAlg. di scelta Client

Richiesta

Lista di risorse disponibili

Richiesta URI specifico

Entità

Client-driven (2/2)

La selezione (automatica o manuale) è 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

WarningsUna 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 ModelValidation Model Expiration Model

Server-Specified ExpirationMeccanismo 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.

CachingNote

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

AcceptUtilizzato 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-EncodingUtilizzato 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

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-EncodingIndica 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: ""

ExpectUtilizzato 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: [email protected]

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-MatchUn 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-MatchUn 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

RangeByte Ranges

Le entità in messaggi HTTP sono rappresentate come sequenze di byte

ranges-specifier = byte-ranges-specifierbyte-ranges-specifier = bytes-unit "=" byte-range-setbyte-range-set = 1#(byte-range-spec|suffix-byte-range-spec)byte-range-spec = first-byte-pos "-" [last-byte-pos]first-byte-pos = 1*DIGITlast-byte-pos = 1*DIGITsuffix-byte-range-spec = "-" suffix-lengthsuffix-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 ] )

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

WarningUtilizzato 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)

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 personaliAbuso di informazioni server log

Server 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 personaliTrasferimento 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 spoofingI client che usano i DNS rischiano attacchi di sicurezza basati su una deliberata falsa-associazione tra indirizzo IP e nome del DNS

Credenziali di autenticazioneI 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.

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

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. chiusura della connessione

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.

http e http/tls relazione di ambra giovannini ferrara – 02/12/2005

Documents