The NetBSD Project

CVS log for pkgsrc/www/ap2-wsgi/Attic/Makefile

[BACK] Up to [cvs.NetBSD.org] / pkgsrc / www / ap2-wsgi

Request diff between arbitrary revisions


Default branch: MAIN


Revision 1.21, Sun Jan 25 12:02:50 2015 UTC (8 years, 1 month ago) by adam
Branch: MAIN
CVS Tags: HEAD
Changes since 1.20: +1 -1 lines
FILE REMOVED

Removed www/ap2-wsgi successor www/py-mod_wsgi

Revision 1.20 / (download) - annotate - [select for diffs], Wed Jun 18 11:35:38 2014 UTC (8 years, 9 months ago) by wiz
Branch: MAIN
CVS Tags: pkgsrc-2014Q4-base, pkgsrc-2014Q4, pkgsrc-2014Q3-base, pkgsrc-2014Q3, pkgsrc-2014Q2-base, pkgsrc-2014Q2
Changes since 1.19: +2 -2 lines
Diff to previous 1.19 (colored)

Update to 4.2.4 for a security fix.

=============
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.

Revision 1.19 / (download) - annotate - [select for diffs], Tue Jun 10 15:22:17 2014 UTC (8 years, 9 months ago) by joerg
Branch: MAIN
Changes since 1.18: +2 -2 lines
Diff to previous 1.18 (colored)

Retire Apache 1.3 and 2.0.

Revision 1.18 / (download) - annotate - [select for diffs], Sat Jun 7 07:44:09 2014 UTC (8 years, 9 months ago) by wiz
Branch: MAIN
Changes since 1.17: +2 -2 lines
Diff to previous 1.17 (colored)

Update to 4.1.3:

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„’ 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„’ 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 „¬sciiencoding 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„’
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„’
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„’ 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„’ 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„’ 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„’
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„’ 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„’ 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 03 Service
Unavailableresponse 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.

Revision 1.17 / (download) - annotate - [select for diffs], Sat Jun 7 07:41:25 2014 UTC (8 years, 9 months ago) by wiz
Branch: MAIN
Changes since 1.16: +7 -5 lines
Diff to previous 1.16 (colored)

Update to 3.5:

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.html
	http://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 00 Errorrather than 00 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.

Revision 1.16 / (download) - annotate - [select for diffs], Sat Jan 25 10:30:26 2014 UTC (9 years, 1 month ago) by wiz
Branch: MAIN
CVS Tags: pkgsrc-2014Q1-base, pkgsrc-2014Q1
Changes since 1.15: +1 -3 lines
Diff to previous 1.15 (colored)

Mark packages as not ready for python-3.x where applicable;
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.

Revision 1.15 / (download) - annotate - [select for diffs], Mon Aug 19 10:09:51 2013 UTC (9 years, 7 months ago) by obache
Branch: MAIN
CVS Tags: pkgsrc-2013Q4-base, pkgsrc-2013Q4, pkgsrc-2013Q3-base, pkgsrc-2013Q3
Changes since 1.14: +3 -3 lines
Diff to previous 1.14 (colored)

Update ap2-wsgi to 3.4.

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.

Revision 1.14 / (download) - annotate - [select for diffs], Sun Oct 28 06:30:08 2012 UTC (10 years, 4 months ago) by asau
Branch: MAIN
CVS Tags: pkgsrc-2013Q2-base, pkgsrc-2013Q2, pkgsrc-2013Q1-base, pkgsrc-2013Q1, pkgsrc-2012Q4-base, pkgsrc-2012Q4
Changes since 1.13: +1 -3 lines
Diff to previous 1.13 (colored)

Drop superfluous PKG_DESTDIR_SUPPORT, "user-destdir" is default these days.

Revision 1.13 / (download) - annotate - [select for diffs], Sat Dec 3 00:02:17 2011 UTC (11 years, 3 months ago) by joerg
Branch: MAIN
CVS Tags: pkgsrc-2012Q3-base, pkgsrc-2012Q3, pkgsrc-2012Q2-base, pkgsrc-2012Q2, pkgsrc-2012Q1-base, pkgsrc-2012Q1, pkgsrc-2011Q4-base, pkgsrc-2011Q4
Changes since 1.12: +3 -1 lines
Diff to previous 1.12 (colored)

Tag the 28 locations that result in a Python 3.1 package as supporting so.
Remove it from the default list for the rest.

