CSS intermitently not applied

[anonymous]

When loading various trac pages, often (but not always) stylesheets are not applied to mainnav, altlinks etc.

Seems to happen most frequently in timeline, but I've seen it in other places too.

Not sure when this was first introduced. Currently tunning [2211] (CGI mode, apache, linux), freshly upgraded from [2119] which didn't exhibit this problem.

Tested with firefox & opera. Behaviour in firefox seems non-deterministic but in opera every second reload of the timeline page has this problem.

Server logs show normal requests for css (both static and trac.cgi/chrome) and responses (304s).

Also created a new vanilla trac environment and the problem appears there too.

[Christopher Lenz]

Have you set up static resource mapping as documented on the Trac CGI wiki page?

[anonymous]

Timeline in firefox when correctly rendered

[anonymous]

Timeline in firefox when css is not rendered

[anonymous]

No, but I just did and it seems to have done the trick.

Thanks!

[enrico.straube@…]

I have always the same problem. I did the static resource mapping but the failure still present. After every reload the styles are gone or some styles are gone.

I have 8 trac project in different folders. There are nonssl and ssl access to the projects. I use virtual hosts on current apache2 an SuSE 9.1 and Trac 0.9-b2.

Please help.

[Christopher Lenz]

This does work, so I have to assume its a configuration issue on your part.

If you think this is really a problem in Trac, then please invest some time and provide a more detailed description of the problem. Check what URLs Trac is using for the CSS, check the Apache access and error logs, and also the Trac log; use ​LiveHTTPHeaders, ieHTTPHeaders or Ethereal to get a trace of the HTTP traffic.

Thanks.

[anonymous]

The same error occurs in my configuration when I use Firefox over SSL :

• Win2k3 Server
• Apache2 with nonssl (lan) and ssl (wan)
• Trac 0.9b2 with ModPython

The CSS style is always applied when I use Internet Explorer (with and without SSL). So, I think is not a problem with trac.

[Romeo]

I have the same Problem, but the other way. The CSS style is always applied when I use Firefox 1.0.6 (with and without SSL) but it isn’t when I use IE 6.0.2900.2180 (with and without SSL). I tried all helps out of this ticket, but no way.

[anonymous]

Folks, please provide more information. Install Ethereal (or ieHTTPHeaders or LiveHTTPHeaders) and attach a trace of the HTTP traffic going on between browser and server. Otherwise it'll not be possible to figure out the problem here. Thanks.

[Christopher Lenz]

(previous comment by me)

[Romeo]

Hello,

here is my log with ieHTTPHeaders (Attachments). The Problem is still present.

Thanks Romeo

[Christopher Lenz]

Romeo, I think these traces show that your static resources are handled by the Trac CGI script. Please make sure to carefully read the mapping static resources section, and make absolutely sure that the rules actually do what they are supposed to do… for example by commenting out the CGI mapping temporarily. The static resources should still be served even when the CGI isn't running.

[Romeo]

Hello cmlenz,

no, I tried all your helps, but it dose not work. Ther is definitely another problem. The problem occurs exactly every second times, when I refresh the site. Romeo

[anonymous]

This is not only a problem with trac, as you will receive similar results on i.e. IMP from Horde.

[Christopher Lenz]

I'm sorry, but if there are errors in downloading the static resources from IE (on every second request or otherwise), those requests are quite certainly handled by the Trac CGI and not by the server itself. This means that your configuration for static resource mapping is not working. Please double check it.

If that still doesn't work, the final release of 0.9 will (again) feature a htdocs_location config option that you can use to instruct Trac to use some other URL for loading the static resources.

In trac.ini:

[trac]
...
htdocs_location /trac-htdocs

In the Apache config:

Alias /trac-htdocs /usr/share/trac/htdocs

(Replace the paths/URLs as appropriate for your deployment)

[anonymous]

