ASP Timeouts

Discussion in 'Classic ASP' started by dgray, Dec 29, 2003.

Thread Status:
Threads that have been inactive for 5 years or longer are closed to further replies. Please start a new thread.
  1. Hi - I am using ASP sessions to control updates to my site. On our previous host, the ASP session timeouts were respected. Here, my settings seem to be ignored in favor of a 2 or 3 minute timeout. If it takes longer than a couple minutes to update a form, the session information is lost and they have to start over. Very frustrating, to say the least.

    Did I miss some other setting that I need for my session timeout settings to be honored?

    thanks,
    Darrell
     
  2. Darrell,

    Add the following to your script(s):

    Server.ScriptTimeout = 3600

    I had the same problem with a script timing out and adding the above statement solved the problem.

    I hope this helps.

    Brad
     
  3. Brad -

    Thanks for the suggestion, but is the users, not the server that is timing out. If they wait too long before clicking to another page or a submit button, their session is dropped and they have to log in again. It gets really annoying when they are filling out a form and lose the contents because their session is gone again.

    I am using Session.Timeout = 20, which worked on our last host. Long enough for most of them to be happy. But it doesn't work here.

    thanks,
    Darrell
     
  4. dgray,

    I think the session timeout at DASP is set to 10 minutes for performance reasons. A value which I believe you cannot override. However, with a small trick, you can make sure that the sessions won't timeout.

    Just include an iFrame in each of your pages, with dimensions of 0 px. The source of the iframe is an asp-page, which reloads itself (using the <meta http-equiv="refresh">-tag.)

    For instance :
    in each page, you include
    <iframe src="dummy.asp" width=0 height=0></iframe>

    then you have the dummy.asp page:
     
  5. Thanks Steurm,

    Clever solution and it seems to do the trick so far.

    regards,
    Darrell
     
  6. Better how?

    The sessions are there whether I use them or not. I don't stuff a lot of data into them, but I do use them to check status. I don't see the advantage of moving that information into cookies. A little less memory for session variables, a little more memory and processing for handling the cookies info.

    Significant size chunks of data go in a database, not in session variables or cookies. I hate to see people lose anything because they closed their browser or lost their line.

    Darrell
     
  7. quote:Originally posted by dgray

    Thanks Steurm,

    Clever solution and it seems to do the trick so far.

    regards,
    Darrell
    </blockquote id="quote"></font id="quote">

    if you know how to, it is better to use cookies whenever you can, instead of sessions.
     
  8. quote:if you know how to, it is better to use cookies whenever you can, instead of sessions.</blockquote id="quote"></font id="quote">
    Exept when the user disabled (non-session) cookies ...
    I think dgray has a point : if not to much data, there is no reason why you shouldn't use sessions I think.

    --
    Steurm
    www.steurm.net/steurm
     
  9. quote:dgray,

    I think the session timeout at DASP is set to 10 minutes for performance reasons. A value which I believe you cannot override. However, with a small trick, you can make sure that the sessions won't timeout.

    Just include an iFrame in each of your pages, with dimensions of 0 px. The source of the iframe is an asp-page, which reloads itself (using the <meta http-equiv="refresh">-tag.)

    For instance :
    in each page, you include
    <iframe src="dummy.asp" width=0 height=0></iframe>

    then you have the dummy.asp page:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >

    <html>
    <head>
    <title>dummy</title>
    <meta http-equiv="refresh" content="120,dummy.asp">
    </head>

    </body>
    </html>


    Since this dummy.asp page is an asp-page, refreshing it (here it reloads every 2 minutes) will keep your sessions alive.

    Hope this helps


    --
    Steurm
    www.steurm.net/steurm</blockquote id="quote"></font id="quote">
    be carefull when trying to use this solution in .NET ... you create a DOS-attack on your own site ... [:I]

    I'll explain myself. My website is secured by forms-authentication. So when trying to reach a page within the secure zone, you will first be redirected to the loginpage to be authenticated. I made the mistake to put the 'keep-my-sessions-alive' functionality (the use of the iframe which reloads) on the login-page (it uses the same footer as the rest of the application) and the page which is reloaded was in the secure zone. So the reloaded page (dummy.aspx) was redirected to the login-page and so it created an infinite loop, resulting in a very high number of requests and in the end putting down the website, because there were too much (way to much!) connections.

    So, just to be sure:
    <ul>[*] do not put the 'keep-my-sessions-alive' functionality on your login page [*] put the page which is reloaded in an unprotected directory [/list]



    --
    Steurm
    www.steurm.net/steurm
     
  10. quote:Originally posted by steurm

    quote:if you know how to, it is better to use cookies whenever you can, instead of sessions.</blockquote id="quote"></font id="quote">
    Exept when the user disabled (non-session) cookies ...
    I think dgray has a point : if not to much data, there is no reason why you shouldn't use sessions I think.

    --
    Steurm
    www.steurm.net/steurm
    </blockquote id="quote"></font id="quote">
     
  11. Thanks for the iframe solution! This really helped me out.

    For those who don't want that ugly black square to appear in mozilla/gecko browsers, just add the following tag to concreal its presence:
    frameborder="0"

    Cheers,
    Shaun



    -Shaun
     
Thread Status:
Threads that have been inactive for 5 years or longer are closed to further replies. Please start a new thread.

Share This Page