Normally I would not use a minor version release to put out
substantial new features, but mod_wsgi 4.0 is going to drag on for a
while yet, so didn't have much choice if wanted to get an updated
version out with things like Python 3.2+ and Apache 2.4 support.
The cumulative list of all the stuff that will be in mod_wsgi 3.4 can
be found at:
Because I back ported the changes quite quickly, it can all do with
some good testing and needs to be checked against the main Python and
Apache versions still. I will make a release candidate tar ball to
make that a bit easier task rather than relying on people having to
use Mercurial to get it from the source code repository. Before that
though there are still a few new changes I am looking at to integrate.
These changes are:
1. Means of turning on hash seed randomisation with recent updates of
Python. I still have a few issues to sort out here. I was supplied a
patch, but it doesn't go far enough and deal adequately with issues
like upgrading patch levels of Python against a mod_wsgi compiled
against an older version. It also didn't allow hash seeding, only
2. Means in authentication handler defined by WSGIUserScript of
overriding the value of REMOTE_USER that is then in turn passed onto
the WSGI application.
3. Changes to WSGI environ variable naming restrictions, used when
passing through headers to allow % such that can use % encoded header
values to pass through with encoded UTF-8. See as discussed in
There have bound to have been a few other features people have
requested and although I will try and go back through email and
tickets so see any that could be done, if there was something you were
waiting on, then speak up now.
My next likely chance to do any more work on this will be next weekend
so you have till then to give me your wish list items or to give any
feedback on the current code if you are able to test it by grabbing it
from the source code repo.
Attached is a patch that solves both of these problems.
This creates a WSGIPythonHashSeed option, which gets set to the
PYTHONHASHSEED environment variable. This option accepts either 'random'
or seed values 0-4294967295.
Needs to be a bit more complicated than that I suspect.
Because it can be set to a specific seed, I don't believe you can make
the assumption that one should allow that environment variable to be
inherited by sub process as that would then affected any Python
programs you might run from the process.
What I was likely to do was to set the environment variable, but defer
doing that until just before Python interpreter initialised. Then
after interpreter initialised, unset the environment variable from C
process level. This does though still leave it with os.environ of the
main interpreter, so may have to be removed manually from that.
The other thing contending with is whether you allow this to be set
differently for different daemon process groups, or just once globally
for the whole Apache and mod_wsgi daemon processes.
Attached is an updated patch that addresses both of these concerns.
It will now setenv right before Py_Initialize, and unsetenv right after.
It will also remove PYTHONHASHSEED from the os.environ when
newInterpreterObject is called. As for the WIN32 stuff, I'm just
> The other thing contending with is whether you allow this to be set
> differently for different daemon process groups, or just once globally
> for the whole Apache and mod_wsgi daemon processes.
With my limited knowledge of the mod_wsgi internals, I'm not quite sure
how this would be done.