On 12/10/06, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
Jeff Garzik wrote: > Jakub Narebski wrote: >> In addition to setting either Expires: header or Cache-Control: max-age >> gitweb should also set Last-Modified: and ETag headers, and also >> probably respond to If-Modified-Since: and If-None-Match: requests. >> >> Would be worth implementing this? > > IMO yes, since most major browsers, caches, and spiders support these > headers. Sending Last-Modified: should be easy; sending ETag needs some consensus on the contents: mainly about validation. Responding to If-Modified-Since: and If-None-Match: should cut at least _some_ of the page generating time. If ETag can be calculated on URL alone, then we can cut If-None-Match: just at beginning of script.
Indeed. Let me add myself to the pileup agreeing that a combination of setting Last-Modified and checking for If-Modified-Since for ref-centric pages (log, shortlog, RSS, and summary) is the smartest scheme. I got locked into thinking ETags.
> That would be a good start, and suffice for many cases. If the CGI can > simply stat(2) files rather than executing git-* programs, that would > increase efficiency quite a bit. As I said, I'm not talking (at least now) about saving generated HTML output. This I think is better solved in caching engine like Squid can be. Although even here some git specific can be of help: we can invalidate cache on push, and we know that some results doesn't ever change (well, with exception of changing output of gitweb).
Indeed - gitweb should not be saving HTML around bit giving the best possible hints to squid and friends. And improving our ability to short-cut and send a 304 - Not Modified.
What can be _easily_ done:
Great plan. :-) cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html