La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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

Presentazioni simili


Presentazione sul tema: "HTTP e HTTP/TLS Relazione di Ambra Giovannini Ferrara – 02/12/2005."— Transcript della presentazione:

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

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

3 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

4 HTTP Introduzione

5 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

6 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.: lordine in cui elencare i parametri)

7 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à: linformazione trasferita come payload di una richiesta o di una risposta. Nei campi dellheader 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 lentità 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.

8 Terminologia (2/3) Age: il tempo trascorso da quando una risposta è stata spedita, o convalidata, dallorigin server (assegnato dal client). Freshness lifetime: il lasso di tempo tra la generazione della risposta e lexpiration 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 dallorigin server. Validator: un elemento del protocollo che è usato per scoprire se unentità in cache è equivalente alloriginale. Inbound: che viaggia verso lorigin server. Outbound: che viaggia verso luser agent.

9 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 lorigin 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.

10 Funzionamento (1/2) LHTTP è 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 sullentità corpo dellentità Livello di trasporto affidabile (es: TCP/IP)

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

12 HTTP Notazioni e grammatica

13 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 è * element, che indica almeno n elementi ed al massimo m. I valori di default sono 0 ed infinito.

14 Argomenti BNF (Backus-Naur Form) (2/2) [regola] Le parentesi quadre includono gli elementi opzionali. N regola Specifica ripetizione: esattamente n occorrenze dellelemento (elemento) è equivalente a * (elemento) # regola Definisce una lista di elementi. La forma completa è # (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 linizio di un commento che si estende fino a fine linea.

15 HTTP Parametri

16 Versione HTTP Schema di numerazione. : incrementato quando nuove caratteristiche non modificano lalgoritmo generale di parsing del messaggio : 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

17 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 dellURI: 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 = /

18 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 :49:37 GMT (preferpreferito nellInternet standard, lunghezza fissa) Sunday, 06-Nov-94 08:49:37 GMT (usato ma obsoleto) Sun Nov 6 08:49: 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

19 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: :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. Schema: delta-seconds = 1*DIGIT

20 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

