kpriv/pkgsrc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
pkgsrc/www/ap2-wsgi/Makefile

28 lines
701 B
Makefile
Raw Normal View History

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.
2013-08-19 12:09:51 +02:00
# $NetBSD: Makefile,v 1.15 2013/08/19 10:09:51 obache Exp $
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.
2007-10-25 00:31:51 +02:00
DISTNAME= mod_wsgi-${VERSION}
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.
2010-09-15 13:51:29 +02:00
PKGNAME= ${APACHE_PKG_PREFIX}-${PYPKGPREFIX}-wsgi-${VERSION}
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.
2007-10-25 00:31:51 +02:00
CATEGORIES= www python
MASTER_SITES= http://modwsgi.googlecode.com/files/
MAINTAINER= jan.m.danielsson@gmail.com
HOMEPAGE= http://modwsgi.googlecode.com/
COMMENT= WSGI module for apache
Set LICENSE to apache-2.0.
2009-04-30 01:18:58 +02:00
LICENSE= apache-2.0
Tag the 28 locations that result in a Python 3.1 package as supporting so. Remove it from the default list for the rest.
2011-12-03 01:02:14 +01:00
PYTHON_VERSIONS_INCLUDE_3X= yes
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.
2007-10-25 00:31:51 +02:00
APACHE_MODULE= yes
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.
2013-08-19 12:09:51 +02:00
VERSION= 3.4
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.
2007-10-25 00:31:51 +02:00
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.
2010-09-15 13:51:29 +02:00
USE_LIBTOOL= yes
GNU_CONFIGURE= yes
CONFIGURE_ARGS+= --with-apxs=${APXS:Q}
CONFIGURE_ARGS+= --with-python=${PYTHONBIN:Q}
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.
2007-10-25 00:31:51 +02:00
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.
2013-08-19 12:09:51 +02:00
PKG_APACHE_ACCEPTED= apache2 apache22 apache24
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.
2007-10-25 00:31:51 +02:00
.include "../../lang/python/extension.mk"
.include "../../mk/apache.mk"
.include "../../mk/bsd.pkg.mk"
Reference in a new issue Copy permalink