httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Pearson <>
Subject Re: mod_session and friends need some help
Date Thu, 30 Jan 2014 01:32:35 GMT
Hi Graham,

On Wed, Jan 29, 2014 at 2:51 PM, Graham Leggett <> wrote:

> On 29 Jan 2014, at 11:17 PM, Erik Pearson <> wrote:
> > Actually, the more I've delved and actually used mod_session and
> friends, the more fundamental the changes have become. For instance, a lot
> of the code that lives in mod_session_cookie and mod_session_dbd seems more
> appropriate for mod_cookie -- including session name, session caching,
> session object creation. With such changes, it is quite difficult to
> isolate into single issue diffs.
> I'm not following the problem you're trying to solve.

- adding the ability to have "session" cookies (that die when the browser
is restarted)
- adding the ability to disable session renewal (i.e. leave the expiry
alone) - important for allowing things like ajax connections to not keep
the session alive artificially.
- add expiry to the env so that web apps can determine the amount of time
left in the session -- for user interface features.

- a bug in mod_session involving session decrypting after a changed key
- a bug in session caching that causes session consumers (e.g.
mod_auth_form) to receive the wrong session object (which just points out
the problem with having the storage modules manage session caching and
session object creation).

- simplifying session configuration: moving session name to mod_session
allows removing the name configuration altogether, simplify cookie
configuration by separating cookie attributes from cookie name.

> It seems you're trying to rearrange and group technologies together from a
> programmer's perspective, instead of grouping functionality together from
> an end user's perspective.

Au contraire -- most of the changes I'm making are driven by the
application need, not just to clean up the code. Of course I do also have
an interest in the design of the modules, from a programmer's perspective.
But isn't this the forum for such considerations?

> Right now, if an end user wants to store a session in a datastore of some
> kind, in the classic "application server" model, storing a reference to
> that session in a cookie, they enable mod_session_dbd. If instead the end
> user wants to store the whole session in the body of a cookie on the
> client, they enable mod_session_cookie. In future, should the end user want
> to store a session in memory, they might use a future mod_session_socache.
> What you seem to want to do is combine mod_session_cookie and
> mod_session_dbd, simply because a cookie is involved in both.

All I really did was to recognize that there is a pattern in any storage
module which uses a cookie to associate a browser with a session -- the
session name. Rather than have each storage module mod_session_foo
implement this config item as SessionFooCookieName, why not make it a core
property of a session? And once you do that, why not just default that to
some sensible string like "mod_session"? Is there, realistically, a session
storage module that would not use cookies as a browser association method
(at least as an option)?

This simplifies the storage modules, both in code and configuration.

> That doesn't make life easier for end users, who are only interested in
> getting a job done.

Aye, it has already simplified my configuration and made my life easier,
other than having to slog through the code. But, seriously, as an end user,
it is just a minor config change.

Frankly, I don't think most end users care to give the session a name at
all, and when they do, don't give a hoot whether it is SessionName or
SessionCookieName. They may well appreciate a standard name as a default,
like "mod_session", or "apache_session" or some such thing that would be
recognizable when inspecting cookies in a browser. The current
implementation requires the end user to provide a cookie name, and
conflates cookie name with cookie properties.

Of course, there may be use cases that the current implementation is
designed to address. That is what I'm hoping will come out of the woodwork,
for it is not documented in the code.


> Regards,
> Graham
> --

Erik Pearson
;; web form and function

View raw message