Internet è una grande rete che collega tra loro computer installati in tutte le parti del mondo
e che li mette in condizione di comunicare tra di loro.
Ciascun computer connesso può svolgere uno solo o entrambi i seguenti ruoli:

 - SERVER
Contiene dati e applicazioni che vengono utilizzati dagli utenti, come applicazioni web, database o server di posta.
  
 - CLIENT
È utilizzato dall'utente per connettersi ai servizi offerti dal server, tramite software specializzati, come
i browser e i client di posta.

La comunicazione CLIENT-SERVER avviene solitamente secondo un modello di richiesta-risposta:
esempio:
il client invia una richiesta al server e questo gli risponde con i dati richiesti.
Per esempio, il client potrebbe richiedere la data corrente a un server per regolare l'orologio del computer locale in modo preciso.
In questo caso il client invierebbe la richiesta al server che risponderebbe inviando l'orario corrente.

Solitamente, si utilizza il computer locale come client per accedere ai server, per esempio per navigare un sito.
Ma non è sempre così: per esempio, nel caso della condivisione peer-to-peer,
il computer locale funge anche da server, in quanto mette a disposizione dei file che possono essere letti da
altri computer connessi alla rete.
Le tipologie di comunicazione che possono transitare su Internet sono molteplici:
pagine web, posta elettronica, messaggistica istantanea, peer-to-peer.

Ciascuna di queste tipologie applicative funziona con uno specifico protocollo di comunicazione e richiede
elementi software differenti.
La tipologia che ci interessa approfondire qui è quella relativa al mondo del Web.
In quest'ambito è possibile identificare i seguenti componenti software:

 - Web Server:
È un programma che si occupa di inviare risorse al client. 
Queste possono essere documenti HTML, immagini, filmati e così via.
Una chiamata AJAX invoca il web server per ottenere i dati.

 - Applicazione web:
Sullo stesso computer che ospita il Web Server viene installato anche il software che implementa il sito web
o l'applicazione web che dovrà essere utilizzata dall'utente.
Si tratta di un insieme di file HTML, fogli di stile CSS, programmi JavaScript e altri elementi, come filmati Flash e altre risorse.
Spesso alcuni di questi contenuti sono generati dinamicamente da elementi di software complessi, che sfruttano
un database per operare elaborazioni e produrre un risultato da sottoporre all'utente.
In questo caso le tecnologie utilizzate possono essere PHP, JSP, ASP e altre.
Solitamente, le risposte alle richieste AJAX vengono prodotte a partire da dati provenienti dal database.

 - Browser:
II browser è il software che l'utente usa per interagire con il sito o l'applicazione web.



2).TCP e IP
La comunicazione tra server web e browser si basa sui protocolli TCP/IP (TCP è l'acronimo di Transmission Control
Protocol, mentre IP sta per Internet Protocol).
Si tratta di una comunicazione punto-a-punto con la quale viene stabilito un canale di comunicazione tra due computer.
 
Ogni scheda di rete presente nel computer è in grado di stabilire una connessione con un altro computer connesso
in rete attraverso una porta TCP/IP (detta anche socket), identificata da un numero, che può andare da 0 a 65535 compresi.

La porta è un concetto virtuale: il fatto di suddividere la comunicazione di rete in porte consente di
organizzare meglio l'utilizzo applicativo.
Sul computer sono attivi processi che implementano uno o più protocolli specifici.

Un esempio molto noto di server è il web server, che è l'applicazione che viene utilizzata per servire ai browser
le pagine web quando navighiamo in rete.
II protocollo di comunicazione tra web server e browser è noto come protocollo HTTP.
Il web server è in ascolto su una porta specifica in attesa che i client si connettano.

Altri esempi di protocolli di comunicazione sono quelli che sottintendono alla gestione della posta elettronica,
la messaggistica istantanea o il peer-to-peer.
I protocolli di comunicazione appena elencati specificano come devono essere formattati i dati che vengono
inviati in rete e cosa devono contenere, ma sono indipendenti dal numero di porta TCP/IP utilizzato.
 
