{"id":118,"date":"2018-07-11T06:33:05","date_gmt":"2018-07-11T06:33:05","guid":{"rendered":"http:\/\/itp16.epgpbooks.inflibnet.ac.in\/?post_type=chapter&p=118"},"modified":"2019-05-15T07:21:48","modified_gmt":"2019-05-15T07:21:48","slug":"cookies-and-sessions","status":"publish","type":"chapter","link":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/chapter\/cookies-and-sessions\/","title":{"rendered":"Cookies and Sessions"},"content":{"raw":"
\"epgp<\/a>\r\n<\/span><\/div>\r\n
\r\n\r\n \r\n

Introduction<\/strong><\/p>\r\n \r\n

In an earlier module, we have seen about HTTP specific APIs. we have started looking at javax.servet.http package. We saw the two interfaces, .HTTPServletRequest and HTTPServletResponse. We have also seen the HTTPServlet class.<\/p>\r\n \r\n

In this module we will be looking at cookies and sessions. Sessions also many times do depend on cookies and the purpose of session is to be able to track the user.<\/p>\r\n \r\n

Let\u2019s start understanding what a cookie really is and how a session is managed in a container. The management of a session in a container is mainly for the purpose of tracking a particular user in a stateless protocol like HTTP. We understand HTTP being a stateless protocol.<\/p>\r\n \r\n

What is a Cookie?\u00a0<\/strong><\/p>\r\n \r\n

Cookie is some kind of a key value pair or some kind of parameter which is stored on the client side. Cookie is managed in the client, but who is responsible for creating those key value pair? It is the server. Where are the cookies used?<\/p>\r\n \r\n

A very simple example<\/p>\r\n \r\n

In a website, as you login, it would ask REMEMBER ME? It\u2019s basically an auto login. How an auto login is done? I should get logged in automatically if I hit this particular URL(server).<\/p>\r\n \r\n

I should not enter username and password every time. Don't show me the login screen when I go to the index page. Straight away just log me in, So how is that managed?<\/p>\r\n \r\n

For managing that, when it says remember me, oh who is remembering whom? Is it the server who is remembering the client? No the server does not have the capability to remember each and every client.<\/p>\r\n \r\n

let\u2019s see what the server does for this? It\u2019s basically done by cookies.<\/p>\r\n \r\n

When you submit the request and you tick the check-box saying remember me, the request which has gone, it has sent a parameter saying that remember me is checked. When this request is received by the server. What the server does is, that while giving back response is adding some Http header, which is an indication to the client that you please remember this cookie for me. It is sending a cookie to the client, please remember this cookie for me, from now onwards whenever you connect to me, you need to send this as a token.<\/span><\/p>\r\n \r\n

The browser (Http client) is making requests to different different servers. The client is supposed to remember various parameters which have been set on it by different servers. It maintains a kind of cookie database. which has to be managed server wise.<\/span><\/p>\r\n \r\n

Certain cookies may be specific to a URL. for a particular URL there is a particular cookie. It will go as part of a request header to the server. Before the cookie goes there, it needs to be set up on the client.<\/span><\/p>\r\n \r\n

Setting up cookie on the client will be done by the server. whenever any request is being created and formatted on the client side to be sent to the server, it will do a check of the cookie database. Do I have a cookie for this particular server. If there is a cookie, a header is put in the request and that's how cookies are being sent from client to server.<\/span><\/p>\r\n \r\n

This will be helpful for auto-login as the browser remembers the username and password as cookies. So that there is no need for the server to send the login page every time, and the user can be authenticated from the cookies being sent from client to server.<\/span><\/p>\r\n \r\n

What is a Session?<\/strong><\/p>\r\n \r\n

Let\u2019s talk about session.<\/span><\/p>\r\n \r\n

You might have seen a shopping cart application. In a shopping cart what is done? When user ticks an item to put it into the cart, that is one request sent to the server. Next time when he ticks another item, another request is sent to the server, but how does the server know that this request is coming from the same client?<\/span><\/p>\r\n \r\n

There is one more product to be added in that cart. How does it manage various carts for all the users?<\/span><\/p>\r\n \r\n

The server has to keep track of users. We understand HTTP is stateless. There was one request sent from the client and then that got disconnected. Disconnected in the sense that the request was over, and the response was given back to the client. Now he moves to the other part of application and says, oh, I need to add another item to the cart.<\/span><\/p>\r\n \r\n

How does the server the identify which cart? Which user? Is some cart created for the user or not?<\/span><\/p>\r\n \r\n

For this there has to be a mechanism of tracking each user on the server side. This tracking involves the use of sessions.<\/span><\/p>\r\n \r\n

We have got something called HTTPSession. This interface is available in javax.servlet.http package.<\/span><\/p>\r\n \r\n

Tracking a Client?\u00a0<\/strong><\/p>\r\n \r\n

How a client is being tracked? But before that, what is the requirement here?<\/span><\/p>\r\n \r\n

The requirement here from server's point of view. The server would like to be able to track each client. We have the HTTP protocol where each request is a new request. You have to identify who it is?<\/span><\/p>\r\n \r\n

It\u2019s not that every client needs to be tracked. We might start tracking a client once he has done login. You many times get user-specific information displayed on all subsequent pages after a successful login. You see your name being displayed. How is all that happening?<\/span><\/p>\r\n \r\n

To start tracking user is the responsibility of the container. It is the container who is tracking the client. This is the responsibility of the container and not the servlet. Servlets are just components which are managed by the container.<\/span><\/p>\r\n \r\n

So let\u2019s see what all happens within the container now?<\/span><\/p>\r\n \r\n

It may be a requirement that a particular client needs to be tracked, we can see how exactly a container would know that a client needs to be tracked. If a client needs to be tracked..the indication to the container has to be given by the application. So the application components\u00a0<\/span>can say, ok, I would like the current client to be tracked. Once it has been identified by the container that this client needs to be tracked, what the client does for him?<\/span><\/p>\r\n \r\n

Think of a server creating a basket(object of HTTPSession) in which we can put various things. There is a basket which has been identified for this particular client which is nothing but our HTTPSession object. If a client needs to be tracked, a HTTPSession object would be created for him. This HTTPSession object is identified with the help of session ID. So there is a session ID which is generated for the client who is to be tracked.<\/span><\/p>\r\n \r\n

The things which happen on a container are<\/span><\/p>\r\n \r\n

a)\u00a0 Generation of Session ID.<\/span><\/p>\r\n

