The documentation should mention that Bugzilla requires the mod_expires and mod_headers Apache modules to be active. If one of them isn't, it's non-trivial to hunt down why Bugzilla doesn't work. I'm told the modules are active by default if a current Apache is being installed. It may well be, though, that you need to install Bugzilla on an existing Apache. This may be old enough not to have them, or not have them active (by default or by admin decision). Most importantly, it's crucial to know all requirements beforehand, in particular if you're planning to install Bugzilla on some hosted Apache.

So, I started to write the documentation for this, and I realized a few things: 1) With our current system, everybody using a non-Apache webserver is going to have terrible performance on every page. 2) It's very difficult to explain to people how to check if the right modules are installed, and then install them. So instead, I'm going to make mod_headers and mod_expires optional. If they're not installed, we won't append the mtime to each file with a "?"--people will just retain the old behavior of clients caching forever.

You know what? It'd be helpful to find out whether I've got the right configuration at all, whether I've got some intermediate-but-basically-working setup or something impossible to work with.

Yeah, I'm going to make checksetup.pl attempt to tell you what's installed, although it won't be able to do it on every system.

Okay, this patch does several things: 1) Refactors Install stuff to have a "_checking_for" subroutine that prints out the "Checking for" message. 2) Makes checksetup.pl check for the existence of apache modules. On many machines, this will only work if you're root, but we print out a fair bit of info about that fact. 3) Makes the .htaccess only set the cache headers if the modules are installed and available. 4) Makes Bugzilla::Template only put a "?" after CSS and JS URLs if Apache will be able to properly set the cache-control headers (because otherwise clients would do a request for every single CSS file on every page load, which is pretty slow).

This is the right patch; the previous one was an older version that wasn't working properly.

Comment on attachment 470355 [details] [diff] [review] v2 Actually, glob reviewed the original patch, he should probably do this one too.

Comment on attachment 470355 [details] [diff] [review] v2 most of this looks excellent :) i'm not sure about the apachectl probing however; after random testing.. debian: need to run apache2ctl not apachectl gentoo: need to run "apache2ctl modules" instead of "apachectl -M" windows: doesn't include apachectl.exe, need to call "httpd.exe -M" from the apache install directory. i'm not sure what our minimum apache version is, but older versions don't support -M r- due to missing apache2ctl

Could try calling apache/apache2/httpd directly with '-t -D DUMP_MODULES'... that might work better than -M.

maybe we should be parsing the output of "httpd -L" instead? that works on apache 1.3 and gentoo (although the apache binary on gentoo is "apache2" not "httpd").

(In reply to comment #9) > maybe we should be parsing the output of "httpd -L" instead? It doesn't contain the information that we need. (That is, I think it only shows compiled-in directives. But whatever it's doing, it doesn't contain the directive information we need.)

Okay, I've fixed the way that we search for apachectl: 1) We now search for all of apachectl, httpd, apache, and apache2 in the path. I'm not using apache2ctl because it has different syntax on Debian and Gentoo, but I'm pretty sure the "httpd" or "apache2" binary on those systems will have identical syntax to all other platforms. 2) We first search for all of those in the normal path, and then in a few extra places. 3) I've made bin_loc work on Windows, so if httpd.exe is in the PATH, this will even work on Windows. 4) I use "-t -D DUMP_MODULES" instead of "-M", in the hope of getting broader compatibility.

You should also update http://www.bugzilla.org/docs/tip/en/html/configuration.html#http to mention mod_expires and mod_headers. On Windows, when I upgraded my local installation, I got a software error because I didn't have these two lines enabled in httpd.conf: LoadModule expires_module modules/mod_expires.so LoadModule headers_module modules/mod_headers.so And despite I fixed AllowOverride, I still couldn't access Bugzilla.

Comment on attachment 470594 [details] [diff] [review] v3 r=glob

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/ modified .htaccess modified Bugzilla/DB.pm modified Bugzilla/Template.pm modified Bugzilla/Install/Requirements.pm modified Bugzilla/Install/Util.pm modified template/en/default/setup/strings.txt.pl Committed revision 7475. Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/4.0/ modified .htaccess modified Bugzilla/DB.pm modified Bugzilla/Template.pm modified Bugzilla/Install/Requirements.pm modified Bugzilla/Install/Util.pm modified template/en/default/setup/strings.txt.pl Committed revision 7405.

The patch required some minor fixes to apply properly on the 4.0 branch. Here's what I checked in on the 4.0 branch.