Standard sources on everything: mod_wsgi: http://code.google.com/p/modwsgi/downloads/detail?name=mod_wsgi-win32-ap22py27-3.3.so&can=2&q= Python: http://www.python.org/getit/releases/2.7.2/ (32-bit) Apache: http://httpd.apache.org/download.cgi#apache22 (32-bit)
I used the standard httpd.conf and tweaked it for my setup. While testing this issue, I have disabled everything non-standard except for the most bare-bones of mod_wsgi setups to load Trac. On Jan 4, 1:28 am, Graham Dumpleton <[email protected]> wrote: > 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.
