Javaweb Learning Summary (7)-About session implementation: cookie and URL rewriting

The context discussed in this article is the Java EE servlet.
We all know that the session is implemented in two main ways : Cookie and URL rewriting, while cookies are preferred (default) , because cookies are enabled by the various modern browsers, but each browser also has settings that allow cookies to expire.
Because the browser starts the cookie feature by default, the cookie function is not normally canceled by the ordinary customer. Over time, when we write code, we will not care about the specific implementation of the session, in fact, there are a lot of noteworthy places, especially in the case of the user to cancel the cookie function.
A servlet session implementation and interface brief introduction:
The servlet specification enforces that the cookie name for the session is forced to jsessionid (which can be customized in Servlet 3.0), and the server generates a unique ID when the browser first requests it. and set this ID to a cookie named Jsessionid, and then through the reponse Addcookie, output to the browser side. In fact, we can either verify the contents by checking the server in debug mode, or use the HTTP protocol interceptor, because all the interfaces of the servlet are also based on the HTTP protocol.
Here's an explanation based on the HTTP protocol:

Browser Request for the first time:
Get/cxt/index.do http/1.1
...
Because it is the first request, there is no cookie to push to the server

The server returns:
http/1.1 OK
Set-cookie:jsessionid=3ef0aec40f2c6c30a0580844c0e6b2e8; Path=/cxt
...
<form name= "form" method= "POST" action= "/sas/login.do;jsessionid=3ef0aec40f2c6c30a0580844c0e6b2e8" >
...
</form>
...

Because the server does not find that the browser does not provide any cookies, the server does not know that the browser does not provide the reason for the cookie: The cookie function may be canceled, or it may be the first time access. So the server generates a cookie called Jsessionid, which uses Set-cookie to push the cookie to the browser; The server's servlet needs to encode the URL using the Reponse.encodeurl method when generating the HTML page, which is actually used to implement the URL rewriting function, because the browser may be canceling the cookie function without providing a cookie. To ensure that the next commit succeeds, the server must ensure that the URL generated to the browser is Jsessionid.

If the cookie function is not canceled, the browser browser requests the second time:
Post/cxt/login.do;jsessionid=3ef0aec40f2c6c30a0580844c0e6b2e8 http/1.1
Cookie:jsessionid=3ef0aec40f2c6c30a0580844c0e6b2e8;
...
The browser's next request is to use the HTTP cookie attribute to push the current domain cookie to the server to indicate its identity. This time, the server knows that the browser supports the cookie feature, and the servlet does not need to use Reponse.encodeurl to encode the URL.

If the browser cookie function is canceled, the browser request content is
Post/cxt/login.do?jsessionid=3ef0aec40f2c6c30a0580844c0e6b2e8 http/1.1
...

The server receives the above content, knowing that the request is the same session as the last request through the Jsessionid parameter after the URL

Session-related class interfaces:
Httpservletrequest.getsession
HttpSession
Httpservletresponse.encodeurl

Two encoding for URL rewriting note
1. Since the browser may be removed from the cookie function, the code we output to the client must support the URL rewriting function, in several cases to explain the
if the pure use of jsp/servlet to write, Then we have to manually encode each URL with Reponse.encodeurl, including the <a> href,form action, or another HREF
2. Using other web frameworks, it's best to use the output href function provided by the framework , otherwise there will be incredible results.
For example, with struts, if struts provides a single tag to implement Html:rewrite, such as The functionality of URL rewriting in struts also includes Html:link and html:form, such as 3. If you do not use any framework, you can use the URL rewriting feature provided by Jstl
Jstl provides a label to implement C:url, such as <c:url value= "Logout.do"/> This will also generate a URL with the Jsessionid property, depending on whether the browser supports cookies.

I believe that through the above summary, we have a more in-depth understanding of how to use session and cookie. Remember, in the implementation of the system with Jsp/servlet, try not to write their own <a> tags, it is best to use the system framework comes with tags to implement, otherwise the browser cancels the cookie function, the system does not support URL rewriting function.

Javaweb Learning Summary (7)-About session implementation: cookie and URL rewriting