grahamdumpleton / mod_wsgi Goto Github PK

Chunked request content is actually not allowed by the WSGI specification.

The mod_wsgi does provide the:

WSGIChunkedRequest On

option for enabling a non WSGI specific feature to allow it, but a web application would still need to technically violate the WSGI specification to make use of it by way of ignoring CONTENT_LENGTH on the request.

Although this works in embedded mode, it doesn't work in daemon mode of mod_wsgi. To have it work in daemon mode will entail a bit of work which has been previously discussed in:

• https://groups.google.com/d/msg/modwsgi/Rk-cXTGSCHQ/U_CIhDfq9t0J

In implementing it, should also chase down proposal by Armin Ronacher of how a WSGI server could flag that chunked request content was supported and being used.

The ap_scan_script_header_err_core_ex() function util_script.c in Apache is used to scan response headers from daemon mode processes. This enforces a fixed limit on the size of the response header values.

This cause a problem for OpenStack keystone which can generate authentication tokens which are longer.

Lift the size limit and/or make it configurable so can be set to be larger.

I'm getting a '503 Service Unavailable' with the following error in the ErrorLog when connecting to the wsgi app:

(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'

I'm running mod_wsgi-4.1.1 + python 2.7.6 + apache 2.2.15 + Linux 2.6.32 x86_64

I started a simple hello world app using mod_wsgi-express:

mod_wsgi-express start-server hello.wsgi

I checked that the sock file exist and has rwx permission by the owner.

mod_wsgi-4.3.0.tar.gz is much better than 4.3.0.tar.gz. Especially when it's mirrored like here:

https://java.net/projects/solaris-userland/sources/community-source-archives/show

(as used by https://java.net/projects/solaris-userland)

Allow enabling of mod_deflate for compressing responses.

In various situations mod_wsgi currently simply calls exit() to kill the process. This means it doesn't destroy Apache memory pools and allow any cleanup functions to be called. This may mean that Apache modules could crash on shutdown if they had finalisers (such as C++ global object destructors) which expect the memory pool cleanup to have occurred.

Example of where this may be the case is discussed in:

• https://groups.google.com/forum/#!topic/modwsgi/2hI8rzvGlP4

In Apache itself, rather than just call exit() is actually does:

    /*
     * Register a cleanup in the config apr_pool_t (normally pconf). When
     * we do a restart (or shutdown) this cleanup will cause the
     * shared object to be unloaded.
     */
    apr_pool_cleanup_register(cmd->pool, modi, unload_module, apr_pool_cleanup_null);


int main(…) {
    …

    destroy_and_exit_process(process, 0);

    return 0; /* Termination 'ok' */
}

static void destroy_and_exit_process(process_rec *process,
                                     int process_exit_value)
{
    /*
     * Sleep for TASK_SWITCH_SLEEP micro seconds to cause a task switch on
     * OS layer and thus give possibly started piped loggers a chance to
     * process their input. Otherwise it is possible that they get killed
     * by us before they can do so. In this case maybe valueable log messages
     * might get lost.
     */
    apr_sleep(TASK_SWITCH_SLEEP);
    apr_pool_destroy(process->pool); /* and destroy all descendent pools */
    apr_terminate();
    exit(process_exit_value);
}

Need to look at whether mod_wsgi needs to do something similar, destroying the main process pool and then calling apr_terminate() before exiting.

Graham, I was wondering if you could digitally sign (PGP/GPG) mod_wsgi releases.

Thanks for your effort!.

Current result has to be:

None - AUTH_USER_NOT_FOUND
True - AUTH_GRANTED
False - AUTH_DENIED

To allow the user to be overridden in Apache request request, allow:

None - AUTH_USER_NOT_FOUND
True - AUTH_GRANTED
string - AUTH_GRANTED with req->user set to user name passed back as string.
False - AUTH_DENIED

See:

https://groups.google.com/forum/#!topic/modwsgi/i2UXumQfmHI

for latest discussion about this.

Need to use environment variables instead.

Check the Python installation and see if it has a shared library available. If it doesn't them put out that this will cause installation to fail or cause problems at run time.

I was trying to install mod_wsgi-4.2.7 from source using Python 2.4, And It fails at during make execution.
Also, It works with Python 2.7 just fine.

Are these versions incompatible by design or it's bug?
Can someone please look into it?

This is the log it generates:

./configure --with-python=/usr/bin/python2.4 --with-apxs=/usr/sbin/apxs

checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for prctl... yes
checking Apache version... 2.2.3
configure: creating ./config.status
config.status: creating Makefile

make

/usr/sbin/apxs -c -I/usr/include/python2.4 -DNDEBUG -D_GNU_SOURCE  -Wc,-g -Wc,-O2  src/server/mod_wsgi.c src/server/wsgi_*.c -L/usr/lib -L/usr/lib/python2.4/config  -lpython2.4 -lpthread -ldl  -lutil -lm
/usr/lib/apr-1/build/libtool --silent --mode=compile gcc -prefer-pic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -fno-strict-aliasing  -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -pthread -I/usr/include/httpd  -I/usr/include/apr-1   -I/usr/include/apr-1  -g -O2 -I/usr/include/python2.4 -DNDEBUG -D_GNU_SOURCE  -c -o src/server/mod_wsgi.lo src/server/mod_wsgi.c && touch src/server/mod_wsgi.slo
src/server/mod_wsgi.c: In function 'wsgi_log_stack_traces':
src/server/mod_wsgi.c:8107: warning: implicit declaration of function '_PyThread_CurrentFrames'
src/server/mod_wsgi.c:8107: warning: assignment makes pointer from integer without a cast
src/server/mod_wsgi.c:8118: error: 'Py_ssize_t' undeclared (first use in this function)
src/server/mod_wsgi.c:8118: error: (Each undeclared identifier is reported only once
src/server/mod_wsgi.c:8118: error: for each function it appears in.)
src/server/mod_wsgi.c:8118: error: expected ';' before 'i'
src/server/mod_wsgi.c:8124: error: 'i' undeclared (first use in this function)
apxs:Error: Command failed with rc=65536
.
make: *** [src/server/mod_wsgi.la] Error 1

We run site through Apache/2.2.16 (Debian) + mod_wsgi/3.3 + Python/2.6.6. The Apache config is shown below:

<VirtualHost *:80>
    ...
    WSGIDaemonProcess <site name> processes=8 threads=1 home=/tmp maximum-requests=500 display-name=%{GROUP} user=nobody
    WSGIProcessGroup <site name>
    WSGIScriptAlias / /xx
    ...
</VirtualHost>

But as time goes by, wsgi process num was reduced from 8 to 6 through shell command ps aux | grep <site name> . Though Apache error log, we found the two processes (pid=10779 and pid=10772) has been shutdown but not restarted.

[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Maximum requests reached 'xxx'.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Shutdown requested 'xxx'.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Stopping process 'xxx'.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Destroying interpreters.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Destroy interpreter 'xxx:80|'.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Cleanup interpreter ''.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Terminating Python.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Python has shutdown.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Maximum requests reached 'xxx'.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Shutdown requested 'xxx'.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Stopping process 'xxx'.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Destroying interpreters.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Destroy interpreter 'xxx:80|'.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Cleanup interpreter ''.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Terminating Python.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Python has shutdown.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Maximum requests reached 'xxx'.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Shutdown requested 'xxx'.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Stopping process 'xxx'.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Destroying interpreters.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Destroy interpreter 'xxx:80|'.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Cleanup interpreter ''.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Terminating Python.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Python has shutdown.
[Wed Oct 15 22:32:14 2014] [info] mod_wsgi (pid=12726): Attach interpreter ''.
[Wed Oct 15 22:32:18 2014] [info] mod_wsgi (pid=12726): Create interpreter 'xxx:80|'.
[Wed Oct 15 22:32:18 2014] [info] [client 219.136.134.164] mod_wsgi (pid=12726, process='xxx', application='xxx:80|'): Loading WSGI script '/xxx'.

Look forward to your reply.

I am trying to install mod_wsgi into a virtualenv with Python 2.7.6 and setuptools 3.6 (but otherwise empty).

pip install mod_wsgi dies with ...

/usr/bin/ld: cannot find -lpython

I am working around this via ...

diff --git a/setup.py b/setup.py
index 09ad4040..27de7ff5 100644
--- a/setup.py
+++ b/setup.py
@@ -88,7 +88,7 @@ with open(os.path.join(os.path.dirname(__file__),
 # Work out location of Python library and how to link it.

 PYTHON_VERSION = get_python_config('VERSION')
-PYTHON_LDVERSION = get_python_config('LDVERSION') or ''
+PYTHON_LDVERSION = get_python_config('LDVERSION') or PYTHON_VERSION

 PYTHON_LIBDIR = get_python_config('LIBDIR')
 PYTHON_CFGDIR =  get_python_lib(plat_specific=1, standard_lib=1) + '/config'

... but I don't know if that's correct for all versions of Python and setuptools. My distutils.sysconfig doesn't seem to define LDVERSION, but it does (I think correctly) define VERSION as '2.7'.

If the daemon mode process crashes when yielding a chunked response by virtue of not setting a content length, or if either embedded or daemon mode is used and the WSGI application triggers an exception while yielding data, then the chunked response is being closed off with a final '0' chunk as if the response was complete rather than it leaving a hanging block with no '0' chunk.

This is possibly undesirable, but then it also isn't really known whether a client could even rely on absence of a '0' chunk to indicate that some sort of error occurred. This is because chunked transfer encoding is a hop by hop header and so a proxy can technically change the chunking due to buffering. It isn't known whether a proxy is required to preserve the absence of a '0' chunk so that a client is aware of it, or whether it is completely within its rights to add a '0' chunk with a subsequent loss of information.

Looking at the Apache HTTP proxy module it does try and ensure that not '0' chunk is added if the connection is broken:

        /* RFC 2616, Section 3.6.1
         *
         * If there is an EOS bucket, then prefix it with:
         *   1) the last-chunk marker ("0" CRLF)
         *   2) the trailer
         *   3) the end-of-chunked body CRLF
         *
         * We only do this if we have not seen an error bucket with
         * status HTTP_BAD_GATEWAY. We have memorized an
         * error bucket that we had seen in the filter context.
         * The error bucket with status HTTP_BAD_GATEWAY indicates that the
         * connection to the backend (mod_proxy) broke in the middle of the
         * response. In order to signal the client that something went wrong
         * we do not create the last-chunk marker and set c->keepalive to
         * AP_CONN_CLOSE in the core output filter.
         *
         * XXX: it would be nice to combine this with the end-of-chunk
         * marker above, but this is a bit more straight-forward for
         * now.
         */
        if (eos && !f->ctx) {
            /* XXX: (2) trailers ... does not yet exist */
            e = apr_bucket_immortal_create(ASCII_ZERO ASCII_CRLF
                                           /* <trailers> */
                                           ASCII_CRLF, 5, c->bucket_alloc);
            APR_BUCKET_INSERT_BEFORE(eos, e);
        }

Other modules such as when proxying SCGI don't try and do this though and always add a EOS bucket after the bucket for the socket, meaning a client couldn't know if the connection was lost. For SCGI at least, this is because there is no chunking of data from SCGI process and so it couldn't know.

Right now have similar problem with responses from daemon mode as don't have any framing of data using chunked encoding or otherwise.

As to when an exception is raised, it looks like the EOS bucket will always be added automatically at the end of a request. The only thing one can appear to do is set r->eos_sent to true to fake out that EOS has already been sent. That should prevent automatic sending of EOS bucket and thus disable sending to '0' chunk if chunked transfer encoding on response.

C:\Users\gbs03566\Desktop\mod_wsgi-4.3.0>python setup.py install
Traceback (most recent call last):
File "setup.py", line 41, in
'Apache httpd server packages.' % APXS)
RuntimeError: The 'apxs' command appears not to be installed or is not executable. Please check the list of prerequisites in the documentation for this package and install any missing Apache httpd server packages.

If I do pip install mod_wsgi in my virtualenv I get this error:

error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.8" but "10.9" during configure

If I instead pip install mod_wsgi==4.2.7, it installs without issue.

P.S. Thanks for all your work! Just saw your blog posts discussing the current state of mod_wsgi and excited to try the new features. Had no idea it was a simple pip install away. Cheers!

This question is related with my question.

Actually I use the Apacha Version over Ubuntu 14.04 LTS 64bits:
Server version: Apache/2.4.7 (Ubuntu)
Server built: Jul 22 2014 14:36:38

When I type command mod_wsgi-express start-server to check if it runs. It seems not running and I have an error:

root@website:/home/website# mod_wsgi-express start-server
Server URL        : http://localhost:8000/
Server Root       : /tmp/mod_wsgi-localhost:8000:0
Server Conf       : /tmp/mod_wsgi-localhost:8000:0/httpd.conf
Error Log File    : /tmp/mod_wsgi-localhost:8000:0/error_log
AH00526: Syntax error on line 16 of /tmp/mod_wsgi-localhost:8000:0/httpd.conf:
Error:\tApache has not been designed to serve pages while\n\trunning as root.  There are known race conditions that\n\twill allow any local user to read any file on the system.\n\tIf you still desire to serve pages as root then\n\tadd -DBIG_SECURITY_HOLE to the CFLAGS env variable\n\tand then rebuild the server.\n\tIt is strongly suggested that you instead modify the User\n\tdirective in your httpd.conf file to list a non-root\n\tuser.\n

I have the same problem during installation to doom. Any suggest is welcome!

More Information:

Modules used in Apache:

Compiled in modules:
  core.c
  mod_so.c
  mod_watchdog.c
  http_core.c
  mod_log_config.c
  mod_logio.c
  mod_version.c
  mod_unixd.c

Python Version:

>>> print (sys.version) 
2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2]

Right now mod_wsgi express accepts a UNIX file system path to a WSGI script file. It does not allow you to specify a Python module to be imported.

Add a --application-type option, which defaults to 'script', which can then be set to either 'module' or 'paste'.

For 'module' mod_wsgi express would organise for that module, which would contain the WSGI application entry point, to be loaded and used for the WSGI application.

For 'paste', it would interpret the the file as a Paste .ini file, with application pipeline being setup in it, and load and use it.

Older versions of Django don't have BASE_DIR in settings.py. Need to come up with recipe that works for older Django versions.

./apxs -c -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -Wc,-g -Wc,-O2 -Wc,'-arch x86_64' src/server/mod_wsgi.c src/server/wsgi__.c -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -arch x86_64 -lpython2.7 -ldl -framework CoreFoundation
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/mod_wsgi.lo src/server/mod_wsgi.c && touch src/server/mod_wsgi.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_apache.lo src/server/wsgi_apache.c && touch src/server/wsgi_apache.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_buckets.lo src/server/wsgi_buckets.c && touch src/server/wsgi_buckets.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_convert.lo src/server/wsgi_convert.c && touch src/server/wsgi_convert.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_daemon.lo src/server/wsgi_daemon.c && touch src/server/wsgi_daemon.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_interp.lo src/server/wsgi_interp.c && touch src/server/wsgi_interp.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_logger.lo src/server/wsgi_logger.c && touch src/server/wsgi_logger.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_metrics.lo src/server/wsgi_metrics.c && touch src/server/wsgi_metrics.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_restrict.lo src/server/wsgi_restrict.c && touch src/server/wsgi_restrict.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_server.lo src/server/wsgi_server.c && touch src/server/wsgi_server.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_stream.lo src/server/wsgi_stream.c && touch src/server/wsgi_stream.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_validate.lo src/server/wsgi_validate.c && touch src/server/wsgi_validate.slo
./libtool --silent --mode=link /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -o src/server/mod_wsgi.la -rpath /usr/libexec/apache2 -module -avoid-version src/server/wsgi_validate.lo src/server/wsgi_stream.lo src/server/wsgi_server.lo src/server/wsgi_restrict.lo src/server/wsgi_metrics.lo src/server/wsgi_logger.lo src/server/wsgi_interp.lo src/server/wsgi_daemon.lo src/server/wsgi_convert.lo src/server/wsgi_buckets.lo src/server/wsgi_apache.lo src/server/mod_wsgi.lo -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -arch x86_64 -lpython2.7 -ldl -framework CoreFoundation
./libtool: line 8962: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.10.xctoolchain/usr/bin/cc: No such file or directory
apxs:Error: Command failed with rc=8323072
.
make: *_* [src/server/mod_wsgi.la] Error 1

madhus-MacBook-Pro:mod_wsgi-4.2.1 madhu$ ls

Added a few includes in makefile as it is searching for it. Not sure what to do with libtool looking for cc in wrong directory, editing apxs doesn't seem like a good option. Any suggestions?

This is to allow a Python script to control host access. It would use WSGIAccessScript.

When running setup-server or start-server, record the original command line from sys.argv as a comment at the top of apachectl so that one can determine later what command was used to create the configuration.

Hello,

I followed https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/apache-auth/ to restrict the access to a webdav shared directory only to users belonging to "DI" group (a group on a django project's database), and ended up with the following apache directives:

LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule dav_lock_module modules/mod_dav_lock.so
LoadModule wsgi_module modules/mod_wsgi.so

<Directory />
    AllowOverride none
    Require all denied
</Directory>

<Directory "/srv/http">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Alias /dav /srv/http/dav

WSGIScriptAlias / /path/to/django/project/projectname/wsgi.py
WSGIPythonPath /path/to/django/project/
WSGIProcessGroup %{GLOBAL}
WSGIApplicationGroup django

DavLockDB /http/.davlockdb

<Location "/dav">
  Dav On
  AuthType Basic
  AuthName "Top Secret"
  AuthBasicProvider wsgi
  WSGIAuthUserScript /path/to/django/project/projectname/wsgi.py
  WSGIAuthGroupScript /path/to/django/project/projectname/wsgi.py
  Require wsgi-group DI
  Require valid-user
</Location>

However, when I access to the dav directory with a webdav client authenticating with a user that doesn't belong to DI group, it anyway can read and write. Apache's error_log, multiple times, says:

mod_wsgi (pid=5815): Authorization of user '(null)' to access '/dav/' failed. User is not a member of any groups.
mod_wsgi (pid=5815): Authorization of user 'prov2' to access '/dav/' failed. User is not a member of designated groups.

Note that it always first says something about a "null" user, then it shows the right username, in this case prov2. As I said, prov2 doesn't belong to DI group on django database.

On the Require line, I wrote 'wsgi-group' instead of just 'group'. If I switch it to group, then the apache error_log says: "AH01664: No group file was specified in the configuration", but the user is still allowed to read and write on dav directory.

My goal is only to allow users belonging to a specific group on django project's database to read and write on this directory... what could be wrong?

My setup is:
apache: 2.4.10-1
mod_wsgi: 3.5-1
python: 3.4.1-1
django: 1.8 (dev)

Greetings,
H.

As detailed in:

• https://groups.google.com/d/msg/modwsgi/0JFLl2Al60k/ci4BdMW4BOUJ

A response header set by the WSGI application is visible to mod_headers when running in embedded mode, but not when using daemon mode.

To test use:

def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!'

    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output))),
                        ('X-Value', 'XXX')]
    start_response(status, response_headers)

    return [output]