b)\u00a0 Creation of HTTPSession Object.<\/span><\/p>\r\n \r\n

Subsequent response which goes from the server now would have a mechanism of telling the client that this is your sessionID.<\/span><\/p>\r\n \r\n

In all your subsequent transactions from now onwards, You need to be sending this back to me. This can be managed through a cookie.<\/span><\/p>\r\n \r\n

Setting up a SessionID value on a client can be done by using a cookie also. Cookie is one of the mechanisms which can be used for session tracking. Whenever any request comes from the client, what would the container do?<\/span><\/p>\r\n \r\n

Do I have any sessionID in the request? If I have I can identify the HTTPSession object for that client. Irrespective of what the application is doing...one of the things done by the container here is to put a time stamp on HTTPSession object that last time when I have received a request from this client is so and so...so last request date-time is being set on the HTTPSession object, this is done because at any point of time a browser can be switched or it can go off. So there is no point in still maintaining the previous HTTPSession for that client.(because that user is gone).<\/span><\/p>\r\n \r\n

So there has to be some mechanism for throwing away those objects of HTTPSession<\/span><\/p>\r\n \r\n

In order to be able to manage the HTTPSession objects and not overdoing it, we should have the mechanism of throwing away the unwanted HTTPSession objects. For that there would be a time-out mechanism. So each HTTPSession according to the requirement of the application,\u00a0<\/span>would have a max inactive interval. If I do not have any request coming from the client which matches this particular sessionID.<\/span><\/p>\r\n \r\n

