We have a PCI application that is interested in occassionally making calls to find out the 'real' idle-timeout value remaining in the SMSESSION. So a header named HTTP_SM_IDLE_TIMETOEXPIRE could be returned on a URI that does not update the session.
I recently opened a case (00452096) and received excellent support as usual. Part of my posting here too is to understand better what others are doing to accurately reflect the 'real' idle timeout remaining in the user's browser.
Aside: This application will make calls to an URL that forces the idle timeout to be 'reset.' This is done to reflect (update) in the SMSESSION browser-side activity the application considers to be valid activity.
The application can set an idle timeout value in the browser but there is some concern this could get out of synch from the real idle timeout value in the session. (One reason is this application spans multiple web servers/platforms.) With an idle timeout header the application would be able to periodically synch the timers between the browser and the SMSESSION.
This application spans multiple country-level domains (TLDs). So a cookie provider will be used too. But I think we are good with how the cookie provider logic works to update the session in the cookie provider domain.
Bottom line: If there's a way to 'synch' the idle-timeout values between the browser's counter and the real idle-timeout value in the SMSESSION this would be powerful for sure. I'm also open to other ideas that I may have overlooked.
Thanks for the excellent feedback by all -- it is greatly appreciated!