and in Apache configuration:

Header edit X-Value ^ "YYY"

If in embedded mode and use curl -v see:

< HTTP/1.1 200 OK
< Date: Fri, 02 May 2014 03:02:25 GMT
< Server: Apache/2.2.26 (Unix) DAV/2 mod_wsgi/4.1.0 Python/2.7.2 mod_ssl/2.2.26 OpenSSL/0.9.8y
< X-Value: YYYXXX
< Transfer-Encoding: chunked
< Content-Type: text/plain
<
* Connection #0 to host localhost left intact

If in daemon mode with:

WSGIDaemonProcess xxx
WSGIProcessGroup xxx

see:

< HTTP/1.1 200 OK
< Date: Fri, 02 May 2014 03:03:03 GMT
< Server: Apache/2.2.26 (Unix) DAV/2 mod_wsgi/4.1.0 Python/2.7.2 mod_ssl/2.2.26 OpenSSL/0.9.8y
< X-Value: XXX
< Content-Length: 12
< Content-Type: text/plain
<
* Connection #0 to host localhost left intact

If mod_wsgi-express is run as root and the --user and --group options were not supplied, Apache will fail to startup and give the real worrying error message of:

Error:\tApache has not been designed to serve pages while\n\trunning as root.  There are known race conditions that\n\twill allow any local user to read any file on the system.\n\tIf you still desire to serve pages as root then\n\tadd -DBIG_SECURITY_HOLE to the CFLAGS env variable\n\tand then rebuild the server.\n\tIt is strongly suggested that you instead modify the User\n\tdirective in your httpd.conf file to list a non-root\n\tuser.\n

