Loggerhead setting 'Cache-Control' header for static fields

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

>> Setting the cache_max_age to something adds a header to the response like:
>>
>>   Expires: Fri, 30 Apr 2010 20:28:21 GMT
>>   Cache-Control: public, max-age=3600
>>
>> Is this necessary to tell stuff like Squid it is ok to cache? I know it
>> does set "ETag", and sending "If-None-Match: <etag>" does give a 304 Not
>> Modified result.
>>
>> However, I guess I don't really know the squid defaults. It would seem
>> generally useful for us, since stuff in 'static' rarely changes. I don't
>> know how much overhead this would save us. In testing locally, I've seen
>> quite a few cases where the main page is displayed, but then Firefox
>> seems to take several more seconds 'spinning' while it loads stuff that
>> seems to be under /static, etc.
>>
>> John
>> =:->
> 
> No matter what Squid thinks, Expires/Cache-Control headers are the right
> way to go. It's just nobody has gotten around to it, especially since
> it's trickier for the dynamic pages.
> 
> bb:approve from me, although I'd be happy with something even higher,
> like 43200 or 86400 seconds.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4

has this to say:

 If none of Expires, Cache-Control: max-age, or Cache-Control: s- maxage
(see section 14.9.3) appears in the response, and the response does not
include other restrictions on caching, the cache MAY compute a freshness
lifetime using a heuristic. The cache MUST attach Warning 113 to any
response whose age is more than 24 hours if such warning has not already
been added.

Also, if the response does have a Last-Modified time, the heuristic
expiration value SHOULD be no more than some fraction of the interval
since that time. A typical setting of this fraction might be 10%.

The calculation to determine if a response has expired is quite simple:

      response_is_fresh = (freshness_lifetime > current_age)


Which says that by default caching should be less than 1 day unless it
wants to give warnings.

Since the '/static/' content is pretty darn static, I think we could set
it up significantly higher. :)

If we really wanted to be cautious, it seems like we could set it to
86400 (1-day) and then the day before rollout, restart the server with
cache = 0, so that the next day when rollout happens, none of the
intermediate caches should think it is ok to use the cached value. I'm
not sure that it is really necessary, though.

For now, I think 0.5 days is a reasonable value, but certainly I'd like
to hear from Michael Hudson or Robert about what they think. Of course,
they're both gone for the weekend :).

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvbP3AACgkQJdeBCYSNAAOAzACgnj7MQ3BAZCeS7QIKnZPW6ZRu
rCIAniliT3BoqbKghMzu5SZILZ945hKS
=pgEV
-----END PGP SIGNATURE-----