Servlet has this API where it can interact with the container and find out about the session, oh for this current user give me his basket, I want to put something there. The container updates the HttpSession object with the last-request time, every time it receives a request from that particular client. So that it can throw away the unwanted HTTPSession objects.<\/span><\/p>\r\n \r\n

There is a mechanism in the container which keeps on checking the HTTPSession objects, is there an object whose difference between the current time and the last request time is greater than the max inactive interval? If so I know this can be thrown away.<\/span><\/p>\r\n \r\n

This is how the container manages and tracks users.<\/span><\/p>\r\n \r\n

How does the container know, when should it start tracking a particular client? That has to be something which is initiated from the application component, mainly a servlet. A servlet would from within the service method, when it gets the request object.<\/span><\/p>\r\n \r\n

In the HTTPServletRequest, we have this\u00a0 method called getSession()<\/span><\/p>\r\n \r\n

This has a boolean parameter which is create-if-necessary. The idea here is, if I say getSession() and if I put the value false,\u00a0<\/span>I am asking the container, are you tracking this client(client whose request is received)? If you are tracking him, give me the corresponding HTTPSession object or you can give me a null here.<\/span><\/p>\r\n \r\n

In case you pass true, it means for this particular client from where the request has arrived, Do you already have a session object? If you have, you can give that to me? If you don\u2019t have then I would like you to start tracking him from now onwards.<\/span><\/p>\r\n \r\n

I had mentioned in the last module, we have the ServletRequest and ServletContext. .Both of these interfaces having those 4 set of methods where object sharing can be done. Those same 4 methods are also available in HTTPSession.<\/span><\/p>\r\n \r\n

HttpSession is basically a basket where you can manage objects. Methods,<\/span><\/p>\r\n

void setAttribute(String name, Object value)<\/span><\/p>\r\n

Object getAttibute(String name) Enumeration<String> getAttributeNames() void removeAttribute(String name)\u00a0<\/span>are available for the HTTPSession as well.<\/span><\/p>\r\n \r\n

So what is there in HTTPSession?<\/span><\/p>\r\n \r\n

a)\u00a0 last requested date time.<\/span><\/p>\r\n

b)\u00a0 max inactive interval<\/span><\/p>\r\n

c)\u00a0 methods for managing attributes<\/span><\/p>\r\n

d)\u00a0 sessionID<\/span><\/p>\r\n \r\n

The getSession() method is overloaded., so if we don\u2019t pass a boolean value then by default it is considered true. So you may not be specifying the boolean value. Now you use getSession(true), how would you know whether it\u2019s a new session object or the client was already being tracked and then you have got the object for it.\u00a0<\/span>You can know this by the method isNew() in HTTPSession We have the appropriate methods for setting and getting the timeout values in the HTTPSession. You can decide the timeout value as per the need of the application. There are few methods in the HTTPServletRequest which are related to the session<\/span><\/p>\r\n \r\n

Session tracking is normally done using cookies. In case cookies are not available, it might be done through URL-rewriting also. So we have a mechanism in the HTTPServletRequest, a method called isRequestedURLFromCookie(),which returns a boolean value. By this you can know whether this client is being tracked by using a cookie or not.\u00a0<\/span>IsRequestedSessionFromURL(), these methods let us know how client is being tracked? whether tracked by cookie or URL-rewriting\u00a0<\/span>If it is URL-rewriting it is slightly tedious for the UI part also because UI components wherever they are specifying a submit button..or wherever the request is being sent, the Session ID needs to be added as a part of URL parameter. So there is this additional task for the UI developer.<\/span><\/p>\r\n \r\n

So tracking through cookie is much simpler. Now we look at the API part related to cookie. We have a separate class called Cookie. We actually have headers, there are headers in the\u00a0<\/span>request through which the cookie is made available to the server. Initially it is the server who is setting up the cookie. There are headers as a part of response also, it is through the response headers by which the cookie is set.<\/span><\/p>\r\n \r\n

The server would use a method to set up a cookie on the client. How does the server do it For that, before the service method is finished, the servlet if wants to set up a cookie in the client, there is method in the HTTPServletResponse...<\/span><\/p>\r\n \r\n