The mod_wsgi-express script should detect this case itself and instead output an error message first stating that when being run as root that the --user and --group options should be supplied. That way users don't get to see Apache's own nasty message and get worried of specific think that mod_wsgi express is doing something wrong.

The ap_scan_script_header_err_brigade() from Apache used to process response headers from daemon mode processes will merge WWW-Authenticate header values onto one line. This caused issues so mod_wsgi was changed to split them again. The splitting though cause problems where WWW-Authenticate header values weren't completely valid and used comma in their values.

What needs to be done is that parser needs to be duplicated with it leaving the headers as is and neither splitting or joining.

For prior discussion see:

• http://code.google.com/p/modwsgi/issues/detail?id=249

Also see #3 which also requires the parser function to be duplicated.

Change is:

• 20cc256

This blocks passing of headers which characters in name other than alpha numerics and '-'.

There are two parts to this.

Fix the Apache 2.4 authnz problems where it could occur even though it was okay for the WSGI application due to Apache 2.4 itself doing it.

Apply the restriction to Apache 2.2.

The changes resulting from #25 need to be back ported to 3.X branch and a CERT possibly raised to force Linix distros to back port the patch to older mod_wsgi versions they run since they otherwise will not fix it.

After moving from mod_wsgi 3.3 (Ubuntu 12.04) to mod_wsgi 3.4 (Ubuntu 13.10), we have seen several occasions where multiple daemon processes segfault at the same time when I touch the main wsgi.py file to perform a graceful restart.

