![[BACK]](/icons/back.gif){kind=icon}
Up to [cvs.NetBSD.org] / pkgsrc / www / py-mod_wsgi
Request diff between arbitrary revisions
Default branch: MAIN
Revision 1.23 / (download) - annotate - [select for diffs], Tue Nov 15 08:52:09 2022 UTC (10 months, 1 week ago) by wiz
Branch: MAIN
CVS Tags: pkgsrc-2023Q2-base,
pkgsrc-2023Q2,
pkgsrc-2023Q1-base,
pkgsrc-2023Q1,
pkgsrc-2022Q4-base,
pkgsrc-2022Q4,
HEAD
Changes since 1.22: +2 -3
lines
Diff to previous 1.22 (colored)
py-ap24-mod_wsgi: update to 4.9.4.
4.9.4
Bugs Fixed
Apache 2.4.54 changed the default value for LimitRequestBody
from 0, which indicates there is no limit, to 1Gi. If the Apache
configuration supplied with a distribution wasnãàÑÕ explicitly
setting LimitRequestBody to 0 at global server scope for the
purposes of documenting the default, and it was actually relying
on the compiled in default, then when using mod_wsgi daemon
mode, if a request body size greater than 1Gi was encountered
the mod_wsgi daemon mode process would crash. Fix ability to
build mod_wsgi against Apache 2.2. Do note that in general only
recent versions of Apache 2.4 are supported
4.9.3
Bugs Fixed
When using WSGITrustedProxies and WSGITrustedProxyHeaders in
the Apache configuration, or --trust-proxy and --trust-proxy-header
options with mod_wsgi-express, if you trusted the X-Client-IP
header and a request was received from an untrusted client,
the header was not being correctly removed from the set of
headers passed through to the WSGI application.
This only occurred with the X-Client-IP header and the same
problem was not present if trusting the X-Real-IP or X-Forwarded-For
headers.
The purpose of this feature for trusting a front end proxy was
in this case for the headers:
X-Client-IP X-Real-IP X-Forwarded-For
and was designed to allow the value of REMOTE_ADDR passed to
the WSGI application to be rewritten to the IP address that a
trusted proxy said was the real remote address of the client.
In other words, if a request was received from a proxy the IP
address of which was trusted, REMOTE_ADDR would be set to the
value of the single designated header out of those listed above
which was to be trusted.
In the case where the proxy was trusted, in addition to
REMOTE_ADDR being rewritten, only the trusted header would be
passed through. That is, if X-Real-IP was the trusted header,
then HTTP_X_REAL_IP would be passed to the WSGI application,
but HTTP_X_CLIENT_IP and HTTP_X_FORWARDED_FOR would be dropped
if corresponding headers had also been supplied. That the header
used to rewrite REMOTE_ADDR was passed through still was only
intended for the purpose of documenting where the value of
REMOTE_ADDR came from. A WSGI application when relying on this
feature should only ever use the value of REMOTE_ADDR and should
ignore the header passed through.
The behaviour as described was therefore based on a WSGI
application not at the same time enabling any WSGI or web
framework middleware to try and process any proxy headers a
second time and REMOTE_ADDR should be the single source of
truth. Albeit the headers which were passed through should have
resulted in the same result for REMOTE_ADDR if the proxy headers
were processed a second time.
Now in the case of the client a request was received from not
being a trusted proxy, then REMOTE_ADDR would not be rewritten,
and would be left as the IP of the client, and none of the
headers listed above were supposed to be passed through.
That REMOTE_ADDR is not rewritten is implemented correctly when
the client is not a trusted proxy, but of the three headers
listed above, HTTP_X_CLIENT_ID was not being dropped if the
corresponding header was supplied.
If the WSGI application followed best practice and only relied
on the value of REMOTE_ADDR as the source of truth for the
remote client address, then that HTTP_X_CLIENT_ID was not being
dropped should pose no security risk. There would however be
a problem if a WSGI application was still enabling a WSGI or
web framework specific middleware to process the proxy headers
a second time even though not required. In this case, the
middleware used by the WSGI application may still trust the
X-Client-IP header and rewrite REMOTE_ADDR allowing a malicious
client to pretend to have a different IP address.
In addition to the WSGI application having redundant checks
for the proxy headers, to take advantage of this, a client
would also need direct access to the Apache/mod_wsgi server
instance.
In the case that only clients on your private network behind
your proxy could access the Apache/mod_wsgi server instance,
that would imply any malicious actor already had access to your
private network and had access to hosts in that private network
or could attach their own device to that private network.
In the case where your Apache/mod_wsgi server instance could
be accessed from the same external networks as a proxy forwarding
requests to it, such as may occur if making use of a CDN proxy
cache, a client would still need to know the direct address
used by the Apache/mod_wsgi server instance.
Note that only one proxy header for designating the IP of a
client should ever be trusted. If you trust more than one, then
which will be used if both are present is undefined as it is
dependent on the order that Apache processes headers. This
hasnãàÑÕ changed and as before to avoid ambiguity you should only
trust one of the proxy headers recognised for this purpose.
4.9.2
Bugs Fixed
When using mod_wsgi-express in daemon mode, and source code
reloading was enabled, an invalid URL path which contained a
byte sequence which could not be decoded as UTF-8 was causing
a process crash.
4.9.1
Bugs Fixed
When using --enable-debugger of mod_wsgi-express to enable Pdb,
it was failing due to prior changes to run Apache in a sub
processes to avoid Apache being shutdown when the window size
changed. This was because standard input was being detached
from Apache and so it was not possible to interact with Pdb.
Now when --enable-debugger is used, or any feature which uses
--debug-mode, Apache will not be run in a sub process so that
you can still use standard input to interact with the process
if needed. This does mean that a window size change event will
again cause Apache to shutdown in these cases though. Update
code so compiles on Python 3.11. Python 3.11 makes structures
for Python frame objects opaque and requires functions to access
struct members.
Features Changed
Historically when a process was being shutdown, mod_wsgi would
do its best to destroy any Python sub interpreters as well as
the main Python interpreter. This was done in case applications
attempted to run any actions on process shutdown via atexit
registered callbacks or other means.
Because of changes in Python 3.9, and possibly because mod_wsgi
makes use of externally created C threads to handle requests,
and not Python native threads, there is now a suspiscion that
attempting to delete Python sub interpreters can hang. It is
believed this may relate to Python core now expecting all Python
thread state objects to have been deleted before the Python
sub interpreter can be destroyed. If they arenãàÑÕ then Python
core code can block indefinitely. If the issue isnãàÑÕ the
externally created C threads that mod_wsgi uses, it might
instead be arising as a problem when a hosted WSGI application
creates its own background threads but they are still running
when the attempt is made to destroy the sub interpreter.
In the case of using daemon mode the result is that processes
can hang on shutdown, but will still at least be deleted after
5 seconds due to how Apache process management will forcibly
kill managed processes after 5 seconds if they do not exit
cleanly themselves. In other words the issue may not be noticed.
For embedded mode however, the Apache child process can hang
around indefinitely, possibly only being deleted if some higher
level system application manager such as systemd is able to
detect the problem and forcibly deleted the hung process.
Although mod_wsgi always attempts to ensure that the externally
created C threads are not still handling HTTP requests and thus
not active prior to destroying the Python interpreter, it is
impossible to guarantee this. Similarly, there is no way to
guarantee that background threads created by a WSGI application
arenãàÑÕ still running. As such, it isnãàÑÕ possible to safely
attempt to delete the Python thread state objects before deleting
the Python sub interpreter.
Because of this uncertainty mod_wsgi now provides a way to
disable the attempt to destroy the Python sub interpreters or
the main Python interpreter when the process is being shutdown.
This will though mean that atexit registered callbacks will
not be called if this option is enabled. It is therefore
important that you use mod_wsgiãàÑÔ own mechanism of being notified
when a process is being shutdown to perform any special actions.
import mod_wsgi
def shutdown_handler(event, **kwargs):
print('SHUTDOWN-HANDLER', event, kwargs)
mod_wsgi.subscribe_shutdown(shutdown_handler)
Use of this shutdown notification was necessary anyway to
reliably attempt to stop background threads created by the WSGI
application since atexit registered callbacks are not called
by Python core until after it thinks all threads have been
stopped. In other words, atexit register callbacks couldnãàÑÕ be
used to reliably stop background threads. Thus use of the
mod_wsgi mechanism for performing actions on process shutdown
is the preferred way.
Overall it is expected that the majority of users will not
notice this change as it is very rare to see WSGI applications
want to perform special actions on process shutdown. If you
are affected, you should use mod_wsgiãàÑÔ mechanism to perform
special actions on process shutdown.
If you need to enable this mode whereby no attempt is made to
destroy the Python interpreter (including sub interpreters) on
process shutdown, you can add at global scope in the Apache
configuration:
WSGIDestroyInterpreter Off
If you are using mod_wsgi-express, you can instead supply the
command line option --orphan-interpreter.
4.9.0
Bugs Fixed
The mod_wsgi code wouldnãàÑÕ compile on Python 3.10 as various
Python C API functions were removed. Note that the changes
required switching to alternate C APIs. The changes were made
for all Python versions back to Python 3.6 and were not
conditional on Python 3.10+ being used. This is why the minor
version got bumped. When using CMMI (configure/make/make
install) method for compiling mod_wsgi if embedded mode was
being disabled at compile time, compilation would fail. When
maximum-requests option was used with mod_wsgi daemon mode,
and a graceful restart signal was sent to the daemon process
while there was an active request, the process would only
shutdown when the graceful timeout period had expired, and not
as soon as any active requests had completed, if that had
occurred before the graceful timeout had expired. When using
the startup-timeout and restart-interval options of WSGIDaemonProcess
directive together, checking for the expiration time of the
startup time was done incorrectly, resulting in process restart
being delayed if startup had failed. At worst case this was
the lessor of the time periods specified by the options
restart-interval, deadlock-timeout, graceful-timeout and
eviction-timeout. If request-timeout were defined it would
however still be calculated correctly. As request-timeout was
by default defined when using mod_wsgi-express, this issue only
usually affect mod_wsgi when manually configuring Apache.
Features Changed
Historically when using embedded mode, wsgi.multithread in the
WSGI environ dictionary has reported True when any multithread
capable Apache MPM were used (eg., worker, event), even if the
current number of configured threads per child process was
overridden to be 1. Why this was the case has been forgotten,
but generally wouldnãàÑÕ matter since no one would ever set up
Apache with a mulithread MPM and then configure the number of
threads to be 1. If that was desired then prefork MPM would be
used.
With mod_wsgi-express since 4.8.0 making it much easier to use
embedded mode and have a sane configuration used, since it is
generated for you, the value of wsgi.multithread has been
changed such that it will now correctly report False if using
embedded mode, a multithread capable MPM is used, but the number
of configured threads is set to 1.
The graceful-timeout option for WSGIDaemonProcess now defaults
to 15 seconds. This was always the case when mod_wsgi-express
was used but the default was never applied back to the case
where mod_wsgi was being configured manually.
A default of 15 seconds for graceful-timeout is being added to
avoid the problem where sending a SIGUSR1 to a daemon mode
process would never see the process shutdown due to there never
being a time when there were no active requests. This might
occur when there were a stuck request that never completed, or
numerous long running requests which always overlapped in time
meaning the process was never idle.
You can still force graceful-timeout to be 0 to restore the
original behaviour, but that is probably not recommended.
4.8.0
Bugs Fixed
Fixed potential for process crash on Apache startup when the
WSGI script file or other Python script file were being preloaded.
This was triggered when WSGIImportScript was used, or if
WSGIScriptAlias or WSGIScriptAliasMatch were used and both the
process-group and application-group options were used with
those directives.
The potential for this problem arising was extremely high on
Alpine Linux, but seem to be very rare on a full Linux of macOS
distribution where glibc was being used.
Include a potential workaround so that virtual environment work
on Windows.
Use of virtual environments in embedded systems on Windows has
been broken ever since python -m venv was introduced.
Initially virtualenv was not affected, although when it changed
to use the new style Python virtual environment layout the same
as python -m venv it also broke. This was with the introduction
of about virtualenv version 20.0.0.
The underlying cause is lack of support for using virtual
environments in CPython for the new style virtual environments.
The bug has existed in CPython since back in 2014 and has not
been fixed. For details of the issue see
https://bugs.python.org/issue22213.
For non Window systems a workaround had been used to resolve
the problem, but the same workaround has never worked on Windows.
The change in this version tries a different workaround for
Windows environments.
Added a workaround for the fact that Python doesnãàÑÕ actually
set the _main_thread attribute of the threading module to the
main thread which initialized the main interpreter or sub
interpreter, but the first thread that imports the threading
module. In an embedded system such as mod_wsgi it could be a
request thread, not the main thread, that would import the
threading module.
This issue was causing the asgiref module used in Django to
fail when using signal.set_wakeup_fd() as code was thinking it
was in the main thread when it wasnãàÑÕ. See
https://github.com/django/asgiref/issues/143.
Using WSGILazyInitialization Off would cause Python to abort
the Apache parent process. The issue has been resolved, but
you are warned that you should not be using this option anyway
as it is dangerous and opens up security holes with the potential
for user code to run as the root user when Python is initialized.
Fix a Python deprecation warning for PyArg_ParseTuple() which
would cause the process to crash when deprecation warnings were
turned on globally for an application. Crash was occuring
whenever anything was output to Apache error log via print().
Features Changed
The --isatty option of mod_wsgi-express has been removed and
the behaviour enabled by the option is now the default. The
default behaviour is now that if mod_wsgi-express is run in an
interactive terminal, then Apache will be started within a sub
process of the mod_wsgi-express script and the SIGWINCH signal
will be blocked and not passed through to Apache. This means
that a window resizing event will no longer cause mod_wsgi-express
to shutdown unexpectedly. When trying to set resource limits
and they canãàÑÕ be set, the system error number will now be
included in the error message.
New Features
Added the mod_wsgi.subscribe_shutdown() function for registering
a callback to be called when the process is being shutdown.
This is needed because atexit.register() doesnãàÑÕ work as required
for the main Python interpreter, specifically the atexit callback
isnãàÑÕ called before the main interpreter thread attempts to
wait on threads on shutdown, thus preventing one from shutting
down daemon threads and waiting on them.
This feature to get a callback on process shutdown was previously
available by using mod_wsgi.subscribe_events(), but that would
also reports events to the callback on requests as they happen,
thus adding extra overhead if not using the request events.
The new registration function can thus be used where only
interested in the event for the process being shutdown.
Added an --embedded-mode option to mod_wsgi-express to make it
easier to force it into embedded mode for high throughput, CPU
bound applications with minimal response times. In this case
the number of Apache child worker processes used for embedded
mode will be dictated by the --processes and --threads option,
completely overriding any automatic mechanism to set those
parameters. Any auto scaling done by Apache for the child worker
processes will also be disabled.
This gives preference to using Apache worker MPM instead of
event MPM, as event MPM doesnãàÑÕ work correctly when told to
run with less than three threads per process. You can switch
back to using event MPM by using the --server-mpm option, but
will need to ensure that have three threads per process or
more.
Locking of the Python global interpreter lock has been reviewed
with changes resulting in a reduction in overhead, or otherwise
changing the interaction between threads such that at high
request rate with a hello world application, a greater request
throughput can be achieved. How much improvement you see with
your own applications will depend on what your application does
and whether you have short response times to begin with. If
you have an I/O bound application with long response times you
likely arenãàÑÕ going to see any difference.
Internal metrics collection has been improved with additional
information provided in process metrics and a new request
metrics feature added giving access to aggregrated metrics over
the time of a reporting period. This includes bucketed time
data on requests so can calculate distribution of server, queue
and application time.
Note that the new request metrics is still a work in progress
and may be modified or enhanced, causing breaking changes in
the format of data returned.
Hidden experimental support for running mod_wsgi-express
start-server on Windows. It will not show in list of sub commands
mod_wsgi-express accepts on Windows, but it is there. There
are still various issues that need to be sorted out but need
assistance from someone who knows more about programming Python
on Windows and Windows programming in general to get it all
working properly. If you are interested in helping, reach out
on the mod_wsgi mailing list.
Revision 1.22 / (download) - annotate - [select for diffs], Wed Jan 5 20:47:37 2022 UTC (20 months, 2 weeks ago) by wiz
Branch: MAIN
CVS Tags: pkgsrc-2022Q3-base,
pkgsrc-2022Q3,
pkgsrc-2022Q2-base,
pkgsrc-2022Q2,
pkgsrc-2022Q1-base,
pkgsrc-2022Q1
Changes since 1.21: +4 -2
lines
Diff to previous 1.21 (colored)
*: set USE_PKG_RESOURCES for more packages
Revision 1.21 / (download) - annotate - [select for diffs], Tue Jan 4 20:55:31 2022 UTC (20 months, 2 weeks ago) by wiz
Branch: MAIN
Changes since 1.20: +2 -1
lines
Diff to previous 1.20 (colored)
*: bump PKGREVISION for egg.mk users They now have a tool dependency on py-setuptools instead of a DEPENDS
Revision 1.20 / (download) - annotate - [select for diffs], Sat Jun 20 16:36:49 2020 UTC (3 years, 3 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2021Q4-base,
pkgsrc-2021Q4,
pkgsrc-2021Q3-base,
pkgsrc-2021Q3,
pkgsrc-2021Q2-base,
pkgsrc-2021Q2,
pkgsrc-2021Q1-base,
pkgsrc-2021Q1,
pkgsrc-2020Q4-base,
pkgsrc-2020Q4,
pkgsrc-2020Q3-base,
pkgsrc-2020Q3,
pkgsrc-2020Q2-base,
pkgsrc-2020Q2
Changes since 1.19: +3 -3
lines
Diff to previous 1.19 (colored)
py-mod_wsgi: updated to 4.7.1 Version 4.7.1 Bugs Fixed Fix up installation on Windows into a virtual environment when using latest virtualenv version, or recent Python versions with the bundled venv module for creating virtual environments. Version 4.7.0 New Features Now releasing parallel mod_wsgi-standalone package to PyPi. This is the same as the mod_wsgi package, except that by installing the mod_wsgi-standalone package, it will automatically trigger the mod_wsgi-httpd package to install the Apache HTTPD server as part of your Python installation. When you run mod_wsgi-express it will use that Apache HTTPD server installation. The mod_wsgi-standalone package is required where you need to install mod_wsgi-express using its own Apache HTTPD installation due to no system Apache HTTPD server package being available, and the installation needs to be done using a requirements.txt file for pip or other package install manager. Using mod_wsgi-standalone will ensure that the mod_wsgi-httpd package is installed first before attempting to build and install mod_wsgi. This guarantee is not provided by pip if you list mod_wsgi-httpd and mod_wsgi packages as two entries. The version numbering of the mod_wsgi-standalone package will follow the mod_wsgi versioning.
Revision 1.19 / (download) - annotate - [select for diffs], Wed Jul 3 19:50:33 2019 UTC (4 years, 2 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2020Q1-base,
pkgsrc-2020Q1,
pkgsrc-2019Q4-base,
pkgsrc-2019Q4,
pkgsrc-2019Q3-base,
pkgsrc-2019Q3
Changes since 1.18: +3 -3
lines
Diff to previous 1.18 (colored)
py-mod_wsgi: updated to 4.6.7 Version 4.6.7: Bugs Fixed Fix Windows build errors due to Python 3.7+ not providing empty function stubs for PyOS_AfterFork_Child() and PyOS_AfterFork_Parent(). Version 4.6.6: Bugs Fixed Fix compilation failures when using Python 3.8. Features Changed When running mod_wsgi-express it will do a search for the location of bash and sh when defining the shell to use for the generated apachectl. The shell used can be overridden using --shell-executable option. This is to get around issue with FreeBSD not having /bin/bash. New Features The Apache request ID is accessible in request events as request_id. The per request data dictionary accessible using mod_wsgi.request_data() is now also accessible in events as request_data.
Revision 1.18 / (download) - annotate - [select for diffs], Tue Dec 11 09:46:23 2018 UTC (4 years, 9 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2019Q2-base,
pkgsrc-2019Q2,
pkgsrc-2019Q1-base,
pkgsrc-2019Q1,
pkgsrc-2018Q4-base,
pkgsrc-2018Q4
Changes since 1.17: +3 -3
lines
Diff to previous 1.17 (colored)
py-mod_wsgi: updated to 4.6.5 Version 4.6.5 Bugs Fixed * When running mod_wsgi-express and serving up static files from the document root, and the WSGI application was mounted at a sub URL using --mount-point, the static files in the document root outside of the mount point for the WSGI application would no longer be accessible. * If no system mime types file can be found, fall back to /dev/null so that Apache can still at least start up. Features Changed * On macOS, use /var/tmp as default parent directory for server root directory rather than value of $TMPDIR. The latter can produce a path which is too long and UNIX socket cannot be written there. New Features * Now possible to use mod_wsgi-express in an a zipapp created using shiv. This entailed a special workaround to detect when shiv was used, so that the unpacked site-packages directory could be added to the Python module search path for mod_wsgi-express.
Revision 1.17 / (download) - annotate - [select for diffs], Sat Apr 14 09:34:15 2018 UTC (5 years, 5 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2018Q3-base,
pkgsrc-2018Q3,
pkgsrc-2018Q2-base,
pkgsrc-2018Q2
Changes since 1.16: +3 -10
lines
Diff to previous 1.16 (colored)
py-mod_wsgi: updated to 4.6.4 Version 4.6.4: Bugs Fixed In more recent Python versions, the config directory in the Python installation incorporates the platform name. This directory was added as an additional directory to search for Python shared libraries when installing using the setup.py file or pip. It should not even be needed for newer Python versions but still check for older Python versions. The only issue arising from the wrong directory, not incorporating the platform name, being used, was a linker warning about the directory not being present. Installing mod_wsgi on Windows would fail as hadnãàÑÕ exclude mod_wsgi daemon mode specific code from Windows build. This would result in compile time error about wsgi_daemon_process being undefined. This problem was introduced to Windows in version 4.6.0. A prior attempt to fix this in 4.6.3 missed one place in the code which needed to be changed. Version 4.6.3 Bugs Fixed When compiled for Python 2.6, when run mod_wsgi would fail to load into Apache due to misisng symbol PyFrame_GetLineNumber. This was only introduced in Python 2.7. Use alternate way to get line number which still yields correct answer. This issue was introduced in mod_wsgi version 4.6.0 in fix to have correct line numbers generated for stack traces on shutdown due to request timeout. Installing mod_wsgi on Windows would fail as hadnãàÑÕ exclude mod_wsgi daemon mode specific code from Windows build. This would result in compile time error about wsgi_daemon_process being undefined. This problem was introduced to Windows in version 4.6.0. When using runmodwsgi management command integration for Django, the file containing the WSGI application entry point was specified via a full filesystem path, rather than by module import path. This meant that relative imports from that file would fail. The file is now imported as a module path based on what WSGI_APPLICATION is set to in the Django settings module. This means the file is imported as part of package for the project and relative imports will work.
Revision 1.16 / (download) - annotate - [select for diffs], Mon Jan 1 10:23:09 2018 UTC (5 years, 8 months ago) by wiz
Branch: MAIN
CVS Tags: pkgsrc-2018Q1-base,
pkgsrc-2018Q1
Changes since 1.15: +1 -3
lines
Diff to previous 1.15 (colored)
apache22: remove, it was eol'd in June 2017 Remove packages that only work with apache22. Remove apache22 references.
Revision 1.15 / (download) - annotate - [select for diffs], Sat Dec 16 07:46:30 2017 UTC (5 years, 9 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2017Q4-base,
pkgsrc-2017Q4
Changes since 1.14: +2 -2
lines
Diff to previous 1.14 (colored)
py-mod_wsgi: updated to 4.5.24 Version 4.5.24: Bugs Fixed Using mod_wsgi in daemon mode on Solaris would cause a process hang or max out CPU usage. Caused by change of variable type to unsigned to get rid of compiler warnings, without fixing how condition check using variable was done. Problem could also affect non Solaris systems if total number of HTTP headers and other variables passed in WSGI environ was greater than 1024. Affected Solaris all the time due to it having a limit of only 16 in operating system for same code, meaning hit problem immediately.
Revision 1.14 / (download) - annotate - [select for diffs], Thu Dec 14 13:25:22 2017 UTC (5 years, 9 months ago) by adam
Branch: MAIN
Changes since 1.13: +2 -2
lines
Diff to previous 1.13 (colored)
py-mod_wsgi: updated to 4.5.23 Bugs Fixed Incorrect check around whether apxs was present on system would result in pip install failing on Windows, and possibly also when using latest Xcode on MacOS X.
Revision 1.13 / (download) - annotate - [select for diffs], Thu Nov 23 10:35:43 2017 UTC (5 years, 10 months ago) by adam
Branch: MAIN
Changes since 1.12: +2 -2
lines
Diff to previous 1.12 (colored)
py-mod_wsgi: updated to 4.5.22 4.5.22: Bugs Fixed: Change in version 4.5.21 caused Windows builds to break with undefined symbol wsgi_daemon_shutdown.
Revision 1.12 / (download) - annotate - [select for diffs], Wed Oct 11 07:17:38 2017 UTC (5 years, 11 months ago) by adam
Branch: MAIN
Changes since 1.11: +2 -2
lines
Diff to previous 1.11 (colored)
py-mod_wsgi: update to 4.5.20 Version 4.5.20: Bugs Fixed Installation on MacOS X using setup.py or pip would fail if Xcode 9.0 was installed.
Revision 1.11 / (download) - annotate - [select for diffs], Fri Sep 1 07:06:43 2017 UTC (6 years ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2017Q3-base,
pkgsrc-2017Q3
Changes since 1.10: +2 -2
lines
Diff to previous 1.10 (colored)
Version 4.5.18: When using --url-alias with mod_wsgi-express and the target of the URL doesnãàÑÕ exist, it will now be assumed that it will be a directory rather than a file, when finally created. This is to accomodate where may have used --setup-only option or setup-server command to pre-generate config files before the directory is created.
Revision 1.10 / (download) - annotate - [select for diffs], Fri Jul 7 15:45:55 2017 UTC (6 years, 2 months ago) by adam
Branch: MAIN
Changes since 1.9: +4 -4
lines
Diff to previous 1.9 (colored)
4.5.17: Bugs Fixed Addition in mod_wsgi-express of --allow-override option in 4.5.16 caused --url-alias option to break.
Revision 1.9 / (download) - annotate - [select for diffs], Fri Apr 14 18:11:50 2017 UTC (6 years, 5 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2017Q2-base,
pkgsrc-2017Q2
Changes since 1.8: +3 -3
lines
Diff to previous 1.8 (colored)
Changes 4.5.15: Bugs Fixed * Incorrect version for mod_wsgi was being reported in server token. * On 32 bit platforms, when reading from request content, all input would be returned and the chunk size would be ignored.
Revision 1.8 / (download) - annotate - [select for diffs], Tue Jan 3 13:23:04 2017 UTC (6 years, 8 months ago) by jperkin
Branch: MAIN
CVS Tags: pkgsrc-2017Q1-base,
pkgsrc-2017Q1
Changes since 1.7: +2 -2
lines
Diff to previous 1.7 (colored)
Use "${MV} || ${TRUE}" and "${RM} -f" consistently in post-install targets.
Revision 1.7 / (download) - annotate - [select for diffs], Fri Sep 9 09:44:52 2016 UTC (7 years ago) by wiz
Branch: MAIN
CVS Tags: pkgsrc-2016Q4-base,
pkgsrc-2016Q4,
pkgsrc-2016Q3-base,
pkgsrc-2016Q3
Changes since 1.6: +2 -2
lines
Diff to previous 1.6 (colored)
Fix PKGNAME to include apache version as well.
Revision 1.6 / (download) - annotate - [select for diffs], Sun Aug 28 15:48:36 2016 UTC (7 years ago) by wiz
Branch: MAIN
Changes since 1.5: +1 -3
lines
Diff to previous 1.5 (colored)
Remove unnecessary PLIST_SUBST and FILES_SUBST that are now provided by the infrastructure. Mark a couple more packages as not ready for python-3.x.
Revision 1.5 / (download) - annotate - [select for diffs], Wed Jun 8 17:43:48 2016 UTC (7 years, 3 months ago) by wiz
Branch: MAIN
CVS Tags: pkgsrc-2016Q2-base,
pkgsrc-2016Q2
Changes since 1.4: +2 -2
lines
Diff to previous 1.4 (colored)
Switch to MASTER_SITES_PYPI.
Revision 1.4 / (download) - annotate - [select for diffs], Wed Jun 10 10:37:06 2015 UTC (8 years, 3 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2016Q1-base,
pkgsrc-2016Q1,
pkgsrc-2015Q4-base,
pkgsrc-2015Q4,
pkgsrc-2015Q3-base,
pkgsrc-2015Q3,
pkgsrc-2015Q2-base,
pkgsrc-2015Q2
Changes since 1.3: +2 -2
lines
Diff to previous 1.3 (colored)
Changes 4.4.12: Bugs Fixed 1. If the WSGI application when run under daemon mode returned response content as many small blocks, this could result in excessive memory usage in the Apache child worker process proxying the request due to many buckets being buffered until the buffer size threshold was reached. If the number of buckets reaches a builtin threshold the buffered data will now be forcibly flushed even if the size threshold hadnãàÑÕ been reached.
Revision 1.3 / (download) - annotate - [select for diffs], Tue Feb 24 08:17:40 2015 UTC (8 years, 7 months ago) by markd
Branch: MAIN
CVS Tags: pkgsrc-2015Q1-base,
pkgsrc-2015Q1
Changes since 1.2: +2 -1
lines
Diff to previous 1.2 (colored)
Add FILES_SUBST so that ALTERNATIVES file has correct substitutions made.
Revision 1.2 / (download) - annotate - [select for diffs], Fri Feb 13 15:56:25 2015 UTC (8 years, 7 months ago) by adam
Branch: MAIN
Changes since 1.1: +2 -2
lines
Diff to previous 1.1 (colored)
Changes 4.4.8: Bugs Fixed 1. The eviction timeout was not being correctly applied when request timeout wasnãàÑÕ being applied at the same time. It may have partly worked if any of inactivity or graceful timeout were also specified, but the application of the timeout may still have been delayed. New Features 1. Added the --error-log-name option to mod_wsgi-express to allow the name of the file used for the error log, when being written to the log directory, to be overridden. 2. Added the --access-log-name option to mod_wsgi-express to allow the name of the file used for the access log, when being written to the log directory, to be overridden. 3. Added the --startup-log-name option to mod_wsgi-express to allow the name of the file used for the startup log, when being written to the log directory, to be overridden.
Revision 1.1 / (download) - annotate - [select for diffs], Sun Jan 25 12:00:28 2015 UTC (8 years, 7 months ago) by adam
Branch: MAIN
The mod_wsgi package provides an Apache module that implements a WSGI compliant interface for hosting Python based web applications on top of the Apache web server.