Bug 56041 - should be able to disable session expiry increment
Summary: should be able to disable session expiry increment
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_session (show other bugs)
Version: 2.4.7
Hardware: PC Linux
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-21 00:32 UTC by Erik Pearson
Modified: 2014-01-21 22:35 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Pearson 2014-01-21 00:32:47 UTC
A common use case, is for client side web apps to provide a constantly refreshed display. The display could be refreshed, for example, with data fetched periodically from the web server. This functionality is used to keep a display updated with changes on the server, such as graphs, tables, messages, etc. 

In the context of an authenticated web page, in which the original page view and subsequent ajax calls all need to be authenticated, the session mechanism will currently update the session cookie with each request, and the expiry time parameter will continually "keep up" with real time. In many cases the web app requirements are that the expiry time should remain at the time when the primary page was provided to the client, with subsequent ajax fetches not updating the expiry. This would provide the experience most people would expect for an authenticated web page left unattended: It will eventually time out.

Another use case is the ability for a client web app to query the server for authentication state, in order to provide a smooth user experience for re-login or a timeout page. Clearly such a server query needs to be included in the authentication realm, yet not affect the expiry of the session.

There would be different ways of implementing this. There could be a server config directive to inhibit expiry incrementing per some sort of path match (e.g. within a LocationMatch). I don't know enough about internals to know the best technical direction.

Another approach, one that would be handy for client web app developers, would be a request header field which would inhibit expiry incrementing.

Another use case would be the ability to give the end user the option of "staying logged in", enabled by a user interface prompt. This would be facilitated by a server request that would be intended to refresh the session and bring the expiry up to date. This could be accomplished either by a specific end-point, configured on the server, or by a header field recognized by mod_session (or friends.)
Comment 1 Erik Pearson 2014-01-21 22:35:22 UTC
I've made a first pass, adding a configuration parameter SessionRefreshExpiry. This config can be set directly in a config file, or set via an If config, triggered on a request header field. I tested with a header field named "X-Session-Refresh-Expiry". Both direct config and via If behave as expected.

I have another couple of changes to sessions that I need for my current project. One has been submitted in bugzilla as an enhancement (need to have cookie with "session" lifetime), and another not submitted yet (need "hard lifetime" of session -- the session may not live longer than this time limit.)

Is it better to submit these as additional patches or as one unified patch? They involve the same set of files or at least overlap -- I don't know enough about svn to determine how difficult it is to manage multiple patches as the codebase is progressively modified without checkin...