Tomcat session detailed _web container

Deep into the Tomcat source analysis session is what!

What a session is.

As we all know, the HTTP protocol itself is stateless (stateless), which is sufficient and unaffected for some simple page displays. And for the increasingly complex dynamic pages, applications, all kinds of need to login authentication scenes, it is powerless. Think of a logged in user is still a prompt login, what will be the feeling.

Therefore, most applications that need to maintain state must be consistent between client and server interaction states. For multiple requests made by the browser, based on the HTTP protocol only, it is not possible to identify whether the request is for the same user. To maintain client-server interaction, you can take a number of strategies, such as:

Cookies

Hide Form form Field

Session

Url

Ssl

This article will delve into the Tomcat source to analyze how the session is used internally in this most common servlet container to keep the client in line with the server state.

As a Web application developer, we've all heard and even learned about the word session and some of the concepts behind it.

Session, spoken in Chinese, is used to maintain state when interacting between two devices. Therefore, at least one party in the session needs to save the state of the session.

In the servlet specification, the session object is represented by the HttpSession interface, which succinctly outlines its main role

Provides a way to identify a user across more than one page request or

Visit to a Web site and to store information about that user.

The servlet container uses this interface to create a sessions between an HTTP

Client and an HTTP server. The session persists to a specified time period,

Across more than one connection or page request from the user. A session

Usually corresponds to one user.

And Tomcat inside is through standardsession implement HttpSession this interface, internal unified use Standardsession to deal with.

When the application is first requested, it is created if a session is required. It is not used directly in the servlet in general. If you are requesting a JSP file, the default implicit object for the JSP is to include

Session, when the servlet file is generated, the internal equivalent contains the

Httpservletrequest.getsession (True)

Therefore, the session object is created directly when the request is made.

The process of creating a session is roughly the following:

Protected session Dogetsession (Boolean create) {

There cannot be a sessions if no context has been assigned yet

Context context = GetContext ();

if (context = = null) {

return (NULL);

}

Return the "session if it exists" and is valid

if (session!= null) &&!session.isvalid ()) {

session = NULL;

}

if (session!= null) {

return (session);

}

Return the requested sessions if it exists and is valid

Manager Manager = Context.getmanager ();

if (manager = = null) {

return (NULL); Sessions are not supported

}

if (Requestedsessionid!= null) {

try {

Session = Manager.findsession (Requestedsessionid);

catch (IOException e) {

session = NULL;

}

if (session!= null) &&!session.isvalid ()) {

session = NULL;

}

if (session!= null) {

Session.access ();

return (session);

}

}

Create a new session if requested and the response are not committed

if (!create) {

return (NULL);

}

if (response!= null

&& Context.getservletcontext ()

. Geteffectivesessiontrackingmodes ()

. Contains (Sessiontrackingmode.cookie)

&& response.getresponse (). iscommitted ()) {

throw New IllegalStateException (

Sm.getstring ("coyoterequest.sessioncreatecommitted"));

}

Attempt to reuse session ID if one is submitted in a cookie

Don't reuse the session ID if it's from URL, to prevent possible

Phishing attacks

Use the SSL session ID if one is present.

if (("/". Equals (Context.getsessioncookiepath ())

&& Isrequestedsessionidfromcookie ()) | | REQUESTEDSESSIONSSL) {

Session = Manager.createsession (Getrequestedsessionid ());

} else {

session = Manager.createsession (null);

}

Creating a new session cookie based in that session

if (Session!= NULL

&& Context.getservletcontext ()

. Geteffectivesessiontrackingmodes ()

. Contains (Sessiontrackingmode.cookie)) {

Cookie cookie =

Applicationsessioncookieconfig.createsessioncookie (

Context, session.getidinternal (), issecure ());

Response.addsessioncookieinternal (cookie);

}

if (session = null) {

return null;

}

Session.access ();

return session;

}

The overall process is basically to determine whether the session already exists, if it is not created. If so, use it directly.

At this point, you need to pay attention to two questions:

When the first request is made, how the session is generated and passed to the client

In subsequent requests, if the client's request is associated with a session that is already on the server side

In the code above, the procedure that determines that a session does not exist and is created is to call the CreateSession method directly, and to determine whether the session is completely newly created or restored if the SessionID is empty.

Public session createsession (String sessionId) {

if ((maxactivesessions >= 0) &&

(Getactivesessions () >= maxactivesessions)) {

rejectedsessions++;

throw New Toomanyactivesessionsexception (

Sm.getstring ("ManagerBase.createSession.ise"),

Maxactivesessions); Look, there's a strategy here.