Você está na página 1de 6

The Need

Maintain conversational state across multiple requests.


Use HttpSession
How does the container know who the client is?
The HTTP protocol uses stateless connections.The client browser makes a connection to
server,sends the request,gets the response, and closes the connection.
In other words the connection exists only for a single request/response.
From IP address : Nope coz to the container your IP address is the IP of router unless you
are on the local IP network.
User logged in and connection is secure : most good website design says dont force the
client to log in unless it really matters.
The answer is Session ID
Client and container exchange session id using cookie.
Somewhere in the service you ask for a session and everything happens on its own
HttpSession session = request.getSession();
It causes a cookie to be sent along with the response on first request.
Generating the cookie and session id, and getting the session id happens from the same
method.
Want to know if the session is new or not?
session.isNew()
Other way to get a session?
From a session event object
i.e from the event handling callback methods when you implement any of the 4 listeners
related to session.
Public void sessionCreated(HttpSessionEvent event){
HttpSession session = event.getSession();
}
What if you want a previous session rather than calling getSession and using isNew()?
HttpSession session = getSession(false);

If (session=null)
IF COOKIES ARE DISABLED CLIENT WILL REJECT SET COOKIE RESPONSE
HEADER
Whats the way out if the client doesnt accept cookies?
URL rewriting.
All you need is that the client and container are able to exchange session id info.
URL rewriting takes the session id thats in the cookie and sticks it right onto the end of
every URL that comes in to this app.

If cookies arent enabled the client will never join a session.


A client with cookies disabled will ignore Set-Cookie response headers.
The clients isNew() method will always return true.
Now URL rewriting works as attaching extra bit of info(session id) at the end of the url.
The container uses this extra info to find a matching session.
URL rewriting works only if cookies fail and you tell the response to encode the url.

How does a container know that cookies arent working?


Initially uses both cookie and URL rewriting for the first request.
On next request if session id is there in the request the container knows that the client
accepts cookies and ignores response.encodeURL() calls

URL rewriting works with sendRedirect()


This works in the scenario when you want to redirect the request to a different URL but
still want to use a session.
The URL encoding method for that is :
response.encodeRediectURL(/BeerTest.do);
How do I do URL rewriting on static HTML pages?
Theres no way to do automatic URL rewriting with your static pages , so if you depend
on sessions, you must use dynamically generated pages.
U cant on static ,only on dynamically generated pages.
Is URL rewriting handled in a vendor specific way?
Tomcat uses a semicolon ;,to append the extra info to the URL.Another vendor may use ,
or anything else.
While tomcat add jsessionid = another vendor may use only session id itself.
only place a jsessionid belongs is a cookie header and nowhere else.
Key Http Session Methods

Setting session time-out


3 ways a session can die :
1.it times out
2.you can invalidate on the session object
3.app goes down
Configuring session time out in DD
<session-config>
<session-timeout>15</session-timeout>
</session-config>
The 15 is in minutes.
It says if the client does not make any request for 15 minutes kill it.
Setting session timeout for a specific session
session.setMaxInactiveInterval(20*60);

Cookies
Cookies can be used for other things besides session like remembering client name.
1. Cookie exchange is automatic
2. Cookie lives as long as session, once client quits his browser, cookie
disappears.
3. Thats how the jsessionid cookie works
4. But you can tell a cookie to stay alive even after the browser shuts down.
Using cookies with the servlet API
You can get cookie related info from request and response headers but dont.
Everything related to cookies has been encapsulated in the Servlet API in 3 classes :
javax.servlet.http.HttpServletRequest
javax.servlet.http.HttpServletResponse
javax.servlet.http.Cookie
Creating a cookie:
Cookie cookie = new Cookie(username,name);
Setting how long a cookie will live on the client:

cookie.setMaxAge(30*60);
Sending the cookie to the client :
response.addCookie(cookie);
Getting the cookies from the client request :
Cookie[] cookies = request.getCookies();
for(int i=0;i<cookies.length;i++){
Cookie cookie= cookies[i];
if(cookie.getName.equals(username)){
String username = cookie.getValue();
out.println(Hello+username);
break;
}
}

Difference between cookies and headers


When you add a header to a response ,you pass the name and value Strings as arguments.
response.addHeader(foo,bar);
But when you add a cookie to a response ,you pass a cookie object.
Cookie cookie = new Cookie(name,name);
response.addCookie(cookie);
Also for headers there are 2 methods setHeader() and addHeader()
But for cookies theres only addCookie()

Você também pode gostar