Quick question for you web programmers. I have a web form that is rather long. It's hosted on godaddy linux hosting. The issue I have is that the session timeout seems to be quite short (1-2 minutes). This is far too short for an end user to be able to fill out the form and submit it before the session times out and an error is thrown. Of course, at this point, all the user's work is now lost.

Is there a way to do a keepalive that will maintain a session's activity WITHOUT refreshing the entire page? (Tried that, it resets all form fields on a refresh)

Any help or even just pointers would be appreciated!

Mason

Oh, if it helps, the form is HERE

It isn't clear why there would be a session involved at all. Seems very odd.

Also, many years since I saw a webform with a reset button

I see the error now:

"Your request timed out. Please retry the request"

I also see that you are using FormMail.pl, I'm pretty sure that FormMail.pl doesn't care about any sort of session, something else it going wrong.

If I were you I'd be tempted to use the forms functionality of Google Docs Spreadsheet instead.

Also, if you really are going to use formmail.pl, make very sure that you have set @recipients value in the Perl file. Otherwise it can be used as a spam gateway.

Thanks for the replies. I definitely set the @recipients value. I have also set the @referrer value as well.

It's just a little weird. I have been using this script for 10+ years without ANY issue at all. Now that I have moved jobs, I needed a different place to host the CGI, hence godaddy. Now all of a sudden I'm getting that weird timeout issue. I have no idea why it's seeing it as an error when it submits. What I was hoping to do was force a refresh on a transparent single pixel image every 45 seconds or so to prevent the timeout. Obviously, if the entire page is refreshed, whatever data has been entered at that point is lost. Bizarre.

You can change that form so that each time a value from any pop-up is chosen everything else is saved. This can also be done on a refresh or outright submit - there's no reason to have to lose the contents already entered. That might mitigate the contents being lost. You can also use javascript to periodically save, but that's not something I've implemented myself, so I don't have any person feedback to give about it.

An easy way to do it is to post all the variables back to the page itself when the refresh or submit happens.

You can also use a session file to save everything and load it back when the form resets/submits. I do either of these in all my PHP forms to keep them self-contained (as opposed to some scripts passing off data to another script, etc.)

With regards to the timeout, I can't say for certain without seeing the code (don't know if anyone else can either). A plain HTML form doesn't have a time limit of any kind that I know of, so there's something else at play here. Do you have any database access? Third-party library access? There's probably some session/cookie data being used for security and that's likely now in conflict with the server settings at GoDaddy (Perl/Apache, etc.. config files)

Whenever I see something like that, it usually means that the new web server has a different configuration than the old one, for instance, a different setting configured, a different version of Apache, a different version of Perl, some kind of different library installed, that sort of thing. I'd be looking in those areas for the source of the issue. If you can find that, you might not need a "refresher" trick.

It is a well known bit of code:

http://www.scriptarchive.com/download.cgi?s=formmail&c=txt&f=FormMail.pl

I know Matt's formmail - old and deprecated. I'm wondering if there is anything _else_ added to it which may be responsible for the effects being seen.

Oh, I forgot one thing.... If nothing has changed in the script, you might try contacting GoDaddy about this. It may very well be something they already know about and can offer a recommendation/solution for.

Ewwkay. FYI, I HAD contacted Godaddy, but their help was less than stellar. Basically the guy said "We can't help with custom scripting." While I understand this, I wasn't REALLY asking about a script problem.

As to the script being depricated, who cares? It works and works well. And my wife fully understands it. (In other words, I don't have to do the coding. She can!)

I was able to get around the issue with the following code:



I let it sit for 20 minutes, and poked around doing other things in the mean time, and it all worked fine. Thanks for all the input guys. Much appreciated!

Tony, I agree. The old server I had complete control over. On the new server, I have basically none. I HATE that part of hosted accounts. But for the price, I can't really argue. Especially since I'm doing it gratis for a non-profit.

That's the most polite thing I've ever seen written about that steaming pile of trash.

I didn't think it was relevant to discuss the merits of the script itself, that's why I didn't bring it up in the first place. But you know me, always trying to be politically correct.

It was the lack of trash talk that made me suspect you didn't know the script and hence posted the source

Ok ok... Y'all can quit ripping on the script I use now.

Only if you promise to switch to the recommended, drop-in replacement.

I've had the Perl Mongers alternative running on my parents' site since 2003 without an issue.

I still prefer my own bespoke solution for my own sites, but then that doesn't have to be so generic and accommodate plugging in to someone else's page structure.

Consider it replaced... I just didn't want to have to redo all those forms. It would seem I won't have to. So cool!