On Wed, Oct 15, 2008 at 7:09 AM, Diez B. Roggisch <[EMAIL PROTECTED]> wrote: > Hi Graham, > > >> > I'm running apache2,mod_wsgi2.0, python2.5. >> >> Why aren't you using latest mod_wsgi 2.3? > > Because I've set up the machine a few months ago and wasn't aware that there > is a newer version. I now upgraded. > >> > THis is the startup message: >> > >> > http://paste.turbogears.org/paste/9664 >> >> Are you still using mod_python? If not, disable it out of Apache as it >> can cause problems for mod_wsgi. > > I now disabled it. > >> Did you completely 'stop' and then 'start' Apache after making any >> recent changes, or at least touch the WSGI script file so daemon >> processes would be reloaded. > > Yes, complete restarts. > >> > The vhost-conf: >> > >> > http://paste.turbogears.org/paste/9666 >> >> Why don't you have a ServerName directive inside VirtualHost? If only >> serving one site and using ServerName from main configuration context, >> you probably don't need the VirtualHost container then. > > Because I just took what the ubuntu system was coming with, and don't know > much about apache configuration. Do you think it might affect the problem? > >> > The boostrap-wsgi-script: >> > >> > http://paste.turbogears.org/paste/9667 >> > >> > If there is *anything* enlightening to say about this, I'm more than glad >> > to hear it. >> > >> > I had the high hopes that such kind of behavior that I've seen PHP >> > exhibit would be something from a better forgotten dark past... >> >> Can you make it clear whether the 404 is generated by Apache or by >> TurboGears? > > After putting a logging-middleware in front of my application, it appears that > the python/TG-code is responsible, not apache. See below for more remarks. > >> Post the lines from the Apache access log which show the 404 errors >> for the request. Are the URLs there what you expect to see? >> >> For more in depth debugging of request and response at WSGI level, use >> second recipe in: >> >> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_ >>and_Response >> >> to capture the complete request and response. Look at them to see if >> they are what you expect. > > Thanks, I did that. After doing the update, things changed *slightly*: the > problem remains that loading a page itself works, yet *some* of it's referred > resources (mostly javascript, sometimes images) produce a 404. > > However, the behavior that putting the url in question (e.g. > http://localhost/collaborate/toscawidgets/resources/ableton.collaborate.frontend/public/javascript/jquery/cluetip/jquery.cluetip.js > ) into a tab, and pressing F5 frequently would show the intermittent 404, or > sometimes the resource, seems to be gone.
Try changing the settings in a wsgi to a deamon mode with 10 threads and 3 processes(or what ever number you need it to be) and then test your 404 again. This should fix your problem. Lucas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
