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.