Here's the stack trace from the core file:

Core was generated by `(wsgi:xxxxxxx)    -k start'.
Program terminated with signal 11, Segmentation fault.

(gdb) bt
#0  new_threadstate (init=1, interp=0x0) at ../Python/pystate.c:202
#1  PyThreadState_New (interp=0x0) at ../Python/pystate.c:213
#2  0x00007f7460a9ca3c in PyGILState_Ensure () at ../Python/pystate.c:600
#3  0x00007f7460e63c68 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#4  0x00007f74653c6f6e in start_thread (arg=0x7f745f2ad700) at pthread_create.c:311
#5  0x00007f74650f19cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
(gdb) bt full
#0  new_threadstate (init=1, interp=0x0) at ../Python/pystate.c:202
        tstate = 0x7f74580008c0
#1  PyThreadState_New (interp=0x0) at ../Python/pystate.c:213
No locals.
#2  0x00007f7460a9ca3c in PyGILState_Ensure () at ../Python/pystate.c:600
        current = <optimized out>
        tcur = 0x0
#3  0x00007f7460e63c68 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
No symbol table info available.
#4  0x00007f74653c6f6e in start_thread (arg=0x7f745f2ad700) at pthread_create.c:311
        __res = <optimized out>
        pd = 0x7f745f2ad700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140137789576960, 7677402908759434006, 0, 140137902719072, 140137902460528, 4096, -7754315576225815786, 
                -7754258218053393642}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = 0
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#5  0x00007f74650f19cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Other threads:

(gdb) thread apply all bt

Thread 4 (Thread 0x7f744de40700 (LWP 15917)):
#0  0x00007f74650b885d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f74650b8701 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:137
#2  0x00007f7460e667a9 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#3  0x00007f74653c6f6e in start_thread (arg=0x7f744de40700) at pthread_create.c:311
#4  0x00007f74650f19cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 3 (Thread 0x7f745faae700 (LWP 25971)):
#0  0x00007f74650e9de3 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f74655ffe25 in apr_sleep () from /usr/lib/libapr-1.so.0
#2  0x00007f7460e63f37 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#3  0x00007f74653c6f6e in start_thread (arg=0x7f745faae700) at pthread_create.c:311
#4  0x00007f74650f19cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 2 (Thread 0x7f7465e85780 (LWP 25876)):
#0  0x00007f7454376724 in _fini () from /usr/lib/x86_64-linux-gnu/libtiff.so.5
#1  0x00007f7465c80f47 in _dl_fini () at dl-fini.c:258
#2  0x00007f7465033071 in __run_exit_handlers (status=-1, listp=0x7f74653b86a8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:77
#3  0x00007f74650330f5 in __GI_exit (status=<optimized out>) at exit.c:99
#4  0x00007f7460e709ca in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#5  0x00007f7460e71ca5 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#6  0x00007f7465ee9ef1 in ap_run_post_config (pconf=0x7f7465e83028, plog=0x7f7465e57028, ptemp=0x7f7465e4d028, s=0x7f7465e49d80) at config.c:104
#7  0x00007f7465ecabd7 in main (argc=3, argv=0x7fffdd66c548) at main.c:765

Thread 1 (Thread 0x7f745f2ad700 (LWP 25972)):
#0  new_threadstate (init=1, interp=0x0) at ../Python/pystate.c:202
#1  PyThreadState_New (interp=0x0) at ../Python/pystate.c:213
#2  0x00007f7460a9ca3c in PyGILState_Ensure () at ../Python/pystate.c:600
#3  0x00007f7460e63c68 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#4  0x00007f74653c6f6e in start_thread (arg=0x7f745f2ad700) at pthread_create.c:311
#5  0x00007f74650f19cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Add a --rotate-logs argument to have rotatelogs to be used with piped logger to enable log file rotation and ageing.

The mod_wsgi express options for creating a server configuration suitable for start/stop via an apachectl command allow the generated configuration to be used from system init scripts. It still requires those init scripts be generated. So, extend what is generated to also include any startup scripts for direct integration into the system startup process manager. All that would then be required is to copy or link the startup scripts into the appropriate location and let the system know about them. Should generate startup scripts suitable for Ubuntu, Debian and RedHat.

Recently I started looking into mod_wsgi running under Windows (Apache/2.2.22). The issue I'm facing is:

• I wish to run against a specific Python version, installed along with my app, in a given directory
• I do not want to depend on a PATH variable, or the presence of a python27.dll in C:\Windows\System32 or C:\Windows\SysWOW64
• However, in order for mod_wsgi to load, it (seems to) need this dll, because when I copy the dll to the Apache bin directory, Apache can load the module. If the dll is not there, I end up with exactly the issue described earlier (#272 on the old tracker).
• Because the module itself can not be loaded, it is also impossible to use the WSGIPythonHome directive

I would expect to be able to load the module (without having a dependency on python27.dll), and only after it has been loaded, have the WSGIPythonHome directive determine which Python installation to use.

I haven't tried building a static version of the module, which presumably would get me out of this circular dependency. But that really is not the direction I like to take. Is there another way out?

Is trying to copy it to itself rather than into Apache modules directory.

When using mod_wsgi express, even though it will default to staying in foreground, the WSGI application still runs in a separate daemon process group.

Add a --debug-mode option which will run a single process for the whole of Apache with a single thread using the Apache -DONE_PROCESS option and mod_wsgi in embedded mode with a single thread. In using this, Apache attaches stdin/stdout to that of the console you can the command in. This then allows the use of pdb to debug your WSGI application.

followed the instructions here but I am getting this error:

copying src/server/apxs_config.py -> build/lib.linux-x86_64-2.6/mod_wsgi/server
running build_ext
building 'mod_wsgi.server.mod_wsgi-py26' extension
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fwrapv -fPIC -I/usr/include/apache2 -I/usr/include/python2.6 -c src/server/wsgi_logger.c -o build/temp.linux-x86_64-2.6/src/server/wsgi_logger.o -I/usr/include/apache2 -I. -I/usr/include/apr-1 -DSSL_EXPERIMENTAL_ENGINE -DMAX_SERVER_LIMIT=200000 -DLDAP_DEPRECATED -DMAXLINE=4096 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fPIC -Wall -fno-strict-aliasing -DLDAP_DEPRECATED -pthread
In file included from src/server/wsgi_apache.h:74,
from src/server/wsgi_logger.h:25,
from src/server/wsgi_logger.c:21:
/usr/include/apache2/mpm_common.h:46:17: error: mpm.h: No such file or directory
error: command 'gcc' failed with exit status 1

Any ideas?

Currently we run mod_wsgi compiled against Python 2 (installed through the Ubuntu package manager). I just realised the Python 3 package for mod_wsgi can not be installed at the same time because the module name and apache directives would conflict. Is there a possibility to have two versions of mod_wsgi, one for python 2 and one for python3, on the same apache server?

This is being suggested for Apache ProxyErrorOverride directive in httpd-dev list. Monitor and perhaps adopt same thing.

If use:

Header set X-Special-Header "XXX" early

then this isn't visible as HTTP_X_SPECIAL_HEADER in auth scripts or in WSGI application.

Would expect it should since should be set before request is even mapped and so should be picked up later.

May or may not be some relationship to #5.

If Apache output filters are detected that could care about seeing the actual content for a HEAD, the mod_wsgi will remap a HEAD request to a GET request. This is to ensure that output filters will generate the same response headers where they are generating some based on the actual content. If this isn't done it is technically breaking the HTTP specification that response headers for GET and HEAD should be the same.

Even though this is the case, provide a directive to disable this auto mapping for those people who believe that they aren't using any Apache output filters where this would matter.

See:

• http://stackoverflow.com/questions/22443245/why-does-apache-wsgi-map-head-to-get-how-to-speed-up-head-in-flask/22444613

Original commentary about the GET vs HEAD problem at:

• http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html

In wsgi_hook_check_user_id(), wsgi_check_password(), wsgi_get_realm_hash(), wsgi_groups_for_user() and wsgi_allow_access() there appear to be bugs in the way that reference counting is handled for the object variable.

Initialisation occurs as:

        object = PyDict_GetItemString(module_dict, "load_session");

This is a borrowed reference, yet have:

            adapter = newHandlerObject(r, rconfig);

            if (adapter) {
            }
            else
                Py_DECREF(object);

Technically creating the handler object shouldn't fail, but if it did, then we would decrement reference on borrowed reference.

Next problem is that have:

                /* Close the log object so data is flushed. */

                method = PyObject_GetAttrString(adapter->log, "close");

                if (!method) {
                    PyErr_Format(PyExc_AttributeError,
                                 "'%s' object has no attribute 'close'",
                                 adapter->log->ob_type->tp_name);
                }
                else {
                    args = PyTuple_New(0);
                    object = PyEval_CallObject(method, args);
                    Py_DECREF(args);
                }

                Py_XDECREF(object);
                Py_XDECREF(method);

If there was no close() on the handler object, then the object variable wouldn't have been overridden, yet we try and decrement reference.

Technically the handler object will always have a close(), but if it didn't for some read, would decrement on borrowed reference.

Due to the UNIX_PATH_MAX defined on the struct sockaddr_un:

#define UNIX_PATH_MAX    108

struct sockaddr_un {
    sa_family_t sun_family;               /* AF_UNIX */
    char        sun_path[UNIX_PATH_MAX];  /* pathname */
};

There is a limit of 107 (108 including the null byte) on the length of a path for a socket - but when the bind is called, the silently truncated path starts causing problems, and you start seeing -1 EADDRINUSE (Address already in use) errors in the strace.

This happens when WSGISocketPrefix is set to a path that might be shorter than 107 characters, but can be longer once the extra information is added (like pid and extension). However the log outputs the full path when it says it can't bind to the socket. As a result, Apache just hangs when talking to WSGI.

This only affects Daemon mode.

While the underlying system can't be changed, it'd probably be useful to somehow catch this weird edge case.

Here's the strace output if you're curious:

$ strace -f ./bin/apache
...
7619  bind(8, {sa_family=AF_FILE, path="/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/ws"}, 110) = -1 EADDRINUSE (Address already in use)
7619  unlink("/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/wsgitest.7619.0.1.sock") = -1 ENOENT (No such file or directory)
7619  bind(8, {sa_family=AF_FILE, path="/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/ws"}, 110) = -1 EADDRINUSE (Address already in use)
7633  connect(11, {sa_family=AF_FILE, path="/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/ws"}, 110) = -1 ECONNREFUSED (Connection refused)
...

And the log:

src/server/mod_wsgi.c(7267): mod_wsgi (pid=7370): Socket for 'graphite-w-otsdb' is '/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/wsgi.7370.0.1.sock'.
(98)Address already in use: mod_wsgi (pid=7370): Removing stale unix domain socket '/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/wsgi.7370.0.1.sock'.
(98)Address already in use: mod_wsgi (pid=7370): Couldn't bind unix domain socket '/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/wsgi.7370.0.1.sock'.

https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIProcessGroup

It would be nice to note in this segment of the docs that the aforementioned directive must reside within a Directory or similar structure. WSGIApplicationGroup has an illustrative example but could also benefit from the added clarification.

To support easy way of doing:

• http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms

As discussed in:

• https://groups.google.com/forum/#!topic/modwsgi/T3_aPTD-RPU/discussion

manipulation of reference counts for auth phase SSL functions is not correct.

This will result in problems under Python 3 and when an error is being raised from the function.

For similar concept see:

• http://httpd.apache.org/docs/trunk/mod/mod_reqtimeout.html

This may only be possible after replacing the current daemon mode input stack with something more independent of the Apache request structure which deals with the socket more directly.

See:

http://emptysqua.re/blog/a-normal-accident-in-python-and-mod-wsgi/

The Python internals does not itself trigger garbage collection before destroying a sub interpreter.

In face value this appears to be wrong and it should.

Look at triggering it explicitly in mod_wsgi.

When the mod_wsgi core was changed to update sys.path when the home option was given to WSGIDaemonProcess so that directory was also searched, a short cut was done of just adding in the empty string. The problem with this is that it only works so long as the current working directory isn't changed.

In order to mirror what happens when you use python script.py, it should be adding the actual absolute directory so that it will always be searched, even if the current working directory changes.

I am using the Mac Ports version of mod_wsgi. I have apache2 @2.2.27_0+preforkmpm, python27 @2.7.8_1 and mod_wsgi @4.2.8_0+python27 installed in Mac OS X 10.9.4. Enabling "LoadModule wsgi_module modules/mod_wsgi.so" in httpd.conf results in a crash as soon as Apache is started. The crash report shows:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 mod_wsgi.so 0x00000001101fec13 wsgi_python_init + 55
1 mod_wsgi.so 0x00000001102000da wsgi_hook_child_init + 133
2 httpd 0x000000010f30c140 ap_run_child_init + 51
3 httpd 0x000000010f32fa6a child_main + 263
4 httpd 0x000000010f32f2fc make_child + 207
5 httpd 0x000000010f32ed68 ap_mpm_run + 2089
6 httpd 0x000000010f3114ce main + 2314
7 libdyld.dylib 0x00007fff8ef675fd start + 1

Commenting out the LoadModule line allows Apache to run, but of course without mod_wsgi.

What could be the problem?

Consider adding options to mod_wsgi-express to allow restrictions to be placed on the maximum number of files that can be opened as well as maximum number of processes.

Note that this options could only do anything if mod_wsgi-express was started as root.

When using mod_wsgi daemon mode, when the Apache child worker process is proxying the response it simply copies the response from the socket and writes it back through the output filter chain. If the HTTP client is slow and isn't reading the response quick enough, then technically this might mean that data gets buffered up in the Apache child worker processes and the proxying code isn't detecting when it is being buffered and forcing a flush when a limit is reached. Thus the per thread memory pool used by Apache grows and not sure if Apache internal applies a limit and forces thing to block until HTTP client has read more. If MaxMemFree isn't set or is large, then that memory will also be retained just by that thread and so can cause unnecessary overall memory usage by the process.