La soluzione di mantentere i dati interamente sul client ha i problemi visti prima, soprattutto legati alla codifica e decodifica degli stessi. Siccome il negozio è composto in gran parte da codice che viene eseguito sul server contestualmente alle richieste, il passo logico successivo è quello di pensare che le informazioni di stato possano venir mantenute direttamente sul server.

Abbiamo detto che il protocollo HTTP non è in grado di "ricordare" i passi eseguiti in precedenza, ma le applicazioni basate su un Web Server possono comunque aggirare il problema mantenendo una propria memoria. Ovvero si può usare un blocco di dati associato ad una particolare sequenza di interazioni di un determinato utente del Web. Questo blocco dati viene comunemente chiamato SESSIONE.

Facciamo un esempio per capire di che cosa stiamo parlando: se un utente si collega al nostro negozio online, inizia una sequenza di richieste al Web Server, che hanno in comune il fatto di provenire dallo stesso utente (e quindi dallo stesso browser in esecuzione). Man mano che l'utente sceglie le merci e le deposita nel carrello della spesa, possiamo mantenere sul server (in memoria, su un file o in una tabella di database) le informazione sulle merci che ha scelto il nostro cliente.

Queste informazioni devono però essere legate ad uno specifico utente, perché possono essere attivi contemporaneamente più utenti che stanno "facendo la spesa". Le informazioni su quello che ha fatto l'utente possono essere mantenute sul server ma occorre un piccolo aiuto da parte del client. Ovvero il browser deve comunicare continuamente al server una informazione per identificare il particolare utente attivo, e distinguerlo dagli altri. Questa informazione viene detta session id.

In questo modo al client non è più richiesto di memorizzare l'intero blocco dati legato ad un particolare utente attivo. Occorre solamente che venga mantenuto lo stretto necessario per identificare il blocco dati associato all'utente. Il session id è generalmente una stringa alfanumerica generata automaticamente con criteri di unicità. Esso può essere codificato nell'output HTML, ma generalmente si preferisce utilizzare una caratteristica dei Web Browser detta "cookies".

Un cookie è una stringa che il server chiede al browser di memorizzare, e che viene riproposta automaticamente dal browser ad ogni successiva richiesta da parte del server allo stesso sito. I sistemi che supportano le sessioni (per esempio le stesse Java Server Pages), generano alla prima richiesta di un utente un cookie contenente un nuovo session id. Da questo momento un blocco dati associato a quel particolare utente, identificato dal cookie, viene mantenuto in memoria. Con le Java Server Pages, la gestione delle sessioni è completamente trasparente al programmatore, che può utilizzarle senza necessità di eseguire altre operazioni.

Le sessioni hanno lo svantaggio di richiedere un cookie, che per ragioni di privacy non tutti i browser sono predisposti ad utilizzare, e impegnano un certo spazio in memoria sul server. Entrambi i problemi sono da considerarsi minori, in quanto oramai sul Web moltissimi siti utilizzano i cookie (con moderazione), e i motori di Java Server Pages sono abbastanza intelligenti da utilizzare poca memoria per mantenerla. Inoltre esistono dei meccanismi che permettono di riciclare la memoria occupata. Infatti una sessione se rimane inutilizzata per un certo periodo di tempo (di solito 20 minuti) "scade" e viene eliminata.

Deve essere cura del programmatore ovviamente utilizzare la sessione per mantenere pochi dati. Per esempio non è molto efficiente utilizzarla per mantenere le immagini dei prodotti scelti nel catalogo: è invece più opportuno, qualora le immagini servissero più volte, effettuare una query al database per visualizzarle, oppure utilizzare altri meccanismi di caching su file. Come sempre bisogna fare dei compromessi tra velocità di esecuzione e spazio utilizzato in memoria.