bugzilla should make use of HTTP/1.1 cache control headers. currently, browsers must entirely reload bug pages on each link click to the bug. this surely burdens bugzilla if not delays the user unnecessarily whenever the user has already downloaded the page. if bugzilla made use of HTTP/1.1 cache control headers, it could instruct the browser to validate its cached copy on each and every link click. this would allow bugzilla the opportunity to tell the browser that the page hasn't changed (304 Not Modified), which is a very small response to send back. myk told me that we have to worry about the fact that a page may appear differently depending on the user, and so we have to be somewhat careful. so, i'd propose having bugzilla send the following response headers: ETag: <etag-value> Cache-control: must-revalidate this will cause the browser to send If-None-Match: <etag-value> whenever it finds a copy of the page already in its cache. bugzilla can respond 304 Not Modified if <etag-value> indicates that the user already has the right version of the document in their cache. otherwise, bugzilla can stream the response as usual (200 OK). this should really help bugzilla performance :-)

Actually, this probably souldn't help bz performace, since 90% of the time is startup time :) Even then, bz would still have to generate the new ETag for acpahe to match against, which would mean knowing the result anyway. You may save on bandwidth though, I guess.

I don't think we'd need to know the result to generate the ETag. We just need to know when the bug was last modified and who the user is (if they are logged in), and when their profile was last modified (since groupset and personal query changes affect what the user sees).

well, delta_ts doesn't mention everything (arguably, thats another bug, but...) Besides, by the time we check permissions and get delta_ts out, 99% of the work has been done. However, more importantly, we (As in bugzilla) can't know that apahce was asked for a conditional response, so we have to do it anyway... Maybe we can once we use mod_perl; I'd have to check.

I believe Apache will automatically issue a 304 response if a CGI script provides a "Last-Modified" header that Apache recognizes as being earlier than the browser-provided "If-Modified-Since" request header. So with a minimum amount of work (figuring this date out), you can at least save on bandwidth and user time, even if your CGI scripts still want to go through the unnecessary work of generating the content anyway.

Right, but we have to define what 'last-modified' means :) Do we care if teh template changed in the mean time? What about a different user being logged in? etc, etc

It's perfectly acceptable to consider a page "modified" only when the true "meat" of the page changes. In other words, if you change a template that doesn't really change the information conveyed by the page, it's perfectly normal to pretend that the page didn't really change and continue to issue a Last-Modified date in the past. HTTP calls this "weak validation" (See RFC2616, 13.3.3) and is generally used only with the Last-Modified method of caching. Maybe you can provide a date stamp somewhere Just In Case someone does make a template change that really needs to invalidate cached pages depending on it, but I don't think that would be generally needed. When the time comes to go all out with ETag-based ("strong validation"), you can re-visit that topic if someone feels it should be revisited.

So the only way to deal with this is using Last-Modified ? BTW please remember that this is not just about Mozilla. I'm currently trying to speed up my own site (mostly a phpBB forum) and in phpBB you can issue a 304 way before you have done 90% of the work. BTW what about pre-check and post-check? Or are those MS specific? Couldn't find anything in bugzilla?

RFE, not a bug. Reassigning Severity appropriately.

Reassigning bugs that I'm not actively working on to the default component owner in order to try to make some sanity out of my personal buglist. This doesn't mean the bug isn't being dealt with, just that I'm not the one doing it. If you are dealing with this bug, please assign it to yourself.

See also bug 233350.

*** Bug 233350 has been marked as a duplicate of this bug. ***

Keeping this bug in our radar till a clear decision is made about it.

This isn't a blocker--we've lived with it for a while, and it's bad but not something that prevents release. Instead, we need to allow people to submit a bug with an invalid token. I'm pretty sure there's a bug filed for that already, and if somebody wants to find that and request that it block, I'd be willing to consider it.

bugzilla.mozilla.org now sits behind a caching reverse-proxy server at Mozilla (and has for a few months now). Caching, of course, is completely disabled at the moment. If Bugzilla issued proper cache-control headers, we would be able to selectively enable some of the caching features. A Vary: header would be useful as well to help the proxy decide when to cache.