Revision 1.12 / (download) - annotate - [select for diffs], Wed Sep 15 11:51:29 2010 UTC (12 years, 6 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2011Q3-base, pkgsrc-2011Q3, pkgsrc-2011Q2-base, pkgsrc-2011Q2, pkgsrc-2011Q1-base, pkgsrc-2011Q1, pkgsrc-2010Q4-base, pkgsrc-2010Q4, pkgsrc-2010Q3-base, pkgsrc-2010Q3
Changes since 1.11: +7 -8 lines
Diff to previous 1.11 (colored)

Changes 3.3:
* 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.

Revision 1.11 / (download) - annotate - [select for diffs], Mon Aug 31 12:42:19 2009 UTC (13 years, 6 months ago) by gdt
Branch: MAIN
CVS Tags: pkgsrc-2010Q2-base, pkgsrc-2010Q2, pkgsrc-2010Q1-base, pkgsrc-2010Q1, pkgsrc-2009Q4-base, pkgsrc-2009Q4, pkgsrc-2009Q3-base, pkgsrc-2009Q3
Changes since 1.10: +2 -2 lines
Diff to previous 1.10 (colored)

Update to 2.5.


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

Revision 1.10 / (download) - annotate - [select for diffs], Tue May 19 08:59:37 2009 UTC (13 years, 10 months ago) by wiz
Branch: MAIN
CVS Tags: pkgsrc-2009Q2-base, pkgsrc-2009Q2
Changes since 1.9: +1 -2 lines
Diff to previous 1.9 (colored)

Use standard location for LICENSE line (in MAINTAINER/HOMEPAGE/COMMENT
block). Uncomment some commented out LICENSE lines while here.

Revision 1.9 / (download) - annotate - [select for diffs], Wed Apr 29 23:18:58 2009 UTC (13 years, 10 months ago) by gdt
Branch: MAIN
Changes since 1.8: +3 -1 lines
Diff to previous 1.8 (colored)

Set LICENSE to apache-2.0.

Revision 1.8 / (download) - annotate - [select for diffs], Wed Apr 29 23:14:58 2009 UTC (13 years, 10 months ago) by gdt
Branch: MAIN
Changes since 1.7: +2 -2 lines
Diff to previous 1.7 (colored)

Update to mod_wsgi 2.4.  (Works with apache22 and trac.)

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=78

    http://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

Revision 1.7 / (download) - annotate - [select for diffs], Fri Sep 12 05:41:59 2008 UTC (14 years, 6 months ago) by epg
Branch: MAIN
CVS Tags: pkgsrc-2009Q1-base, pkgsrc-2009Q1, pkgsrc-2008Q4-base, pkgsrc-2008Q4, pkgsrc-2008Q3-base, pkgsrc-2008Q3, cube-native-xorg-base, cube-native-xorg
Changes since 1.6: +2 -2 lines
Diff to previous 1.6 (colored)

Update to 2.3 (approved by maintainer), and add patch-aa to fix a link issue
(submitted upstream).  I can't find any summary of changes, just a bunch of
wiki pages:

http://code.google.com/p/modwsgi/wiki/ChangesInVersion0104
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0105
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0106
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0200
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0201
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0202
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0203

Revision 1.6 / (download) - annotate - [select for diffs], Thu Jun 12 02:14:55 2008 UTC (14 years, 9 months ago) by joerg
Branch: MAIN
CVS Tags: pkgsrc-2008Q2-base, pkgsrc-2008Q2, cwrapper
Changes since 1.5: +3 -1 lines
Diff to previous 1.5 (colored)

Add DESTDIR support.

Revision 1.5 / (download) - annotate - [select for diffs], Fri Apr 25 20:39:13 2008 UTC (14 years, 10 months ago) by joerg
Branch: MAIN
Changes since 1.4: +1 -3 lines
Diff to previous 1.4 (colored)

Update PYTHON_VERSIONS_COMPATIBLE
- 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.

Revision 1.4 / (download) - annotate - [select for diffs], Tue Dec 18 01:00:13 2007 UTC (15 years, 3 months ago) by gdt
Branch: MAIN
CVS Tags: pkgsrc-2008Q1-base, pkgsrc-2008Q1, pkgsrc-2007Q4-base, pkgsrc-2007Q4
Changes since 1.3: +2 -2 lines
Diff to previous 1.3 (colored)

Update to 1.3 (from Jan Danielsson).

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.

Revision 1.3 / (download) - annotate - [select for diffs], Wed Nov 21 15:19:51 2007 UTC (15 years, 4 months ago) by gdt
Branch: MAIN
Changes since 1.2: +2 -2 lines
Diff to previous 1.2 (colored)

Update to 1.2, from Jan Danielsson.
Remove lib/httpd from PLIST, as apache claims it.

Upstream does not provide NEWS or ChangeLog, and the changes seem to
be various bugfixes.

Revision 1.2 / (download) - annotate - [select for diffs], Thu Oct 25 14:50:06 2007 UTC (15 years, 5 months ago) by gdt
Branch: MAIN
Changes since 1.1: +3 -3 lines
Diff to previous 1.1 (colored)

Update to 1.1, and support python 2.3.  From Jan Danielsson.

(Upstream does not provide a NEWS file.)

Revision 1.1.1.1 / (download) - annotate - [select for diffs] (vendor branch), Wed Oct 24 22:31:51 2007 UTC (15 years, 5 months ago) by gdt
Branch: TNF
CVS Tags: pkgsrc-base
Changes since 1.1: +0 -0 lines
Diff to previous 1.1 (colored)

The aim of mod_wsgi is to implement a simple to use Apache module which can
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.

Revision 1.1 / (download) - annotate - [select for diffs], Wed Oct 24 22:31:51 2007 UTC (15 years, 5 months ago) by gdt
Branch: MAIN

Initial revision

This form allows you to request diff's between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.




CVSweb <webmaster@jp.NetBSD.org>