httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Pearson <e...@adaptations.com>
Subject Re: mod_session and friends need some help
Date Thu, 30 Jan 2014 17:01:13 GMT
Good Morning Graham,

On Thu, Jan 30, 2014 at 1:48 AM, Graham Leggett <minfrin@sharp.fm> wrote:

> On 30 Jan 2014, at 3:32 AM, Erik Pearson <erik@adaptations.com> wrote:
>
> > 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?
>
> If you want to engage the community, you don't start with the position
> "everything's broken, and I demand you fix it for me". In this email alone
> you list functionality that you insist doesn't exist but does, you list
> feature requests, you list bugs that apparently exist but aren't
> articulated well enough to do anything to fix, and you're arguing that we
> should change the underlying design.
>
> Please identify one specific issue that reflects your need, and keep on
> topic with that issue until it is resolved.
>

I'm sorry if that came off with the wrong attitude! I thought I was
responding in a repartee fashion. The point I was first trying to make is
that there are some rather fundamental changes that I have made to
mod_session and friends, in order to fit my application requirements, and,
contrary to my instincts and the advice I had received on the list, I don't
think it can be handled (if it were to be contributed back to the project)
as piecemeal, single-issue diffs.

On this specific sub-thread, you chose to single out a single topic. When
you asked "I'm not following the problem you're trying to solve.", I chose
to list the number of enhancements and bugs that I've encountered over a
few days of working on the mod_session and friends code. I'm sorry, I
didn't mean that to be taken as piling on, but merely to show that I've
thought and worked hard on this issue,  that my concerns are not trivial,
and that this single issue (where the "name" for a session is configured)
is just one small part of a larger puzzle.

Really, seriously, I''m humbled by the entire Apache httpd project -- I am
merely stumbling along my path, stubbornly attempting to solve the
challenges between me and the successful implementation of this project.


>
> > 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)?
>
> Yes there is, please familiarise yourself with per user sessions:
> http://httpd.apache.org/docs/2.4/mod/mod_session_dbd.html#peruser


I'm aware of the "per user" mode of mod_session_dbd -- my wording was
careful, since mod_session_dbd includes cookies as a strategy. Whereas I
was at first puzzled to discover per user mode, since it turns the session
on its head, I now think it is a clever and very specific type of session,
at the one extreme it is a lightweight user account. But I won't go off
topic -- I still don't see that any session storage submodule won't support
the session cookie as a method of sticking to a browser (while they may
also support other methods).

Cheers, Erik.



>
>
> Regards,
> Graham
> --
>
>


-- 
Erik Pearson
Adaptations
;; web form and function

Mime
View raw message