I always wondered why there is this "feature" that is coded to call the serve every so often (1200 seconds, 20 minutes), so this evening I decided to dig and try to understand.
Going back to the SMF pre-1.0 code, the first commit message related to that code is:
and the javascript timeout was set to 600 seconds.
If I got this right, the problem would be posting times or any kind of "action" running for more than 20 minutes could result in a session timeout.
The session is deleted from the database if no activity is detected in "databaseSession_lifetime" or 60 seconds.
The install value of databaseSession_lifetime is 2880 that corresponds to 48 minutes.
A couple of thoughts.
1) 20 minutes of POSTing is likely to fail on most of the "normal" servers. Let alone 48.
2) To generate a POST longer than 20 minutes you have to upload... with my (not that fast) connection about 35MB. Yes, nowadays file are big, but
that big would choke most of the servers anyway and would fill up all the space in no time.
3) ...I forgot about it.
So, do you think I got it right?
What would you say if a pull request come up removing it? O:-) <= hypothetical question of course :P
posting vs POSTing, there is a difference.
You mean 20+ minutes on the post page?
I didn't think about that, good point...
meh. I have to find another way to get rid of that fake image in index.php then. :P
I'm sure I'm being naive here, but why does the session need to be kept alive? Is it not enough to validate the session cookie upon submitting the post?
The session lives in the database for about 48 minutes, then it is removed.
If you are writing a post and it takes you more than 48 minutes to write it, the checkSession security function will find no session and raise an "your session timeout" error.
True that this is a non-fatal error, so you'd just have to re-post the message, but some people my not notice the fact and "lose" the post, and maybe later complain that the post was removed/not posted.
I don't see a reason to remove it
The proper fix for this would be to have a two-stage posting process where you first fetch a fresh session token.