Session life cycle

I didn’t pay much attention when I was studying before, but today I went back and studied the life cycle of Session carefully.

Session is stored on the server side. Generally, in order to prevent it from being stored in the server's memory (for high-speed access), the Session is created when the user accesses the server for the first time. It should be noted that only accessing JSP, Servlet, etc. A Session will be created only when the program is running. Only accessing static resources such as HTML and IMAGE will not create a Session. You can call request.getSession(true) to force a Session.

　When does the Session expire?

　1. The server will clear the Session that has been inactive for a long time from the server memory, and the Session will become invalid at this time. The default expiration time of Session in Tomcat is 20 minutes.

　2. Call the invalidate method of Session.

　Session browser requirements:

　　Although the Session is saved on the server and is transparent to the client, its normal operation still requires the support of the client browser. This is because Session needs to use Cookie as an identification mark. The HTTP protocol is stateless, and the Session cannot determine whether it is the same client based on the HTTP connection. Therefore, the server sends a Cookie named JSESSIONID to the client browser, and its value is the ID of the Session (that is, HttpSession.getId() The return value). Session uses this cookie to identify whether it is the same user.

This cookie is automatically generated by the server. Its maxAge attribute is generally -1, which means it is only valid within the current browser and is not shared between browser windows. It will become invalid when the browser is closed. Therefore, when two browser windows on the same machine access the server, two different Sessions will be generated. However, new windows opened by links, scripts, etc. within the browser window (that is, windows that are not opened by double-clicking the desktop browser icon, etc.) are excluded. This type of child window will share the cookie of the parent window and therefore share a Session.

　Note: A newly opened browser window will generate a new Session, except for child windows. Child windows will share the Session of the parent window. For example, when you right-click on a link and select "Open in new window" from the pop-up shortcut menu, the child window can access the Session of the parent window.

What should I do if the client browser disables the Cookie function or does not support Cookies? For example, the vast majority of mobile browsers do not support cookies. Java Web provides another solution: URL address rewriting.

URL address rewriting is a solution for clients that do not support cookies. The principle of URL address rewriting is to rewrite the user's Session ID information into the URL address. The server can parse the rewritten URL to obtain the Session ID. In this way, even if the client does not support cookies, Session can be used to record user status. The HttpServletResponse class provides encodeURL (String url) to implement URL address rewriting. This method will automatically determine whether the client supports cookies. If the client supports cookies, the URL will be output intact. If the client does not support cookies, the user's Session ID will be rewritten into the URL.

　Note: TOMCAT determines whether the client browser supports cookies based on whether the request contains cookies. Although the client may support cookies, since no cookies will be carried in the first request (because there are no cookies to carry), the rewritten URL address will still contain jsessionid. When accessing for the second time, the server has already written the cookie in the browser, so the URL address after rewriting will not contain jsessionid.

The above is the detailed content of Session life cycle. For more information, please follow other related articles on the PHP Chinese website!