Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > .NET > .NET 1.0 and Visual Studio.NET > VS.NET 2002/2003
Password Reminder
Register
| FAQ | Members List | Search | Today's Posts | Mark Forums Read
VS.NET 2002/2003 Discussions about the Visual Studio.NET programming environment, the 2002 (1.0) and 2003 (1.1). ** Please don't post code questions here ** For issues specific to a particular language in .NET, please see the other forum categories.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the VS.NET 2002/2003 section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old October 1st, 2007, 10:02 AM
Registered User
 
Join Date: Oct 2007
Location: Pune, Maharashtra, India.
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
Default HttpSession What is and How to?

Hi all,

    I am really asking very basic question that what is HTTP Session?

 Yes, you will get a lot information on googling.

But i wanted to know that where the session object is maintained,

so that the server identifies the unique client?

Is it transfered to and fro with request and response?

As each request is processed at server in a separate thread,

and each time we access the session object through request. [i.e. request.getSession()].

So does the server maintains the sessions of all the requests some where or each time it

gets from incoming request.

And what if we put large objects in the session variable?


Please make these concepts clear.

Thanks & Regards,

Sandip Bhoi

Reply With Quote
  #2 (permalink)  
Old October 1st, 2007, 12:41 PM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
Default

When a page request is processed by the ASP.NET runtime (the aspnet worker process) the session information for the particular requester (i.e. the client instance based on the asp session cookie or querystring value) is provided to the page class that is instantiated for each aspx page. Internally the HTTPSession class associates the data to the client based on the session ID.

The data itself is maintained by the web server. If using in process session (InProc) the session data is kept in server memory and thus can be lost if the web application restarts. If using SQL server based session, the data is persisted in a SQL database which makes it easy to use session in a web server farm. Because of the physical persistence provided by a SQL database session data is kept as long as the session ID is valid regardless of environment changes such as application restarts. No session information is passed between he client and server apart from the session ID token itself. Look in your cookies and you'll see the session ID.

You can put large objects into session. The only real limitation is server memory. It's a good practice to clean up the session variables you no longer need. Unlike the garbage collection of the framework runtime, because session is designed to provide some form of "persistence" to a stateless application platform, it hangs around until it's erased, the web app is restarted or the session the data belongs to times out. Depending on how you design your application you could be in trouble if you need to put lots of large objects into session. That might also flag a problem with the application design.

-Peter
Reply With Quote
  #3 (permalink)  
Old October 4th, 2007, 01:13 AM
Registered User
 
Join Date: Oct 2007
Location: Pune, Maharashtra, India.
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Thank you Peter,

     Thank you very much for explaining this in details.

Again some query --

Is there any thing on browser related to Session?

The browser is having the cookie JSESSIONID which contains the unique session id. The cookies travels to and fro with request and response.

Then does the server identify the same session of the client from session id in the cookie?

Can cookie modified at client side? what if the cookie is modified at client side? It may interfere with other session and every thing may go wrong...

Please explain this thing.

Thank you once again for spending you precious time for the same.

-Sandip Bhoi





Reply With Quote
  #4 (permalink)  
Old October 4th, 2007, 11:46 AM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
Default

Quote:
quote:Originally posted by sandip.bhoi
 Is there any thing on browser related to Session?

Yes, the session ID cookie, but that's all. No session data resides in the browser.

Quote:
quote:Originally posted by sandip.bhoi
 The browser is having the cookie JSESSIONID which contains the unique session id. The cookies travels to and fro with request and response.

Then does the server identify the same session of the client from session id in the cookie?
Don't you mean "SESSIONID" (no J)? Yes the server identifies "who" the user is based on the session id in the cookie. That's how it matches up the in memory data to a user.

Quote:
quote:Originally posted by sandip.bhoi
 Can cookie modified at client side? what if the cookie is modified at client side? It may interfere with other session and every thing may go wrong...

Yes, technically you could change your cookie. If you change the session ID in the cookie, you'll most definately affect the way the application behaves. If you were able to spoof another user's session ID you could then operate in their session. This is why user authentication should be maintained in something like a forms authentication ticket which is encrypted and much more difficult to hack.

-Peter
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
HttpSession and HttpSessionState praveenthonda ASP.NET 2.0 Professional 1 September 5th, 2007 04:33 PM



All times are GMT -4. The time now is 02:53 PM.


Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.