Options de suivi des sessions
La prise en charge des sessions HTTP implique également le suivi des sessions. Effectuez le suivi de session à l'aide de l'un des trois éléments suivants : cookies, réécriture de l'URL ou informations SSL (Secure Sockets Layer).
Suivi de sessions à l'aide de cookies
Le suivi de sessions à l'aide de cookies est l'option par défaut. Aucune programmation spécifique n'est nécessaire pour réaliser le suivi de sessions à l'aide de cookies.
Suivi de sessions à l'aide de la réécriture des URL
Une application qui assure le suivi des sessions par la réécriture de l'URL doit obéir à certaines règles de programmation. Le développeur d'applications doit :
- Programmer des servlets pour le codage des URL
- Fournir un servlet ou un fichier JSP (JavaServer Pages) comme point d'entrée de l'application
L'utilisation de la réécriture des URL exige également que vous activiez la réécriture des URL dans l'utilitaire de gestion de session.
Programmation des servlets de session pour le codage des URL
Selon que le servlet renvoie les URL au navigateur ou qu'il les réachemine, ajoutez la méthode encodeURL ou la méthode encodeRedirectURL dans le code du servlet. Vous trouverez ci-après des exemples illustrant les éléments à remplacer dans le code actuel de votre servlet.
Réécriture des URL à renvoyer au navigateur
Soit l'instruction suivante :
out.println("<a href=\"/store/catalog\">catalog<a>");
Modifiez le servlet pour qu'il appelle la méthode encodeURL avant d'envoyer l'URL au flux de sortie :
out.println("<a href=\"""); out.println(response.encodeURL ("/store/catalog")); out.println("\">catalog</a>"");
Réécriture des URL à réacheminer
Soit l'instruction suivante :
response.sendRedirect ("http://myhost/store/catalog");
Modifiez le servlet pour qu'il appelle la méthode encodeRedirectURL avant d'envoyer l'URL au flux de sortie :
response.sendRedirect (response.encodeRedirectURL ("http://myhost/store/catalog"));
Les méthodes encodeURL et encodeRedirectURL font partie de l'objet HttpServletResponse. Ces appels servent à vérifier que la réécriture de l'URL est configurée avant le codage de l'URL. Si elle ne l'est pas, les appels renvoient l'URL d'origine.

- Dans la console d'administration, cliquez sur .
- Dans Propriétés supplémentaires, cliquez sur Propriétés personnalisées.
- Dans la page Propriétés personnalisées, cliquez sur Nouveau.
- Dans la page de paramètres, entrez la propriété à configurer dans la zone Nom et la valeur à lui associer dans la zone Valeur.
- Cliquez sur Valider ou sur OK.
- Cliquez sur Sauvegarder dans la barre des tâches de la console d'administration pour sauvegarder les modifications apportées à la configuration.
- Redémarrez le serveur.
Fourniture d'un servlet ou d'un fichier JSP comme point d'entrée
Le point d'entrée d'une application, tel que l'écran initial présenté, n'a peut-être pas besoin d'utiliser des sessions. Cependant, si un support de session est nécessaire pour l'application ou une partie de celle-ci (par exemple, un servlet), toutes les URL sont codées, une fois la session créée, pour transmettre l'ID de session au servlet (ou à un autre composant de l'application) concerné.
L'exemple suivant explique comment intégrer le code Java™ dans un fichier JSP :
<%
response.encodeURL ("/store/catalog");
%>
Suivi de session à l'aide des informations SSL (obsolète)

Aucune programmation spécifique n'est nécessaire pour réaliser le suivi de sessions à l'aide d'informations SSL (Secure Sockets Layer).
Pour utiliser les informations SSL comme mécanisme de suivi des sessions, sélectionnez l'option Activer le suivi SSL sur la page de propriétés de l'utilitaire de gestion de session. Dans la mesure où l'ID de la session SSL est négocié entre le navigateur Web et le serveur HTTP, cet ID ne peut pas survivre à une défaillance du serveur HTTP. En revanche, la défaillance d'un serveur d'applications n'affecte pas l'ID de la session SSL, si un serveur HTTP externe est présent entre WebSphere Application Server et le navigateur.
Le suivi des sessions à l'aide d'informations SSL n'est pris en charge que pour les serveurs Web IBM® HTTP Server et iPlanet. Vous pouvez contrôler la durée de vie d'un ID de session SSL en configurant des options sur le serveur Web. Par exemple, dans IBM HTTP Server, définissez la variable de configuration SSLV3TIMEOUT de sorte que l'ID de session SSL ait une durée de vie adéquate. Si ce délai est trop court, la session peut prendre fin avant terme. Par ailleurs, certains navigateurs Web appliquent leur propre temporisation à la durée de vie de l'ID de session SSL. Il est possible qu'ils n'autorisent pas l'ID de session SSL à survivre suffisamment longtemps pour qu'il puisse servir de mécanisme de suivi des sessions. Le serveur HTTP interne de WebSphere Application Server prend aussi en charge le suivi SSL.
Lorsque l'ID de session SSL est utilisé comme mécanisme de suivi de session dans un environnement cloné, utilisez des cookies ou la réécriture d'URL pour assurer le maintien de l'affinité de session. Le cookie ou l'URL réécrite contient les informations d'affinité de session qui permettent au serveur Web d'acheminer correctement une session vers le même serveur pour chaque demande.