Posted by ansorg on November 24, 2008 at 4:28pm
Jump to:
| Project: | Bitcache |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Arto |
| Status: | closed (fixed) |
Issue Summary
hi,
I try to use fileframework/bitcache as a replacement for the image module. I notice that images served through the fileframework do not cached in the browser, probably because the response headers for such images containstore, no-cache, must-revalidate, post-check=0, pre-check=0, max-age=1209600
Can this be changed so that stuf from fileframework adheres to the caching settings that are defined in the "Performance" setting?
thanks
Comments
#1
Maybe a bitcache could adjust headers so that content pulled from the bitcache would get cached in the browser by default? The content is referenced by it's hash so it's not likely that it will change or expire :).
#2
Those headers are not set by Bitcache, but rather by Drupal's core code. In release 6.x-1.0-alpha3 I've overridden the
Cache-Control,ExpiresandLast-Modifiedheaders set by Drupal; the relevant file isbitcache.server.inc(around line 126, in this release) and the relevant bits of the HTTP spec are:In this latest release, the Bitcache module outputs a
Cache-Controlheader of "private, no-transform" and anExpiresheader per 14.21 of the spec: "To mark a response as 'never expires,' an origin server sends an Expires date approximately one year from the time the response is sent."This can still be much improved upon, especially by implementing full support for conditional
ETagrequests (the SHA-1 checksums of bitstreams conveniently serve as strong entity tags), but it's already a far sight better than the previous headers that were preventing caching altogether.Suggestions and patches for further improvements would be most welcome.
#3
Automatically closed -- issue fixed for two weeks with no activity.