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:
this will cause the browser to send
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. ***
*** Bug 365070 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.
*** Bug 298227 has been marked as a duplicate of this bug. ***
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.
*** Bug 696865 has been marked as a duplicate of this bug. ***