Un po' di storia di HTTP. Il protocollo HTTP. (HyperText Transfer Protocol) Il protocollo HTTP 1.0. Connessione stateless (HTTP/1.
|
|
|
- Mariangela Sarti
- 8 anni fa
- Visualizzazioni
Transcript
1 Un po' di storia di HTTP Il protocollo HTTP (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) HTTP originale (anche noto come HTTP/0.9) uso quasi solo sperimentale HTTP/1.0 il primo a larga diffusione ancora molto usato HTTP/1.1 per migliorare l'efficienza del web per migliorare la gestione delle cache Il protocollo HTTP 1.0 Connessione stateless (HTTP/1.0) HyperText Transfer Protocol RFC-1945 (HTTP/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 ( ) D-1
2 Protocollo HTTP/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 HTTP/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 / HTTP/1.0 response HTTP/ 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 / HTTP/1.0 response HTTP/ 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 ) Metodo POST ( TCP setup ) request POST /cgi-bin/form.cgi HTTP/1.0 Content-type: text/plain Content-length: 12 Antonio Lioy response HTTP/ 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 HTTP (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 g Microsoft Telnet> set logfile mylog.txt Microsoft Telnet> open server_web 80 GET / HTTP/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 ( ) D-2
3 Test manuale di HTTP (*nix) installare (se non presente) il programma "netcat" aprire una finestra di shell dare i seguenti comandi: $ nc server_web 80 > output.txt GET / HTTP/1.1 1 <enter> Host: nome_server_web <enter> Connection: close <enter> <enter> Codice di stato HTTP 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 HTTP/ 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 HTTP/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 susseguente un Redirect User-Agent: product response header: Header HTTP/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 ( ) D-3
4 tre possibili formati: HTTP 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 più semplice Il protocollo HTTP/0.9 non documentato in nessun RFC request: GET URI response: entity-body Problemi di HTTP/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 HTTP/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 HTTP/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 HTTP/1.1: virtual host con HTTP/1.0 occorreva un indirizzo IP per ogni server web ospitato su un nodo (multihomed) con HTTP/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 ( ) D-4
5 HTTP/1.1: virtual host (esempio) 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 HTTP/1.1 Host: DNS HTTP HTTP/1.1: connessioni persistenti uso di un unico canale TCP per trasmettere più interazioni richiesta-risposta è il comportamento di default in HTTP/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 HTTP/1.1 Host: HTTP Connessioni persistenti: esempio ( TCP setup ) GET / HTTP/1.1 Host: GET /favicon.gif HTTP/1.1 Host: Connection: close HTTP/ OK... HTTP/ 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 HTTP (client può provare nuova versione ma poi usare vecchia) svantaggi: sovraccarico del server (possibile denial-of-service) HTTP/1.1: pipeline 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 HTTP/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 in HTTP/1.1 implementata come codifica dei dati oppure come codifica di trasmissione A.Lioy - Politecnico di Torino ( ) D-5
6 Codifiche dati codifica applicata ad una risorsa prima di trasferirla (proprietà del dato, non della trasmissione) poiché HTTP è 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 utile quando il server non conosce a priori la dimensione dei dati da trasferire caso tipico dei server dinamici (es. ASP, PHP, JSP) si frammenta la risposta in pezzi (detti chunk ) meno importante in HTTP/1.0 (fine dati implicita alla chiusura del canale) ma protocollo meno efficiente 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... 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 / PNG / HTTP-1.1 e le prestazioni 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 HTTP-1.1 complesso: connessioni persistenti, pipelining, compressione (body risultante) <html><body>ciao</body></html> A.Lioy - Politecnico di Torino ( ) D-6
7 Test HTTP 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: HTTP/1.0 con 4 connessioni simultanee HTTP/1.1 con 1 connessione persistente HTTP/1.1 pipeline con 1 connessione persistente HTTP/1.1 pipeline + compressione con 1 connessione persistente Risultati test HTTP 1.0 vs. 1.1 WAN first-time retrieval against Apache server , , ,23 HTTP/1.0 HTTP/1.1 HTTP/1.1 pipelined TCP packets time (s) 182 2,11 HTTP/1.1 pipelined w. compression PUT uri http-version HTTP/1.1: metodo PUT 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: PUT /avviso.txt HTTP/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 è 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 HTTP/1.1 Host: Expect: 100-continue... voti.pdf... HTTP/ Continue HTTP/ OK HTTP/1.1: metodo DELETE 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 HTTP/1.1 Host: lioy.polito.it Content-Length: 0 HTTP/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) A.Lioy - Politecnico di Torino ( ) D-7
8 TRACE / HTTP/1.1 Host: C Metodo TRACE: esempio HTTP/ OK Date: Sun, 20 May :29:05 GMT Server: Apache Transfer-Encoding: chunked Content-Type: message/http 29 TRACE / HTTP/1.1 Host: S HTTP/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 0 OPTIONS / HTTP/1.1 Host: Metodo OPTIONS: esempio S HTTP/1.1: metodo CONNECT riservato all uso con proxy capaci di creare un tunnel sicuro (es. SSL) C HTTP/ OK Date: Sun, 20 May :51:25 GMT Server: Apache/ (Unix) Content-Length: 0 Allow: GET, HEAD, OPTIONS, TRACE 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) 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: 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) A.Lioy - Politecnico di Torino ( ) D-8
9 HTTP/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 HTTP/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) HTTP/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: ) HTTP/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 HTTP/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 HTTP/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 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 A.Lioy - Politecnico di Torino ( ) D-9
![q=qualityvalue ], lingue accettabili es. Accept-Language: it, en-gb;q=0.8, en;q=0.7 HTTP/1.](/docs-images/42/1202767/images/page_9.jpg "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")
10 HTTP/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 HTTP/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 HTTP/1.0 in HTTP/1.1 si preferisce Cache-Control Gestione della cache richieste del client voglio o meno risposte presenti in cache risposte del server non mettere in cache... 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 Response-cache-directive (I) public risposta può essere messa in cache (shared/private) private [ = header-name, ] non mettere in shared cache (tutto o alcuni header) no-cache [ = header-name, ] non mettere in cache (tutto o alcuni header) no-store non mettere in cache (shared/private) su disco no-transform must-revalidate il proxy / client deve rivalidare con origin server quando la risorsa in cache diventa stale A.Lioy - Politecnico di Torino ( ) D-10
11 Response-cache-directive (II) proxy-revalidate il proxy / client deve rivalidare con origin server quando la risorsa in cache diventa stale max-age=secondi scadenza dei dati 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 HTTP/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 HTTP/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 HTTP/1.1 entity header (I) Allow: metodo, 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 HTTP/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 A.Lioy - Politecnico di Torino ( ) D-11
12 Codici di stato standard HTTP/ Continue 101 Switching protocols 200 OK 201 Created 202 Accepted 203 Non-authoritative ti 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 HTTP: HTTP/1.0 effettua singole transazioni ed è stateless HTTP/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 HTTP v1 in HTTP/1.0 v2 (+ v1) in HTTP/1.1 Perché gestire lo stato in HTTP? 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 I 4 comandamenti dei cookie è lecito mantenere traccia dello stato di una sessione HTTP 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! A.Lioy - Politecnico di Torino ( ) D-12
13 Definizione dei cookie inizialmente definito da Netscape: Persistent client state HTTP cookies diventato poi standard IETF: HTTP state management mechanism : v1 = RFC-2109 v2 = RFC-2965 le specifiche Netscape e v1 sono obsolete ma ancora usate RFC-2964 Use of HTTP 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 HTTP diverse verso lo stesso server Supporto dei cookie nei browser Netscape Navigator dalla versione 2.0 registrati nel file cookies.txt in (default in Netscape\Users\username) Microsoft IE dalla versione 3.0 registrati in \Windows\Cookies o nel profilo utente \Documents and Settings\username\Cookies 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 Trasmissione dei cookie (v1): S > C cookie inserito nell header della risposta HTTP 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 HTTPS A.Lioy - Politecnico di Torino ( ) D-13
14 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 HTTP della richiesta tutte le coppie nome/valore dei relativi cookie se l URL specificata nella richiesta HTTP è quella di una pagina dinamica (es. CGI o ASP), l'applicazione troverà la stringa dei cookie nella variabile d ambiente HTTP_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 Esempio (passo 3) il client riceve: 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 A.Lioy - Politecnico di Torino ( ) D-14
15 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?) 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) Cambiamento di significato in v1 l attributo Secure richiedeva trasmissione solo su HTTPS 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: Cookie2: highest-cookie-version-understood A.Lioy - Politecnico di Torino ( ) D-15
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
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);
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
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
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
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
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
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,
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
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
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
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
Nelle reti di calcolatori, le porte (traduzione impropria del termine. port inglese, che in realtà significa porto) sono lo strumento
I protocolli del livello di applicazione Porte Nelle reti di calcolatori, le porte (traduzione impropria del termine port inglese, che in realtà significa porto) sono lo strumento utilizzato per permettere
Reti di Telecomunicazione Lezione 7
Reti di Telecomunicazione Lezione 7 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Il protocollo Programma della lezione file transfer protocol descrizione architetturale descrizione
Il protocollo HTTP (HyperText Transfer Protocol) Un po' di storia di HTTP. Il protocollo HTTP 1.0. A.Lioy - Politecnico di Torino ( ) D-1
(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 e la trasmissione
URI. Introduzione. Pag. 1
URI Introduzione Gli URI (Universal Resource Indentifier) sono una sintassi usata in WWW per definire i nomi e gli indirizzi di oggetti (risorse) su Internet. Questi oggetti sono considerati accessibili
Il protocollo HTTP (HyperText Transfer Protocol)
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
Reti di Telecomunicazione Lezione 6
Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server
HTTP adaptation layer per generico protocollo di scambio dati
HTTP adaptation layer per generico protocollo di scambio dati Sandro Cavalieri Foschini 101786 Emanuele Richiardone 101790 Programmazione in Ambienti Distribuiti I - 01FQT prof. Antonio Lioy A.A. 2002-2003
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
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
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
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
Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 2005, ore 15.00
Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 200, ore 1.00 NB: alcune domande hanno risposta multipla: si richiede di identificare TUTTE le risposte corrette. Cognome: Nome:
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 Il protocollo (HyperText Transfer Protocol) Antonio Lioy < lioy@polito.it > Politecnico di Torino Dip. Automatica e Informatica protocollo client-server ideato per la richiesta e la
Dal protocollo IP ai livelli superiori
Dal protocollo IP ai livelli superiori Prof. Enrico Terrone A. S: 2008/09 Protocollo IP Abbiamo visto che il protocollo IP opera al livello di rete definendo indirizzi a 32 bit detti indirizzi IP che permettono
Cognome Nome Matricola Tempo a disposizione per lo svolgimento: 1 ora e 20 min Avvertenza: Si usi lo spazio dopo ogni quesito per lo svolgimento.
Infrastrutture e Protocolli per Internet Prof. A. Capone a Prova in itinere Luglio 004 Cognome Nome Matricola Tempo a disposizione per lo svolgimento: ora e 0 min Avvertenza: Si usi lo spazio dopo ogni
Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 2005, ore 15.00
Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 2005, ore 15.00 NB: alcune domande hanno risposta multipla: si richiede di identificare TUTTE le risposte corrette. Cognome: Nome:
Approfondimento di Marco Mulas
Approfondimento di Marco Mulas Affidabilità: TCP o UDP Throughput: banda a disposizione Temporizzazione: realtime o piccoli ritardi Sicurezza Riservatezza dei dati Integrità dei dati Autenticazione di
Inizializzazione degli Host. BOOTP e DHCP
BOOTP e DHCP a.a. 2002/03 Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/~auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica 1 Inizializzazione degli Host Un
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
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/
Lezione n 1! Introduzione"
Lezione n 1! Introduzione" Corso sui linguaggi del web" Fondamentali del web" Fondamentali di una gestione FTP" Nomenclatura di base del linguaggio del web" Come funziona la rete internet?" Connessione"
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
Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni client
Versione 25.4.05 Sistemi informativi applicati (reti di calcolatori): appunti delle lezioni Architetture client/server: applicazioni client 1 Architetture client/server: un esempio World wide web è un
Modulo 1: Posta elettronica
Contenuti Architettura di Internet Principi di interconnessione e trasmissione World Wide Web Posta elettronica Motori di ricerca Tecnologie delle reti di calcolatori Servizi Internet (come funzionano
Architettura del. Sintesi dei livelli di rete. Livelli di trasporto e inferiori (Livelli 1-4)
Architettura del WWW World Wide Web Sintesi dei livelli di rete Livelli di trasporto e inferiori (Livelli 1-4) - Connessione fisica - Trasmissione dei pacchetti ( IP ) - Affidabilità della comunicazione
Le Reti Informatiche
Le Reti Informatiche modulo 10 Prof. Salvatore Rosta www.byteman.it s.rosta@byteman.it 1 Nomenclatura: 1 La rappresentazione di uno schema richiede una serie di abbreviazioni per i vari componenti. Seguiremo
CORSO DI RETI SSIS. Lezione n.2. 2 Novembre 2005 Laura Ricci
CORSO DI RETI SSIS Lezione n.2. 2 Novembre 2005 Laura Ricci IL DOMAIN NAME SYSTEM (DNS) Indirizzi IP poco adatti per essere memorizzati da utenti umani è prevista la possibiltà di associare nomi simbolici
Lezione 1 Introduzione
Lezione 1 Introduzione Ingegneria dei Processi Aziendali Modulo 1 Servizi Web Unità didattica 1 Protocolli Web Ernesto Damiani Università di Milano I Servizi Web Un Servizio Web è un implementazione software
Reti di calcolatori. Reti di calcolatori
Reti di calcolatori Reti di calcolatori Rete = sistema di collegamento tra vari calcolatori che consente lo scambio di dati e la cooperazione Ogni calcolatore e un nodo, con un suo indirizzo di rete Storia:
Il Web Server e il protocollo HTTP
Corso PHP Parte 2 Il Web Server e il protocollo HTTP E un programma sempre attivo che ascolta su una porta le richieste HTTP. All arrivo di una richiesta la esegue e restituisce il risultato al browser,
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
Oreste Signore, <oreste@w3.org> Responsabile Ufficio Italiano W3C Area della Ricerca CNR - via Moruzzi, 1-56124 Pisa
http://www.w3c.it/education/2012/upra/basicinternet/#(1) 1 of 16 Oreste Signore, Responsabile Ufficio Italiano W3C Area della Ricerca CNR - via Moruzzi, 1-56124 Pisa Master in Comunicazione
Bibliografia: Utenti e sessioni
Bibliografia: Utenti e sessioni http: protocollo stateless http si appoggia su una connessione tcp e lo scambio nel contesto di una connessione si limita a invio della richiesta, ricezione della risposta.
NOTE LEGALI E PRIVACY
NOTE LEGALI E PRIVACY L'accesso a questo sito web da parte dei visitatori è soggetto alle seguenti condizioni. Le informazioni, i loghi, gli elementi grafici, le immagini, e quant'altro pubblicato e/o
Il protocollo HTTP (cont.)
Il protocollo HTTP (cont.) Corso di Applicazioni Telematiche A.A. 2008-09 Lezione n.2 Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria HTTP: Response La risposta
TITOLARE DEL TRATTAMENTO Il "titolare" del trattamento di eventuali dati personali rilevati a seguito della consultazione del sito è SEVAL S.r.l.
PRIVACY POLICY SCOPO Il presente documento è rivolto a coloro che interagiscono con i servizi web del sito accessibili via internet a partire dall indirizzo www.seval.it. In tale informativa, resa ai sensi
1) GESTIONE DELLE POSTAZIONI REMOTE
IMPORTAZIONE ESPORTAZIONE DATI VIA FTP Per FTP ( FILE TRANSFER PROTOCOL) si intende il protocollo di internet che permette di trasferire documenti di qualsiasi tipo tra siti differenti. Per l utilizzo
(Domain Name System) DNS (Domain Name System) Architettura del DNS DNS. A.Lioy - Politecnico di Torino (2013) B-1. Antonio Lioy < lioy@polito.
(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
Reti di Telecomunicazioni Mobile IP Mobile IP Internet Internet Protocol header IPv4 router host indirizzi IP, DNS URL indirizzo di rete
IP Analizziamo con sufficiente dettaglio il sistema denominato IP, usato per consentire a due computer mobili di spostarsi liberamente in altre reti pur mantenendo lo stesso indirizzo IP. In particolare,
Topologia delle reti. Rete Multipoint: ogni nodo è connesso agli altri tramite nodi intermedi (rete gerarchica).
Topologia delle reti Una RETE DI COMPUTER è costituita da un insieme di elaboratori (NODI) interconnessi tra loro tramite cavi (o sostituti dei cavi come le connessioni wireless). Rete Point-to-Point:
19. LA PROGRAMMAZIONE LATO SERVER
19. LA PROGRAMMAZIONE LATO SERVER Introduciamo uno pseudocodice lato server che chiameremo Pserv che utilizzeremo come al solito per introdurre le problematiche da affrontare, indipendentemente dagli specifici
Network Services Location Manager. Guida per amministratori di rete
apple Network Services Location Manager Guida per amministratori di rete Questo documento illustra le caratteristiche di Network Services Location Manager e spiega le configurazioni di rete per sfruttarne
INFORMATIVA SUL DIRITTO ALLA PRIVACY PER LA CONSULTAZIONE DEL SITO WEB www.arlatighislandi.it
INFORMATIVA SUL DIRITTO ALLA PRIVACY PER LA CONSULTAZIONE DEL SITO WEB www.arlatighislandi.it redatto ai sensi del decreto legislativo n 196/2003 2 GENNAIO 2014 documento pubblico 1 PREMESSA 3 SEZIONE
LA GESTIONE DELLE VISITE CLIENTI VIA WEB
LA GESTIONE DELLE VISITE CLIENTI VIA WEB L applicazione realizzata ha lo scopo di consentire agli agenti l inserimento via web dei dati relativi alle visite effettuate alla clientela. I requisiti informatici
FTP. Appunti a cura del prof. ing. Mario Catalano
FTP Appunti a cura del prof. ing. Mario Catalano Il protocollo FTP 1/2 Attraverso il protocollo FTP (File Transfer Protocol) è possibile trasferire uno o più files di qualsiasi tipo tra due macchine Tale
Come funziona il WWW. Architettura client-server. Web: client-server. Il protocollo
Come funziona il WWW Il funzionamento del World Wide Web non differisce molto da quello delle altre applicazioni Internet Anche in questo caso il sistema si basa su una interazione tra un computer client
ESERCITAZIONE Semplice creazione di un sito Internet
ESERCITAZIONE Semplice creazione di un sito Internet Sistemi e Tecnologie Informatiche - Prof. Gregorio Cosentino 1 Internet Una rete globale che connette milioni di computer in tutto il mondo, anarchica
Software di gestione della stampante
Questo argomento include le seguenti sezioni: "Uso del software CentreWare" a pagina 3-11 "Uso delle funzioni di gestione della stampante" a pagina 3-13 Uso del software CentreWare CentreWare Internet
Reti di Calcolatori. Il Livello delle Applicazioni
Reti di Calcolatori Il Livello delle Applicazioni Il DNS Gli indirizzi IP sono in formato numerico: sono difficili da ricordare; Ricordare delle stringhe di testo è sicuramente molto più semplice; Il Domain
Cookie: è scaduto il 2 giugno il termine per mettersi in regola con le prescrizioni del Garante
1 di 5 04/06/2015 13:17 Cookie: è scaduto il 2 giugno il termine per mettersi in regola con le prescrizioni del Garante Stampa Invia per mail Condividi Come previsto dal Provvedimento dell'8 maggio 2014,
Parte II: Reti di calcolatori Lezione 9
Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II: Reti di calcolatori Lezione 9 Giovedì 2-04-2015 1 Come per una pagina Web, anche
Internet e posta elettronica. A cura di Massimiliano Buschi
Internet e posta elettronica A cura di Massimiliano Buschi Concetti fondamentali Internet www Tcp/ip Browser Terminologia Esistono un sacco di termini con cui bisogna famigliarizzare http url Link Isp
Omeka PURL Plugin. Torino, 30 settembre 2013. Emilio Remogna
Omeka PURL Plugin Torino, 30 settembre 2013 Emilio Remogna 1 Estendere Omeka 1.1 Plugin - Plugin: componente software che aggiunge - se installato - una specifica funzionalità ad una applicazione (software)
Esempi di applicazioni internet. WEB Trasferimento File Posta Elettronica Sistema dei nomi di dominio (DNS)
Esempi di applicazioni internet WEB Trasferimento File Posta Elettronica Sistema dei nomi di dominio (DNS) 17 Il Web: terminologia Pagina Web: consiste di oggetti indirizzati da un URL (Uniform Resource
Manuale per la configurazione di AziendaSoft in rete
Manuale per la configurazione di AziendaSoft in rete Data del manuale: 7/5/2013 Aggiornamento del manuale: 2.0 del 10/2/2014 Immagini tratte da Windows 7 Versione di AziendaSoft 7 Sommario 1. Premessa...
ARP (Address Resolution Protocol)
ARP (Address Resolution Protocol) Il routing Indirizzo IP della stazione mittente conosce: - il proprio indirizzo (IP e MAC) - la netmask (cioè la subnet) - l indirizzo IP del default gateway, il router
Architettura client-server
Architettura client-server In un architettura client-server ci sono due calcolatori connessi alla rete: un client che sottopone richieste al server un server in grado di rispondere alle richieste formulate
Cosa è un foglio elettronico
Cosa è un foglio elettronico Versione informatica del foglio contabile Strumento per l elaborazione di numeri (ma non solo...) I valori inseriti possono essere modificati, analizzati, elaborati, ripetuti
Caratteristiche del protocollo HTTP. Il protocollo HTTP. Messaggi HTTP. Versioni del protocollo
Caratteristiche del protocollo HTTP Scambio di messaggi di richiesta e risposta Transazione HTTP o Web Il protocollo HTTP Protocollo stateless Basato sul meccanismo di naming degli URI per identificare
Cookie. Krishna Tateneni Jost Schenck Traduzione: Luciano Montanaro
Krishna Tateneni Jost Schenck Traduzione: Luciano Montanaro 2 Indice 1 Cookie 4 1.1 Politica............................................ 4 1.2 Gestione........................................... 5 3 1
Sicurezza nelle applicazioni multimediali: lezione 9, firewall. I firewall
I firewall Perché i firewall sono necessari Le reti odierne hanno topologie complesse LAN (local area networks) WAN (wide area networks) Accesso a Internet Le politiche di accesso cambiano a seconda della
MODELLO CLIENT/SERVER. Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it
MODELLO CLIENT/SERVER Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it POSSIBILI STRUTTURE DEL SISTEMA INFORMATIVO La struttura di un sistema informativo
appunti delle lezioni Architetture client/server: applicazioni client
Sistemi informativi applicati (reti di calcolatori): appunti delle lezioni Architetture client/server: applicazioni client 1 Architetture client/server: un esempio World wide web è un esempio particolarmente
EUROCONSULTANCY-RE. Privacy Policy
Privacy Policy EUROCONSULTANCY-RE di Concept Design 95 Ltd Registered in England - Co. Reg. no. 3148248 - VAT no.690052547 (GB) No. Iscrizione Camera di Commercio di Milano (REA) 1954902 Codici Fiscale
Impostare il browser per navigare in sicurezza Opzioni di protezione
Impostare il browser per navigare in sicurezza Opzioni di protezione Data la crescente necessità di sicurezza e tutela dei propri dati durante la navigazione in rete, anche gli stessi browser si sono aggiornati,
In questa pagina si descrivono le modalità di gestione del sito in riferimento al trattamento dei dati personali degli utenti che lo consultano.
LE POLICY SULLA PRIVACY DI QUESTO SITO PERCHE QUESTO AVVISO In questa pagina si descrivono le modalità di gestione del sito in riferimento al trattamento dei dati personali degli utenti che lo consultano.
Client - Server. Client Web: il BROWSER
Client - Server Client Web: il BROWSER Il client Web è un applicazione software che svolge il ruolo di interfaccia fra l utente ed il WWW, mascherando la complessità di Internet. Funzioni principali Inviare
GRUPPO CAMBIELLI. Posta elettronica (Webmail) Consigli di utilizzo
GRUPPO CAMBIELLI Posta elettronica (Webmail) Consigli di utilizzo Questo sintetico manuale ha lo scopo di chiarire alcuni aspetti basilari per l uso della posta elettronica del gruppo Cambielli. Introduzione
BACKUP APPLIANCE. User guide Rev 1.0
BACKUP APPLIANCE User guide Rev 1.0 1.1 Connessione dell apparato... 2 1.2 Primo accesso all appliance... 2 1.3 Configurazione parametri di rete... 4 1.4 Configurazione Server di posta in uscita... 5 1.5
Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet
Indirizzi Internet e Protocolli I livelli di trasporto delle informazioni Comunicazione e naming in Internet Tre nuovi standard Sistema di indirizzamento delle risorse (URL) Linguaggio HTML Protocollo
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
Introduzione alle applicazioni di rete
Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza
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
UTILIZZO DEI COOKIES (informativa conforme al Provvedimento del Garante Privacy del 8 Maggio 2014)
UTILIZZO DEI COOKIES (informativa conforme al Provvedimento del Garante Privacy del 8 Maggio 2014) Star Link srl, Titolare del trattamento dei dati personali, informa che questo Sito internet fa uso di
SIEMENS GIGASET S450 IP GUIDA ALLA CONFIGURAZIONE EUTELIAVOIP
SIEMENS GIGASET S450 IP GUIDA ALLA CONFIGURAZIONE EUTELIAVOIP Gigaset S450 IP Guida alla configurazione EUTELIAVOIP Rev1-0 pag.2 INDICE SCOPO...3 TELEFONARE CON EUTELIAVOIP...3 CONNESSIONE DEL TELEFONO
Rsync su GNU/Linux e su Windows? (Backup sincronizzato su disco di rete e/o RAID1 su server FreeNAS)
Rsync su GNU/Linux e su Windows? (Backup sincronizzato su disco di rete e/o RAID1 su server FreeNAS) Augusto Scatolini (webmaster@comunecampagnano.it) Ver. 1.0 Gennaio 2011 rsync è un software per Unix
Informativa ex art. 13 D.lgs. 196/2003
Informativa ex art. 13 D.lgs. 196/2003 Gentile Utente, l Hotel Eurolido (di seguito, Società ) rispetta e tutela la Sua privacy. Ai sensi dell art. 13 del Codice della Privacy (d.lgs. 196 del 30 giugno
prof. Mario Dalessandro
INTERNET Internet in pratica è una rete vastissima, costituita dall interconnessione di migliaia di reti pubbliche e private, utilizzata per scopi differenti, ma comunque volta a creare e diffondere informazioni.
Laplink FileMover Guida introduttiva
Laplink FileMover Guida introduttiva MN-FileMover-QSG-IT-01 (REV.01/07) Recapiti di Laplink Software, Inc. Per sottoporre domande o problemi di carattere tecnico, visitare il sito: www.laplink.com/it/support/individual.asp
Reti di Calcolatori PROTOCOLLO FTP
Reti di Calcolatori PROTOCOLLO FTP D. Talia RETI DI CALCOLATORI - UNICAL 8-1 File File Transfer Protocol Modello FTP Operazioni FTP Comandi del protocollo Esempi di Client FTP avanzati D. Talia RETI DI
POLICY COOKIE Gentile visitatore,
POLICY COOKIE Gentile visitatore, GGS S.r.l. quale titolare del trattamento dei dati, desidera fornirle alcune informazioni sui cookies gestiti accedendo all indirizzo www.noly.it nel rispetto della Direttiva
Applicazioni web. Sommario. Parte 4 http. http Metodi, intestazioni e codici di stato get post Parametri e cookie. Applicazioni web.
Parte 4 http Sommario http Metodi, intestazioni e codici di stato get post Parametri e cookie 1 Http Hyper Text Transfer Protocol Protocollo di livello applicazione per sistemi informativi distribuiti,
Manuale Terminal Manager 2.0
Manuale Terminal Manager 2.0 CREAZIONE / MODIFICA / CANCELLAZIONE TERMINALI Tramite il pulsante NUOVO possiamo aggiungere un terminale alla lista del nostro impianto. Comparirà una finestra che permette
Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione
I semestre 04/05 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 1
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
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
Consiglio regionale della Toscana. Regole per il corretto funzionamento della posta elettronica
Consiglio regionale della Toscana Regole per il corretto funzionamento della posta elettronica A cura dell Ufficio Informatica Maggio 2006 Indice 1. Regole di utilizzo della posta elettronica... 3 2. Controllo