View source for Methods to Maintain a HTTP Session

=Internal=

* [[HTTP_Session#Methods_to_Maintain_a_HTTP_Session|HTTP Session]]

=Persistent Cookies=

Cookies are pieces of information generated by a Web server and stored by the user's browser, ready for future access. When a browser receives a cookie, it saves the cookie and thereafter sends the cookie back to the server it has seen it from each time it accesses a page on that server, subject to certain rules. Because a cookie's value can uniquely identify a client, cookies are often used for session tracking.  

The cookies are transferred using HTTP headers and the servlet API has special method calls to help dealing with cookies. 

To retrieve the cookies from the request, use:

<pre>
public Cookie[] HttpServletRequest.getCookies()
</pre>

To send cookies, use

<pre>
public void HttpServletResponse.addCookie(Cookie cookie)
</pre>

Because cookies are sent using HTTP headers, they should be added to the response before the response had been committed.

=User Authentication=

One way to perform session tracking is to leverage the information that comes with user authentication. After the client logs in, the username is available to a servlet through <tt>getRemoteUser()</tt>. We can use the username to track a client session. Once the user has logged in, the browser remembers her username and resends the name and the password as the user makes new requests. A servlet can identify the user through her user name and thereby track her session. 

Avantages:
* It is easy to implement, simply tell the server to protect a set of pages and then use <tt>getRemoteUser()</tt>.
* This techniques works even when the user accesses the site from different machines.
Disadvantages:
* It requires each user to register for an account and then log on each time he starts visting the site. 
* HTTP basic authentication provides no logout mechanism, the user has to exit the browser to log out. 
* A user cannot maintain simultaneoulsy more than one session at the same time.

=Hidden Form Fields=

One way to support anonymous session tracking is to use hidden form fields:

<pre>
    <FORM ACTION="/servlet/MyServlet" METHOD=POST>
        ...
        <INPUT TYPE=hidden NAME="id" VALUE="34F4E3VKS423">
    </FORM>
</pre>

The hidden fields are not displayed in the client's browser and they are sent back to the server when the form is submitted. In a sense, the hidden forms define constant variables for a form. To a servlet receiving the form, there is no difference between a hidden field and a visible field. 

Advantages:
* Hidden fields are supported by all the popular browsers, they demand no special server requirements.
* Hidden fields can be used with clients that haven't registered or logged in.
Disadvantages:
* The session persist only through sequences of dynamically generated forms. The session cannot be maintained with static documents, emailed documents, bookmarked documents or browser shutdowns.

=URL Rewriting=

URL rewriting is another way to support anonymous session tracking. When the response page is generated on the server, the embedded URLs the user might click on are dynamically modified (or rewritten) to include session information. There are three ways to rewrite an URL:

==Extra path information==

The extra information, usually an unique session ID, is appended to the URL as extra path: <tt>http://server:port/servlet/MyServlet/__123__</tt>. This works well on all servers, but it doesn't work well if the servlet has to use the extra path information as true path information.

==Added parameters==

The extra information is appended as a parameter part of the query string: <tt>http://server:port/servlet/MyServlet__?sessionID=123__</tt>. This works on all servers, but it can cause parameter naming collisions. 

==Custom server-specific URL change==

The session information is encoded in URL in a non-standard way: <tt>http://server:port/servlet/MyServlet__;sessionID=123__</tt>. This may not work well on all servers.

The advantages and disadvantages of URL rewriting closely match those of hidden form fields. The major difference is that URL rewriting works for all dynamically created documents, not just forms.