aspose file tools*
The moose likes Servlets and the fly likes session = cookie? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "session = cookie?" Watch "session = cookie?" New topic
Author

session = cookie?

Mathias Nilsson
Ranch Hand

Joined: Oct 13, 2003
Posts: 107
Hi ranchers!
I've read in many topics that a session is a cookie? Is this true? If it is
then how come I can use sessions when I don't accept cookies?
// Mathias


SCJP2 , MCP( 70-229 ) , Preparing For SCWDC
Tim Baker
Ranch Hand

Joined: Oct 04, 2003
Posts: 541
no a session and cookies are not the same thing. a session just means a series of page requests made by the same user in a relatively short space of time that are all linked together in some way.
the servlet container (ie tomcat etc) maintains the session information by default by setting a cookie on the users machine and when this gets sent back by the user for every other request it knows that it is the same session
if the user doesn't accept the cookie the container will not by default be able to track sessions, so you have to do something else to help it out! what you do is called URL Rewriting where a session number is put into all the urls in the pages that are sent to the user, so when they request this url the container knows which session it is!
for all the URLs in your page you want to track sessions on call response.encodeURL(String url).
i suspect a search on this forum might turn up a similar answer to this question too


Kim Jong II (North Korea's Dear Leader) said:Nuclear weapons don't kill people, people kill people.
Bosun Bello
Ranch Hand

Joined: Nov 06, 2000
Posts: 1510
It's somewhat true. The session handling mechanism uses cookies in the background. If cookies are disabled, it will try to use URLRewriting if possible (if implemented).


Bosun (SCJP, SCWCD)
So much trouble in the world -- Bob Marley
Mathias Nilsson
Ranch Hand

Joined: Oct 13, 2003
Posts: 107
It's somewhat true. The session handling mechanism uses cookies in the background. If cookies are disabled, it will try to use URLRewriting if possible (if implemented).

it will try? Does that mean that session isn't 100% bulletproof?
// Mathias
Tim Baker
Ranch Hand

Joined: Oct 04, 2003
Posts: 541
it means if YOU implemented it using your code!
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

I wouldn't imply someone has to 'implement' URL rewriting.

URL re-writing will *always* succeed (not just 'try'), if the following conditions are met:
1) you use the appropriate API
2) the container administrator hasn't disabled re-writing. There are very few reasons to do this, and it's on by default.
3) it's *required* (because the user has disabled cookies)

There is an API to handle this, it's on HttpServletResponse and there are two methods:

encodeURL()
encodeRedirectURL()

using these to encode all links in your JSP pages or servlets will ensure that sessions are given the best chance of survival.
Malli Raman
Ranch Hand

Joined: Nov 07, 2001
Posts: 312
Originally posted by Mike Curwen:
I wouldn't imply someone has to 'implement' URL rewriting.

URL re-writing will *always* succeed (not just 'try'), if the following conditions are met:
1) you use the appropriate API
2) the container administrator hasn't disabled re-writing. There are very few reasons to do this, and it's on by default.
3) it's *required* (because the user has disabled cookies)

There is an API to handle this, it's on HttpServletResponse and there are two methods:

encodeURL()
encodeRedirectURL()

using these to encode all links in your JSP pages or servlets will ensure that sessions are given the best chance of survival.

Hi,
What is difference between encodeURL() and encodeRedirectURL() method.
Thanks & Regards,
M.S.Raman
Malhar Barai
Author
Ranch Hand

Joined: Aug 17, 2001
Posts: 399
Hi...
encodeURL(java.lang.String url)
Encodes the specified URL by including the session ID in it, or, if encoding is not needed, returns the URL unchanged.
encodeRedirectURL(java.lang.String url)
Encodes the specified URL for use in the sendRedirect method or, if encoding is not needed, returns the URL unchanged.
hth
MB


Malhar Barai
SOA & Java Book
Malli Raman
Ranch Hand

Joined: Nov 07, 2001
Posts: 312
Originally posted by Malhar Barai:
Hi...
encodeURL(java.lang.String url)
Encodes the specified URL by including the session ID in it, or, if encoding is not needed, returns the URL unchanged.
encodeRedirectURL(java.lang.String url)
Encodes the specified URL for use in the sendRedirect method or, if encoding is not needed, returns the URL unchanged.
hth
MB

Hi,
But in this forum , someone mentioned that both methods includes the session id as jSessionid, but he is not clearly mention the difference between the two method. So only difference is encodeRedirectURL method won't includes the SEssion Id for encoding. Am I right?
Regards,
M.S.Raman
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

wrong. please *read* the API. The difference is obvious.

if you intend to use the URL in the sendRedirect() method, use encodeRedirectURL(). If you are not going to use the URL in that method, then encodeURL() is fine.

Both methods will encode the jsesssionid into the URL, and both will only do so if necessary (if the user has cookies disabled, or when cookie status is undetermined), and if the container has been configured to do allow url re-writing.
Malli Raman
Ranch Hand

Joined: Nov 07, 2001
Posts: 312
Originally posted by Mike Curwen:
wrong. please *read* the API. The difference is obvious.

if you intend to use the URL in the sendRedirect() method, use encodeRedirectURL(). If you are not going to use the URL in that method, then encodeURL() is fine.

Both methods will encode the jsesssionid into the URL, and both will only do so if necessary (if the user has cookies disabled, or when cookie status is undetermined), and if the container has been configured to do allow url re-writing.


Thanks Mike.
M.S.Raman
Justin Chu
Ranch Hand

Joined: Apr 19, 2002
Posts: 209
    
    1
Originally posted by Mike Curwen:
wrong. please *read* the API. The difference is obvious.

if you intend to use the URL in the sendRedirect() method, use encodeRedirectURL(). If you are not going to use the URL in that method, then encodeURL() is fine.

Both methods will encode the jsesssionid into the URL, and both will only do so if necessary (if the user has cookies disabled, or when cookie status is undetermined), and if the container has been configured to do allow url re-writing.


Thanks for rephrasing the API description.

So what is the *difference* in the way the URL is encoded in both situations?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: session = cookie?