Cycle de vie des sessions

Je n'y prêtais pas beaucoup d'attention lorsque j'étudiais auparavant, mais aujourd'hui, je suis revenu et j'ai étudié attentivement le cycle de vie de Session.

La Session est stockée côté serveur. Généralement, afin d'éviter qu'elle ne soit stockée dans la mémoire du serveur (pour un accès haut débit), la Session est créée lorsque l'utilisateur accède pour la première fois au serveur. time. Il convient de noter que l'accès uniquement à JSP, Servlet, etc. Une session ne sera créée que lorsque le programme est en cours d'exécution. Seul l'accès à des ressources statiques telles que HTML et IMAGE ne créera pas de session. getSession(true) pour forcer une session.

　Quand la Session expirera-t-elle ?

　1. Le serveur effacera la session qui est inactive depuis longtemps de la mémoire du serveur et la session deviendra invalide. Le délai d'expiration par défaut de la session dans Tomcat est de 20 minutes.

　 2. Appelez la méthode invalidate de Session.

Exigences du navigateur de session :

　　Bien que la Session soit enregistrée sur le serveur et soit transparente pour le client, son fonctionnement normal nécessite toujours le support du navigateur client. En effet, Session doit utiliser Cookie comme marque d'identification. Le protocole HTTP est sans état et la session ne peut pas déterminer s'il s'agit du même client sur la base de la connexion HTTP. Par conséquent, le serveur envoie un cookie nommé JSESSIONID au navigateur client et sa valeur est l'ID de la session (c'est-à-dire : HttpSession.getId() renvoie la valeur). Session utilise ce cookie pour identifier s'il s'agit du même utilisateur.

Ce cookie est généré automatiquement par le serveur. Son attribut maxAge est généralement -1, ce qui signifie qu'il n'est valide que dans le navigateur actuel et n'est pas partagé entre les fenêtres du navigateur. Il deviendra invalide à la fermeture du navigateur. . Par conséquent, lorsque deux fenêtres de navigateur sur la même machine accèdent au serveur, deux sessions différentes seront générées. Cependant, les nouvelles fenêtres ouvertes par des liens, des scripts, etc. dans la fenêtre du navigateur (c'est-à-dire les fenêtres non ouvertes en double-cliquant sur l'icône du navigateur du bureau, etc.) sont exclues. Ce type de fenêtre enfant partagera le cookie de la fenêtre parent, elle partagera donc une Session.

　Remarque : Une fenêtre de navigateur nouvellement ouverte générera une nouvelle session, à l'exception des fenêtres enfants. Les fenêtres enfants partageront la session de la fenêtre parent. Par exemple, lorsque vous cliquez avec le bouton droit sur un lien et sélectionnez « Ouvrir dans une nouvelle fenêtre » dans le menu contextuel contextuel, la fenêtre enfant peut accéder à la session de la fenêtre parent.

Que faire si le navigateur client désactive la fonction cookie ou ne prend pas en charge les cookies ? Par exemple, la grande majorité des navigateurs mobiles ne prennent pas en charge les cookies. Java Web propose une autre solution : la réécriture d'adresse URL.

La réécriture d'adresse URL est une solution pour les clients qui ne supportent pas les cookies. Le principe de la réécriture d'adresse URL est de réécrire les informations d'ID de session de l'utilisateur dans l'adresse URL. Le serveur peut analyser l'URL réécrite pour obtenir l'ID de session. De cette manière, même si le client ne prend pas en charge les cookies, la session peut être utilisée pour enregistrer le statut de l'utilisateur. La classe HttpServletResponse fournit encodeURL (String url) pour implémenter la réécriture d'adresse URL Cette méthode déterminera automatiquement si le client prend en charge les cookies. Si le client prend en charge les cookies, l'URL sera affichée intacte. Si le client ne prend pas en charge les cookies, l'ID de session de l'utilisateur sera réécrit dans l'URL.

　Remarque : TOMCAT détermine si le navigateur client prend en charge les cookies en fonction du fait que la demande contient ou non des cookies. Bien que le client puisse prendre en charge les cookies, puisqu'aucun cookie ne sera transporté lors de la première requête (car il n'y a pas de cookies à transporter), l'adresse URL réécrite contiendra toujours jsessionid. Lors du deuxième accès, le serveur a déjà écrit le cookie dans le navigateur, donc l'adresse URL après réécriture ne contiendra pas jsessionid.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!