Thursday, January 28, 2016

Cookie vs URL Rewriting

Cookie
With the first response from a stateful servlet after a session is created, the server (container) sends a cookie with a session identifier back to the client, often along with a small amount of other useful information (all less than 4 KB). The container sends the cookie, named JSESSIONID, in the HTTP response header.
Upon each subsequent request from the same Web client session, if the client supports cookies it sends the cookie back to the server as part of the request, and the cookie value is used by the server to look up session state information to pass to the servlet.
With subsequent responses, the container sends the updated cookie back to the client.
The servlet code is not required to do anything to send a cookie; this is handled by the container. Sending cookies back to the server is handled automatically by the Web browser, unless the end-user disables cookies.

The container uses the cookie for session maintenance. A servlet can retrieve cookies using the getCookies() method of the HttpServletRequest object, and can examine cookie attributes using the accessor methods of the javax.servlet.http.Cookie objects.

URL Rewriting
An alternative to using cookies is URL rewriting, through the encodeURL() method of the response object. This is where the session ID is encoded into the URL path of a request.

The name of the path parameter is jsessionid, as in the following example:
http://<host><:port>/myapp/index.html?jsessionid=6789

Similarly to the functionality of cookies, the value of the rewritten URL is used by the server to look up session state information to pass to the servlet.

Source
https://docs.oracle.com/cd/A97688_16/generic.903/a97680/develop.htm#1005024


No comments:

Post a Comment

java - fill distinct objects in ArrayList

If you have a list that contains some objects that it is considered as duplication when two or three fields of these objects are equal. How ...