|
| 1 | +============= |
| 2 | +Version 4.3.2 |
| 3 | +============= |
| 4 | + |
| 5 | +Version 4.3.2 of mod_wsgi can be obtained from: |
| 6 | + |
| 7 | + https://github.com/GrahamDumpleton/mod_wsgi/archive/4.3.2.tar.gz |
| 8 | + |
| 9 | +Known Issues |
| 10 | +------------ |
| 11 | + |
| 12 | +1. The makefiles for building mod_wsgi on Windows are currently broken and |
| 13 | +need updating. As most new changes relate to mod_wsgi daemon mode, which is |
| 14 | +not supported under Windows, you should keep using the last available |
| 15 | +binary for version 3.X on Windows instead. |
| 16 | + |
| 17 | +Bugs Fixed |
| 18 | +---------- |
| 19 | + |
| 20 | +1. Linux behaviour when using ``connect()`` on a non blocking UNIX socket |
| 21 | +and the listener queue is full, is apparently not POSIX compliant and it |
| 22 | +returns ``EAGAIN`` instead of ``ECONNREFUSED``. The code handling errors |
| 23 | +from the ``connect()`` wasn't accomodating this non standard behaviour |
| 24 | +and so would fail immediately rather than retrying. |
| 25 | + |
| 26 | +2. Only change working directory for mod_wsgi daemon process after having |
| 27 | +dropped privileges to target user. This is required where the specified |
| 28 | +working directory is on an NFS file system configured so as not to have |
| 29 | +root access priviliges. |
| 30 | + |
| 31 | +3. The workaround for getting pyvenv style virtual environments to work |
| 32 | +with Python 3.3+ would break brew Python 2.7 on MacOS X as brew Python |
| 33 | +appears to not work in embedded systems which use Py_SetProgramName() |
| 34 | +instead of using Py_SetPythonHome(). Now only use Py_SetProgramName() if |
| 35 | +detect it is actually a pyvenv style virtual environment. This even appears |
| 36 | +to be okay for brew Python 3.4 at least as it does still work with the |
| 37 | +Py_SetProgramName() call even if brew Python 2.7 doesn't. |
| 38 | + |
| 39 | +New Features |
| 40 | +------------ |
| 41 | + |
| 42 | +1. If the ``WSGIPythonHome`` directive or the ``python-home`` option is |
| 43 | +used with the ``WSGIDaemonProcess`` directive, the path provided, which is |
| 44 | +supposed to be the root directory of the Python installation or virtual |
| 45 | +environment, will be checked to see if it is actually accessible and refers |
| 46 | +to a directory. If it isn't, a warning message will be logged along with |
| 47 | +any details providing an indication of what may be wrong with the supplied |
| 48 | +path. |
| 49 | + |
| 50 | +This is being done to warn when an invalid path has been supplied that |
| 51 | +subsequently is likely to be rejected and ignored by the Python |
| 52 | +interpreter. In such a situation where an invalid path is supplied the |
| 53 | +Python interpreter doesn't actually log anything and will instead silently |
| 54 | +fallback to using any Python installation it finds by seaching for |
| 55 | +``python`` on the users ``PATH``. This may not be the Python installation |
| 56 | +or virtual environment you intended be used. |
| 57 | + |
| 58 | +2. The Apache configuration snippet generated as an example when running |
| 59 | +the ``install-module`` sub command of ``mod_wsgi-express`` to install the |
| 60 | +``mod_wsgi.so`` into the Apache installation itself, will now output a |
| 61 | +``WSGIPythonHome`` directive for the Python installation or virtual |
| 62 | +environment the mod_wsgi module was compiled against so that the correct |
| 63 | +Python runtime will be used. |
0 commit comments