we have this method called addCookie() where the parameter is the Cookie. Cookie class is in javax.servlet.Http package. Cookie has a simple constructor. You have to use the key value pair..<\/span><\/p>\r\n \r\n

Cookie has a name and a value. Cookie has an expiry time. A particular cookie should be managed on the client for a specific period of time.<\/span><\/p>\r\n \r\n

There is method in Cookie by which the setting of expiry time can be done. This is how the server would be able to set Cookie on the client. The servlet would like to check what are the cookies which have arrived from a particular client. For that HTTPServletRequest has method called getCookies() which gives us an array of cookies. If there are no cookies this method does not return an empty array. it would return null. So it\u2019s important to remain careful here so that you don\u2019t get NullPointerException. So it\u2019s good to carry out a check for the null. don\u2019t straight away go for writing loop here.<\/span><\/p>\r\n\r\n\r\n\r\n
you can view video on Cookies and Sessions<\/strong><\/td>\r\n\"\"<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n\r\n

Suggested Reading:<\/strong><\/p>\r\n\r\n<\/div>\r\n

\r\n
    \r\n \t
  1. Core Servlets and Java Server Pages Volume 2 by Marty Hall & Larry Brown, Second Edition, Pearson Education.<\/li>\r\n \t
  2. Inside Servlets by Dustin R Callaway, Pearson Education.<\/li>\r\n \t
  3. Java Server Programming for Professionals by Ivan Bayross, Sharanam Shah, Cynhthia Bayross and Vaishali Shah Shroff Publishers and Distributros.<\/li>\r\n \t
  4. http:\/\/download.oracle.com\/otndocs\/jcp\/servlet-3.0-fr-oth-JSpec\/<\/li>\r\n<\/ol>\r\n<\/div>","rendered":"
    \"epgp<\/a>
    \n<\/span><\/div>\n
    \n

     <\/p>\n

    Introduction<\/strong><\/p>\n

     <\/p>\n

    In an earlier module, we have seen about HTTP specific APIs. we have started looking at javax.servet.http package. We saw the two interfaces, .HTTPServletRequest and HTTPServletResponse. We have also seen the HTTPServlet class.<\/p>\n

     <\/p>\n

    In this module we will be looking at cookies and sessions. Sessions also many times do depend on cookies and the purpose of session is to be able to track the user.<\/p>\n

     <\/p>\n

    Let\u2019s start understanding what a cookie really is and how a session is managed in a container. The management of a session in a container is mainly for the purpose of tracking a particular user in a stateless protocol like HTTP. We understand HTTP being a stateless protocol.<\/p>\n

     <\/p>\n

    What is a Cookie?\u00a0<\/strong><\/p>\n

     <\/p>\n

    Cookie is some kind of a key value pair or some kind of parameter which is stored on the client side. Cookie is managed in the client, but who is responsible for creating those key value pair? It is the server. Where are the cookies used?<\/p>\n

     <\/p>\n

    A very simple example<\/p>\n

     <\/p>\n

    In a website, as you login, it would ask REMEMBER ME? It\u2019s basically an auto login. How an auto login is done? I should get logged in automatically if I hit this particular URL(server).<\/p>\n

     <\/p>\n

    I should not enter username and password every time. Don’t show me the login screen when I go to the index page. Straight away just log me in, So how is that managed?<\/p>\n

     <\/p>\n

    For managing that, when it says remember me, oh who is remembering whom? Is it the server who is remembering the client? No the server does not have the capability to remember each and every client.<\/p>\n

     <\/p>\n

    let\u2019s see what the server does for this? It\u2019s basically done by cookies.<\/p>\n

     <\/p>\n

    When you submit the request and you tick the check-box saying remember me, the request which has gone, it has sent a parameter saying that remember me is checked. When this request is received by the server. What the server does is, that while giving back response is adding some Http header, which is an indication to the client that you please remember this cookie for me. It is sending a cookie to the client, please remember this cookie for me, from now onwards whenever you connect to me, you need to send this as a token.<\/span><\/p>\n

     <\/p>\n

    The browser (Http client) is making requests to different different servers. The client is supposed to remember various parameters which have been set on it by different servers. It maintains a kind of cookie database. which has to be managed server wise.<\/span><\/p>\n

     <\/p>\n

    Certain cookies may be specific to a URL. for a particular URL there is a particular cookie. It will go as part of a request header to the server. Before the cookie goes there, it needs to be set up on the client.<\/span><\/p>\n

     <\/p>\n

    Setting up cookie on the client will be done by the server. whenever any request is being created and formatted on the client side to be sent to the server, it will do a check of the cookie database. Do I have a cookie for this particular server. If there is a cookie, a header is put in the request and that’s how cookies are being sent from client to server.<\/span><\/p>\n

     <\/p>\n

    This will be helpful for auto-login as the browser remembers the username and password as cookies. So that there is no need for the server to send the login page every time, and the user can be authenticated from the cookies being sent from client to server.<\/span><\/p>\n

     <\/p>\n

    What is a Session?<\/strong><\/p>\n

     <\/p>\n

    Let\u2019s talk about session.<\/span><\/p>\n

     <\/p>\n

    You might have seen a shopping cart application. In a shopping cart what is done? When user ticks an item to put it into the cart, that is one request sent to the server. Next time when he ticks another item, another request is sent to the server, but how does the server know that this request is coming from the same client?<\/span><\/p>\n

     <\/p>\n

    There is one more product to be added in that cart. How does it manage various carts for all the users?<\/span><\/p>\n

     <\/p>\n

    The server has to keep track of users. We understand HTTP is stateless. There was one request sent from the client and then that got disconnected. Disconnected in the sense that the request was over, and the response was given back to the client. Now he moves to the other part of application and says, oh, I need to add another item to the cart.<\/span><\/p>\n

     <\/p>\n

    How does the server the identify which cart? Which user? Is some cart created for the user or not?<\/span><\/p>\n

     <\/p>\n

    For this there has to be a mechanism of tracking each user on the server side. This tracking involves the use of sessions.<\/span><\/p>\n

     <\/p>\n

    We have got something called HTTPSession. This interface is available in javax.servlet.http package.<\/span><\/p>\n

     <\/p>\n

    Tracking a Client?\u00a0<\/strong><\/p>\n

     <\/p>\n

    How a client is being tracked? But before that, what is the requirement here?<\/span><\/p>\n

     <\/p>\n

    The requirement here from server’s point of view. The server would like to be able to track each client. We have the HTTP protocol where each request is a new request. You have to identify who it is?<\/span><\/p>\n

     <\/p>\n

    It\u2019s not that every client needs to be tracked. We might start tracking a client once he has done login. You many times get user-specific information displayed on all subsequent pages after a successful login. You see your name being displayed. How is all that happening?<\/span><\/p>\n

     <\/p>\n

    To start tracking user is the responsibility of the container. It is the container who is tracking the client. This is the responsibility of the container and not the servlet. Servlets are just components which are managed by the container.<\/span><\/p>\n

     <\/p>\n

    So let\u2019s see what all happens within the container now?<\/span><\/p>\n

     <\/p>\n

    It may be a requirement that a particular client needs to be tracked, we can see how exactly a container would know that a client needs to be tracked. If a client needs to be tracked..the indication to the container has to be given by the application. So the application components\u00a0<\/span>can say, ok, I would like the current client to be tracked. Once it has been identified by the container that this client needs to be tracked, what the client does for him?<\/span><\/p>\n

     <\/p>\n

    Think of a server creating a basket(object of HTTPSession) in which we can put various things. There is a basket which has been identified for this particular client which is nothing but our HTTPSession object. If a client needs to be tracked, a HTTPSession object would be created for him. This HTTPSession object is identified with the help of session ID. So there is a session ID which is generated for the client who is to be tracked.<\/span><\/p>\n

     <\/p>\n

    The things which happen on a container are<\/span><\/p>\n

     <\/p>\n

    a)\u00a0 Generation of Session ID.<\/span><\/p>\n

    b)\u00a0 Creation of HTTPSession Object.<\/span><\/p>\n

     <\/p>\n

    Subsequent response which goes from the server now would have a mechanism of telling the client that this is your sessionID.<\/span><\/p>\n

     <\/p>\n

    In all your subsequent transactions from now onwards, You need to be sending this back to me. This can be managed through a cookie.<\/span><\/p>\n

     <\/p>\n

    Setting up a SessionID value on a client can be done by using a cookie also. Cookie is one of the mechanisms which can be used for session tracking. Whenever any request comes from the client, what would the container do?<\/span><\/p>\n

     <\/p>\n

    Do I have any sessionID in the request? If I have I can identify the HTTPSession object for that client. Irrespective of what the application is doing…one of the things done by the container here is to put a time stamp on HTTPSession object that last time when I have received a request from this client is so and so…so last request date-time is being set on the HTTPSession object, this is done because at any point of time a browser can be switched or it can go off. So there is no point in still maintaining the previous HTTPSession for that client.(because that user is gone).<\/span><\/p>\n

     <\/p>\n

    So there has to be some mechanism for throwing away those objects of HTTPSession<\/span><\/p>\n

     <\/p>\n

    In order to be able to manage the HTTPSession objects and not overdoing it, we should have the mechanism of throwing away the unwanted HTTPSession objects. For that there would be a time-out mechanism. So each HTTPSession according to the requirement of the application,\u00a0<\/span>would have a max inactive interval. If I do not have any request coming from the client which matches this particular sessionID.<\/span><\/p>\n

     <\/p>\n

    Servlet has this API where it can interact with the container and find out about the session, oh for this current user give me his basket, I want to put something there. The container updates the HttpSession object with the last-request time, every time it receives a request from that particular client. So that it can throw away the unwanted HTTPSession objects.<\/span><\/p>\n

     <\/p>\n

    There is a mechanism in the container which keeps on checking the HTTPSession objects, is there an object whose difference between the current time and the last request time is greater than the max inactive interval? If so I know this can be thrown away.<\/span><\/p>\n

     <\/p>\n

    This is how the container manages and tracks users.<\/span><\/p>\n

     <\/p>\n

    How does the container know, when should it start tracking a particular client? That has to be something which is initiated from the application component, mainly a servlet. A servlet would from within the service method, when it gets the request object.<\/span><\/p>\n

     <\/p>\n

    In the HTTPServletRequest, we have this\u00a0 method called getSession()<\/span><\/p>\n

     <\/p>\n

    This has a boolean parameter which is create-if-necessary. The idea here is, if I say getSession() and if I put the value false,\u00a0<\/span>I am asking the container, are you tracking this client(client whose request is received)? If you are tracking him, give me the corresponding HTTPSession object or you can give me a null here.<\/span><\/p>\n

     <\/p>\n

    In case you pass true, it means for this particular client from where the request has arrived, Do you already have a session object? If you have, you can give that to me? If you don\u2019t have then I would like you to start tracking him from now onwards.<\/span><\/p>\n

     <\/p>\n

    I had mentioned in the last module, we have the ServletRequest and ServletContext. .Both of these interfaces having those 4 set of methods where object sharing can be done. Those same 4 methods are also available in HTTPSession.<\/span><\/p>\n

     <\/p>\n

    HttpSession is basically a basket where you can manage objects. Methods,<\/span><\/p>\n

    void setAttribute(String name, Object value)<\/span><\/p>\n

    Object getAttibute(String name) Enumeration<String> getAttributeNames() void removeAttribute(String name)\u00a0<\/span>are available for the HTTPSession as well.<\/span><\/p>\n

     <\/p>\n

    So what is there in HTTPSession?<\/span><\/p>\n

     <\/p>\n

    a)\u00a0 last requested date time.<\/span><\/p>\n

    b)\u00a0 max inactive interval<\/span><\/p>\n

    c)\u00a0 methods for managing attributes<\/span><\/p>\n

    d)\u00a0 sessionID<\/span><\/p>\n

     <\/p>\n

    The getSession() method is overloaded., so if we don\u2019t pass a boolean value then by default it is considered true. So you may not be specifying the boolean value. Now you use getSession(true), how would you know whether it\u2019s a new session object or the client was already being tracked and then you have got the object for it.\u00a0<\/span>You can know this by the method isNew() in HTTPSession We have the appropriate methods for setting and getting the timeout values in the HTTPSession. You can decide the timeout value as per the need of the application. There are few methods in the HTTPServletRequest which are related to the session<\/span><\/p>\n

     <\/p>\n

    Session tracking is normally done using cookies. In case cookies are not available, it might be done through URL-rewriting also. So we have a mechanism in the HTTPServletRequest, a method called isRequestedURLFromCookie(),which returns a boolean value. By this you can know whether this client is being tracked by using a cookie or not.\u00a0<\/span>IsRequestedSessionFromURL(), these methods let us know how client is being tracked? whether tracked by cookie or URL-rewriting\u00a0<\/span>If it is URL-rewriting it is slightly tedious for the UI part also because UI components wherever they are specifying a submit button..or wherever the request is being sent, the Session ID needs to be added as a part of URL parameter. So there is this additional task for the UI developer.<\/span><\/p>\n

     <\/p>\n

    So tracking through cookie is much simpler. Now we look at the API part related to cookie. We have a separate class called Cookie. We actually have headers, there are headers in the\u00a0<\/span>request through which the cookie is made available to the server. Initially it is the server who is setting up the cookie. There are headers as a part of response also, it is through the response headers by which the cookie is set.<\/span><\/p>\n

     <\/p>\n

    The server would use a method to set up a cookie on the client. How does the server do it For that, before the service method is finished, the servlet if wants to set up a cookie in the client, there is method in the HTTPServletResponse…<\/span><\/p>\n

     <\/p>\n

    we have this method called addCookie() where the parameter is the Cookie. Cookie class is in javax.servlet.Http package. Cookie has a simple constructor. You have to use the key value pair..<\/span><\/p>\n

     <\/p>\n

    Cookie has a name and a value. Cookie has an expiry time. A particular cookie should be managed on the client for a specific period of time.<\/span><\/p>\n

     <\/p>\n

    There is method in Cookie by which the setting of expiry time can be done. This is how the server would be able to set Cookie on the client. The servlet would like to check what are the cookies which have arrived from a particular client. For that HTTPServletRequest has method called getCookies() which gives us an array of cookies. If there are no cookies this method does not return an empty array. it would return null. So it\u2019s important to remain careful here so that you don\u2019t get NullPointerException. So it\u2019s good to carry out a check for the null. don\u2019t straight away go for writing loop here.<\/span><\/p>\n\n\n\n
    you can view video on Cookies and Sessions<\/strong><\/td>\n\"\"<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Suggested Reading:<\/strong><\/p>\n<\/div>\n

    \n
      \n
    1. Core Servlets and Java Server Pages Volume 2 by Marty Hall & Larry Brown, Second Edition, Pearson Education.<\/li>\n
    2. Inside Servlets by Dustin R Callaway, Pearson Education.<\/li>\n
    3. Java Server Programming for Professionals by Ivan Bayross, Sharanam Shah, Cynhthia Bayross and Vaishali Shah Shroff Publishers and Distributros.<\/li>\n
    4. http:\/\/download.oracle.com\/otndocs\/jcp\/servlet-3.0-fr-oth-JSpec\/<\/li>\n<\/ol>\n<\/div>\n","protected":false},"author":4,"menu_order":20,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":["mr-pravin-jain"],"pb_section_license":""},"chapter-type":[],"contributor":[58],"license":[],"class_list":["post-118","chapter","type-chapter","status-publish","hentry","contributor-mr-pravin-jain"],"part":3,"_links":{"self":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapters\/118","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/wp\/v2\/users\/4"}],"version-history":[{"count":11,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapters\/118\/revisions"}],"predecessor-version":[{"id":409,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapters\/118\/revisions\/409"}],"part":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapters\/118\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/wp\/v2\/media?parent=118"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapter-type?post=118"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/wp\/v2\/contributor?post=118"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/wp\/v2\/license?post=118"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}