21 Content Codings Indica quale decodifica deve essere applicata allentità LIANA (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

22 Transfer Codings (1/2) Utilizzato per indicare quale trasformazione di codifica è stata, può, o dovrebbe applicata allcorpo dellentità per assicurare un trasporto sicuro LIANA 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 lerrore 501 ( Unimplemented ) e chiude la connessione.

23 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 allentità originale Transfer coding proprietà del messaggio

24 Media Types (1/2) Fornisce estensibilità alle tipologie dei dati e la negoziazione dei tipi. LIANA (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 Unentità trasferita mediante messaggio HTTP deve essere rappresentata nellappropriata forma canonica prima della trasmissione, eccetto per il tipo text.

25 Media Types (2/2) Multipart Types Lestensione MIME permette di incapsulare più entità con diverse tipologie allinterno 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. Lunica eccezione è il tipo multipart/byteranges che è interpretato da alcuni meccanismi di caching HTTP.

26 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

27 Quality Values Indica limportanza 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")])

28 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 dallIANA. 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

29 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

30 Range Units Premette ad un client di specificare nella richiesta che solo una parte dellentità sia inclusa nella risposta Utilizzati nei campi: Range Content-Range Lunica range unit definita dallHTTP/1.1 è bytes. Schema: range-unit = bytes-unit | other-range-unit bytes-unit = "bytes" other-range-unit = token

31 HTTP Messaggi

32 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

33 Headers del messaggio (1/2) Header: general-header (applicabili ad entrambi i tipi di messaggio, ma non allentità 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

34 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 = Ordine degli header non è significativo Sono permessi più header con lo stesso nome di campo, e vengono interpretati come una lista di possibili valori; lordine in cui sono ricevuti è significante, perché si intendono elencati partendo dal valore principale.

35 Corpo del messaggio Utilizzato per trasportare lentità associata alla richiesta/risposta Il message body si differenzia dallentity body solo quando è presente transfer-coding Il formato è il seguente: message-body = entity-body |

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

37 HTTP Richiesta

38 Richiesta: formato generale Request = Request-Line *((general-header | request-header | entity-header) CRLF) CRLF [ message-body ] MetodoURLVersione sp crlf Header:spValorecrlf crlf Header:spValorecrlf

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

40 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

41 HTTP Risposta

42 Risposta: formato generale Response = Status-Line *((general-header | response-header | entity-header)CRLF) CRLF [ message-body ] VersioneStatus codeFrase sp crlf Header:spValorecrlf crlf Header:spValorecrlf

43 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

44 Status Code e Frase Esplicativa (1/2) Lo status-code è un intero di 3 cifre (destinato allinterpretazione automatica) che indica se e come il server ha capito la richiesta La frase è una descrizione testuale (destinata allutente) 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.

45 Status Code e Frase Esplicativa (2/2) Status-Code = "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 = *

46 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

47 HTTP Entità

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

49 Entity Headers Specificano le metainformazioni sullenity-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

50 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 loggetto presente nel corpo dellentità. 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.

51 HTTP Connessioni

52 Connessioni Non Persistenti vs Connessioni Persistenti Connessioni non persistenti: ciascuna connessione TCP veniva chiusa subito dopo che il server aveva inviato loggetto 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.

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

54 Passaggi della connessione Chiusura (2/2) ServerClient FIN 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 allaltro 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.

55 HTTP Metodi

56 Metodi Sicuri Metodi Idempotenti Sicuri: non provocano azioni inaspettate Get Head Idempotenti: ripetendo la stessa richiesta più volte, leffetto è 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.

57 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

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

59 Head Risposta meta-informazioni degli header Utilizzato per: testare la validità dei link laccessibilità le modifiche

60 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.

61 Put Permette lo store di unentità 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

62 Delete Permette di richiedere allorigin 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à

63 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.

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

65 HTTP Status code

66 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.

67 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. Linformazione ritornata con la risposta dipende dal metodo usato nella richiesta, esempi: get : unentità 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 : unentità che descrive o contiene il risultato di unazione trace : unentità 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.

68 Successo (2xx) (2/2) 203 Non-Authoritative Information Le metainformazioni ritornate negli header non sono il set definitivo disponibile dallorigin 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 luser agent dovrebbe fare un reset della visione del documento che ha causato linvio della richiesta. Questo permette, ad esempio, di far inserire input allutente 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.

69 Redirezione (3xx) (1/2) Questa classe di status code indica quali azioni future deve eseguire luser agent per soddisfare le richieste 300 Multiple Choices La risorsa richiesta corrisponde ad una qualsiasi delle rappresentazioni disponibili, ognuna con una specifica locazione; lutente, 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 allutente. 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 allutente.

70 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.

71 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 unentità contenente spiegazioni sullerrore, 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 dellentità; se il server non vuole dare queste informazioni, può rispondere anche con lo status code 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 dallURI. 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.

72 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 lheader Proxy-Authenticate; il client può ripetere la richiesta inserendo lheader Proxy-Authorization. 408 Request Timeout Il client non ha prodotto nessuna richiesta nellarco 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 lutente sia in grado di risolvere il conflitto. La risposta dovrebbe includere nel body informazioni per permettere allutente 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.

73 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é lentità richiesta è più grande di quella che vuole o può processare. Il server può chiudere la connessione per prevenire linvio di altre richieste analoghe. Se la condizione è temporanea, il server dovrebbe includere nella risposta lheader 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é lentità 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 lheader Range ed il valore specificato supera il valore possibile. 417 Expectation Failed Le aspettative richieste nellheader Expect non possono essere fornite dal server.

74 Client Error (4xx) (4/4) 401 Unauthorized La richiesta necessita di autenticazione dellutente. La risposta deve includere un header WWW-Authenticate. Il client può ripetere la richiesta inserendo lheader 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? si Risposta no 401 Unauthorized no 401 Unauthorized WWW-Authenticate

75 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 unentità contenente la spiegazione sulla situazione di errore, specificando se è temporanea o permanente. Luser agent dovrebbe mostrare lentità ricevuta allutente. 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 lheader 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.

76 HTTP Negoziazione dei contenuti

77 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

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

79 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 lalgoritmo 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 lalgoritmo 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).

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

81 Client-driven (2/2) La selezione (automatica o manuale) è compiuta dallagent-driven, dopo aver ricevuto una risposta iniziale dallorigin 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 lentità desiderata

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

83 HTTP Caching

84 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 sullorigin server Warnings Una cache può ritornare nella risposta una copia scaduta, aggiungendo lheader 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 lazione più restrittiva.

85 Expiration Model Validation Model Expiration 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 lorigin server per la convalida. Heuristic Expiration Se lorgin 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 lorigin server. Last-Modified Dates Header Last-Modified : un copia è considerata valida se lentità non è stata modificata dopo questa data. Weak e Strong Validators Strong validator: per ogni cambiamento dellentità originale, la cache deve essere aggiornata (Modalità più utlizzata) Weak validator: la cache viene aggiornata solo in presenza di cambiamenti semanticamente significanti.

86 Caching Note Response cacheability Costruzione di risposte dalla cache con lintera 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 allutente quello che ha visto quando la risorsa è stata ricevuta precedentemente Non è applicato nessun meccanismo di expiration time.

87 HTTP Header

88 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 lheader Accept, significa che ogni media types è accettato. Se è presente lheader Accept e il server non riesce a soddisfare la richiesta, questultimo risponde con lo status code 406 ( not acceptable ).

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

90 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 lheader Accept-Encoding, significa che ogni character set è accettato. Se è presente lheader Accept-Encoding e il server non riesce a soddisfare la richiesta, questultimo risponde con lo status code 406 (not acceptable.

91 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

92 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

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

94 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.

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

96 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 ] | "no-store" | "no-transform" | "must-revalidate" | "proxy-revalidate" | "max-age" "=" delta-seconds | "s-maxage" "=" delta-seconds | cache-extension cache-extension = token [ "=" ( token | quoted-string ) ]

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

98 Content-Encoding Indica quali content conding opzionali sono stati applicati allentity 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 dellentità identificata dal Request-URI. Se il content-coding di unentità in una richiesta non è accettabile dallorigin server, questultimo dovrebbe rispondere con lo status code 415 (Unsupported Media Type).

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

100 Content-Length Indica la dimensione dellentity-body Content-Length = "Content-Length" ":" 1*DIGIT Esempio: Content-Length: 3495

101 Content-Location Indica da quali ulteriori locazioni, oltre allURI specificato nella richiesta, lentità è accessibile Content-Location = "Content-Location" ":"( absoluteURI | relativeURI )

102 Content-MD5 Digest MD5 dellentity body Content-MD5 = "Content-MD5" ":" md5-digest md5-digest = Permette di controllare lintegrità del messaggio Il digest MD5 è basato sul contenuto dellentity-body, incluso ogni content- coding applicato. Se il messaggio è stato trasferito con transfer- encoding, prima di verificare lintegrità deve essere rimossa la codifica LHTTP permette di calcolare un digest MD5 anche per i tipi MIME Solo gli origin server o i client possono generare questo campo

103 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 /47022 Se il server riceve una richiesta con un range non soddisfabile, risponde con lo status code 416 (Requested range not satisfiable).

104 Content-Type Indica il media type dellentity-body Content-Type = "Content-Type" ":" media- type Esempio: Content-Type: text/html; charset=ISO

105 Date Rappresenta data e ora in cui il messaggio è stato generato Date = "Date" ":" HTTP-date Esempio: Date: Tue, 15 Nov :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.

106 ETag Fornisce il valore dellentity 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: ""

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

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

109 From Dovrebbe contenere un indirizzo From = "From" ":" mailbox Esempio: From:

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

111 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 questheader 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)

112 If-Modified-Since Rende un metodo condizionale: se lentità 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 :43:31 GMT

113 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 questheader 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

114 If-Range Se un client ha una copia parziale di unentità nella sua cache, e vorrebbe avere una copia aggiornata dellintera 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.

115 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 :43:31 GMT Rende un metodo condizionale.

116 Last-Modified Indica data e ora dellultima modifica apportata alla risorsa Last-Modified = "Last-Modified" ":" HTTP-date Esempio: Last-Modified: Tue, 15 Nov :45:26 GMT

117 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

118 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

119 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

120 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

121 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

122 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 dellentità Range = "Range" ":" ranges-specifier

123 Referer Permette al client di specificare, per beneficio del server, lindirizzo della risorsa da cui ha ottenuto il request-URI Referer = "Referer" ":" ( absoluteURI | relativeURI ) Esempio: Referer:

124 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 :59:59 GMT Retry-After: 120

125 Server Contiene informazioni sul software usato dallorigin 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 nellordine con cui maggiormente identificano lapplicazione

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

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

128 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 dellentità

129 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

130 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 nellordine con cui maggiormente identificano lapplicazione

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

132 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

133 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

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

135 HTTP Considerazioni sulla sicurezza

136 Informazioni personali Client HTTP: conoscenza di un gran numero di informazioni personali Esempi: nome dellutente password prevenire la diffusione di queste informazioni Implementatori di interfacce: stare molto attenti Storia piccoli errori o incomprensioni (tra linterfaccia e lutente) portano a gravi problemi di sicurezza e/o di privacy

137 Informazioni personali Abuso di informazioni server log Server dati sullutente 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

138 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 linteresse di privacy dellutente Header Accept può rivelare informazioni sullutente 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

139 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 dallamministratore 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 unopportunità per degli attacchi. Le cache aumentano questo problema Soluzione parziale: crittografia Attacchi denial of service

140 HTTP/TLS Introduzione

141 Estratto Luso 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.

142 HTTP/TLS Inizializzazione della connessione

143 Inizializzazione connessione Lagente dellutente che funge da HTTP client, agisce anche come TLS client Lagente dellutente inizia una connessione con il server sulla porta appropriata e spedisce un TLS ClientHello per cominciare lhandshake TLS Dopo aver finito lhandshake TLS il client può inviare la prima richiesta HTTP

144 HTTP/TLS Chiusura della connessione

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

146 Chiusura connessione (2/3) Comportamento del client HTTP usa la chiusura della connessione come segnale di fine dati limplementazione 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 lalert di chiusura del server chiusura incompleta lato server

147 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 lalert di chiusura del client chiusura incompleta lato client

148 HTTP/TLS Porte

149 Numero di porta Il primo dato che un server HTTP si aspetta di ricevere da un client è lheader 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)

150 HTTP/TLS URI

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

152 RIFERIMENTI

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


Scaricare ppt "HTTP e HTTP/TLS Relazione di Ambra Giovannini Ferrara – 02/12/2005."

Presentazioni simili


Annunci Google