=============
Version 4.2.4
=============
Version 4.2.4 of mod_wsgi can be obtained from:
https://github.com/GrahamDumpleton/mod_wsgi/archive/4.2.4.tar.gz
Bugs Fixed
----------
1. Fixed one off error in applying limit to the number of supplementary
groups allowed for a daemon process group. The result could be that if
more groups than the operating system allowed were specified to the option
``supplementary-groups``, then memory corruption or a process crash could
occur.
2. Improved error handling in setting up the current working directory and
group access rights for a process when creating a daemon process group. The
change means that if any error occurs that the daemon process group will be
restarted rather than allow it to keep running with an incorrect working
directory or group access rights.
New Features
------------
1. Added the ``--setup-only`` option to mod_wsgi express so that it is
possible to create the configuration when using the Django management command
``runmodwsgi`` without actually starting the server.
=============
Version 4.2.3
=============
Version 4.2.3 of mod_wsgi can be obtained from:
https://github.com/GrahamDumpleton/mod_wsgi/archive/4.2.3.tar.gz
Bugs Fixed
----------
1. The feature for starting mod_wsgi express using the Django management
command ``runmodwsgi`` was broken by the 4.2.2 release.
=============
Version 4.2.2
=============
Version 4.2.2 of mod_wsgi can be obtained from:
https://github.com/GrahamDumpleton/mod_wsgi/archive/4.2.2.tar.gz
Bugs Fixed
----------
1. The ``envvars`` file was being overwritten even if it existed and had
been modified.
New Features
------------
1. Output the location of the ``envvars`` file when using the
``setup-server`` command for ``mod_wsgi-express`` or if using the
``start-server`` command and the ``--envars-script`` option was being used.
2. Output the location of the ``apachectl`` script when using the
``setup-server`` command for ``mod_wsgi-express``.
=============
Version 4.2.1
=============
Version 4.2.1 of mod_wsgi can be obtained from:
https://github.com/GrahamDumpleton/mod_wsgi/archive/4.2.1.tar.gz
Bugs Fixed
----------
1. The auto generated configuration would not work with an Apache
installation where core Apache modules were statically compiled into Apache
rather than being dynamically loaded.
=============
Version 4.2.0
=============
Version 4.2.0 of mod_wsgi can be obtained from:
https://github.com/GrahamDumpleton/mod_wsgi/archive/4.2.0.tar.gz
New Features
------------
1. Added ``mod_wsgi.server_metrics()`` function which provides access to a
dictionary of data derived from the Apache worker scoreboard. In effect this
provides access to the same information that is used to create the Apache
server status page.
Note that if ``mod_status`` is not loaded into Apache, or the compile time
configuration of Apache prohibits the scoreboard from being available, this
function will return ``None``.
Also be aware that only partial information about worker status, and no
information about requests, will be returned if the ``ExtendedStatus``
directive is not also set to ``On``.
Although ``mod_status`` needs to be loaded, it is not necessary to enable
any URL to expose the server status page.
2. Added support for a platform plugin for New Relic to ``mod_wsgi-express``
which will report server status information up to New Relic if the
``--with-newrelic`` option is supplied when running mod_wsgi express.
That same option also enables the New Relic Python agent. If you only want
one or the other, you can instead use the ``--with-newrelic-agent`` and
``--with-newrelic-platform`` options.
The feature of ``mod_wsgi-express`` for reporting data up to the New Relic
Platform is dependent upon the separate ``mod_wsgi-metrics`` package being
installed.
4.1.3
Known Issues
1. The makefiles for building mod_wsgi on Windows are currently
broken and need updating. As most new changes relate to mod_wsgi
daemon mode, which is not supported under Windows, you should keep
using the last available binary for version 3.X on Windows instead.
Bugs Fixed
1. The setup.py file wasnât always detecting the Python library
version suffix properly when setting it up to be linked into the
resulting mod_wsgi.so. This would cause an error message at link
time of:
4.1.2
Bugs Fixed
1. The integration for Django management command was looking for
the wrong name for the admin script to start mod_wsgi express.
2. The code which connected to the mod_wsgi daemon process was
passing an incorrect size into the connect() call for the size of
the address structure. On some Linux systems this would cause an
error similar to:
(22)Invalid argument: mod_wsgi (pid=22944): Unable to connect to
\
WSGI daemon process 'localhost:8000' on \
'/tmp/mod_wsgi-localhost:8000:12145/wsgi.22942.0.1.sock'
This issue was only introduced in 4.1.0 and does not affect older
versions.
3. The deadlock detection thread could try and acquire the Python
GIL after the Python interpreter had been destroyed on Python
shutdown resulting in the process crashing. This issue cannot be
completely eliminated, but the deadlock thread will now at least
check whether the flag indicating process shutdown is happening
has been set before trying to acquire the Python GIL
4.1.1
Bugs Fixed
1. Compilation would fail on Apache 2.4 due to a change in the
Apache API to determine the name of the MPM being used.
4.1.0
Bugs Fixed
1. If a UNIX signal received by daemon mode process while still
being initialised to signal that it should be shutdown, the process
could crash rather than shutdown properly due to not registering
the signal pipe prior to registering signal handler.
2. Python doesnât initialise codecs in sub interpreters automatically
which in some cases could cause code running in WSGI script to fail
due to lack of encoding for Unicode strings when converting them.
The error message in this case was:
LookupError: no codec search functions registered: can't find
encoding
The âasciiâ encoding is now forcibly loaded when initialising sub
interpreters to get Python to initialise codecs.
3. Fixed reference counting bug under Python 3 in SSL var_lookup()
function which can be used from an auth handler to look up SSL
variables.
4. The WWW-Authenticate headers returned from a WSGI application
when run under daemon mode are now always preserved as is.
Because of previously using an internal routine of Apache, way back
in time the values of multiple WWW-Authenticate headers would be
merged when there was more than one. This would cause an issue with
some browsers.
A workaround was subsequently implemented above the Apache routine
to break apart the merged header to create separate ones again,
however, if the value of a header validly had a â,â in it, this
would cause the header value to be broken apart where it wasnât
meant to. This could issues with some type of WWW-Authenticate
headers.
Features Removed
1. No longer support the use of mod_python in conjunction with
mod_wsgi. When this is attempted an error is forced and Apache will
not be able to start. An error message is logged in main Apache
error log.
2. No longer support the use of Apache 1.3. Minimum requirement is
now Apache 2.0.
Features Changed
1. Use of kernel sendfile() function by wsgi.file_wrapper is now
off by default. This was originally always on for embedded mode
and completely disabled for daemon mode. Use of this feature can
be enabled for either mode using WSGIEnableSendfile directive,
setting it to On to enable it.
The default is now off because kernel sendfile() is not always able
to work on all file objects. Some instances where it will not work
are described for the Apache EnableSendfile directive.
http://httpd.apache.org/docs/2.2/mod/core.html#enablesendfile
Although Apache has use of sendfile() enabled by default for static
files, they are moving to having it off by default in future version
of Apache. This change is being made because of the problems which
arise and users not knowing how to debug it and solve it.
Thus also erring on side of caution and having it off by default
but allowing more knowledgeable users to enable it where they know
always using file objects which will work with sendfile().
2. The HTTPS variable is no longer set within the WSGI environment.
The authoritative indicator of whether a SSL connection is used is
wsgi.url_scheme and a WSGI compliant application should check for
wsgi.url_scheme. The only reason that HTTPS was supplied at all
was because early Django versions supporting WSGI interface werenât
correctly using wsgi.url_scheme. Instead they were expecting to
see HTTPS to exist.
This change will cause non conformant WSGI applications to finally
break. This possibly includes some Django versions prior to Django
version 1.0.
Note that you can still set HTTPS in Apache configuration using
the SetEnv or SetEnvIf directive, or via a rewrite rule. In that
case, that will override what wsgi.url_scheme is set to and once
wsgi.url_scheme is set appropriately, the HTTPS variable will be
removed from the set of variables passed through to the WSGI
environment.
3. The wsgi.version variable has been reverted to 1.0 to conform
to the WSGI PEP 3333 specification. It was originally set to 1.1
on expectation that revised specification would use 1.1 but that
didnât come to be.
4. The inactivity-timeout option to WSGIDaemonProcess now only
results in the daemon process being restarted after the idle timeout
period where there are no active requests. Previously it would also
interrupt a long running request. See the new request-timeout option
for a way of interrupting long running, potentially blocked requests
and restarting the process.
5. If the home option is used with WSGIDaemonProcess, in addition
to that directory being made the current working directory for the
process, an empty string will be added to the start of the Python
module search path. This causes Python to look in the current
working directory for Python modules when they are being imported.
This behaviour brings things into line with what happens when
running the Python interpreter from the command line. You must
though be using the home option for this to come into play.
Do not that if your application then changes the working directory,
it will start looking in the new current working directory and not
that which is specified by the home option. This again mirrors what
the normal Python command line interpreter does.
New Features
1. Add supplementary-groups option to WSGIDaemonProcess to allow
group membership to be overridden and specified comma separate list
of groups used instead.
2. Add a graceful-timeout option to WSGIDaemonProcess. This option
is applied in a number of circumstances.
When maximum-requests and this option are used together, when
maximum requests is reached, rather than immediately shutdown,
potentially interupting active requests if they donât finished with
shutdown timeout, can specify a separate graceful shutdown period.
If the all requests are completed within this time frame then will
shutdown immediately, otherwise normal forced shutdown kicks in.
In some respects this is just allowing a separate shutdown timeout
on cases where requests could be interrupted and could avoid it if
possible.
When cpu-time-limit and this option are used together, when CPU
time limit reached, rather than immediately shutdown, potentially
interupting active requests if they donât finished with shutdown
timeout, can specify a separate graceful shutdown period.
3. Add potentially graceful process restart option for daemon
processes when sent a graceful restart signal. Signal is usually
SIGUSR1 but is platform dependent as using same signal as Apache
would use. If the graceful-timeout option had been provided to
WSGIDaemonProcess, then the process will attempt graceful shutdown
first based on the that timeout, otherwise normal shutdown procedure
used as if received a SIGTERM.
4. Add memory-limit option to WSGIDaemonProcess to allow memory
usage of daemon processes to be restricted. This will have no affect
on some platforms as RLIMIT_AS/RLIMIT_DATA with setrlimit() isnât
always implemented. For example MacOS X and older Linux kernel
versions do not implement this feature. You will need to test
whether this feature works or not before depending on it.
5. Add virtual-memory-limit option to WSGIDaemonProcess to allow
virtual memory usage of daemon processes to be restricted. This
will have no affect on some platforms as RLIMIT_VMEM with setrlimit()
isnât always implemented. You will need to test whether this feature
works or not before depending on it.
6. Access, authentication and authorisation hooks now have additional
keys in the environ dictionary for mod_ssl.is_https and
mod_ssl.var_lookup. These equate to callable functions provided by
mod_ssl for determining if the client connection to Apache used
SSL and what the values of variables specified in the SSL certifcates,
server or client, are. These are only available if Apache 2.0 or
later is being used.
7. For Python 2.6 and above, the WSGIDontWriteBytecode directive
can be used at global scope in Apache configuration to disable
writing of all byte code files, ie., .pyc, by the Python interpreter
when it imports Python code files. To disable writing of byte code
files, set directive to On.
Note that this doesnât prevent existing byte code files on disk
being used in preference to the corresponding Python code files.
Thus you should first remove .pyc files from web application
directories if relying on this option to ensure that .py file is
always used.
8. Add request-timeout option to WSGIDaemonProcess to allow a
separate timeout to be applied on how long a request is allowed to
run for before the daemon process is automatically restarted to
interrupt the request.
This is to counter the possibility that a request may become blocked
on some backend service, thereby using up available requests threads
and preventing other requests to be handled.
In the case of a single threaded process, then the timeout will
happen at the specified time duration from the start of the request
being handled.
Applying such a timeout in the case of a multithreaded process is
more problematic as doing a restart when a single requests exceeds
the timeout could unduly interfere with with requests which just
commenced.
In the case of a multi threaded process, what is instead done is
to take the total of the current running time of all requests and
divide that by the number of threads handling requests in that
process. When this average time exceeds the time specified, then
the process will be restarted.
This strategy for a multithreaded process means that individual
requests can actually run longer than the specified timeout and a
restart will only be performed when the overall capacity of the
processes appears to be getting consumed by a number of concurrent
long running requests, or when a specific requests has been blocked
for an excessively long time.
The intent of this is to allow the process to still keep handling
requests and only perform a restart when the available capacity of
the process to handle more requests looks to be potentially on the
decline.
9. Add connect-timeout option to WSGIDaemonProcess to allow a
timeout to be specified on how long the Apache child worker processes
should wait on being able to obtain a connection to the mod_wsgi
daemon process.
As UNIX domain sockets are used, connections should always succeed,
however there have been some incidences seen which could only be
explained by the operating system hanging on the initial connect
call without being added to the daemon process socket listener
queue. As such the timeout has been added. The timeout defaults to
15 seconds.
This timeout also now dictates how long the Apache child worker
process will attempt to get a connection to the daemon process when
the connection is refused due to the daemon socket listener queue
being full. Previously how long connection attempts were tried was
based on an internal retry count rather than a configurable timeout.
10. Add socket-timeout option to WSGIDaemonProcess to allow the
timeout on indvidual read/writes on the socket connection between
the Apache child worker and the daemon process to be specified
separately to the Apache Timeout directive.
If this option is not specified, it will default to the value of
the Apache Timeout directive.
11. Add queue-timeout option to WSGIDaemonProcess to allow a request
to be aborted if it never got handed off to a mod_wsgi daemon
process within the specified time. When this occurs a â503 Service
Unavailableâ response will be returned.
This is to allow one to control what to do when backlogging of
requests occurs. If the daemon process is overloaded and getting
behind, then it is more than likely that a user will have given up
on the request anyway if they have to wait too long. This option
allows you to specify that a request that was queued up waiting
for too long is discarded, allowing any transient backlog to be
quickly discarded and not simply cause the daemon process to become
even more backlogged.
12. Add listen-backlog option to WSGIDaemonProcess to allow the
daemon process socket listener backlog size to be specified. By
default this limit is 100, although this is actually a hint, as
different operating systems can have different limits on the maximum
value or otherwise treat it in special ways.
13. Add WSGIPythonHashSeed directive to allow Python behaviour
related to initial hash seed to be overridden when the interpreter
supports it.
This is equivalent to setting the PYTHONHASHSEED environment variable
and should be set to either random or a number in the range in
range [0; 4294967295].
14. Implemented a new streamlined way of installing mod_wsgi as a
Python package using a setup.py file or from PyPi. This includes
a mod_wsgi-express script that can then be used to start up
Apache/mod_wsgi with an auto generated configuration on port 8000.
This makes it easy to run up Apache for development without
interfering with the main Apache on the system and without having
to worry about configuring Apache. Command line options can be used
to override behaviour.
Once the mod_wsgi package has been installed into your Python
installation, you can run:
mod_wsgi-express start-server
Then open your browser on the listed URL. This will verify that
everything is working. Enter CTRL-C to exit the server and shut it
down.
You can now point it at a specific WSGI application script file:
mod_wsgi-express start-server wsgi.py
For options run:
mod_wsgi-express start-server --help
If you already have another web server running on port 8000, you
can override the port to be used using the --port option:
mod_wsgi-express start-server wsgi.py --port 8001
15. Implemented a Django application plugin to add a runmodwsgi
command to the Django management command script. This allows the
automatic run up of the new mod_wsgi express script, with it hosting
the Django web site the plugin was added to.
To enable, once the mod_wsgi package has been installed into your
Python installation, add mod_wsgi.server to the INSTALLED_APPS
setting in your Django settings file.
After having run the collectstatic Django management command, you
can then run:
python manage.py runmodwsgi
For options run:
python manage.py runmodwsgi --help
To enable automatic code reloading in a development setting, use
the option:
python manage.py runmodwsgi --reload-on-changes
16. The maximum size that a response header/value can be that is
returned from a WSGI application under daemon mode can now be
configured. The default size has also now been increased from 8192
bytes to 32768 bytes. The name of the option to WSGIDaemonProcess
to set the buffer size used is header-buffer-size.
Security Issues
Local privilege escalation when using daemon mode. (CVE-2014-0240)
The issue is believed to affect Linux systems running kernel versions
>= 2.6.0 and < 3.1.0.
The issue affects all versions of mod_wsgi up to and including
version 3.4.
The source of the issue derives from mod_wsgi not correctly handling
Linux specific error codes from setuid(), which differ to what
would be expected to be returned by UNIX systems conforming to the
Open Group UNIX specification for setuid().
http://man7.org/linux/man-pages/man2/setuid.2.htmlhttp://pubs.opengroup.org/onlinepubs/009695399/functions/setuid.html
This difference in behaviour between Linux and the UNIX specification
was believed to have been removed in version 3.1.0 of the Linux
kernel.
https://groups.google.com/forum/?fromgroups=#!topic/linux.kernel/u6cKf4D1D-k
The issue would allow a user, where Apache is initially being
started as the root user and where running code under mod_wsgi
daemon mode as an unprivileged user, to manipulate the number of
processes run by that user to affect the outcome of setuid() when
daemon mode processes are forked and so gain escalated privileges
for the users code.
Due to the nature of the issue, if you provide a service or allow
untrusted users to run Python web applications you do not control
the code for, and do so using daemon mode of mod_wsgi, you should
update mod_wsgi as soon as possible.
Bugs Fixed
1. Python 3 installations can add a suffix to the Python library.
So instead of libpythonX.Y.so it can be libpythonX.Ym.so.
2. When using daemon mode, if an uncaught exception occurred when
handling a request, when response was proxied back via the Apache
child process, an internal value for the HTTP status line was not
cleared correctly. This was resulting in a HTTP status in response
to client of â200 Errorâ rather than â500 Internal Server Errorâ.
Note that this only affected the status line and not the actual
HTTP status. The status would still be 500 and the client would
still interpret it as a failed request.
3. Null out Apache scoreboard handle in daemon processes for Apache
2.4 to avoid process crash when lingering close cleanup occurs.
4. Workaround broken MacOS X XCode Toolchain references in Apache
apxs build configuration tool and operating system libtool script.
This means it is no longer necessary to manually go into:
Applications/Xcode.app/Contents/Developer/Toolchains
and manually add symlinks to define the true location of the compiler
tools.
Restore ability to compile mod_wsgi source code under Apache
1.3.
6. Fix checks for whether the ITK MPM is used and whether ITK MPM
specific actions should be taken around the ownership of the mod_wsgi
daemon process listener socket.
7. Fix issue where when using Python 3.4, mod_wsgi daemon processes
would actually crash when the processes were being shutdown.
8. Made traditional library linking the default on MacOS X. If
needing framework style linking for the Python framework, then use
the --enable-framework option. The existing --disable-framework
has now been removed given that the default action has been swapped
around.
New Features
1. For Linux 2.4 and later, enable ability of daemon processes to
dump core files when Apache CoreDumpDirectory directive used.
2. Attempt to log whether daemon process exited normally or was
killed off by an unexpected signal.
either because they themselves are not ready or because a
dependency isn't. This is annotated by
PYTHON_VERSIONS_INCOMPATIBLE= 33 # not yet ported as of x.y.z
or
PYTHON_VERSIONS_INCOMPATIBLE= 33 # py-foo, py-bar
respectively, please use the same style for other packages,
and check during updates.
Use versioned_dependencies.mk where applicable.
Use REPLACE_PYTHON instead of handcoded alternatives, where applicable.
Reorder Makefile sections into standard order, where applicable.
Remove PYTHON_VERSIONS_INCLUDE_3X lines since that will be default
with the next commit.
Whitespace cleanups and other nits corrected, where necessary.
Changes In Version 3.4
Bugs Fixed
1. If using write() function returned by start_response() and a non string value
is passed to it, then process can crash due to errors in Python object
reference counting in error path of code.
2. If using write() function returned by start_response() under Python 3.X and a
Unicode string is passed to it rather than a byte string, then a memory leak
will occur because of errors in Python object reference counting.
3. Debug level log message about mismatch in content length generated was
generated when content returned less than that specified by Content-Length
response header even when exception occurring during response generation
from an iterator. In the case of an exception occuring, was only meant to
generate the log message if more content returned than defined by the
Content-Length response header.
4. Using writelines() on wsgi.errors was failing.
5. If a UNIX signal received by daemon mode process while still being
initialised to signal that it should be shutdown, the process could crash
rather than shutdown properly due to not registering the signal pipe prior to
registering signal handler.
6. Python doesn't initialise codecs in sub interpreters automatically which in
some cases could cause code running in WSGI script to fail due to lack of
encoding for Unicode strings when converting them. The error message in this
case was:
LookupError: no codec search functions registered: can't find encoding
The 'ascii' encoding is now forcibly loaded when initialising sub
interpreters to get Python to initialise codecs.
7. Response Content-Type header could be corrupted when being sent in
multithreaded configuration and embedded mode being used. Problem thus
affected Windows and worker MPM on UNIX.
Features Changed
1. The HTTPS variable is no longer set within the WSGI environment. The
authoritative indicator of whether a SSL connection is used is
wsgi.url_scheme and a WSGI compliant application should check for
wsgi.url_scheme. The only reason that HTTPS was supplied at all was because
early Django versions supporting WSGI interface weren't correctly using
wsgi.url_scheme. Instead they were expecting to see HTTPS to exist.
This change will cause non conformant WSGI applications to finally break.
This possibly includes some Django versions prior to Django version 1.0.
Note that you can still set HTTPS in Apache configuration using the SetEnv or
SetEnvIf directive, or via a rewrite rule. In that case, that will override
what wsgi.url_scheme is set to and once wsgi.url_scheme is set appropriately,
the HTTPS variable will be removed from the set of variables passed through
to the WSGI environment.
2. The wsgi.version variable has been reverted to 1.0 to conform to the WSGI PEP
3333 specification. It was originally set to 1.1 on expectation that revised
specification would use 1.1 but that didn't come to be.
3. Use of kernel sendfile() function by wsgi.file_wrapper is now off by default.
This was originally always on for embedded mode and completely disabled for
daemon mode. Use of this feature can be enabled for either mode using
WSGIEnableSendfile directive, setting it to On to enable it.
The default is now off because kernel sendfile() is not always able to work
on all file objects. Some instances where it will not work are described for
the Apache EnableSendfile directive.
http://httpd.apache.org/docs/2.2/mod/core.html#enablesendfile
Although Apache has use of sendfile() enabled by default for static files,
they are moving to having it off by default in future version of Apache. This
change is being made because of the problems which arise and users not
knowing how to debug it and solve it.
Thus also erring on side of caution and having it off by default but allowing
more knowledgeable users to enable it where they know always using file
objects which will work with sendfile().
New Features
1. Support use of Python 3.2.
2. Support use of Apache 2.4.
3. Is now guaranteed that mod_ssl access handler is run before that for
mod_wsgi so that any per request variables setup by mod_ssl are available in
the mod_wsgi access handler as implemented by WSGIAccessScript directive.
4. Added 'python-home' option to WSGIDaemonProcess allowing a Python virtual
environment to be used directly in conjunction with daemon process. Note that
this option does not do anything if setting WSGILazyInitialization to 'Off'.
5. Added 'lang' and 'locale' options to WSGIDaemonProcess to perform same tasks
as setting 'LANG' and 'LC_ALL environment' variables. Note that if needing to
do the same for embedded mode you still need to set the environment variables
in the Apache envvars file or init.d startup scripts.
6. Split combined WWW-Authenticate header returned from daemon process back into
separate headers. This is work around for some browsers which require
separate headers when multiple authentication providers exist.
7. For Python 2.6 and above, the WSGIDontWriteBytecode directive can be used at
global scope in Apache configuration to disable writing of all byte code
files, ie., .pyc, by the Python interpreter when it imports Python code
files. To disable writing of byte code files, set directive to 'On'.
Note that this doesn't prevent existing byte code files on disk being used
in preference to the corresponding Python code files. Thus you should first
remove .pyc files from web application directories if relying on this option
to ensure that .py file is always used.
8. Add supplementary-groups option to WSGIDaemonProcess to allow group
membership to be overridden and specified comma separated list of groups to
be used instead.
9. Add 'memory-limit' option to WSGIDaemonProcess to allow memory usage of
daemon processes to be restricted. This will have no affect on some platforms
as RLIMIT_AS/RLIMIT_DATA with setrlimit() isn't always implemented. For
example MacOS X and older Linux kernel versions do not implement this
feature. You will need to test whether this feature works or not before
depending on it.
10. Add 'virtual-memory-limit' option to WSGIDaemonProcess to allow virtual
memory usage of daemon processes to be restricted. This will have no affect
on some platforms as RLIMIT_VMEM with setrlimit() isn't always implemented.
You will need to test whether this feature works or not before depending on
it.
11. Access, authentication and authorisation hooks now have additional keys in
the environ dictionary for 'mod_ssl.is_https' and 'mod_ssl.var_lookup'. These
equate to callable functions provided by mod_ssl for determining if the
client connection to Apache used SSL and what the values of variables
specified in the SSL certifcates, server or client, are. These are only
available if Apache 2.0 or later is being used.
12. Add 'mod_wsgi.queue_start' attribute to WSGI environ so tools like New Relic
can use it to track request queueing time. This is the time between when
request accepted by Apache and when handled by WSGI application.
* Bug fixes:
1. Inactivity timeout not triggered at correct time when occurs for first
request after process is started.
2. Back off timer for failed connections to daemon process group wasn't
working correctly and no delay on reconnect attempts was being applied.
3. Logging not appearing in Apache error log files when using daemon mode
and have multiple virtual hosts against same server name.
4. Eliminate logging of KeyError exception in threading module when processes
are shutdown when using Python 2.6.5 or 3.1.2 or later. This wasn't
indicating any real problem but was annoying all the same.
5. Fix potential for crash when logging error message resulting from failed
group authorisation.
6. Fix compilation problems with Apache 2.3.6.
Bug Fixes
1. Change to workaround problem where correct version of Python
framework isn't being found at run time and instead uses the standard
system one, which may be the wrong version. Change is for those Python
versions on MacOS X which include a .a in Python config directory,
which should be symlinked to framework, link against the .a
instead. For some reason, doing this results in framework then being
picked up from the correct location.
This problem may well have only started cropping up at some point due
to a MacOS X Leopard patch update as has been noticed that Python
frameworks installed previously stopped being found properly when
mod_wsgi was subsequently recompiled against them. Something may
therefore have changed in compiler tools suite.
For more details see:
http://code.google.com/p/modwsgi/issues/detail?id=28
2. Remove isatty from Log object used for stdout/stderr. It should
have been a function and not an attribute. Even so, isatty() is not
meant to be supplied by a file like object if it is associated with a
file descriptor. Thus, packages which want to use isatty() are
supposed to check for its existance before calling it. Thus wasn't
ever mod_wsgi that was wrong in not supply this, but the packages
which were trying to use it.
For more details see:
http://code.google.com/p/modwsgi/issues/detail?id=146
patch-aa was incorporated into a larger related change upstream:
http://code.google.com/p/modwsgi/issues/detail?id=107
Changes as described at:
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0204
Bug Fixes
1. Compilation would fail on Windows due to daemon mode specific code
not being conditionally compiled out on that platform. This was a
problem introduced by changes in mod_wsgi 2.3.
2. Fix bug where wrong Apache memory pool used when processing
configuration directives at startup. This could later result in memory
corruption and may account for problems seen with 'fopen()'
errors. See:
http://code.google.com/p/modwsgi/issues/detail?id=78http://code.google.com/p/modwsgi/issues/detail?id=108
3. Fix bug where Python interpreter not being destroyed correctly in
Apache parent process on an Apache restart. This was resulting in slow
memory leak into Apache parent process on each restart. This
additional memory usage would then be inherited by all child processes
forked from Apache parent process.
Note that this change does not help for case where mod_python is also
being loaded into Apache as in that case mod_python is responsible for
intialising Python and in all available versions of mod_python it
still doesn't properly destroy the Python interpreter either and so
causes memory leaks which mod_wsgi cannot work around.
Also, this doesn't solve problems with the Python interpreter itself
leaking memory when destroyed and reinitialised. Such memory leaks in
Python seem to occur for some versions of Python on particular
platforms.
For further details see:
http://code.google.com/p/modwsgi/issues/detail?id=99
4. Fix bug whereby POST requests where 100-continue was expected by
client would see request content actually truncated and not be
available to WSGI application if application running in daemon
mode. See:
http://code.google.com/p/modwsgi/issues/detail?id=121
5. Fix bug where Apache optimisation related to keep alive connections
can kick in when using wsgi.file_wrapper with result that if amount of
data is between 255 and aproximately 8000 bytes, that a completely
empty response will result. This occurs because Apache isn't flushing
out the file data straight away but holding it over in case subsequent
request on connection arrives. By then the file object used with
wsgi.file_wrapper can have been closed and underlying file descriptor
will not longer be valid. See:
http://code.google.com/p/modwsgi/issues/detail?id=132
6. Modify how daemon process shutdown request is detected such that no
need to block signals in request threads. Doing this caused problems
in processes which were run from daemon mode process and which needed
to be able to receive signals. New mechanism uses a internal pipe to
which signal handler writes a character, with main thread performing a
poll on pipe waiting for that character to know when to shutdown. For
additional details see:
http://code.google.com/p/modwsgi/issues/detail?id=87
9. Fix bug where excessive transient memory usage could occur when
calling read() or readline() on wsgi.input with no argument. See:
http://code.google.com/p/modwsgi/issues/detail?id=126
Note that calling read() with no argument is actually a violation of
WSGI specification and any application doing that is not a WSGI
compliant application.
10. Fix bug where daemon process would crash if User/Group directives
were not specified prior to WSGIDaemonProcess in Apache configuration
file. See:
http://code.google.com/p/modwsgi/issues/detail?id=40
11. Fix bug whereby Python exception state wasn't being cleared
correctly when error occurred in loading target of
WSGIImportScript. See:
http://code.google.com/p/modwsgi/issues/detail?id=117
Features Changed
1. No longer populate 'error-notes' field in Apache request object
notes table, with details of why WSGI script failed. This has been
removed as information can be seen in default Apache multilanguage
error documents. Because errors may list paths or user/group
information, could be seen as a security risk. Features Added
1. Added 'mod_wsgi.version' to WSGI environment passed to WSGI
application. For details see:
http://code.google.com/p/modwsgi/issues/detail?id=93
2. Added 'process_group' and 'application_group' attributes to
mod_wsgi module that is created within each Python interpreter
instance. This allows code executed outside of the context of a
request handler to know whether it is running in a daemon process
group and what it may be called. Similarly, can determine if running
in first interpreter or some other sub interpreter. For details see:
http://code.google.com/p/modwsgi/issues/detail?id=27
3. Added closed and isatty attributes to Log object as well as close()
method. For wsgi.errors these aren't required, but log object also
used for stderr and stdout (when enabled) and code may assume these
methods may exist for stderr and stdout. The closed and isatty
attributes always yield false and close() will raise a run time error
indicating that log cannot be closed. For details see:
http://code.google.com/p/modwsgi/issues/detail?id=82
4. Apache scoreboard cleaned up when daemon processes first
initialised to prevent any user code interfering with operation of
Apache. For details see:
http://code.google.com/p/modwsgi/issues/detail?id=104
5. When running configure script, can now supply additional options
for CPPFLAGS, LDFLAGS and LDLIBS through environment variables. For
details see:
http://code.google.com/p/modwsgi/issues/detail?id=107
6. Better checking done on response headers and an explicit error will
now be produce if name or value of response header contains an
embedded newline. This is done as by allowing embedded newline would
cause daemon mode to fail when handing response in Apache child
process. In embedded mode, could allow application to pass back
malformed response headers to client. For details see:
http://code.google.com/p/modwsgi/issues/detail?id=81
7: Ensure that SYSLIBS linker options from Python configuration used
when linking mod_wsgi Apache module. This is now prooving necessary as
some Apache distributions are no longer linking system maths library
and Python requires it. To avoid problem simply link against mod_wsgi
Apache module and system libraries that Python needs. For details see:
http://code.google.com/p/modwsgi/issues/detail?id=115
8: Reorder sys.path after having called site.addsitedir() in
WSGIPythonPath and python-path option for WSGIDaemonProcess. This
ensures that newly added directories get moved to front of sys.path
and that they take precedence over standard directories. This in part
avoids need to ensure --no-site-packages option used when creating
virtual environments, as shouldn't have an issue with standard
directories still overriding additions. For details see:
http://code.google.com/p/modwsgi/issues/detail?id=112
9. Update USER, USERNAME and LOGNAME environment variables if set in
daemon process to be the actual user that the process runs as rather
than what may be inherited from Apache root process, which would
typically be 'root' or the user that executed 'sudo' to start Apache,
if they hadn't used '-H' option to 'sudo'. See:
http://code.google.com/p/modwsgi/issues/detail?id=129
10. Build process now inserts what is believed to be the directory
where Python shared library is installed, into the library search path
before the Python config directory. This should negate the need to
ensure that Python shared library is also symlink into the config
directory next to the static library as linkers would normally expect
it. See:
http://code.google.com/p/modwsgi/issues/detail?id=136
- assume that Python 2.4 and 2.5 are compatible and allow checking for
fallout.
- remove PYTHON_VERSIONS_COMPATIBLE that are obsoleted by the 2.3+
default. Modify the others to deal with the removals.
Fix bug whereby mod_wsgi daemon process could hang when a request with
content greater than UNIX socket buffer size, was directed at a WSGI
application resource handler which in turn returned a response, greater
than UNIX socket buffer size, without first consuming the request content.
host any Python application which supports the Python WSGI interface. The
module would be suitable for use in hosting high performance production web
sites, as well as your average personal sites running on commodity web hosting
services.
wiz
joerg
obache
asau
adam
gdt
epg