Nonostante questo, per convenzione i protocolli solitamente si associano a specifiche porte.
Per esempio, il protocollo HTTP generalmente comunica sulla porta 80, ma questo non è obbligatorio, è solo convenzionale.
L'utilizzo di porte diverse e specifiche per i diversi protocolli permette di comunicare in modo contemporaneo
con uno o più server tramite applicazioni diverse.
Per esempio, questo avviene quando si naviga su Internet, intanto si scarica la posta elettronica, mentre
magari si stanno condividendo dei file tramite peer-to-peer e si sta chattando con MSN.
 
Tutte queste applicazioni utilizzano porte e protocolli diversi e girano in contemporanea sul computer locale,
che si connette a server diversi.
Uno stesso server potrebbe avere in esecuzione più processi server, per gestire più protocolli contemporaneamente.
Sebbene sia possibile stabilire una comunicazione con un protocollo specifico su una qualsiasi porta, ciascuno
di questi ha una porta predefinita, definita da un organismo internazionale (ZANA - http://www.iana.org/).



3).IL PROTOCOLLO HTTP
Il protocollo HTTP (HyperTextTransfer Protocol) è molto semplice e basato sullo scambio di dati testuali.
Il client invia una richiesta al server, che la interpreta e fornisce una risposta, restituendo anche un codice 
di stato che può indicare un eventuale errore. Esistono diverse tipologie di richieste;
queste possono avere o non avere parametri.

Caratteristiche
La semplicità del protocollo HTTP è stata un elemento fondamentale per l'affermazione e per il successo del Web.
Sono tre gli elementi essenziali che lo caratterizzano.

 1. È privo del concetto di stato. Questo significa che il server non è in grado di mettere in relazione
    una richiesta con le precedenti. Anche se queste provengono dallo stesso client, per il server
    potrebbero arrivare da origini diverse.
    
 2. Riguardando una comunicazione di rete, non è possibile fornire all'utente un feedback immediato,
    tipico invece delle applicazioni desktop.
    Un programma che gira in locale sul computer è in grado di comunicare quasi istantaneamente
    con la memoria e il disco;
    un'applicazione web, basata su un protocollo di rete che impiega il modello richiesta-risposta, non è
    in grado di essere così immediata.
    In quest'ambito la soluzione è quella di utilizzare AJAX, che può limitare l'impatto sull'interfaccia utente
    imposto dall'uso di protocolli e tecnologie sostanzialmente nate per una semplice esposizione di informazioni
    e non pensate come piattaforma sulla quale realizzare applicazioni.
    
 3. Il server e il client sono macchine diverse. Alcune operazioni svolte dall'utente con il browser non sono
    intercettate dal server o non possono essere definite con precisione secondo l'intenzione dell'utente.
    Per esempio, il server non è in grado di capire la differenza tra informazioni ricevute a seguito del clic
    su un pulsante di invio e quelle ricevute facendo Indietro e poi Avanti dopo l'invio di un modulo.
    Questo aspetto è dovuto alla natura del protocollo HTTP e dei browser.
    È per questo motivo che alcuni di questi, come Safari o Firefox, richiedono una precisa conferma per
    un'azione di reinvio di dati già spediti al server.
    
Tutte queste problematiche devono essere chiare allo sviluppatore che intende utilizzare AJAX nel proprio sito o
applicazione web, in quanto, quando si intraprende questa strada, è indispensabile avere un componente lato server
intelligente, in grado di eseguire elaborazioni e controlli.
Senza di questo non è possibile implementare applicazioni AJAX.



          A. Un esempio di RICHIESTA
Cosa succede quando si richiede la visualizzazione di una pagina web? 
Il sistema esegue una serie di passaggi, che qui vengono riassunti brevemente:

4. L'utente richiede la visualizzazione di una pagina al browser, specificandone l'indirizzo nella
   relativa barra del browser, per esempio: http://www.esempio.it/index.php
    
5. Il browser formula una richiesta per ottenere la risorsa richiesta dall'utente
   (in questo caso è il file index. html) e la invia per mezzo del protocollo HTTP al server www. esempio.it
   Quindi attende una risposta.
    
