Un po' di storia di HTTP. Il protocollo HTTP. (HyperText Transfer Protocol) Il protocollo HTTP 1.0. Connessione stateless (HTTP/1.
|
|
|
- Fausta Longhi
- 6 anni fa
- Visualizzazioni
Transcript
1 Un po' di storia di Il protocollo (HyperText Transfer Protocol) Antonio Lioy < > Politecnico di Torino Dip. Automatica e Informatica protocollo client-server ideato per la richiesta e la trasmissione di pagine HTML (e poi di risorse web in generale) originale (anche noto come /0.9) uso quasi solo sperimentale /1.0 il primo a larga diffusione ancora molto usato /1.1 per migliorare l'efficienza del web per migliorare la gestione delle cache Il protocollo 1.0 Connessione stateless (/1.0) HyperText Transfer Protocol RFC-1945 (/1.0) servizio di default: TCP/80 protocollo stateless B 1. connection S B GET 2. request S lecito per il client chiudere la connessione prima di aver ricevuto la risposta o parte di essa chiusura del canale da parte del server dati a 8 bit (ossia "8-bit clean") alfabeto di default: ISO (= Latin-1) B HTML S B S 3. response 4. close I link URL (Uniform Resource Locator) schema : // user : host : porta / path # àncora schemi regolari: http, telnet, ftp, gopher, file schemi irregolari: news:newsgroup mailto:indirizzo-postale definizione base in RFC-1738, più (LDAP), 2017 (external-body), 2192 (IMAP), 2224 (NFS), Evoluzione dei link URL sono indirizzi fisici (usando CNAME si può fare qualcosa di logico, ma poco) URN (Uniform Resource Name) è l evoluzione futura, per usare nomi logici, replicazione,... URI (Uniform Resource Identifier) RFC-3986 URI = URL + URN A.Lioy - Politecnico di Torino ( ) G-1
2 Protocollo /1.0 comandi ASCII con righe terminate da CR+LF i dati possono essere binari (perché il protocollo è 8-bit clean ) messaggi costituiti da header + body header sono righe che iniziano con keyword: header separato dal body mediante una riga vuota (ossia contenente solo CR+LF) Metodi /1.0 GET uri http-version richiede la risorsa associata alla URI specificata HEAD uri http-version restituisce solo gli header della risposta, non i dati POST uri http-version invia dei dati al server (nel body) affinché vengano elaborati dalla URI indicata risposte devono iniziare con http-version status-code [ commento_testuale ] notare che la URI è il path della risorsa richiesta (quando si è connessi direttamente all'origin server) la URI completa (quando si è connessi ad un proxy) request Metodo GET ( TCP setup ) GET / /1.0 response / OK Date: Wed, 20 May :58:21 GMT Server: Apache/1.0.0 Content-Type: text/html Content-Length: 1534 Last-modified: Fri, 5 May :14:23 GMT <html>... </html> ( TCP teardown ) request Metodo HEAD ( TCP setup ) HEAD / /1.0 response / OK Date: Wed, 20 May :58:21 GMT Server: Apache/1.0.0 Content-Type: text/html Content-Length: 1534 Last-modified: Fri, 5 May :14:23 GMT ( TCP teardown ) request Metodo POST ( TCP setup ) POST /cgi-bin/form.cgi /1.0 Content-type: text/plain Content-length: 12 Antonio Lioy response / OK Date: Mon, 8 Mar :30:24 GMT Server: Apache/1.2.6 Content-type: text/plain dati ricevuti da stdin: Antonio Lioy ( TCP teardown ) Test manuale di (Windows) aprire una finestra di comando (aka finestra DOS ) dare i seguenti comandi: C:\> telnet Microsoft Telnet> set localecho Microsoft Telnet> set crlf Microsoft Telnet> set logging Microsoft Telnet> set logfile mylog.txt Microsoft Telnet> open server_web 80 GET / /1.0 <enter> <enter> suggerimento: se non si vuole attivare il log allora attivare lo scrolling sulla finestra per vedere tutta la risposta del server (Proprietà Layout Screen buffer size Height) A.Lioy - Politecnico di Torino ( ) G-2
3 Test manuale di (*nix) installare (se non presente) il programma "netcat" aprire una finestra di shell dare i seguenti comandi: $ nc server_web 80 > output.txt GET / /1.1 <enter> Host: nome_server_web <enter> Connection: close <enter> <enter> Codice di stato tutte le risposte contengono un codice di stato di 3 cifre XYZ la prima cifra (X) fornisce il major status dell azione richiesta X=1 : informational X=2 : success X=3 : redirection X=4 : client error X=5 : server error seconda e terza cifra affinano lo stato Codici di stato standard / OK 201 Created 202 Accepted 204 No Content 301 Moved permanently 302 Moved temporarily 304 Not modified 400 Bad request 401 Unauthorized 403 Forbidden 404 Not found 500 Internal server error 501 Not implemented 502 Bad gateway 503 Service unavailable Redirect se l oggetto richiesto non è disponibile alla URI indicata, il server può indicare la nuova URI tramite una risposta con codice 3xx e header Location: nuova-uri il browser può: connettere automaticamente il client alla nuova URI se il metodo richiesto era GET o HEAD mentre gli è vietato farlo se il metodo era POST per supportare i browser vecchi (= che non capiscono Redirect) o pigri si consiglia di inviare nella risposta un body costituito da una pagina HTML che fornisca la nuova URL in modo comprensibile da un essere umano general header: Date: http-date Pragma: no-cache request header: Header /1.0 (I) Authorization: credentials From: user-agent-mailbox If-Modified-Since: http-date 304 se l entity non è cambiata dalla data indicata Referer: URI richiesta proveniente da un link alla URI indicata User-Agent: product response header: Header /1.0 (II) Location: absolute-uri Server: product WWW-Authenticate: challenge entity body header: Allow: method Content-Encoding: x-gzip x-compress Content-Length: length Content-Type: MIME-media-type Expires: http-date Last-Modified: http-date A.Lioy - Politecnico di Torino ( ) G-3
4 tre possibili formati: date RFC-822 = Sun, 06 Nov :49:37 GMT RFC-850 = Sunday, 06-Nov-94 08:49:37 GMT asctime = Sun Nov 6 08:49: accettare tutti, generare solo RFC-822 sempre GMT, mai l indicazione del fuso orario Il protocollo /0.9 più semplice non documentato in nessun RFC request: GET URI response: entity-body Problemi di /1.0 progettato per oggetti statici dimensione nota a priori altrimenti possibile troncamento dei dati impossibile continuare collegamento interrotto progettato per richiedere e ricevere singole pagine: ogni oggetto richiede una connessione separata una connessione TCP per ogni richiesta: TCP setup richiede tempo (3-way handshake) TCP slow start richiede tempo la chiusura del canale fa perdere le informazioni sulla congestione della rete gestione elementare della cache Il protocollo /1.1 (I) RFC-2616 connessioni persistenti (è il default) e pipelining maggior velocità (più transazioni su stesso canale) miglior trasmissione del body negoziazione formato dati e lingua del body frammentazione (chunked encoding) per pagine dinamiche trasmissione parziale gestione della cache modalità specificate dal protocollo proxy gerarchici Il protocollo /1.1 (II) supporto per server virtuali più server logici associati allo stesso indirizzo IP nuovi metodi: PUT, DELETE, TRACE, OPTIONS, CONNECT nuovo metodo di autenticazione (basato su digest) a livello di trasporto /1.1: virtual host con /1.0 occorreva un indirizzo IP per ogni server web ospitato su un nodo (multihomed) con /1.1 non è più necessario: più server logici associati allo stesso indirizzo IP ottenibili tramite alias nel DNS (record CNAME) il client deve indicare il virtual host desiderato tramite il suo FQDN (Fully Qualified Domain Name) nuovo header: Host: FQDN [ : port ] A.Lioy - Politecnico di Torino ( ) G-4
5 /1.1: virtual host (esempio) /1.1: connessioni persistenti host.provider.it IN A IN CNAME host.provider.it IN CNAME host.provider.it (collegamento a host.provider.it, ossia IP ) GET /index.html /1.1 Host: DNS uso di un unico canale TCP per trasmettere più interazioni richiesta-risposta è il comportamento di default in /1.1 chi si comporta diversamente deve dichiararlo con: Connection: close non è un header end-to-end ma hop-by-hop cosa importante per proxy e gw (collegamento a host.provider.it, ossia IP ) GET /index.html /1.1 Host: Connessioni persistenti: esempio ( TCP setup ) GET / /1.1 Host: GET /favicon.gif /1.1 Host: Connection: close / OK... / OK Connection: close... ( TCP teardown ) Connessioni persistenti: pro e contro vantaggi: minor overhead apertura (3-way handshake) e chiusura canale (4-way handshake e suoi timeout) miglior gestione delle congestioni di rete (mantenimento della window TCP) client può fare pipelining delle richieste (server deve fornire risposte nello stesso ordine) risparmio di CPU (su tutti i nodi della catena) evoluzione dolce a nuove versioni di (client può provare nuova versione ma poi usare vecchia) svantaggi: sovraccarico del server (possibile denial-of-service) /1.1: pipelining possibile inviare più richieste senza attendere le risposte del server ottimizza la trasmissione TCP molto utile quando si richiedono in un colpo solo più elementi (di una stessa risorsa) attenzione: sono richieste sequenziali, non parallele (le risposte saranno ricevute nello stesso ordine delle richieste) in caso di errore, potrebbe essere necessario ripetere tutto il comando /1.1: compressione risparmio: di byte trasmessi di tempo (come percepito dall utente finale) costi: CPU sul client CPU sul server (se compressione fatta al volo ) ma la risorsa oggi scarsa è la banda, non la CPU (ma attenzione al consumo energetico per UA su dispositivi mobili) in /1.1 implementata come codifica dei dati oppure come codifica di trasmissione A.Lioy - Politecnico di Torino ( ) G-5
6 Codifiche dati codifica applicata ad una risorsa prima di trasferirla (proprietà del dato, non della trasmissione) poiché è 8-bit clean, codifica = compressione utile per conservare il MIME-type della risorsa header: Content-Encoding e Accept-Encoding codifiche possibili: gzip = GNU zip (RFC-1952) = LZ-77 + CRC-32 compress = programma Unix (adaptative LZW) deflate = zlib (RFC-1950) + deflate (RFC-1951) identity = nessuna codifica default se Content-Encoding assente accettabili i nomi pre-standard x-gzip e x-compress Codifiche di trasmissione specifica la modalità di trasferimento di una risorsa (proprietà della trasmissione, non del dato) header: TE e Transfer-Encoding simile all header MIME Content-Transfer-Encoding ma poiché il canale è pulito a 8 bit l unica difficoltà è determinare la lunghezza del messaggio valori (possibili più di uno): identity (default) gzip, compress, deflate chunked (se presente, deve essere l ultimo) Codifica chunked si frammenta il body della risposta in pezzi (detti chunk ) utile quando il server non conosce a priori la dimensione dei dati da trasferire impossibile usare l'header Content-Length caso tipico dei server dinamici (es. ASP, PHP, JSP) trasmettono la risposta man mano che la generano (quando il buffer di trasmissione è pieno o il programmatore richiede esplicitamente l'invio) meno importante in /1.0 (fine dati implicita alla chiusura del canale)... ma rischio di troncamento in caso di problemi di rete risposta finita o incompleta? Codifica chunked : sintassi sintassi (del body): *chunk last-chunk *(entity-header CR LF) CR LF ogni chunk: chunk-size [ chunk-extensions ] CR LF chunk-data CR LF size in hex, ultimo chunk è quello con size=0 nota: "*" indica zero o più ripetizioni dell'oggetto seguente Codifica chunked: esempio CSS / PNG / -1.1 e le prestazioni... Transfer-Encoding: chunked CRLF CRLF 6 CR LF <html> CRLF 18 CRLF <body>ciao</body></html> CRLF 0 CRLF CRLF CRLF chunk n.1 chunk n.2 chunk n.3 (last) CSS semplifica HTML (e quindi ne riduce la dimensione) PNG ha compressione migliore di GIF es. risparmio del 12% sulle 40 immagini del test impatto di -1.1 complesso: connessioni persistenti, pipelining, compressione (body risultante) <html><body>ciao</body></html> A.Lioy - Politecnico di Torino ( ) G-6
7 Test 1.0 vs. 1.1 test di Nielsen, Gettys et al (W3C) pagina di test: dimensione HTML = 40 kb contiene 43 immagini in-line (totale 130 kb) test consistente in 44 GET (una per ciascun oggetto) in vari modi: /1.0 con 4 connessioni simultanee /1.1 con 1 connessione persistente /1.1 pipeline con 1 connessione persistente /1.1 pipeline + compressione con 1 connessione persistente Risultati test 1.0 vs. 1.1 WAN first-time retrieval against Apache server , , ,23 /1.0 /1.1 /1.1 pipelined TCP packets time (s) 182 2,11 /1.1 pipelined w. compression Confronto tra techniche di trasmissione /1.1: metodo PUT PUT uri http-version /1.0 TCP setup req 1 res 1 /1.1 (connessione persistente) TCP setup req 1 res 1 TCP teardown req 2 TCP setup res 2 req 2 TCP teardown res 2 TCP teardown il request body costituisce una nuova risorsa da memorizzarsi sul server alla URI specificata il request body è una nuova versione da sostituirsi a quella specificata dalla URI risposte: 201 (Created), 200 (OK) o 204 (No content) esempio: /1.1 (connessione persistente + pipeline) TCP setup req 1+2 res 1 res 2 TCP teardown t PUT /avviso.txt /1.1 Host: lioy.polito.it Content-Type: text/plain Content-Length: 40 Il 31/5/2007 non ci sarà lezione. Il codice 100 Continue /1.1: metodo DELETE è inefficiente trasmettere un grosso request body se il server rifiuterà la richiesta senza neanche guardarlo: es. utente non autorizzato o metodo non supportato tipicamente relativo a PUT e POST il client chiede conferma esplicita prima di trasmettere il request body PUT /voti.pdf /1.1 Host: Expect: 100-continue... voti.pdf... / Continue / OK DELETE uri http-version chiede eliminazione della risorsa alla URI specificata nessuna garanzia che sia cancellata, anche se OK risposte: 200 (OK) se eseguita + body con dettagli 202 (Accepted) se canc. richiede decisione umana 204 (No content) se eseguita ma senza dettagli esempio: DELETE /voti.html /1.1 Host: lioy.polito.it Content-Length: 0 A.Lioy - Politecnico di Torino ( ) G-7
8 /1.1: metodo TRACE TRACE uri http-version richiede di ricevere copia della richiesta richiesta incapsulata in un response body con tipo MIME "message/http" tramite i request header Via (aggiunti dai proxy e dai gateway) è possibile tracciare il collegamento a livello applicativo tramite il request header Max-Forwards è possibile limitare il numero di proxy attraversati (utile in caso di loop) TRACE / /1.1 Host: C Metodo TRACE: esempio / OK Date: Sun, 20 May :29:05 GMT Server: Apache Transfer-Encoding: chunked Content-Type: message/http 29 TRACE / /1.1 Host: S 0 /1.1: metodo OPTIONS OPTIONS uri http-version richiede di conoscere le opzioni supportate dal server solo opzioni generali se URI=*, altrimenti quelle generali+specifiche della URI (es. lingue in cui la risorsa è disponibile) tramite il request header Max-Forwards: N è possibile richiedere le opzioni non all origin server ma al proxy N-1 attraversato OPTIONS / /1.1 Host: C Metodo OPTIONS: esempio / OK Date: Sun, 20 May :51:25 GMT Server: Apache/ (Unix) Content-Length: 0 Allow: GET, HEAD, OPTIONS, TRACE S /1.1: metodo CONNECT riservato all uso con proxy capaci di creare un tunnel verso un origin server inutile per connessioni normali (si elimina il proxy ) indispensabile per creare connessioni sicure S attraverso un proxy (perché sono end-to-end) UA P OS CONNECT /1.1 Host: negoziazione SSL / TLS tunnel SSL / TLS creazione tunnel TCP tunnel TCP Trasmissione parziale utile quando si vuole riprendere un trasferimento interrotto header del server: Accept-Ranges: none bytes Content-Range: bytes start stop/total (total=* se dimensione totale ignota) header del client: Range: range1, range2,, rangen possibili range: start stop (intervallo, estremi inclusi) lastn (gli ultimi lastn byte) startbyte (da startbyte sino alla fine) A.Lioy - Politecnico di Torino ( ) G-8
9 Entity tag (Etag) identificativo opaco da usarsi in alternativa alla data di modifica per sapere se una entity è cambiata inserito dal server nel response header tramite: Etag: [ W/ ] hex_string tag uguali implicano: (strong Etag) oggetti identici (stessi byte) (weak Etag) oggetti equivalenti (stesso effetto) valore usato dal client in request header con: If-Match (es. aggiornare con PUT una versione precedente solo se non è già stata modificata) If-None-Match (es. fare GET di nuova versione) /1.1 request header (I) Accept: media-range [ ; q=qualityvalue ], formati dati accettabili es. Accept: image/jpeg, image/*;q=0.5 Accept-Charset: charset [ ; q=qualityvalue ], set di caratteri accettabili Accept-Encoding: cont-enc [ ; q=qualityvalue ], codifiche del contenuto accettabili Accept-Language: language [ ; q=qualityvalue ], lingue accettabili es. Accept-Language: it, en-gb;q=0.8, en;q=0.7 /1.1 request header (II) Authorization: credenziali credenziali in risposta ad una richiesta di autenticazione da parte dell origin server Expect: comportamento-atteso, il server risponde con 417 se non capisce From: rfc822-address importante soprattutto per contattare chi ha attivato un robot che crea problemi problemi di privacy/spamming Host: hostname [ : port ] virtual host da contattare (porta di default: 80) /1.1 request header (III) If-Match: etagvalue, applicare il metodo solo se la risorsa corrisponde ad uno dei tag indicati If-Modified-Since: http-date applicare il metodo solo se la risorsa è stata modificata dopo la data indicata If-None-Match: etagvalue, applicare il metodo solo se la risorsa non corrisponde ad alcuno dei tag indicati If-Range: etagvalue http-date inviare tutta la risorsa se è cambiata, altrimenti solo la porzione indicata (da usarsi con Range: ) /1.1 request header (IV) If-Unmodified-Since: http-date applicare il metodo solo se la risorsa non è stata modificata dopo la data indicata Max-Forwards: max-num-forwards da usarsi con TRACE e OPTIONS per identificare il nodo intermedio che deve rispondere max-num-forwards decrementato da ogni nodo Proxy-Authorization: credenziali credenziali in risposta ad una richiesta di autenticazione da parte di un proxy /1.1 request header (V) Range: intervallo chiede di ricevere solo l intervallo di dati indicato offsetfrom offsetto (es. bytes= ) lastbytes (es. bytes= 500) Referer: absoluteuri relativeuri URI della pagina che ha generato l attuale richiesta campo assente se URI inserita da tastiera TE: [ trailers ] [ transf-enc [ ; q=qualityvalue ] ], chunk trailers e codifiche di trasferimento accettabili User-Agent: nome-prodotto identifica il software che implementa il client A.Lioy - Politecnico di Torino ( ) G-9
10 /1.1 response header (I) Accept-Ranges: bytes none indica se il server permette il download parziale Age: agevalue indica i secondi trascorsi da quando la risorsa è stata inserita in cache (del server, gateway o proxy) ha senso solo in proxy, gateway o server con cache ETag: entity-tag un identificativo opaco unico della risorsa richiesta Location: absolute-uri effettua un redirect alla URI indicata /1.1 response header (II) Proxy-Authenticate: sfida sfida proposta da un proxy per autenticare il client Retry-After: http-date secondi in caso di indisponibilità del server Server: nome-prodotto identifica il software che implementa il rispondente Vary: * request-header,... indica i campi della richiesta da cui dipende la risposta (e quindi la validità di una copia in cache) WWW-Authenticate: sfida sfida proposta dall origin server per autenticare il client /1.1 general header (I) Cache-Control: req-cache-dir res-cache-dir, controllo della cache nella richiesta e nella risposta direttive del client e del server verso i proxy Connection: close per connessione non persistenti (con server o proxy) Date: http-date data di invio della richiesta o della risposta Pragma: no-cache per compatibilità con /1.0 in /1.1 si preferisce Cache-Control Gestione della cache richieste del client voglio o meno risposte presenti in cache espresse tramite una o più request-cache-directive risposte del server non mettere in cache espresse tramite una o più response-cache-directive no-cache Request-cache-directive (I) voglio una risposta dall origin server no-store non memorizzare (in tutto o in parte) né la richiesta né la risposta max-age=secondi voglio una risposta non più vecchia di X s max-stale [ =secondi ] accetto anche risposte scadute (da non più di X s) min-fresh=secondi voglio una risposta che sia ancora valida tra X s Request-cache-directive (II) no-transform ai proxy è vietato effettuare trasformazioni della risorsa (es. alcuni cambiano il formato delle immagini per risparmiare spazio) only-if-cached non voglio contattare origin server utile con reti sovraccariche A.Lioy - Politecnico di Torino ( ) G-10
11 public Response-cache-directive (I) risposta può essere messa in cache (shared/private) private [ = header-name, ] non mettere in shared cache (tutto o alcuni header) solo per i proxy (gli UA possono fare cache) no-cache [ = header-name, ] UA non deve fornire dati in cache (tutto o alcuni header) senza prima averli rivalidati con OS no-store non mettere in cache (shared/private) su disco Response-cache-directive (II) no-transform il proxy non deve applicare alcuna trasformazione perché spesso i proxy trasformano i contenuti multimediali per risparmiare spazio e/o banda (tipico su rete mobile) must-revalidate UA deve rivalidare con OS quando la risorsa in cache diventa stale proxy-revalidate il proxy deve rivalidare con OS quando la risorsa in cache diventa stale Response-cache-directive (III) max-age=secondi scadenza dei dati (poi bisogna rivalidarli con OS) s-maxage=secondi scadenza dei dati in una shared cache ha priorità su max-age (solo per shared cache) nota: max-age e s-maxage hanno priorità su un eventuale header Expires: della risorsa /1.1 general header (II) Trailer: header-name, gli header indicati sono in coda al body chunked non possono essere Transfer-Encoding, Content- Length e Trailer Transfer-Encoding: codifica-di-trasferimento /1.1 general header (III) Upgrade: protocollo, il client propone di passare ad un protocollo migliore (a giudizio del server tra quelli elencati) Via: protocol nodo [ commento ], sequenza di nodi intermedi (proxy o gateway) nodo = host [ : porta ] oppure uno pseudonimo Warning: codice_di_stato agente testo [ data ] tipicamente usato dai proxy per avvisare di condizioni particolari se testo non ISO allora RFC-2047 Codici di stato per i warning 110 Response is stale la risorsa è vecchia 111 Revalidation failed impossibile contattare origin server per rivalidare 112 Disconnected operation proxy scollegato dalla rete 113 Heuristic expiration proxy ha scelto euristicamente una scadenza 199 Miscellaneous warning 214 Transformation applied proxy ha cambiato la codifica dei dati trasmessi 299 Miscellaneous persistent warning A.Lioy - Politecnico di Torino ( ) G-11
12 Allow: metodo, /1.1 entity header (I) fornito dal server con stato 405 (Method Not Allowed) per individuare i metodi permessi fornito dal client con PUT per suggerire i metodi con cui la risorsa dovrebbe essere accessibile Content-Encoding: codifica Content-Language: language Content-Length: num-bytes numero (in base 10) di byte del body Content-Location: absoluteuri relativeuri utile nel caso una risorsa fornita a seguito di una negoziazione sia anche accessibile direttamente /1.1 entity header (I) Content-MD5: base64-md5-digest per proteggere l integrità dei dati trasferiti (da errori casuali, non da attacchi!) Content-Range: intervallo Content-Type: mime-type Expires: http-date Last-Modified: http-date Codici di stato standard / 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 (Moved temporarily) 303 See other 304 Not modified 400 Bad request 401 Unauthorized 403 Forbidden 404 Not found 500 Internal server error 501 Not implemented 502 Bad gateway 503 Service unavailable Gestione dello stato le applicazioni web devono mantenere informazioni sugli utenti quando navigano: tra pagine diverse in tempi successivi (minuti, ore, giorni) vari motivi: preferenze utente (es. lingua, dimensione font) dati di business (es. carrello dei prodotti) problema con : /1.0 effettua singole transazioni ed è stateless /1.1 permette transazioni multiple sulla stessa connessione ma è stateless tra connessioni successive Possibili metodi per gestire lo stato a livello di applicazione: tramite URL speciali generate dinamicamente es. tramite campi nascosti (type=hidden) di un form passati in modo invisibile (metodo POST) passati in modo visibile (metodo GET) es. a livello di protocollo di trasporto: cookie in v1 in /1.0 v2 (+ v1) in /1.1 Perché gestire lo stato in? gestire lo stato senza modificare le URL gli utenti possono scambiarsi le URL tra loro (senza per questo scambiarsi lo stato) non si sporcano le cache intermedie con dati uguali ma corrispondenti ad URL diverse pagine diverse ma corrispondenti ad URL uguali minimizzare l impatto sulla configurazione del server e dell applicazione associare l utente allo stato anche se è anonimo (es. non passa da portale di autenticazione) salvare lo stato in memoria permanente permane tra reboot, start/stop di UA, cambio di IP A.Lioy - Politecnico di Torino ( ) G-12
13 I 4 comandamenti dei cookie è lecito mantenere traccia dello stato di una sessione se 1) l utente ne è conscio e consenziente 2) l utente può cancellare lo stato quando vuole 3) le informazioni di stato non sono fornite a terzi senza il consenso esplicito dell utente 4) le informazioni di stato non contengono dati sensibili e non posso essere usate per ottenere dati sensibili Cookie scopo: memorizzare informazioni da parte del server in locale sul client in cui gira il browser in questo modo si alleggerisce il server... ma si introducono elementi di: aleatorietà (=UA che non supporta/accetta cookie) rischio (=cookie letti/manipolati sul client o in rete) 1. store the cookie! 2. stored 3. here is the cookie! Definizione dei cookie inizialmente definito da Netscape: Persistent client state cookies diventato poi standard IETF: state management mechanism : v1 = RFC-2109 v2 = RFC-2965 le specifiche Netscape e v1 sono obsolete ma ancora usate RFC-2964 Use of state management contiene avvertenze su problemi / pericoli dei cookie Caratteristiche dei cookie dati di piccole dimensioni registrati sul client (persistent information) e inviati al server cookie creati dal server sul client tramite header: Set-Cookie:... (v1) Set-Cookie2:... (v2) cookie trasmessi dal client al server tramite header: Cookie:... i cookie sono nel formato nome=valore salvati localmente dal browser (in un file) dati comunicati al server ai successivi accessi usati per creare un collegamento logico tra richieste diverse verso lo stesso server Firefox 32 cookies.sqlite mini database IE 11 file cookie:user@site Cookie nei browser Limiti dei cookie limitazioni riguardo il minimo numero di cookie che devono essere trattati totale minimo per user agent (su disco): max 300 cookie max 4 kb per cookie totale = 1.2 MB max per server/dominio (su disco dell'ua, nella RAM del server ma solo per gli utenti simultanei): max 20 cookie / client max 4 kb per cookie totale = 80 kb max / client A.Lioy - Politecnico di Torino ( ) G-13
14 Trasmissione dei cookie (v1): S > C cookie inserito nell header della risposta sintassi del cookie: Set-Cookie: cookiename=cookievalue [ ; EXPIRES=dateValue ] [ ; DOMAIN=domainName ] [ ; PATH=pathName ] [ ; SECURE ] Cookie: valore, scadenza, secure il nome del cookie ed il relativo valore sono stringhe qualsiasi: prive di virgola, punto-e-virgola e spazio tali caratteri devono essere espressi in esadecimale (%2C, %3B, %20) EXPIRES: data di scadenza dopo la quale il cookie può essere eliminato dal client formato RFC-822 Wdy, DD Mon YY hh:mm:ss GMT se non viene specificata una scadenza, il cookie scade alla chiusura del browser (memorizzato non su disco ma in RAM: cookie volatile / temporaneo) SECURE: cookie trasmesso solo su canale S Cookie: dominio, path DOMAIN indica il dominio autorizzato a gestire il cookie (ad es. polito.it) soltanto le richieste effettuate a tale dominio provocano la trasmissione del cookie se il dominio non è specificato, il browser usa il nome del server che ha mandato il cookie PATH indica il percorso in cui si è autorizzati a usare il cookie (ad es. /didattica/ ) soltanto le richieste a URL in tale percorso potranno provocare la trasmissione del cookie se il path non è specificato, il browser usa quello della URL che ha scatenato l'invio del cookie Trasmissione di un cookie (V1): C > S quando il browser sta per effettuare accesso ad una URL, controlla se esistono cookie associati al dominio e al percorso in caso affermativo include nell header della richiesta tutte le coppie nome/valore dei relativi cookie se l URL specificata nella richiesta è quella di una pagina dinamica (es. CGI o ASP), l'applicazione troverà la stringa dei cookie nella variabile d ambiente _COOKIE Cookie: nome1=valore1; nome2=valore2;... Esempio (passo 1) cookie usato per gestire la lista dei libri selezionati da un utente che accede ad un negozio virtuale il client accede al server e riceve: Set-Cookie: customer=john_smith; expires=sat, 28-Aug-99 00:00:00 GMT; path=/cgi/bin/; domain=books.virtualshopping.com; secure Esempio (passo 2) quando il client accede ad una URL nel percorso /cgi/bin invia al server un header che contiene: Cookie: customer=john_smith il client riceve come risposta: Set-Cookie: part_number=book1; path=/cgi/bin ;... il client richiede una URL nel percorso /cgi/bin e manda: Cookie: customer=john_smith; part_number=book1 A.Lioy - Politecnico di Torino ( ) G-14
15 il client riceve: Esempio (passo 3) Set-Cookie: shipping=fedex; path=/cgi/bin/deliver;... il client accede ad una URL nel percorso /cgi/bin/deliver e manda: Cookie: customer=john_smith; part_number=book1; shipping=fedex Problemi dei cookie il meccanismo basato su cookie permette di creare profili degli utenti user tracking = termine usato per indicare la possibilità di tracciare i siti visitati da un utente e quindi le sue abitudini e i suoi interessi esempio: se un utente scarica un banner pubblicitario da un sito, oltre a ricevere un immagine riceve anche un cookie per tutti i siti appartenenti al circuito è possibile impostare e recuperare il valore dei cookie riguardanti le preferenze di navigazione di un utente i cookie possono essere disabilitati sul browser Problemi dei cookie autenticazione tramite cookie (es. siti commerciali che associano l utente al carrello virtuale, one-click order) è fortemente sconsigliata: lettura dei cookie durante la trasmissione e sul client attacchi che permettono di intercettare i cookie: packet sniffing web spoofing attacchi al client (virus, worm, javascript,...) sub-domain attack (quale parte del dominio è responsabile del servizio web che usa il cookie?) Rifiuto di un cookie (v1) lo UA può rifiutare un cookie per motivi di sicurezza se è "sospetto" rifiuti consigliati (RFC-2109): Path non è un prefisso della URI richiesta Domain non contiene un punto o non inizia con punto Domain non contiene l'host della URI esempi di rifiuti per la URI path=/pagamenti/ domain=.com. domain=b.com. domain=.x.com Trasmissione dei cookie (v2): S > C nuova sintassi (v2) specificata in RFC-2965 uno o più cookie (lista separata da virgole) Set-Cookie2: cookiename=cookievalue [ ; Comment=commentText ] [ ; CommentURL="URL" ] [ ; Discard ] [ ; Domain=domainName ] [ ; Max-Age=dateValue ] [ ; Path=pathName ] [ ; Port="comma-separated-port-list" ] [ ; Secure ] [ ; Version=versionNumber ] Nuovi attributi dei cookie v2 Comment e/o CommentURL informano l utente circa lo scopo del cookie Discard chiede all UA di cancellare il cookie quando termina (=cookie volatile, da conservarsi solo in RAM) Max-Age numero di secondi dopo cui cancellare il cookie Port porte TCP a cui restituire il cookie Version numero di versione (attualmente pari a 1) A.Lioy - Politecnico di Torino ( ) G-15
16 Cambiamento di significato in v1 l attributo Secure richiedeva trasmissione solo su S in v2 l attributo Secure è un suggerimento del server: trattare in modo sicuro il client dovrebbe trasmettere il cookie al server tramite un canale con sicurezza non inferiore a quella con cui è stato ricevuto Trasmissione dei cookie (v2): C > S nuova sintassi (v2) specificata in RFC-2965 uno o più cookie (lista separata da virgole) Cookie: $Version=cookieVersion ; cookiename=cookievalue [ ; $Domain=domainName ] [ ; $Port="portNumber" ] [ ; $Path=pathName ] Request header Cookie2 quando un client trasmette almeno un cookie avente numero di versione maggiore di quella implementata dal client deve avvisare il server dichiarando la propria versione tramite: HttpOnly nuovo attributo dei cookie, supportato dai browser più recenti ma non ancora standard rende i cookie non accessibili da JS client-side superabile con tecniche più sofisticate Cookie2: highest-cookie-version-understood obiettivi: /2 velocizzare il caricamento delle pagine ridurre il carico sul server nuove caratteristiche: compressione degli header (diventano binari!) multiplexing delle richieste ("stream" paralleli) server push (es. del CSS prima che sia richiesto dallo UA) attenzione: Chrome e Firefox useranno /2 solo su canali TLS! A.Lioy - Politecnico di Torino ( ) G-16
Tito Flagella - Il protocollo HTTP
Tito Flagella - tito@link.it Il protocollo HTTP Il protocollo HTTP È il protocollo standard tramite il quale i server Web rispondono alle richieste dei client (inizialmente i browser); È basato su un modello
Il protocollo HTTP (HyperText Transfer Protocol) Un po' di storia di HTTP. Il protocollo HTTP 1.0. A.Lioy - Politecnico di Torino (2003-15) G-1
Il protocollo HTTP (HyperText Transfer Protocol) Antonio Lioy < lioy@polito.it > Politecnico di Torino Dip. Automatica e Informatica Un po' di storia di HTTP protocollo client-server ideato per la richiesta
Un po' di storia di HTTP. Il protocollo HTTP. (HyperText Transfer Protocol) Il protocollo HTTP 1.0. Connessione stateless (HTTP/1.
Un po' di storia di HTTP Il protocollo HTTP (HyperText Transfer Protocol) Antonio Lioy < lioy@polito.it > Politecnico di Torino Dip. Automatica e Informatica protocollo client-server ideato per la richiesta
Ipertesto (testo + link a risorse)
Ipertesto (testo + link a risorse) testo a + dimensioni = che contiene informazioni di diverso "genere mediale" = indirizza a altri testi, immagini (statiche o mobili, ricevute tutte insieme o a lotti...),
Il protocollo HTTP. Caratteristiche del protocollo HTTP. Versioni del protocollo. Due tipologie di messaggi:
Caratteristiche del protocollo HTTP Scambio di messaggi di richiesta e risposta Transazione HTTP o Web Protocollo stateless Il protocollo HTTP Basato sul meccanismo di naming degli URI per identificare
Corso di Applicazioni Telematiche
Corso di Applicazioni Telematiche A.A. 2008-09 Lezione n.1 Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria Il World Wide Web è un sistema distribuito per la presentazione
Introduzione. Java HTTP. G. Prencipe
Java html e http G. Prencipe prencipe@di.unipi.it Introduzione Tutte le comunicazioni tra client e server Web avvengono mediate il (HyperText Transfer Protocol, attualmente alla versione 1.1), che è un
Sicurezza delle applicazioni web: protocollo HTTP
Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Anno Accademico 2010/2011 Sicurezza delle applicazioni web: protocollo HTTP Alessandro Reina, Aristide Fattori 05 Maggio
Il protocollo HTTP. Corso di Applicazioni Telematiche. A.A Lezione n.2 Prof. Roberto Canonico
Il protocollo HTTP Corso di Applicazioni Telematiche A.A. 2005-06 Lezione n.2 Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria Il World Wide Web Il World Wide Web
Stack protocolli TCP/IP
Stack protocolli TCP/IP Application Layer Transport Layer Internet Layer Host-to-Nework Layer DNS SMTP Telnet HTTP TCP UDP IP Insieme di eterogenei sistemi di rete... 1 Concetti base Differenza tra i concetti
WWW = URL + HTTP + HTML
Tecnologie Web Il protocollo HTTP 1 HTTP WWW = URL + HTTP + HTML HTTP è l acronimo di Hyper ypertext ext Transfer Protocol E il protocollo di livello applicativo utilizzato per trasferire le risorse Web
Il protocollo HTTP e HTTPS
Il protocollo HTTP e HTTPS Guida Apache di Openskills Introduzione al protocollo HTTP Il protocollo HTTP (Hyper Text Transfer Protocol) viene usato da tutti i client e server web e gestisce il modo con
Programmazione in Rete
Programmazione in Rete a.a. 2005/2006 http://www.di.uniba.it/~lisi/courses/prog-rete/prog-rete0506.htm dott.ssa Francesca A. Lisi lisi@di.uniba.it Orario di ricevimento: mercoledì ore 10-12 Sommario della
Web caching. Corso di Applicazioni Telematiche. A.A Lezione n.3 - parte I Prof. Roberto Canonico
Web caching Corso di Applicazioni Telematiche A.A. 2005-06 Lezione n.3 - parte I Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria Web caching Si parla genericamente
Appunti di Sistemi A cura del prof. ing. Mario Catalano. Internet e il Web
Appunti di Sistemi A cura del prof. ing. Mario Catalano Internet e il Web 1 Internet Internet è un insieme di reti informatiche collegate tra loro in tutto il mondo. Tramite una connessione a Internet
Sicurezza delle applicazioni web: protocollo HTTP
Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Anno Accademico 2009/2010 Sicurezza delle applicazioni web: protocollo HTTP Roberto Paleari roberto@security.dico.unimi.it
Applicazioni e protocolli a livello applicazione
Applicazioni e protocolli a livello applicazione Applicazione: processi distribuiti comunicanti vengono eseguiti sugli host di rete come processi utente scambio di messaggi per implementare l applicazione
Sicurezza delle applicazioni web: protocollo HTTP
Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Anno Accademico 2013/2014 Sicurezza delle applicazioni web: protocollo HTTP Andrea Lanzi 14 Maggio 2014 Andrea Lanzi
Protocollo HTTP. Alessandro Sorato
Un protocollo è un insieme di regole che permettono di trovare uno standard di comunicazione tra diversi computer attraverso la rete. Quando due o più computer comunicano tra di loro si scambiano una serie
Sicurezza delle applicazioni web: protocollo HTTP
Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Anno Accademico 2012/2013 Sicurezza delle applicazioni web: protocollo HTTP Srdjan Matic, Aristide Fattori 17 Maggio
Architetture Web Protocolli di Comunicazione
Architetture Web Protocolli di Comunicazione Alessandro Martinelli alessandro.martinelli@unipv.it 10 Maggio 2011 Architetture Web Architetture Web Protocolli di Comunicazione Il Client Side Il Server Side
INFORMATICA DISTRIBUITA. lez 5 World Wide Web (cont)
INFORMATICA DISTRIBUITA prof. lez 5 World Wide Web (cont) Università degli Studi di Milano Scienze e Tecnologie della Comunicazione Musicale a.a. 2009-2010 Protocolli usabili nelle URL http: ftp: : http://www.dico.unimi.it/
Applicazioni di rete 1
Applicazioni di rete 1 PROTOCOLLO TCP Proprietà: - verifica che i dati siano arrivati ed automaticamente provvede in caso negativo alla loro ritrasmissione - esegue checksum sui dati per garantire che
Mantenimento dello stato
Mantenimento dello stato Laboratorio Progettazione Web AA 2009/2010 Chiara Renso ISTI- CNR - c.renso@isti.cnr.it Abbiamo visto come il passaggio di informazioni (parametri) tra le pagine possa avvenire
url uniform resource locator
url uniform resource locator m. patrignani nota di copyright questo insieme di slides è protetto dalle leggi sul copyright il titolo ed il copyright relativi alle slides (inclusi, ma non limitatamente,
2.5. L'indirizzo IP identifica il computer di origine, il numero di porta invece identifica il processo di origine.
ESERCIZIARIO Risposte ai quesiti: 2.1 Non sono necessarie modifiche. Il nuovo protocollo utilizzerà i servizi forniti da uno dei protocolli di livello trasporto. 2.2 Il server deve essere sempre in esecuzione
Web e HTTP. path name. host name Realizzato da Roberto Savino. www.someschool.edu/somedept/pic.gif
Web e HTTP Terminologia Una pagina web consiste di oggetti Un oggetto può essere un file HTML, una immagine JPG, ecc. Una pagina web consiste di un file HTML base che fa riferimento a diversi oggetti al
Real Time Streaming Protocol. Akshat Sikarwar - Columbia University Traduzione e adattamento di Massimo De Santo, Università di Salerno
Real Time Streaming Protocol Akshat Sikarwar - Columbia University Traduzione e adattamento di Massimo De Santo, Università di Salerno Sommario Introduzione Proprietà del protocollo messaggi di RTSP Messaggi
Architettura dell Informazione
Architettura dell Informazione 6. - Protocolli a livello applicazione nel WWW Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://pages.di.unipi.it/milazzo milazzo di.unipi.it Master in
Lo strato di applicazione in Internet
Lo strato di applicazione in Internet Prof. Ing. Carla Raffaelli a.a. 2004/2005 Protocolli applicativi Sono i protocolli utilizzati dalle applicazioni per scambiarsi informazioni Esempi: HTTP per il web,
Architetture Applicative Il Web
Architetture Applicative Il Web Alessandro Martinelli alessandro.martinelli@unipv.it 18 Marzo 2014 Architetture Architetture Web L Architettura Client-Server HTTP Protocolli di Comunicazione Fondamenti
2Dove vogliamo arrivare:
2Dove vogliamo arrivare: siti web dinamici Per programmazione lato server si intende quella serie di tecniche che consentono di produrre risorse in tempo reale, che un server web può restituire ai client
Il Protocollo HTTP e la programmazione di estensioni Web
Il Protocollo HTTP e la programmazione di estensioni Web 1 Il protocollo HTTP È il protocollo standard inizialmente ramite il quale i server Web rispondono alle richieste dei client (prevalentemente browser);
Attacchi Web - Introduzione alla sicurezza nelle applicazioni Web
Attacchi Web Introduzione alla sicurezza nelle applicazioni Web Davide Marrone davide@security.dico.unimi.it Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Dipartimento
Mariarosaria Napolitano. Architettura TCP/IP. Corso di: Laboratorio di tecnologie informatiche e telematiche
Mariarosaria Napolitano Architettura TCP/IP Corso di: Laboratorio di tecnologie informatiche e telematiche Contesto e Prerequisiti Contesto E' rivolto agli studenti del V anno degli Istituti Tecnici Industriali
Caratteristiche del protocollo HTTP. Il protocollo HTTP. Messaggi HTTP. Versioni del protocollo. Valeria Cardellini Università di Roma Tor Vergata
Caratteristiche del protocollo HTTP Scambio di messaggi di richiesta e risposta Transazione HTTP o Web Il protocollo HTTP Valeria Cardellini Università di Roma Tor Vergata Protocollo stateless Basato sul
L'HyperText Transfer Protocol (HTTP)
L'HyperText Transfer Protocol (HTTP) Tito Flagella Laboratorio Applicazioni Internet - Università di Pisa Tito Flagella - tito@link.it Slide Title L'HyperText Transfer Protocol (HTTP) La Prima specifica
Tecnologie Web T Il protocollo HTTP
Tecnologie Web T Il protocollo HTTP Home Page del corso: http://www-db.disi.unibo.it/courses/tw/ Versione elettronica: 1.03.HTTP.pdf Versione elettronica: 1.03.HTTP-2p.pdf 1 HTTP WWW = URL + HTTP + HTML
WWW = URL + HTTP + HTML
Tecnologie Web T Il protocollo HTTP Home Page del corso: http://www-db.disi.unibo.it/courses/tw/ Versione elettronica: 1.03.HTTP.pdf Versione elettronica: 1.03.HTTP-2p.pdf 1 HTTP WWW = URL + HTTP + HTML
Protocolli di strato applicazione
Modello client-server Protocolli strato applicazione in Internet Gruppo Reti TLC claudio.casetti@polito.it http://www.tlc-networks.polito.it/ Tipica applicazione tra client e server Client: inizia comunicazione
OSOR. Applicazioni di Rete
OSOR Applicazioni di Rete 1 Client-Server in Sistemi Distribuiti Host A Host B Client TCP/UDP IP Network Interface Internet Risultati Server TCP/UDP IP Network Interface Richiesta Applicazioni di Rete
(Domain Name System) DNS (Domain Name System)
(Domain Name System) Antonio Lioy < lioy@polito.it > Politecnico di Torino Dip. Automatica e Informatica (Domain Name System) è il sistema scelto da Internet per mantenere la corrispondenza nomi - indirizzi
Protocolli applicativi: FTP
Protocolli applicativi: FTP FTP: File Transfer Protocol. Implementa un meccanismo per il trasferimento di file tra due host. Prevede l accesso interattivo al file system remoto; Prevede un autenticazione
Protocolli strato applicazione in Internet
Protocolli strato applicazione in Internet Gruppo Reti TLC claudio.casetti@polito.it http://www.tlc-networks.polito.it/ Protocolli di strato applicativo - 1 Modello client-server Tipica applicazione tra
RETI DI CALCOLATORI Home Work ritardi e livello applicativo
RETI DI CALCOLATORI Home Work ritardi e livello applicativo Prima parte Q1. Supponiamo che un router A trasmetta un pacchetto su un collegamento con un router B, che la frequenza di trasmissione del collegamento
Reti di Calcolatori Servizi di Rete Laboratorio di Didattica in Rete
Reti di Calcolatori Servizi di Rete Laboratorio di Didattica in Rete Reti di calcolatori Protocolli di Trasmissione: Il modello ISO/OSI L architettura TCP/IP Protocolli di trasmissione Un protocollo di
Progettazione Siti Web: Web
Progettazione Siti Web: Web Dr. Ing. Information Management Systems (IMS) Research Group, Dipartimento di Ingegneria dell Informazione, Università degli Studi di Padova {silvello}@dei.unipd.it Corso di
UDP. User Datagram Protocol. UDP Connectionless
UDP User Datagram Protocol IP fornisce un unreliable datagram service tra gli host I Transport protocols forniscono un servizio di consegna end-to-end tra gli endpoints di una connessione UDP Connectionless
Sicurezza delle applicazioni web: protocollo HTTP
Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Sicurezza delle applicazioni web: protocollo HTTP Alessandro Reina Aristide Fattori
Configurazione delle interfacce di rete
Configurazione delle interfacce di rete A.A. 2006/2007 Alessandro Botticelli Instradamento dei datagrammi IP Routing : scelta del percorso su cui inviare i dati i router formano struttura interconnessa
World Wide Web. WWW e Tim Berners Lee
World Wide Web Storia Definizione Terminologia Tecnologie FdI 2013/2014 GMDN 2014 1 WWW e Tim Berners Lee Il World Wide Web è una collezione di informazioni fra loro collegate e mantenute su calcolatori
Protocolli per il Web. Impianti Informatici. Protocolli applicativi
Protocolli per il Web Protocolli applicativi I protocolli applicativi 2 Applicazioni Socket interface HTTP (WEB) SMTP (E-MAIL) FTP... NFS RPC DNS... Trasporto TCP UDP Rete ICMP RIP OSPF IP ARP RARP Non
Il livello trasporto: Introduzione e protocollo UDP
Corso di Laurea in Ingegneria Informatica Corso di Reti di Calcolatori a.a. 2009/10 Roberto Canonico (roberto.canonico@unina.it) Antonio Pescapè (pescape@unina.it) Il livello trasporto: Introduzione e
Il livello trasporto: Introduzione e protocollo UDP
Corsi di Laurea in Ingegneria Informatica Ingegneria delle Telecomunicazioni Ingegneria dell Automazione Corso di Reti di Calcolatori Simon Pietro Romano (spromano@unina.it) Antonio Pescapè (pescape@unina.it)
Web (1) Internet. Elementi di Sicurezza e Privatezza Lezione 9 Web Security (1) Chiara Braghin. chiara.braghin@unimi.it! 20/11/12. browser.
Elementi di Sicurezza e Privatezza Lezione 9 Web Security (1) Chiara Braghin chiara.braghin@unimi.it! Web (1) File HTML browser Internet URL Server web server Client il protocollo: HTTP 1 1 Web (2) Server
Informatica. Dipartimento di Economia. Ing. Cristiano Gregnanin. 8 novembre Corso di laurea in Economia
Informatica Dipartimento di Economia Ing. Cristiano Gregnanin Corso di laurea in Economia 8 novembre 2016 1 / 28 Rete informatica La rete informatica è la condivisione d informazioni o servizi. un computer
Architetture Applicative Il Web
Architetture Applicative Il Web Alessandro Martinelli alessandro.martinelli@unipv.it 18 Marzo 2014 Architetture Architetture Web L Architettura Client-Server HTTP Protocolli di Comunicazione Fondamenti
Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Parte II Lezione 5
Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II Lezione 5 Martedì 18-03-2014 1 Livello di applicazione Architetture
Fondamenti di Internet e Reti
sul Livello Applicativo 1. o HTTP (basi) Di seguito è riportato il contenuto (in codifica testuale ASCII) di una richiesta HTTP. Rispondere alle domande seguenti indicando dove trovate la risposta nella
Progettazione di Servizi Web e Reti di Calcolatori
Progettazione di Servizi Web e Reti di Calcolatori Prompt dei comandi Politecnico di Torino Prof. Antonio Lioy AA 2015-2016, esercitazione di laboratorio n.2 Per usare gli applicativi nslookup e wget è
Lezione 6. Siti, Utenti e Sessioni
Lezione 6 Siti, Utenti e Sessioni Classificazione dei siti Siti statici Sono siti con contenuti che variano poco frequentemente Dal punto di vista tecnologico sono costituiti da pagine html Siti dinamici
Sicurezza delle applicazioni di rete
Sicurezza delle applicazioni di rete Antonio Lioy < lioy @ polito.it > Politecnico di Torino Dip. Automatica e Informatica Sicurezza di canale autenticazione (singola o mutua), integrità e segretezza solo
Reti di Calcolatori. Master "Bio Info" Reti e Basi di Dati Lezione 2
Reti di Calcolatori Sommario Software di rete TCP/IP Livello Applicazione Http Livello Trasporto (TCP) Livello Rete (IP, Routing, ICMP) Livello di Collegamento (Data-Link) I Protocolli di comunicazione
Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione
I semestre 03/04 Comunicazione tra Computer Protocolli Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica 2
Dipartimento Affari Interni e Territoriali Direzione Centrale per i Servizi Demografici INA-SAIA. SSLProxy. Manuale Utente. versione 1.
SSLProxy Manuale Utente versione 1.0 Indice 1 Panoramica... 3 2 Installazione...4 2.1 Prerequisiti... 4 2.2 Acquisizione del pacchetto... 4 2.3 Copia dei file sulla postazione client... 4 2.4 Esecuzione
D B M G Il linguaggio HTML
Programmazione Web Il linguaggio HTML Il linguaggio HTML Concetti di base Le interfacce utente in HTML I form Le tabelle Il passaggio dei parametri contenuti nei form @2011 Politecnico di Torino 1 Concetti
PROTOCOLLI APPLICATIVI PER INTERNET
PROTOCOLLI APPLICATIVI PER INTERNET IC3N 2000 N. 5 La famiglia dei protocolli TCP/IP Applicazioni e-mail,ftp,ssh,www TCP UDP ICMP IP ARP RARP IEEE 802-Ethernet-X25-Aloha ecc. Collegamento fisico 6 1 Protocolli
Interfaccia Web per customizzare l interfaccia dei terminali e
SIP - Session Initiation Protocol Il protocollo SIP (RFC 2543) è un protocollo di segnalazione e controllo in architettura peer-to-peer che opera al livello delle applicazioni e quindi sviluppato per stabilire
ACCESSO ALLA POSTA ELETTRONICA TRAMITE OUTLOOK WEB ACCESS
ACCESSO ALLA POSTA ELETTRONICA TRAMITE OUTLOOK WEB ACCESS Versione 1.2 9 Luglio 2007 Pagina 1 di 16 SOMMARIO 1. Cos è Outlook Web Access... 3 2. Quando si usa... 3 3. Prerequisiti per l uso di Outlook
@2011 Politecnico di Torino 1
Concetti di base Programmazione Web Il linguaggio HTML HTML consente di annotare un testo per contrassegnare le parti che lo compongono Le annotazioni sono realizzate tramite i "tag" Visualizzare documenti
Protocolli multimediali
Protocolli multimediali RTP, RTCP, RTSP Ormai molte applicazioni scambiano informazioni in cui le relazioni temporali sono molto importanti. La Telefonia via Internet, Videoconferenza, Lezioni a distanza,
Metodologie Informatiche Applicate al Turismo
Metodologie Informatiche Applicate al Turismo 6. - Protocolli a livello applicazione usati su Internet Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://www.di.unipi.it/ milazzo milazzo
Corso di Reti di Telecomunicazioni. Giovanni Schembra. Trasmissione trame su canale broadcast
Indirizzi LAN e ARP Corso di Reti di Telecomunicazioni Giovanni Schembra 1 Trasmissione trame su canale broadcast I nodi di una LAN si scambiano trame su un canale broadcast: quando un nodo in una LAN
Livello applicazione: protocollo HTTP, cookie, web cache
Livello applicazione: protocollo HTTP, cookie, web cache Prof.ssa Gaia Maselli maselli@di.uniroma1.it Parte di queste slide sono state prese dal materiale associato ai libri: 1) B.A. Forouzan, F. Mosharraf
Applicazioni web centrati sui dati (Data-centric web applications)
Applicazioni web centrati sui dati (Data-centric web applications) 1 ALBERTO BELUSSI ANNO ACCADEMICO 2009/2010 WEB La tecnologia del World Wide Web (WWW) costituisce attualmente lo strumento di riferimento
Internet e Tecnologia Web
INTERNET E TECNOLOGIA WEB Corso WebGis per Master in Sistemi Informativi Territoriali AA 2005/2006 ISTI- CNR c.renso@isti.cnr.it Internet e Tecnologia Web...1 TCP/IP...2 Architettura Client-Server...6
ORGANIZZAZIONE DI SISTEMI OPERATIVI E RETI
ORGANIZZAZIONE DI SISTEMI OPERATIVI E RETI CORSO DI LAUREA IN INGEGNERIA INFORMATICA SPECIFICHE DI PROGETTO A.A. 2007/2008 VERSIONE 1.0 Il progetto consiste nello sviluppo di un applicazione client/server.
INFORMATICA. Prof. MARCO CASTIGLIONE. Istituto Tecnico Statale Tito Acerbo - PESCARA
INFORMATICA Prof. MARCO CASTIGLIONE Istituto Tecnico Statale Tito Acerbo - PESCARA 1.1 Introduzione Internet è una rete di calcolatori collegati tra loro e fisicamente posizionati in tutto il mondo RETE
Protocolli applicativi basati su TCP/IP
Protocolli applicativi basati su TCP/IP A.A. 2005/2006 Walter Cerroni Protocolli applicativi Sono i protocolli utilizzati dalle applicazioni per scambiarsi informazioni attraverso la rete Esempi: HTTP
Seminari Eucip, Esercizio e Supporto di Sistemi Informativi
Seminari Eucip, Esercizio e Supporto di Sistemi Informativi Servizi di Dipartimento di Informtica e Sistemistica Università di Roma La Sapienza Sicurezza su Sicurezza della La Globale La rete è inerentemente
Programmazione in Rete
Programmazione in Rete a.a. 2005/2006 http://www.di.uniba.it/~lisi/courses/prog-rete/prog-rete0506.htm dott.ssa Francesca A. Lisi lisi@di.uniba.it Orario di ricevimento: mercoledì ore 10-12 Sommario della
Infrastrutture e Protocolli per Internet Laboratorio 1
Advanced Network Technologies Laboratory Infrastrutture e Protocolli per Internet Laboratorio 1 Stefano Napoli Alberto Pollastro Politecnico di Milano Laboratori Responsabili di Laboratorio: Stefano Napoli
Siti web centrati sui dati (Data-centric web applications)
Siti web centrati sui dati (Data-centric web applications) 1 A L B E R T O B E L U S S I A N N O A C C A D E M I C O 2 0 1 2 / 2 0 1 3 WEB La tecnologia del World Wide Web (WWW) costituisce attualmente
Struttura di un applicazione Instant Developer
La creazione di un nuovo tipo di installazione avviene dall interno del manager, a partire dall installazione di default che è stata creata da In.de quando l applicazione è stata pubblicata per la prima
Introduzione alla rete Internet
Introduzione alla rete Internet Gruppo Reti TLC nome.cognome@polito.it http://www.telematica.polito.it/ INTRODUZIONE ALLE RETI TELEMATICHE - 1 Copyright Quest opera è protetta dalla licenza Creative Commons
I Principali Servizi del Protocollo Applicativo
1 I Principali Servizi del Protocollo Applicativo Servizi offerti In questa lezione verranno esaminati i seguenti servizi: FTP DNS HTTP 2 3 File Transfer Protocol Il trasferimento di file consente la trasmissione
Prova in itinere Esempio d esame 1
Fondamenti di Internet e Reti Proff. A. Capone, M. Cesana, I. Filippini, G. Maier Cognome Nome Matricola Prova in itinere Esempio d esame 1 Tempo complessivo a disposizione per lo svolgimento: 1h30m Usare
Infrastrutture e Protocolli per Internet Laboratorio 1
Advanced Network Technologies Laboratory Infrastrutture e Protocolli per Internet Laboratorio 1 Stefano Napoli Alberto Pollastro Politecnico di Milano Laboratori Responsabili di Laboratorio: Stefano Napoli
Luca Tesei. Laboratorio di Sviluppo Web: Le Basi. Modulo IFTS. Fermo 31/03, 03/04, 07/ Prof. Luca Tesei Università di Camerino 1
Luca Tesei Laboratorio di Sviluppo Web: Le Basi Modulo IFTS Fermo 31/03, 03/04, 07/04 2017 Prof. Luca Tesei Università di Camerino 1 Informazioni di Contatto Email docente: luca.tesei@unicam.it Telefono:
Programmazione Web D B M G. Il linguaggio HTML
Programmazione Web Il linguaggio HTML Il linguaggio HTML Concetti di base Le interfacce utente in HTML I form Le tabelle Il passaggio dei parametri contenuti nei form HTML: HyperText Markup Language Standard
Introduzione alla rete Internet
Introduzione alla rete Internet Gruppo Reti TLC nome.cognome@polito.it http://www.telematica.polito.it/ INTRODUZIONE A INTERNET - 1 Internet: nomenclatura Host: calcolatore collegato a Internet ogni host
Capitolo 2 - parte 2. Corso Reti ed Applicazioni Mauro Campanella
Capitolo 2 - parte 2 Corso Reti ed Applicazioni Mauro Campanella La nascita del World Wide Web L idea fu nel 1989 di Tim Berners Lee, fisico del CERN di Ginevra. Vi era la necessità di far collaborare
la trasmissione è regolata solamente dall algoritmo per il controllo del flusso prima di inviare l ACK.
1. Considerare il problema della stima del Round Trip Time. Supporre che inizialmente RTT valga 200 ms. Il mittente invia un segmento e riceve l ACK relativo dopo 100 ms, quindi invia un altro segmento,
Metodologie Informatiche Applicate al Turismo
Metodologie Informatiche Applicate al Turismo 3. I Protocolli di Internet Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://www.di.unipi.it/ milazzo milazzo di.unipi.it Corso di Laurea
Sommario. Breve storia di Internet Commutazione di pacchetto e TCP/IP Il Web HTTP HTML CGI... Connessione tra basi di dati e Web
Sommario Breve storia di Internet Commutazione di pacchetto e TCP/IP Il Web HTTP HTML CGI... Connessione tra basi di dati e Web Internetworking (collegamento fra reti e sistemi eterogenei) Nasce da un
Internet Architettura del www
Internet Architettura del www Internet è una rete di computer. Il World Wide Web è l insieme di servizi che si basa sull architettura di internet. In una rete, ogni nodo (detto host) è connesso a tutti
Informatica per Umanisti Antonio Lieto. Parte IV Le reti informatiche, Internet e il Web (Come colleghiamo i computer?)
Informatica per Umanisti Antonio Lieto Parte IV Le reti informatiche, Internet e il Web (Come colleghiamo i computer?) 1 ARGOMENTI DI QUESTO GRUPPO DI LUCIDI WEB Il Web come applicazione Internet Il Web
Modulo o Form in Html
Pagina dinamica E un documento contenente oggetti, dati e informazioni che possono variare anche in base all iterazione dell utente con il documento stesso. Un esempio classico è quello di una persona
WINDOWS TERMINAL SERVER PER L ACCESSO REMOTO AL SISTEMA DI PROTOCOLLO INFORMATICO
Servizi per l e-government nell università Federico II WINDOWS TERMINAL SERVER PER L ACCESSO REMOTO AL SISTEMA DI PROTOCOLLO INFORMATICO CONNESSIONE_TERMINAL_SERVER PAG. 1 DI 13 Indice 1. Premessa...3
TCP/IP: elemento unificante
TCP/IP: elemento unificante L elemento unificante di Internet è la suite di protocolli TCP/IP (non solo TCP e IP!) per la trasmissione dei dati Non sono elementi unificanti di Internet: tecnologia di accesso