The 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), Sessinon is created when the user accesses the server for the first time. It should be noted that the Session will only be created when accessing programs such as JSP and Servlet. Static resources such as HTML and IMAGE do not create a Session. You can call request.getSession(true) to force a Session to be generated.
When does the session expire?
1. The server will clear the session that has not been active for a long time from the server memory, and the session will be invalid at this time. The default expiration time of Session in Tomcat is 20 minutes.
2. Call the invalidate method of the Session.
Session requirements for browsers:
Although the session is stored 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 cookies as identification signs. The HTTP protocol is stateless, and the Session cannot determine whether it is the same client based on the HTTP connection, so the server sends a cookie named JSESSIONID to the client browser, whose value is the id of the Session (that is, HttpSession.getId() The return value). Session identifies whether it is the same user based on this cookie.
The cookie is automatically generated by the server, and its maxAge attribute is generally -1, which means that it is only valid in the current browser, and is not shared between browser windows, and it will be invalid when the browser is closed. Therefore, when two browser windows of the same machine access the server, two different sessions will be generated. The exception is new windows opened by links, scripts, etc. within a browser window (that is, windows that are not opened by double-clicking a desktop browser icon, etc.). Such child windows will share the cookie of the parent window, so they will share a Session.
Note: Newly opened browser windows will generate new sessions, except for child windows. The child window will share the Session of the parent window. For example, when you right-click on the link and select "Open in New Window" from the pop-up shortcut menu, the child window can access the parent window's Session.
What 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 offers 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 id information of the user session 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, the Session can be used to record the user state. 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 unchanged. If the client does not support cookies, the id of the user session 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 the first request will not carry any cookie (because there is no cookie to carry), the rewritten URL will still contain jsessionid. When accessing for the second time, the server has already written a cookie in the browser, so the rewritten URL will not have jsessionid in it.