Given how long mod_wsgi 3.X has been out there and the significant number of downloads even for Windows, if this was some underlying problem in mod_wsgi my first thought would be that it is likely to have shown itself a long time ago. In other words, you are the first to ever report this specific issue for a version of mod_wsgi which has already seen substantial use.
So, at this point I am more likely to suspect it is caused by a third party module, especially with how the Apache memory management system works. Can I ask you to disable any significant Apache modules such as mod_auth_sspi, mod_dav_* and any caching modules and see if the issue goes away. If it does go away, then start adding the modules back one by one to see at what point it resurfaces. If you can give a list of all the Apache modules being loaded, that would also be of interest. Graham On 4 January 2012 13:48, kylealanhale <[email protected]> wrote: > I am setting up Trac on a new production machine and from time to time > get requests returned with strange Content-Type headers. For example, > when requesting a CSS file (/support/chrome/site/style.css), I get the > following response: > > HTTP/1.1 200 Ok > Date: Wed, 04 Jan 2012 01:31:36 GMT > Server: Apache/2.2.21 (Win32) DAV/2 mod_auth_sspi/1.0.4 mod_wsgi/ > 3.3 Python/2.7.2 SVN/1.7.2 > Content-Length: 6677 > Last-Modified: Wed, 28 Dec 2011 21:41:45 GMT > Keep-Alive: timeout=5, max=97 > Connection: Keep-Alive > Content-Type: softspace > > body { > [the response body follows...] > > Note the Content-Type header. It came through as various values: > "softspace", "read", "application", "__mtime__", "/support", "HTTP/ > 1.1", various bits of binary data, and others. Obviously somehow data > is getting crossed with this response, from another thread or > something. > > I first saw the behavior from Chrome, and so confirmed this response > with other browsers, through Fiddler, and on multiple machines. It is > happening with various files, and types of files, although they all > seem to be static content (images, stylesheets, scripts, etc.) In all > instances the response body and other headers were intact; only the > Content-Type header appears to be affected. > > At first I assumed that something was weird with Trac's WSGI handling, > and so I inserted some middleware into the stack for logging. For the > above request, I got: > > [Tue Jan 03 18:31:36 2012] [error] [client 10.61.210.56] Headers > for /chrome/site/style.css - [('Content-Type', 'text/css'), ('Content- > Length', '6677'), ('Last-Modified', 'Wed, 28 Dec 2011 21:41:45 GMT')], > referer: http://dpsystems01/support/ > > So, Trac is sending the correct headers via start_response. This was > true with every request that had this problem. In other words, it > seems that the scrambling is happening in mod_wsgi's internals. > > I have another (custom) WSGI application running on the same server... > they are both set to use "WSGIApplicationGroup %{GLOBAL}" to prevent > problems with importing the svn module. However, I confirmed that the > error still occurs without the other application loaded, so it doesn't > seem to be causing the interference. > > I feel like I may be missing something obvious, but can't figure out > what it is. Any suggestions on where I can look next? > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
