HTTP redirect when IDLE gets a certain value

There are a few ways to implement an idle timeout, and each depends on some specific characteristics of the application. Ultimately though, unless you're designing an elaborate PUSH mechanism (ie. Comet), some action must be performed by the client (PULL/REQUEST) for the server to respond with some action. Here are a few ideas.

 

 

1. Cookie - you can absolutely set quasi-relative expiration values in cookies. Access Policy Manager (APM) does this natively. You just need to rewrite the expiration value of the cookie on each HTTP response, which can be done in an iRule. The idea here would be that the user session would expire by virtue of the cookie missing after some length of idle time.

 

 

2. Session table - using some unique identifier (probably a cookie), you can set a session table entry that marks the last request made by a user. If the next request comes in after a specified timeout, you can take some action. The cookie/identifier itself must just be a unique value (ie. GUID) that can be used to identify a specific user session. The session table is updated on each request.

 

 

3. JavaScript in the browser - this is actually quite common. A small piece of JavaScript is inserted into each payload response that starts a timer on page load. At the end of the timer a message box can appear notifying the user of impending session expiration. The previous two ideas require some explicit action to be taken by the user - clicking a link after the session expired to see a result. To send a redirect with the previous methods, the user would have to actively do something in the browser first. Combining this method with either of the previous two (removing a cookie or deleting a session table entry), the user experience wouldn't necessarily need an explicit user action. To send a redirect with this method, the JavaScript code could either issue a redirect directly, or induce a non-interactive GET request causing the iRule (upon expired session) to issue a redirect.

 

 

In any case, you wouldn't use the IP::idle_timeout command, but rather some arbitrary expiration value and active "markers" placed either in a cookie, session table, JavaScript code, or a combination of each.