https://bz.apache.org/bugzilla/show_bug.cgi?id=57300

Paul Spangler <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #1 from Paul Spangler <[email protected]> ---
Created attachment 33017
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33017&action=edit
Proposed new directive SessionExpiryUpdateInterval

This patch adds a new directive to mod_session, SessionExpiryUpdateInterval,
similar to the description by Christoph. It defines the number of seconds that
the expiry value may change in a clean session without having to save the
session again.

It's added to mod_session instead of mod_session_dbd because the session
submodules don't have access to the original expiry value. It also has the
benefit of skipping session encoding/crypto. This change is disabled by
default, meaning sessions with expiry changes will be written every request
unless this directive is set.

By putting this in mod_session, it means submodules won't always receive a call
to save. So the Cache-Control headers must be set on session load, which I
would argue is more correct anyway, since the use of session data in processing
the request (e.g. form auth) should prevent caching, regardless of whether or
not the response contains session data.

The patch also includes a change to how sessions without a max age are saved.
Following the same logic that we don't need to write a session if the data
hasn't changed and the expiry has only changed by a small amount, we don't need
to write a session if the data hasn't changed and there is no expiry at all. In
this case, it's a behavior change that is not controlled by a directive.
Perhaps the most noticeable effect is that new sessions that are never written
to are never saved. For example, the presence of Session On without anything
that uses the session will no longer result in a session cookie.

I will attach a second patch containing the test changes.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to