6. II server identifica la risorsa richiesta e la restituisce al client.
 
7. Il browser riceve il file e lo analizza, individuando gli altri elementi presenti nella pagina, come le
   innmagini, i fogli stile CSS, i file JavaScript e così via.
   Invia quindi una richiesta al server per ciascun elemento presente nella pagina richiesta.
    
8. Quando il browser ha tutti gli elementi necessari, produce una rappresentazione grafica della pagina,
   che presenta a ll'utente.
   Talvolta la visualizzazione della pagina (rendering) avviene in modo parziale, man mano che gli elementi
   necessari arrivano al client.
   
Quando non specificato diversamente, il protocollo HTTP utilizza implicitamente la porta 80.
Il numero di porta si specifica immediatamente a seguito del nome del server, da cui è separata con il simbolo
dei due punti.
L'indirizzo dell'esempio è quindi equivalente al seguente: http://www.esempio.it:80/index html.

Questo significa che il browser contatta il server www.esempio.it,
apre una socket sulla porta 80 e invia una richiesta HTTP per recuperare la risorsa /index.php
 
La richiesta è un blocco di testo che in questo caso vede nella prima linea il seguente contenuto:

  GET /index.php HTTP/1.1
La parola chiave GET indica al server che si sta richiedendo una risorsa. 
Questa è sicuramente una delle parole chiave utilizzate più diffusamente ed è quella predefinita quando
la richiesta parte dalla digitazione di un indirizzo nel browser web.
A seguire c'è ('identificativo della risorsa richiesta e successivamente compare la versione del protocollo,
in questo caso è la 1.1

