Last Comment Bug 167808 - bugzilla should make use of HTTP/1.1 cache control headers
: bugzilla should make use of HTTP/1.1 cache control headers
Status: NEW
[wanted-bmo]
:
Product: Bugzilla
Classification: Server Software
Component: Bugzilla-General (show other bugs)
: unspecified
: All All
: -- enhancement with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: default-qa
:
Mentors:
http://bugzilla.mozilla.org/show_bug....
: 233350 298227 365070 696865 (view as bug list)
Depends on: 156865 147833 594962
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-10 14:26 PDT by Darin Fisher
Modified: 2011-10-24 13:49 PDT (History)
19 users (show)
mkanat: blocking3.0-
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Darin Fisher 2002-09-10 14:26:10 PDT
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 :-)
Comment 1 Bradley Baetz (:bbaetz) 2002-09-10 16:42:32 PDT
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.
Comment 2 Myk Melez [:myk] [@mykmelez] 2002-09-10 17:47:15 PDT
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).
Comment 3 Bradley Baetz (:bbaetz) 2002-09-10 19:37:02 PDT
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.
Comment 4 David Nesting 2002-12-08 19:20:15 PST
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.
Comment 5 Bradley Baetz (:bbaetz) 2002-12-08 23:16:31 PST
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
Comment 6 David Nesting 2002-12-14 12:59:26 PST
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.
Comment 7 Bart van Bragt 2003-03-11 13:44:29 PST
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?
Comment 8 Shane H. W. Travis 2005-02-18 22:44:36 PST
RFE, not a bug. Reassigning Severity appropriately.
Comment 9 Dave Miller [:justdave] (justdave@bugzilla.org) 2005-03-24 00:23:02 PST
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.
Comment 10 Marc Schumann [:Wurblzap] 2005-06-21 01:35:10 PDT
See also bug 233350.
Comment 11 Zach Lipton [:zach] 2005-06-24 17:10:24 PDT
*** Bug 233350 has been marked as a duplicate of this bug. ***
Comment 12 Olav Vitters 2007-01-09 12:07:36 PST
*** Bug 365070 has been marked as a duplicate of this bug. ***
Comment 13 Frédéric Buclin 2007-01-09 12:28:23 PST
Keeping this bug in our radar till a clear decision is made about it.
Comment 14 Max Kanat-Alexander 2007-02-04 05:28:32 PST
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.
Comment 15 Dave Miller [:justdave] (justdave@bugzilla.org) 2007-10-02 13:06:29 PDT
*** Bug 298227 has been marked as a duplicate of this bug. ***
Comment 16 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-04-18 10:45:07 PDT
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.
Comment 17 Teemu Mannermaa (:wicked) 2011-10-24 13:49:20 PDT
*** Bug 696865 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.