The ability to even have Session variables is premised on IIS being allowed to place a cookie onto the client's system. This cookie contains a 16-character identifier that allows IIS to track the requests that are made by that client. Internally, this identifier is associated with a collection. This association allows IIS to not only implement Session variables, but also to time out the session itself (and the variables along with it).
The fact that the identifier is a cookie means that those users (and you know who you are) who don't have cookies turned on will not have their session variables stored. Just so that we're clear, not accepting cookies doesnot mean that the session variables won't exist. But every time the cookie-less user makes a page request, a new session id will be generated, along with a call to the Session_OnStart procedure. So there is, in effect, no persistence of the variables from page to page. What's worse, you're site will bombard them with requests to store a cookie on their system (one for every page that they hit). So, in the interest of a better user interface, a different approach might be called for.
The 'better' way would be to check to see if the user will even accept cookies before going too far into your web site. The technique to do this is quite simple. On one page, set a cookie on the user's browser. Then on a subsequent page, check for the presence of that cookie. If it's not there, then the user has disabled cookies, at which point you may want to warn them what they're in for.
As we've already mentioned Session variables are implemented as a collection
of values. As such, there is no practical limit to the number or type of variables
that can be stored. There are, however, technical reasons to limit the objects
that are stored. But more on that in the next section.
Comments