Static resource mapping takes care of "core" trac, but not any plugin chrome (I'm currently seeing this issue with webadmin & generallinksyntaxplugin).

If trac.cgi misbehaves when serving chrome it should be fixed IMHO.

[anonymous]

Moreover, static resource mapping requires to create aliases for each virtual host, and each project on the virtual host (because of e.g. project banners and other static content in the projectname/htdocs directory).

The suggestion to use static resource mapping is a pathetic excuse for not fixing a bug that causes major pain and inconvenience for at least a subset of users.

[Matthew Good]

I don't see why you would need to put the aliases in each virtual host. If you feel the need to map the projects' htdocs resources statically this can be done with an AliasMatch rule instead of an Alias per-project.

Unfortunately while CGI is the most widely supported way of running web applications it has the inherent problem of requiring a new process for each request, so any startup overhead is repeated on every request. The initialization of Trac's plugin system has increased this startup overhead and is one of the reasons use of CGI is discouraged in favor of FastCGI, mod_python, or tracd. Adding WSGI support will also increase the number of alternatives to CGI for running Trac.

We can't fix the inherent problems in CGI (besides offering alternatives) and it's not reasonable to remove the plugin system just so that Trac can handle the htdocs requests smoothly as a CGI. So basically the remaining options are: static resource mapping, or don't use CGI.

[anonymous]

This strikes me as a completely bogus explanation. If Trac is able to startup, query the database, push out some wiki page, all of this in a fraction of a second, why on earth should it then timeout after 30 seconds while trying to send some simple and tiny static content?

This has clearly nothing to do with "startup overhead" or "inherent problems in CGI" - it's a bug in the CGI script.

[Christopher Lenz]

Are you talking about an individual request to a single static resource, or a request to a HTML page that embeds 10-15 of such resources?

In the former case, yeah, that would be a bug in Trac. In the latter case, I believe you're simply hitting the limit of how many processes can be launched how quickly, and how well the web server can juggle them.

[anonymous]

Both. If I just request the banner logo (like: ​http://example.com/project/chrome/site/logo.png), the error happens the same way as if I request the whole page. E.g. reproducibly for every second reload, the request times out and Mozilla says: "The image … cannot be displayed because it contains errors".

I can reproduce this with Mozilla 1.7.12 and Firefox 1.0.7, and others apparently have the same problem with IE (judging from the comments). I tried to switch off keep-alive in the Mozilla preferences, but this just eliminates the wait for the timeout (i.e. the request fails instantaneously).

And for some reason, wget will always faithfully fetch the banner logo without any problem (but of course with wget each fetch is a different wget process).To my unaided eye, this looks like Trac is not handling correctly something that every standard browser does when reloading a resource.

Perhaps the 'If-Modified-Since' header in the request is not handled correctly?

[anonymous]

Using Trac 0.9.2 with CGI on Apache and Windows, I found that I definitely had to add

[trac]
...
htdocs_location /trac

to trac.ini to make the static resource mapping work correctly (fast loads!). From reading the docs, it seemed like it was already a default that didn't need to be specified although the .ini didn't have it as an entry (?!). Thanks!

[anonymous]

It's certainly possible to workaround the problem somehow, but these ugly workarounds would not be neccessary if trac would properly handle the browsers effort to revalidate the cache on page reload (which appears to be the basic problem, judging from the symptoms).

I suppose trac pushes out dynamic content with no-cache headers, thus only the static content breaks, as the browser will reload the dynamic content rather than trying to validate the cache. For the static content, the browser probably marks the cache as invalid after the timeout, thus every second reload succeeds…

[markus]

For the static content, the browser probably marks the cache as invalid after the timeout, thus every second reload succeeds

This would be exactly the same problem that probably causes #2006.

[Christian Boos]

Could someone who experience the bug described here try the patch provided in the above mentioned ticket?

[MicahElliott]

This appears to be fixed in 0.9.4. I had a very vanilla CGI 0.9.2 setup. Now I've updated my Trac installation, maintained the same httpd.conf settings, and the "every other reload stall / missing static content" issue is gone.

[Matthew Good]

Yes, as previously mentioned this is a duplicate of #2006, which was fixed for 0.9.4

[markus]

Yeah, but we're still wondering if it's the flush(), the corrected date format or both that solve these reload problems.

I'd really appreciate if someone could test this since I noticed (slightly) slower load times when using the so-called flush-patch.

[Christian Boos]

(clearing report:35)