(1)
This is an insurance measure
because the session requires cookie support by default,
but some client browsers
need to specify the session ID on the server in the URL when the cookie is turned off, that is, 5F4771183629C9834F8382E23BE13C4C
uses a method (forgot the method). Name) You can get this thing by processing the URL string.
This method will determine whether your browser has enabled cookies. If he thinks it should be added, he will add it
(2)
Link 1: wapbrowse.jsp?curAlbumID=9;
Link 2: wapbrowse.jsp;jsessionid=5AC6268DD8D4D5D1FDF5D41E9F2FD960?curAlbumID=9;
these two links are copied from the source generated when the simulator is running, both of which point to wapbrowse.jsp, link 1 does not contain jsessionid, so it is in wapbrowse The variable in .jsp is null, open wapbrowse.jsp through link 2, you can access the session variable normally
(3)
URL rewriting function, a function set to prevent some users from banning cookies and unable to use session. The long string after jsessionid is The ID number of the session on your server, so that you can use the session without cookie.
(4)
http itself has no session and cannot track the client's information.
In order to implement sessions, there must be browser support. Browsers can use cookies to store sessions, which is the most common practice.
However, if I write a browser that fully complies with the http protocol, but does not cooperate with the session requirements of the server, the server cannot generate a session.
Fortunately, all current browsers support session requirements. Even if the cookie is turned off, the browser will pass the sessionid to the server. This id is stored in the browser's memory space, not in the hard disk cookie.
(5)
sessionid is placed on the browser side as a temporary cookie.
The specific information of the session is placed on the server side.
Every time a browser makes a request, it will identify itself with the sessionid in the http header.
Now that you're using Struts, and JSTL by the way,
here's a very useful tag:
Listing 12. Action syntax
var="name" scope="scope">
...
URL rewriting is performed automatically by actions. If the JSP container detects a cookie that stores the ID of the user's current session, then no rewriting is necessary. However, if no such cookie exists, all URLs generated are rewritten to encode the session ID. Note: URL rewriting to include this identity will stop if the appropriate cookie is present on subsequent requests.
Reference: http://www-900.ibm.com/developerWorks/cn/java/j-jstl0318/index.shtml
(6)
Method 1: Follow the servlet/jsp file name in the url and add ;jsessionid=sessionId, where sessionId is obtained by HttpSession.getId(), such as http://localhost:8080/aaa/bbb.jsp;jsessionid=saldjfsdflsaeir234?para=1 ¶2=2
Method 2: Save a session manager HashMap:sessionId---sessionRef in application(ServletContext), so that it can be called in all servlets/jsp, which needs to pass sessionId as a parameter in the url, such as http: //localhost:8080/aaa/bbb.jsp?sessionId=saldjfsdflsaeir234?para=1¶2=2, get it with request.getParameter("sessionId") on the server side
(7) The
session is saved on the server side. The server finds the corresponding session according to the session_id in the url request.
Taking a bbs as an example, the website needs to obtain the user's information according to each request url. If the cookie method is used, the user information is all stored in the cookie, which may be unsafe; if the session method is used, the user information can be stored in the server. At the end, as long as the server gets the session_id from the http request, it can get the user information stored in the session, so the security is relatively high. The way the session is represented in the server depends on the server, it may be written to a temporary file, or it may be placed directly in memory.
There are two ways for the server to get the session_id from the http request: cookie and url rewriting. If the client enables cookies, the session_id can be stored in the cookie; if the cookie is disabled, use the url rewriting method, add the .jsessionid=xxxxx parameter part to the url, and the server will try to get the .jsessionid parameter from the url as session_id.
( 8)
Cookie is the text format data stored in the client, session is the unique identifier established by the server for the client when the client logs in to the application, and the client's data such as user account can be saved in the session.
General cookies can be used to save your login account and password. When you log in to the application service, it is automatically added to the login interface or directly sent to the server for login. This is your login information that you often see on the forum. Implementation of the option to save one year
(9)
In the http message format, the cookie and session are in the same package location.
If ie finds that the package contains cookie/session information, it will be based on the security level. Decide whether to save the relevant information, for example, if the security mechanism allows the use of cookies, then IE will save the cookie information in a temporary file, and each time the server file is requested, the received session information will be added to the request message. , this is the principle of session saving information. If the security mechanism does not allow the use of cookies, although IE has received the cookie and session information, the cookie information will not be written to the temporary file, and when IE requests the server file again, it will not store the received session information. When added to the request message, the server cannot know the session information.
jessionid通过这样的方式来从客户端传递到服务器端,从而来标识session。
注意一点，jsessionid跟一般的url参数传递方式是不同的，不是作为参数跟在"？"后面，而是紧跟在url后面用"；"来分隔。
这样在用户禁用cookie的时候我们也可以传递jsessionid来使用session了，
只不过需要每次都把jseesionid作为参数跟在url后面传递。
那这样岂不是很麻烦，每次请求一个url都要判断cookie是否可用，
如果禁用了cookie，还要从url里解析出jsessionid，然后跟在处理完后转到的url后面，以保持jsessionid的传递。
这些问题sun当然已经帮我们想到了。
所以提供了2个方法来使事情变得简单：response.encodeURL()和response.encodeRedirectURL()。
这2个方法会判断cookie是否可用，如果禁用了会解析出url中的jsessionid，并连接到指定的url后面，如果没有找到jessionid会自动帮我们生成一个。
至于为什么要有2个方法？这2个方法有什么不同？google了一下，说是这2个方法在判断是否要包含jsessionid的逻辑上会稍有不同。
在调用HttpServletResponse.sendRedirect前，应该先调用encodeRedirectURL()方法，否则可能会丢失Sesssion信息。
这2个方法的使用方法如：response.sendRedirect(response.encodeURL("/myapp/input.jsp"));。
如果cookie没有禁用，我们在浏览器地址栏中看到的地址是这样的：/myapp/input.jsp，如果禁用了cookie，我们会看到：/myapp/input.jsp;jsessionid=73E6B2470C91A433A6698C7681FD44F4。
所以，我们在写web应用的时候，为了保险起见，应该在程序里的每一个跳转url上都使用这2个方法，来保证session的可用性。
以前很少遇到这样的问题，今天又涨见识了...