Recording of learning (Session life cycle)



Session life cycle
1. Generate
The session exists on the server side and is typically placed in the server's memory. When a user accesses the server for the first time, the creation is established. It is not created when accessing a static resource such as HTML, image, etc, when it is accessed by a JSP, servlet, etc., and can be called request.getsession (true) to force the session to be generated.
2. Failure
--1--
The server clears the session two times before and after the specified life cycle.
--2--
Call the session's invalidate () method and the session will be cleared.
3, the requirements of the browser:
Although the session is saved on the server and is transparent to the client, it still needs the support of the client browser for its normal operation. This is because the session needs to use a cookie as the identification mark. The HTTP protocol is stateless, and the session cannot determine whether it is the same client based on an HTTP connection, so the server sends a cookie named Jsessionid to the client browser. Its value is the ID of the session (that is, the return value of Httpsession.getid ()). The session is based on the cookie to identify whether it is the same user. The cookie is automatically generated by the server, and its MaxAge property is typically-1, which means that only the current browser is valid, and the browser windows are not shared, and the browser is disabled. Therefore, when the server is accessed by two browser windows of the same machine, two different sessions are generated. However, new windows that are opened by links, scripts, and so on in the browser window (that is, not by double-clicking on Windows that are open by desktop browser icons). Such sub-Windows share a parent window's cookie, so a session is shared.
Note: The newly opened browser window will generate a new session, except for the child window. The child window will share the session of the parent window. For example, when you right-click on a link and select Open in New window in the popup shortcut menu, the child window can access the session of the parent window.

What to do if the client browser disables the cookie feature or does not support cookies. For example, most mobile browsers do not support cookies. The Java Web provides another solution: URL-Address rewriting. URL address Rewriting is a solution that does not support cookies for clients. The principle of URL address rewriting is to rewrite the ID information of the user session to the URL address. The server is able to parse the rewritten URL to get the session ID. This allows you to use the session to record user status even if the client does not support cookies. The HttpServletResponse class provides a encodeurl (String URL) implementation for URL address rewriting, which automatically determines whether the client supports cookies. If the client supports cookies, the URL is output intact. If the client does not support cookies, the ID of the user session is 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, no cookie will be brought with the first request (because there is no cookie to carry), and the address after the URL address is rewritten is still jsessionid. The server has already written a cookie in the browser when the second visit is made, so the address in the URL address rewrite will not be jsessionid.