A tutorial – Servlet & JSP – seconda parte

Servlet and JSP

A tutorial: Servlet & JSP

Servlet & JSP: a tutorial è l’unico libro che ho trovato che parlasse esplicitamente di Servlet 3.0 e JSP 2.2, fin dalla copertina. All’interno del libro vengono spesso evidenziate le novità appunto apportate da questa versione delle due tecnologie in poi (attualmente non sono le ultime disponibili, con Java EE 6 sono state rilasciate le versioni 3.1 delle specifiche Servlet e 2.3 delle specifiche JavaServer Pages, ma non ho trovato libri più aggiornati).

Se desiderate approfondire l’argomento, è possibile comprare il libro in versione cartacea o
versione Kindle su Amazon (in lingua inglese). Personalmente ho acquistato la versione Kindle perchè, a differenza di altri libri dove la differenza è trascurabile, qua la versione kindle costa 1/4 dell’altra.

Sessioni e session management

Per le applicazioni web è importantissimo, data la natura stateless di HTTP (un server non sa nulla di default su ciò che è accaduto prima). Per ricordare informazioni quali se è stato effettuato o meno il login ad esempio, è necessario avere un qualche stato dell’applicazione. Questo si può ottenere attraverso 4 diverse soluzioni:

1. Url rewriting

Aggiungo un token alla query string, si usa in particolare se i token non devono essere portati appresso troppi url, ma uno soltanto o comunque pochi. Un possibile problema è dato dal fatto che comunque il token, essendo presente nella query string, è visibile a tutti, quindi non è adatto per trasmettere dati sensibili (posso codificarlo al limite, passando una stringa codificata che rappresenta il token della sessione).

Si implementa all’interno del Servlet con

request.getParameter(“Nome-parametro-queurystring”);

poi utilizzerò quel parametro per garantire uno stato alla mia web application

2. Hidden fields

Invece di aggiungere all’url i valori dello stato, li inserisco in campi hidden all’interno di un form HTML. Un vantaggio immediato è dato dalla quantità e dimensione degli stessi: la query string è limitata, mentre un form no.

Con l’url rewriting è accumulato dalla difficoltà nel portarsi dietro per molte pagine gli stessi parametri, diventa problematico.

3. Cookies

E’ il metodo preferibile quando devo portarmi dietro le informazioni sullo stato della web application per 3 o più pagine.

Un cookie è una coppia chiave/valore passato tra server e browser, all’interno degli HTTP headers, e posso avere al massimo 20 coppie per ogni sito.

Il problema principale di questo approccio è che l’utente può rifiutarlo nelle impostazioni del browser.

Dal punto di vista dell’impostazione in Java, si effettua con

Cookie c = new Cookie(“nome”,”valore”);
per poi utilizzare addCookie(c) sull’oggetto HttpServletResponse, inviando così il cookie al browser dell’utente, che lo riceve e poi lo rinvierà al server per ciascuna delle richiesta successive. Questa appena esposta è la procedura con la quale il cookie viene creato Server-Side. E’ anche possibile creare un cookie client-side utilizzando javascript, ma non è l’argomento di questo articolo.

Quando il browser effettua una richiesta alla mia applicazione Web costruita con un HttpServlet, posso leggere i cookie con il metodo getCookies() dell’oggetto HttpServletRequest. Purtroppo non c’è un get per nome, bisogna scorrerli tutti con un ciclo.

Per cancellare un cookie invece bisogna crearne uno nuovo con lo stesso nome e maxAge=0, cioè un cookie che scade istantaneamente e viene rimosso.

4. HttpSession Object

E’ il metodo più potente e versatile dei 4: il Servlet Container crea una HttpSession quando un utente visita il sito, e fa in modo che tale oggetto conservi lo stato dell’applicazione per tutta la durata della visita dell’utente al sito. Ogni sessione è legata ad un solo utente, ed è ottenibile programmaticamente con il metodo getSession() dell’oggetto HttpServletRequest.

All’interno della sessione posso salvare oggetti Java di qualsiasi tipo (serializzabili) con setAttribute (e getAttribute per richiamarlo), ma devo fare attenzione e non esagerare perchè comunque sono oggetti che vanno in memoria.

E’ presente anche un metodo getAttributes che me li restituisce tutti, con un oggetto da scorrere (interfaccia Enumeration, simile a Iterator ma senza remove()).

Rispetto ai cookie, con l’HttpSession non c’è nulla salvato localmente al client, tranne un cookie JSESSIONID che appunto serve a sapere a quale oggetto HttpSession associare un certo client. Ovviamente deve essere un valore non difficilmente prevedibile da parte di malintenzionati.

Se la sessione termina è buona norma distruggere HttpSession e liberare memoria, ma in alternativa scade da solo dopo un certo intervallo di inattività, impostabile dal programmatore (se impostato 0 significa che non scadrà mai).


Presto ci sarà un altro articolo con altri estratti e riassunti dal libro. Se non volete aspettare potete acquistare il libro versione cartacea o
versione Kindle su Amazon (in lingua inglese).

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *