Where did you get the mod_wsgi.so file? The mod_wsgi download page? Are you using PSF install of Python?
Are you using 32 bit Apache and Python? It should die if you aren't, but want to make sure. Are you using standard Apache distro configuration file, or did you replace the default Apache configuration with your own? Graham On 4 January 2012 19:21, Kyle Alan Hale <[email protected]> wrote: > Right. I ought not suppose it's mod_wsgi that has the problem; it could be > anything on the Apache side. > > However, I have whittled down my loaded modules as far as I can while still > keeping Trac loading, and the issue persists. In fact, I was able to > reproduce the issue after disabling all modules, third party or not, besides > mod_wsgi and mod_authz_host (required to set permissions on the wsgi > script). > > I also installed a fresh copy of Trac and disabled all Trac plugins I had > installed; the problem persisted. > > Some additional things that leaked through as a Content-Type header during > this round of testing: > > 'application/javascript') > (= > /chrome/common/js/jquery.js > ACCEPT > C:\Windows\system32\cmd.exe > CGI/1.1 > TRAC_ENV_INDEX_TEMPLATE > must be unicode, not str > trac-0.12.1-py2.7-win32.egg > > > It may very well all be random and not at all useful, but it is interesting > that most of it is plain text (although there are bits of binary data, as > mentioned before), and that several things seem to indicate that the data is > being leaked from something Python-related. > > So, I agree that it doesn't seem likely that code that has been in the wild > as long as 3.3 has would have a bug like this, but I can't think of anything > else third-party that I can disable. > > Also, I tried extensively to reproduce this bug with my custom WSGI app > running on the same server, and haven't been able to. That's what confuses > me the most: if Trac is sending headers correctly, why does it only seem to > be manifesting itself in Trac? > > Maybe I am logging the headers from Trac incorrectly? I don't think so, > though.. Double-check my trac.wsgi: > > import os > > def application(environ, start_response): > if not 'trac.env_parent_dir' in environ: > environ.setdefault('trac.env_path', 'c:/var/www/trac') > if 'PYTHON_EGG_CACHE' in environ: > os.environ['PYTHON_EGG_CACHE'] = environ['PYTHON_EGG_CACHE'] > elif 'trac.env_path' in environ: > os.environ['PYTHON_EGG_CACHE'] = \ > os.path.join(environ['trac.env_path'], '.egg-cache') > elif 'trac.env_parent_dir' in environ: > os.environ['PYTHON_EGG_CACHE'] = \ > os.path.join(environ['trac.env_parent_dir'], '.egg-cache') > > from trac.web.main import dispatch_request > return dispatch_request(environ, start_response) > > class LogHeaders(object): > def __init__(self, app): > self.app = app > def __call__(self, environ, start_response): > def log_response_headers(*args): > print >>environ['wsgi.errors'], 'Headers for', environ['PATH_INFO'], '-', > args[1] > return start_response(*args) > return self.app(environ, log_response_headers) > > application = LogHeaders(application) > > > On Tue, Jan 3, 2012 at 11:14 PM, Graham Dumpleton > <[email protected]> wrote: >> >> 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. >> > > -- > 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.
