Re: [RFC] gitweb wishlist and TODO list (part 1)

[Jakub Narebski <jnareb@gmail.com>]

Robert Fitzsimons wrote:
>> * Cache validation and infinite cache for unchanging pages
>> 
>>   By itself cache validation would not bring much performance boost (for
>>   gitweb installations with large traffic), but with the reverse proxy,
>>   aka. caching engine, aka. HTTP accelerator in front of server this could
>>   help a lot.

BTW in mod_perl cache validation is as simple as using meets_condition()
method on request object after we send at least one of validator
headers (Last-Modified:, ETag:)... but this would mean that cache
validation would be available only when under mod_perl...

> There is no need for extra servers to provide server side caching.
> Apache2 includes suitable modules (mod_cache) which can be configured to
> cache in memory or disk the pages generated by gitweb.
[...]
> mod_cache will only cache pages with a query string in the url if they
> have an expires header.  So we can put a temporary hack in using
> mod_expires until gitweb sets an appropriate value.

>From the discussion in the 
  "Re: kernel.org mirroring (Re: [GIT PULL] MMC update)"
  http://thread.gmane.org/gmane.comp.version-control.git/33604
thread Apache mod_cache doesn't bring much. Perhaps because of the above...
although adding artificial expires header seems a bit like a hack.

> Also the content type would need to be change to just return text/html
> or MSIE will do the wrong think if it's given a application/xhtml+xml
> page.

>From gitweb.perl:

  # require explicit support from the UA if we are to send the page as
  # 'application/xhtml+xml', otherwise send it as plain old 'text/html'.
  # we have to do this because MSIE sometimes globs '*/*', pretending to
  # support xhtml+xml but choking when it gets what it asked for.

This was added by Alp Toker <alp@atoker.com> in f6801d669ee11:
  "gitweb: Send XHTML as 'application/xhtml+xml' where possible"

-- 
Jakub Narebski
Poland