Loggerhead setting 'Cache-Control' header for static fields

[Michael Hudson]

On 01/05/10 13:47, Robert Collins wrote:
> That seems fine; btw there is a much better http reference these days:
> http://tools.ietf.org/wg/httpbis/
>
> Many unclear/ambiguous regions of the standard have been clarified and fixed.
>
> The squid in the DC is acting as a front-end server: its allowed to
> pretend to be the backend; so we can have loggerhead offer year-long
> caching to squid, and tell squid to only offer 1 day or whatever to
> clients. Broadly though:
>   -- if the content will change /meaning/ cache with care
>   -- if the content won't change at all - cache aggressively.
>
> Using new URL's is a great way to move things into the won't-change at
> all category.

FWIW, I don't think there is a squid between the internet and loggerhead 
at all in the data centre currently.  The flow goes like this

  (internet)->Apache->Loggerhead

Apache use mod_rewrite to serve Loggerhead's static images (^/static/.* 
URLs) and a prg rewrite map to decide when to serve static branch data. 
  Code-browsing requests are proxied straight to a loggerhead process 
running on another host.

Loggerhead has a mix of never-change URLs -- static resources and 
+filediff URLs based on revision ids, which would only change when 
loggerhead changes, rarely-change URLs -- e.g. revision pages for a 
given revno, which would only change in a non-append-only push and pages 
that change fairly frequently, e.g. the front /changes page that changes 
whenever new revisions arrive on the branch.

In principle, we could detect non-append-only pushes and invalidate the 
cache when we find one, say from the branch scanner, allowing us to 
cache most pages pretty aggressively without losing too much 
correctness, but I don't know if that would be worth it.

Cheers,
mwh