Edgewall Software
Modify

Opened 19 years ago

Closed 18 years ago

Last modified 12 years ago

#2038 closed defect (duplicate)

CSS intermitently not applied

Reported by: anonymous Owned by: Christopher Lenz
Priority: normal Milestone:
Component: general Version: 0.9.3
Severity: normal Keywords:
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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.

Attachments (4)

correct.gif (39.7 KB ) - added by anonymous 19 years ago.
Timeline in firefox when correctly rendered
broken.gif (23.9 KB ) - added by anonymous 19 years ago.
Timeline in firefox when css is not rendered
OK_Trac_Romeo.txt (6.9 KB ) - added by Romeo 18 years ago.
False_Trac_Romeo.txt (4.7 KB ) - added by Romeo 18 years ago.

Download all attachments as: .zip

Change History (32)

comment:1 by Christopher Lenz, 19 years ago

Owner: changed from Jonas Borgström to Christopher Lenz
Status: newassigned

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

by anonymous, 19 years ago

Attachment: correct.gif added

Timeline in firefox when correctly rendered

by anonymous, 19 years ago

Attachment: broken.gif added

Timeline in firefox when css is not rendered

comment:2 by anonymous, 19 years ago

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

Thanks!

comment:3 by Matthew Good, 19 years ago

Resolution: worksforme
Status: assignedclosed

comment:4 by enrico.straube@…, 18 years ago

Resolution: worksforme
Status: closedreopened

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.

comment:5 by Christopher Lenz, 18 years ago

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.

comment:6 by anonymous, 18 years ago

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.

comment:7 by Romeo, 18 years ago

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.

comment:8 by anonymous, 18 years ago

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.

comment:9 by Christopher Lenz, 18 years ago

(previous comment by me)

comment:10 by Romeo, 18 years ago

Hello,

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

Thanks Romeo

by Romeo, 18 years ago

Attachment: OK_Trac_Romeo.txt added

by Romeo, 18 years ago

Attachment: False_Trac_Romeo.txt added

comment:11 by Christopher Lenz, 18 years ago

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.

comment:12 by Romeo, 18 years ago

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

comment:13 by anonymous, 18 years ago

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

comment:14 by Christopher Lenz, 18 years ago

Milestone: 0.9
Resolution: worksforme
Status: reopenedclosed
Version: devel0.9b2

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)

comment:15 by anonymous, 18 years ago

Resolution: worksforme
Status: closedreopened
Version: 0.9b20.9

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.

comment:16 by anonymous, 18 years ago

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.

comment:17 by Matthew Good, 18 years ago

Resolution: worksforme
Status: reopenedclosed

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.

comment:18 by anonymous, 18 years ago

Resolution: worksforme
Status: closedreopened

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.

comment:19 by Christopher Lenz, 18 years ago

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.

comment:20 by anonymous, 18 years ago

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?

comment:21 by anonymous, 18 years ago

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!

comment:22 by anonymous, 18 years ago

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…

comment:23 by markus, 18 years ago

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.

comment:24 by Christian Boos, 18 years ago

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

comment:25 by MicahElliott, 18 years ago

Version: 0.90.9.4

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.

comment:26 by Matthew Good, 18 years ago

Milestone: 0.9.4
Resolution: duplicate
Status: reopenedclosed
Version: 0.9.40.9.3

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

comment:27 by markus, 18 years ago

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.

comment:28 by Christian Boos, 12 years ago

Milestone: 0.9.4

(clearing report:35)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christopher Lenz.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christopher Lenz to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.