La singola riga di testo sopra riportata non è l'unico elemento che compone una richiesta HTTP:
a seguire, infatti, ci sono una serie di informazioni aggiuntive, che descrivono il contesto entro cui è stata
formulata la richiesta. Sono dette intestazioni (headers).
Per esempio, una richiesta completa di tipo GET potrebbe avere il seguente aspetto:

      GET /index.php HTTP/1.1 
      Host: www.esempio.it
      User-Agent: Mozilla/9.0 (Windows NT; it-IT;
      Accept: image/gif, image/jpeg, image/pjpeg, image/png, */*
      Accept-Language: it
      Accept-Charset: iso-8859-1, *, utf-8

Le singole intestazioni contengono informazioni utili a proposito del client o della richiesta che il server
può utilizzare per svolgere meglio il proprio lavoro.
La quantità e il contenuto delle intestazioni varia in funzione del browser.
Nel caso dell'esempio, le intestazioni hanno il significato seguente:

 - Host
    Indica il server a cui è stata indirizzata la richiesta.
    Alcuni computer possono avere più nomi, quindi questa indicazione consente di capire a quale
    server logico è stata indirizzata la richiesta e permette di agire di conseguenza.
   
 - User -Agent
    Contiene una stringa descrittiva del client che ha inoltrato la richiesta, che solitamente è un
    browser web, ma potrebbe anche non esserlo. Se lo fosse, da questa stringa il server potrebbe 
    essere in grado di determinarne il produttore, differenziando per esempio Internet Explorer da
    Firefox o Safari, distinguendo anche per piattaforma.
    In questo caso il server potrebbe essere in grado di restituire contenuto ottimizzato per uno
    specifico browser o piattaforma. Da questa stringa è possibile inoltre capire se il dispositivo 
    che ha inviato la richiesta è un browser per PC oppure per PDA o altri dispositivi.
    Per esempio, si potrebbero intercettare le richieste inviate da un iPhone Apple e restituire
    contenuti ottimizzati e ritagliati in modo specifico per questo determinato dispositivo.
    
 - Accept
    Indica il formato di immagini supportato dal browser; quando il server restituisce la risposta,
    dovrebbe considerare queste informazioni e restituire solo risorse nel formato supportato dal client 
    che ha inviato la richiesta.
    
 - Accept-Language
    Indica la lingua configurata nel client. Nel caso dell'esempio, chi ha formulato la richiesta sta
    utilizzando software localizzato in italiano.
    In funzione del linguaggio il server dovrebbe essere in grado di restituire contenuto localizzato
    per la lingua richiesta.
   
 - Accept-Charset
    Questa intestazione indica l'insieme di caratteri supportato dal client che ha formulato la richiesta.
    Il charset è un concetto molto tecnico che riguarda la codifica di alfabeti non latini
    (paesi dell'est, cinese, russo, arabo e altri).
   


          B. Un esempio di RISPOSTA
Alla ricezione di una richiesta, il server avvia i processi necessari a recuperare il contenuto collegato
alla risorsa richiesta e prepara una risposta da restituire al client.

Anche questa è composta da un blocco di dati testuale, strutturato in modo analogo a una richiesta.
Una risposta plausibile per la richiesta sopra illustrata è la seguente:

      HTTP/1.1 200 OK
      Last-Modified: Sun, 16 Gen 2013. 13:00:00 GMT

      Date: Mon, 17 Gen 2013 17:13:00 GMT
      Status : 200
      Content -Type: text/html
      Content -Length: 100
      <html>
        <head>
          <title>Titolo della pagina</title>
        </head>
        <body>
          <h1>Intestazione</h1>
        </body>
      </html>

La struttura della risposta è speculare a quella di una richiesta: è composta da una riga di stato, da un
insieme di intestazioni e da un corpo (anche le richieste possono avere un corpo, come si vedrà in seguito
in merito al metodo POST: per il metodo GET il corpo non è previsto).

La prima riga inizia con il nome del protocollo, a cui segue il codice di stato e una breve descrizione del
suo significato.
Questa parte è fondamentale per le applicazioni AJAX, in quanto il codice di ritorno è indispensabile per
poter individuare eventuali errori di comunicazione e comportarsi di conseguenza.
In questo caso il codice di stato è 200: significa che il server è stato in grado di recuperare la risorsa
richiesta senza problemi.
La descrizione dello stato infatti recita un tranquillizzante OK.
Le intestazioni di risposta che si vedono nel listato hanno il seguente significato:

 - Last-Modified
    Contiene la data di ultima modifica della risorsa richiesta;
    in questo caso è banalmente il momento di ultima modifica del file index html. Questa informazione è
    importante per l'implementazione di cache locali o strategie diverse di richiesta del file.
 
 - Date
    Indica la data della richiesta.
    
 - Status
    Ripete il codice di stato HTTP indicato nella linea di stato.
    
 - Content-Type
    Indica il tipo di dato contenuto nella risposta.
    In questo caso text/html indica che contiene un documento HTML. 
    Se ci fosse stato invece un documento XML il tipo sarebbe stato text/xml, e così via.
    I tipi di contenuto, detti anche tipi MIME (Multipurpose Internet Mail Extensions),
    sono standardizzata da IANA e possono essere consultati all'indirizzo
    http://www.iana.org/assignments/media-types/.
   
 - Content-Length
    Contiene la dimensione della risposta. Questa informazione consente al browser di ottimizzare
    l'allocazione di memoria e semplificare le fasi di lettura della risposta.
    Nell'esempio, la risposta è composta da 100 byte, che è proprio la dimensione della parte testuale che segue.
    
Dopo una riga vuota è presente il corpo della risposta, che in questo caso è un semplice documento HTML:

  <html>
    <head>
      <title>Titolo della pagina</title>
    </head>
    <body>
      <h1>Intestazione</h1>
    </body>
  </html>




4).CODICI dello STATO
L'esempio appena descritto ha come codice di stato il valore 200, che indica il buon esito della richiesta.
Ma non sempre va tutto bene; sono infatti diverse le problematiche che si possono presentare.
Sebbene dal punto di vista logico il protocollo HTTP sia alquanto semplice, in realtà quando si entra nel
dettaglio dei particolari non è affatto banale. II protocollo prevede diversi codici di stato,
suddivisi in gruppi.
Ciascuno di questi è identificato da un numero, che è presente come prima cifra del codice di errore.
I gruppi sono i seguenti:

 - Informativi: 1xx
    Contengono informazioni che il client può utilizzare per meglio regolarsi.
    
 - Successo: 2xx
    Raggruppano tutti i codici che fanno riferimento a un esito positivo.
    
 - Redirezione: 3xx
    II client deve intraprendere operazioni aggiuntive per completare correttamente la richiesta.
    
 - Errore client: 4xx
    La richiesta è errata o non può essere soddisfatta.

 - Errore server: 5xx
    La richiesta sembra valida ma un problema sul server impedisce che venga soddisfatta.
    
I codici di errore previsti dal protocollo HTTP 1.1 sono raccolti nella seguente Tabella:

          Tabella Codici di errore del protocollo HTTP 1.1

Codice                       Descrizione
  100  Continua.
  101  Scambio protocolli.
  102  Elaborazione (WebDAV).
  200  OK.
  201  Creata (la risorsa richiesta è stata creata).
  202  Accettata (la richiesta è stata accettata ma sarà elaborata in seguito).
  203  Informazione non autoritativa.
  204  Nessun contenuto (da ritornare).
  205  Reimpostazione contenuto.
  206  Contenuto parziale (download parziali e quindi la loro sospensione e ripresa in un secondo momento).
  207  Multi stato (WebDAV).
  300  Scelte multiple (l'URL richiesto potrebbe portare a risorse differenti, video a diversa risoluzione).
  301  Spostato in modo permanente (questo URL non è più valido).
  302  Trovato (trattato dai server/browser come 301 o 303).
  303  Altro (la risorsa richiesta è disponibile sotto un altro URL).
  304  Non modificata (la risorsa non è stata aggiornata dopo l'ultimo download).
  305  Utilizzare proxy.
  306  Cambiare proxy (in disuso).
  307  Deviazione temporanea (sebbene ora la risorsa debba essere richiesta al nuovo URL.
  400  Richiesta errata (per sintassi scorretta o altri problemi).
  401  Non autorizzata (la risorsa è protetta da autenticazione, che non è stata eseguita con successo).
  402  Pagamento richiesto (in disuso).
  403  Proibito (la risorsa è corretta, ma ne è proibito l'accesso).
  404  Non trovata.
  405  Metodo non consentito (utilizzato POST al posto di GET o viceversa).
  406  Non accettabile.
  407  Richiesta autenticazione proxy.
  408  Richiesta in timeout.
  409  Conflitto.
  410  Andata (per sempre, solitamente viene invece utilizzato 404).
  411  Lunghezza richiesta.
  412  Precondizione fallita.
  413  Entità di richiesta troppo grande.
  414  URL di richiesta troppo lungo.
  415  Tipo di media non supportato.
  416  Intervallo di richiesta non soddisfabile.
  417  Aspettative fallite.
  422  Entità non elaborabile (WebDAV).
  423  Bloccata (WebDAV).
  424  Dipendenza fallita (WebDAV).
  425  Collezione non ordinata (WebDAV).
  426  Aggiornamento richiesto.
  500  Errore interno del server (errore generico).
  501  Non implementato.
  502  Gateway errato.
  503  Servizio non disponibile.
  504  Timeout gateway.
  505  Versione HTTP non supportata.
  506  Anche la variante dovrebbe negoziare (errore di configurazione interno).
  507  Spazio non sufficiente (WebDAV).
  509  Limite di banda superata.
  510  Estensione non supportata.

  


5).PARAMETRI
Le richieste, oltre il nome della risorsa da recuperare, possono contenere parametri. Questi possono essere
utilizzati per meglio indicare al server ciò che si desidera ottenere.
Per esempio,si consideri un sito di e-commerce in cui, la risorsa visualizza_fattura.php potrebbe richiedere
di specificare ('identificativo della fattura da visualizzare e il codice dell'utente.
II protocollo HTTP dispone dei meccanismi necessari per passare queste informazioni dal client al server,
che li potrà utilizzare per restituire, nel corpo della risposta, le informazioni adeguate.
La modalità di passaggio dei parametri si differenzia in funzione del tipo di richiesta.

    La risorsa qui presa come esempio non ha come estensione il solito html, ma php.
    Questo identifica le pagine scritte con il linguaggio di programmazione PHP,
    una tecnologia che consente di scrivere in modo semplice del codice server in grado
    di eseguire l'elaborazioni necessarie, in questo caso, per ottenere i dati di 
    quella specifica fattura da un database.


A. Richiesta di tipo GET
Nel caso di una richiesta di tipo GET i parametri sono specificati come parte dell'URL di richiesta.
Ipotizzando che il codice della fattura debba essere passato a visualizza_fattura.php
nel parametro id e il codice cliente nel parametro customer_id, una richiesta valida potrebbe 
essere la seguente:

  visualizza_fattura.php?id=1827812&customer_id=83298
Come si nota, i parametri sono indicati dopo un punto di domanda (?), che li separa dal nome della risorsa richiesta.
Ciascun parametro è composto da una coppia chiave/valore, separata dal segno uguale (=).
Decisamente un approccio molto leggibile. Ogni parametro è separato dall'altro da una & (e commerciale).

Si noti che il valore dei parametri è passato in formato codificato URL (URL-encoded).
Questo tipo di codifica serve a rappresentare caratteri speciali che potrebbero causare problemi al protocollo testuale HTTP.
Questi vengono quindi sostituiti con sequenze numeriche che hanno come prefisso il simbolo di percentuale.
II carattere spazio, per esempio, viene sostituito da %20.



B. Richiesta di tipo POST
La parola chiave POST rappresenta un'alternativa molto spesso utilizzata al posto dell'onnipresente GET.
Se quest'ultima sottintende al semplice recupero di una risorsa, l'uso di POST è invece relativo a una richiesta
di elaborazione che il client rivolge al server.
I dati inviati tramite POST, dal punto di vista logico, sono utilizzati come parametri di ingresso a un algoritmo,
che potrà poi comportare anche la loro memorizzazione, insieme al risultato dell'elaborazione, in una qualche base dati.
È possibile elaborare anche i parametri di una GET, mail significato logico delle due operazioni è differente:

   con GET si ottiene una risorsa meglio definita dal contenuto dei parametri;
   
   con POST si inviano dei dati al server per eseguire un'elaborazione.

È quel lo che succede tutte le volte che si scrivono dati in un modulo presente in una pagina web e si fa clic sul 
pulsante di invio. I dati presenti nelle caselle di testo, selezionati nelle caselle combinate o scelti con pulsanti
radio o di spunta vengono codificati come sopra descritto e inviati al server nel corpo della richiesta.

Per esempio, si consideri un modulo di ricerca di un messaggio di posta in un'interfaccia online.
La richiesta che parte dal browser potrebbe essere simile alla seguente:

     POST/find.php HTTP/1.1 
     Host: www.esempio.it
     User-Agent: Mozilla/9.0 (Windows NT; it-IT;
     Accept: image/gif, image/jpeg, image/pjpeg, image/png, */*
     Accept-Language: it
     Accept-Charset: iso-8859-1, *, utf-8 
     query=Testo%20da%20trovare&mode=search

Come si nota osservando il listato, al posto della parola chiave GET c'è POST e, dopo le intestazioni,
è presente un corpo, che contiene la stringa di richiesta, opportunamente codificata.


6).ALTRI METODI
Oltre a GET e POST nel protocollo HTTP ci sono diversi altri metodi:

 - OPTIONS
    Consente di ottenere dal server l'elenco dei metodi da esso supportati.
    
 - HEAD
    Ritorna una risposta costituita come una normale risposta a una GET, ma senza il corpo della risposta;
    consente di verificare la validità di un URL o l'ultima data di modifica di una risorsa.
    
 - PUT
    Utilizzato per memorizzare il corpo del messaggio sul server utilizzando come chiave l'identificativo
    della richiesta.
    
 - DELETE
    Cancella dal server i dati associati al l'identificativo di richie sta passato.
    
 - TRACE
    Consente di diagnosticare eventuali problemi di comunicazione tra client e server. Non fa altro che
    restituire la richiesta ricevuta nel corpo della risposta.