Imagecache appears to give Images a long past expires header: 11/19/1978.
Because of this Browsers cannot cache the images, which impacts performance massively. In Gallery-like Views like this; page loads takes quite some time. If I have even more images on one page, like here: I had to find another solution that circumvents Imagecache. The page was loading extremely slow.

What makes it worse that the long load time is repeated every time a user reloads the page. Only firefox seemingly caches the image, until page load is completed, it takes also Firefox quite long. Using Yslow one sees the many Http Requests that are slowing down the page load.

Is this a bug or done by will? As one can wonderfully use views for Image Galleries and the kind of Navigation with Images I use, this stops Imagecache from being usable for that, which is a pity.

Maybe there is a way I can tweak this, even If you want to keep it for the normal release?

#64 image_303419.patch933 bytesdrewish
#59 image_303419.patch1.5 KBdrewish
Passed: 12400 passes, 0 fails, 0 exceptions View
#56 image_303419.patch1.38 KBdrewish
Passed: 12247 passes, 0 fails, 0 exceptions View
#53 image_303419.patch1.08 KBdrewish
Passed: 12418 passes, 0 fails, 0 exceptions View
#51 image_303419.patch1.09 KBdrewish
Passed: 12422 passes, 0 fails, 0 exceptions View
#46 imagecache_303419.patch781 bytesdrewish
Failed: Failed to apply patch. View
#45 imagecache_expires.patch534 bytesbrunodbo
Failed: Failed to apply patch. View


eigentor’s picture

Status: Active » Closed (fixed)

It appears to be a bug in one installation only. In another the 2.0 Version works as expected and Images get a correct expires header that lasts for two weeks.

Oghnia’s picture

I have the same problem,, I installed the latest version of imagecache and everytime I load my page it seems like imagecache is recreating all the images - unlike the older version everything popped up right away?

any solutions,,

Oghnia’s picture

Status: Closed (fixed) » Active

should i create a new issue

eigentor’s picture

No, we'd rather revive this one. As I experienced, this appears to depend on different things than Image cache, maybe some unwanted interaction with other modules - Übercart? (which I also have installed in the not working version), so it would be nice to find out what causes this nasty bug. What modules do you have installed in your buggy version?

Maybe Dopry, who knows the module from the inside, could help us find a track where the stopping of the caching could start? For anyone trying to reproduce the error: install Yslow for Firefox and have a look if your images are cached correctly (the expires header should be two weeks in the future, I believe Drupal caches Images and other stuff for two weeks by default (set in .htaccess))

Oghnia’s picture

the expiry date on the images is set to
Sun, 19 Nov 1978 05:00:00 GMT

now how do i fix that ?

willdashwood’s picture

Same problem here, I'm running an Übercart store and all the product images aren't cached.

Expires:	 Sun, 19 Nov 1978 05:00:00 GMT, Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control:	store, no-cache, must-revalidate, post-check=0, pre-check=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0

It's having a big impact on the store so I'd really like to get to the bottom of it. Any idea where to start?

eigentor’s picture

This is pointing towars Übercart having to do with this. In another installation where it works, Übercart is not present. I posted an issue in the Ubercart issue queue:

@willdashwood: which Version of Ubercart do you run? I am running 1.0 rc5 version.

gmenzel’s picture

Any news on this? This really is a quite annoying problem and any support to find a solution would be very much appreciated!

eigentor’s picture

You'll have to stick to the Übercart queue. As to brian, only Imagecache 1.x was supported at the time I reported the issue. Don't know what is the actual state. But it appears to be not a problem of imagecache.

drewish’s picture

Status: Active » Fixed

sounds good to me.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

brunodbo’s picture

Status: Closed (fixed) » Active

I'm experiencing the same problem as described in the original report, without Übercart installed. Some more specifics:

- the problem occurs with both GD2 and ImageMagick
- it only seems to happen with jpg images. Eg. png images that are converted with imagecache are cached fine by the browser.
- the same problem occurs on two different sites, on two different servers

I'm running:

- Drupal 5.15
- Imagecache 5.x-2.3
- ImageAPI 5.x-1.4

drewish’s picture

Status: Active » Postponed (maintainer needs more info)

there's nothing there to go on. need more information, perhaps access to your site.

brunodbo’s picture

I'll start by disabling other contrib modules one by one to see if it's the combination of imagecache with something else that's causing this to happen.

ugerhard’s picture

I'm experiencing the same problem with Imagecache 6.x-2.0-beta5 on Drupal 6.9. Here's one of the imagecache'd images:

These are the response headers:

Date: Thu, 29 Jan 2009 14:42:06 GMT
Server: Apache/2.0.53 (Linux/SUSE) DAV/2 PHP/5.1.4 SVN/1.1.3
X-Powered-By: PHP/5.1.4
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Thu, 01 Jan 2009 11:43:04 GMT
Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Length: 19033
Etag: "eae9f9a919aebbe24264628a6a9d322a"
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/jpeg

200 OK

Here's the original:

These are the response headers:

Date: Thu, 29 Jan 2009 14:42:46 GMT
Server: Apache/2.0.53 (Linux/SUSE) DAV/2 PHP/5.1.4 SVN/1.1.3
Last-Modified: Thu, 01 Jan 2009 11:40:53 GMT
Etag: "e10540-f520-4bfebb40"
Accept-Ranges: bytes
Content-Length: 62752
Cache-Control: max-age=1209600
Expires: Thu, 12 Feb 2009 14:42:46 GMT
Content-Type: image/jpeg

200 OK

If you need more information, please let me know.

ugerhard’s picture

I did some more digging. The following headers seems to be set by Drupal core (see drupal_page_header():, which is called in _drupal_bootstrap (see since imagecache'd images are not served directly but through Drupal and file_transfer().

Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0

One would probably have to "override" these headers in _imagecache_cache_set_cache_headers() by setting them there to some sensible values for image files. Sadly, I'm no expert in http headers at all, so I don't really know what sensible headers would be...

drewish’s picture

so i'm guessing you're seeing those headers the first time the file is requested when it's generated right? are the files actually being saved to disk?

drewish’s picture

i just viewed and the headers i'm seeing are:
Cache-Control:max-age=172800, public, must-revalidate
Date:Fri, 30 Jan 2009 00:32:39 GMT
Expires:Sun, 01 Feb 2009 00:32:40 GMT
Keep-Alive:timeout=15, max=100
Last-Modified:Thu, 01 Jan 2009 11:43:04 GMT
Server:Apache/2.0.53 (Linux/SUSE) DAV/2 PHP/5.1.4 SVN/1.1.3

ugerhard’s picture

re #17: The files are written to disc, and I see these headers every time a request to the file is made. That is, I *saw* (that's re #18) before I added for testing purposes the following lines to the end of _imagecache_cache_set_cache_headers():

  $headers[] = 'Expires: ' . gmdate('D, d M Y H:i:s', time() + 172800) .' GMT';
  $headers[] = 'Cache-Control: max-age=172800, public, must-revalidate';

These add 2 days (counting from the time of the request) to the Expires and Cache-Control headers. That's why you saw these different headers in #18.

From some browsing on my site (with Firefox 3.05 BTW) it seems (because now previously loaded images appear instantaneously instead of with some delay) that the browser now really takes the images from its browser cache instead of requesting them anew each time.

abedzilla’s picture


i'm running a galleries and photography discussion site with tons of high quality images stored and displayed in my site.
And it seems this is the problem why my page load time is really slow.

dagomar’s picture

Same issue.
I havent installed Ubercart. Every time a page loads, the images are being downloaded again.

re to #19

I added those 2 lines, this ONLY had some effect in firefox. Chrome and Internet Explorer stay slow.

---- yet another edit ----

I dont have this problem with the older version of imagecache

mgtadmin’s picture

Version: 5.x-2.0 » 5.x-2.x-dev

I'm having the same problem.

I'm on Drupal 5.15 with the latest dev version of imagecache and have ubercart installed.

Imagecache is not caching images. See for an example. One thing I noticed is that clicking on a link will always force a re-load of the images, whereas clicking the browser's back/forward buttons does not force a re-load.

dagomar’s picture

I have just performed a test. Let me first say that I think this issue should have a high priority. Even though the module is usable, this issue renders it unusable for production environment. My test consists of a clean install of drupal 5.15, and the minimal amount of modules needed for imagecache (with exception of Admin menu). Here a list of all enabled extra modules:

1. Administration Menu 5.x-2.8
2. Content 5.x-1.10
3. ImageField 5.x-2.4
4. ImageAPI 5.x-1.4
5. ImageAPI GD2 5.x-1.4
6. ImageCache 5.x-2.3
7. Imagecache UI 5.x-2.3

I added 2 presets, and an imagefield to the 'page' content type. I added some pages with a picture and found the following header information:

Response Headers
Date	Mon, 16 Feb 2009 21:33:49 GMT
Server	Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.3 with Suhosin-Patch
X-Powered-By	PHP/5.2.4-2ubuntu5.3
Expires	Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified	Mon, 16 Feb 2009 21:33:51 GMT
Cache-Control	store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Length	5536
Etag	"a32ed304fc48700c04da0f1d4c8022fa"
Keep-Alive	timeout=15, max=97
Connection	Keep-Alive
Content-Type	image/jpeg

Request Headers 
User-Agent	Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/2009011913 Firefox/3.0.6
Accept	image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language	en-gb,en;q=0.5
Accept-Encoding	gzip,deflate
Accept-Charset	ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive	300
Connection	keep-alive
Cookie	SESSd3c1a38d1dbe20e4c4c5a3194ea9faa3=edd14cd47f1288291f7f8ed78cd51289; SESS404ea41198f9cfaf0f5edc9cb0b7b01f

I am very sorry to say that this goes a little over my head. I have no experience with this whatsoever. I kindly urge some better scripter to have a look at this. Thanks!

dagomar’s picture

I have just now conducted the same test with a clean install of D6, here headers seem ok, so nothing to post.

drupalina’s picture

Priority: Normal » Critical

I don't have Ubercart installed, and I've noticed that recently the site started having this exact same problem.

I'm on Drupal 5.12
ImageField 5.x-1.2-rc1 (I will soon upgrade to 5x-1.2 and/or 2.4, but that doesn't matter)
ImageAPI 1.4
ImageCache 2.3
ImageCache Profiles 1.4

My site used to be very-very fast and atracted many people from the developping world, where many people are on 56k dial-up comnnection. Now my site is practically unusable to my main target audience and I can tell that my site visits have fallen dramatically! So this is a pretty critical issue.

Here's one more interesting piece of information:
Following the YSlow instructions, in my .htacess file I've set it so that the expres heading is set to +2 years, AND my ETags are set to none. But now while my YSlow is showing eveything as normal, the images produced by ImageCache module have their expiry set in 1978 and ALSO they all now have ETags (even though the .htaccess file is telling the apache not to produce ETags ).

--- Edit update ---
I noticed from the ImageCache code that the ImageCache.module is trying to do something with the Headers and ETags. I think if that maintainers of this module would remove or modily that code, then this should fix it. (But then again, I'm not a coder)

PLEASE-please someone fix this !

costinius’s picture


Upgraded from version 5-1.3 to 5-2.3 and the site slowed down dramatically.

Despite the fact that the files are created in files/imagecache directory, it looks like with every page refresh it re-creates the images from the beginning.

No Ubercart installed.

Stephan_M’s picture

Because of this problem i reverted to the older version of imagecache 1.x, together with the fitting thickbox-module 1.x and all was fine again.

sashomi’s picture

Same problem. I have drupal 5.16 with latest imagecache 2.3 and latest Ubercart 1.7. Really don't think the problem is related somehow to Ubercart. I added these two lines from #19, if fixes expire date, but don't see any acceleration in loading images. I digged a liitle (half day :)) to see the differences with 1.7 but they are not so many, at least in this case with headers. I removed _imagecache_cache_set_cache_headers () because in 1.7 file_transfer($path, $headers) sends only "Content-Type" and "Content-Length" in $headers, but this didn't change anything. When I reversed to 1.7 everything started working like charm even with Ubercart. I can't catch this nasty bug. Dagomar in #24 says, that in D5 in clean install has this problem, but in D6 doesn't. This makes me think, that the problem is in 5x version. I hope this helps.
Maybe I'll revert to the old 1.7 version too like Stephan_M. Don't like the idea though :(

brunodbo’s picture

@drewish: Is there anything else we can do to help diagnose the problem?

drewish’s picture

Title: Imagecache prevents caching of Images » Incorrect exipration headers with private file transfers
Version: 5.x-2.x-dev » 6.x-2.x-dev

is anyone experiencing this using public files? i'm guessing that it's private file specific. bumping this back to 6.x since that's the newest version where it occurs.

ugerhard’s picture

I'm using public files and do have the problem (Drupal 6, see #15, #16, #19).

To me it looks like *every* download of an imagecached file is routed through a full Drupal bootstrap (which sets the headers seen above that prevent caching), even when not using Drupal's private files setting. Imagecache creates its files, but these are not served directly.

drewish’s picture

ugerhard, when the file is first generated it's sent by drupal. after that the file should be found by the webserver and sent without loading drupal. hence my questions up thread asking if the files were actually being written to the disk.

brunodbo’s picture

I'm experiencing this problem using public files. Yep, files are being written to disk.

mrfelton’s picture

Drupal 6.10, latest imagecache, files are being written to disk, and only once (they are not being regenerated on every request) - they just don't have an expires header.

drewish’s picture

if the only time those headers are sent is once then this is annoying but not critical.

talking with ugerhard on irc i feel like his problem is due to a files path with files/files in it which seems like a separate issue.

Alatalo’s picture

Same slowness issue here with Drupal 6.10 and Imagecache 6.x-2.0-beta8. Browsers tested: Firefox 3.0.7/Mac and Safari 4.0 public beta/Mac.

This seems to be somehow related to that my current Drupal configuration has
* Clean urls: Disabled
* Filesystem / Download method: Private

Usually I set both of those differently (clean urls enabled and download method public). Now with different settings this is the first time ever I've encountered this problem. My host doesn't support clean urls/mod_rewrite so I cannot test it the other way around.

You can the site and problem it in action at
Refresh the page and the server loads all pictures again. It doesn't regenerate files in filesystem. Browser also displays the pictures immediately after refreshing but it also redraws/re-gets them all again at the same time and overdraws them on screen. Very strange.

JordanMagnuson’s picture

Same problem using ImageCache 5.x-2.3, public transfer mode, no ubercart:

Response Headers:
Date:Thu, 02 Apr 2009 06:47:06 GMT
	****Expires:Sun, 19 Nov 1978 05:00:00 GMT****
	Last-Modified:Thu, 02 Apr 2009 06:46:41 GMT
	Cache-Control:store, no-cache, must-revalidate, post-check=0, pre-check=0
	Keep-Alive:timeout=15, max=90
tobiasr’s picture

No expires header here too on 5.x, subscribing.

abedzilla’s picture


abedzilla’s picture

I use drupal 5.16 and imagecache 5x-2.3 and i user private file transfer.
Here's what i do to set the image expires date and override the drupal_page_header() function.

in imagecache.module file, find the function:

function imagecache_transfer($path)

Then find this code:

$headers[] = 'Content-Length: '. $fileinfo[7];

add this code just below the code above:

$headers[] = "Expires: " . date("D, d M Y H:i:s", time () + 864000) . " GMT";

so the code will look like this:

function imagecache_transfer($path) {
  if (function_exists('mime_content_type')) {
    $mime = mime_content_type($path);
  else {
    $size = getimagesize($path);
    $mime = $size['mime'];
  $headers = array('Content-Type: '. mime_header_encode($mime));

  if ($fileinfo = stat($path)) {
    $headers[] = 'Content-Length: '. $fileinfo[7];
    $headers[] = "Expires: " . date("D, d M Y H:i:s", time () + 864000) . " GMT";
    _imagecache_cache_set_cache_headers($fileinfo, $headers);
  file_transfer($path, $headers);

done! the image expire header is now set to 10 days from the last access.
You may see the result here:

brunodbo’s picture

The fix in #40 doesn't work for me: on the first request (= when imagecache creates the file) the headers are set as specified in the added line:

$headers[] = "Expires: " . date("D, d M Y H:i:s", time () + 864000) . " GMT";

On a next request (so when the file is sent by the webserver, see #32), the 11/19/1978 expires header is set again.

The 11/19/1978 expires header is set *only* for files generated by imagecache though.

For testing purposes, I tried adding (to check a jpg file):

ExpiresByType image/jpeg "access plus 1 month"

to my Apache config (in addition to the default expires setting in Drupal's .htaccess). No success though, imagecache generated files are still sent with an expires header of 11/19/1978.

brunodbo’s picture

Appearantly, the images generated by imagecache are getting their expires and cache control headers from drupal_page_header() in (line 568 in D5): if you modify the values in that function, the values in the image's expires header change.

The 11/19/1978 expires header is set for anonymous as well as authenticated users.

brunodbo’s picture

Ok, so we already knew that ...

brunodbo’s picture

The two lines from #19 seem to solve the problem for me. Apologies for spamming the issue queue.

brunodbo’s picture

Status: Postponed (maintainer needs more info) » Needs review
534 bytes
Failed: Failed to apply patch. View

Attached patch (created for imagecache v5-2.3) adds the following lines to imagecache.module (see #19):

$headers[] = 'Expires: ' . gmdate('D, d M Y H:i:s', time() + 1209600) .' GMT';
$headers[] = 'Cache-Control: max-age=1209600, public, must-revalidate';

(I used 1209600 (= two weeks), as this is the caching period Drupal uses in .htaccess.)

drewish’s picture

781 bytes
Failed: Failed to apply patch. View

confirmed that this patch fixes the caching. did a little reading on the Cache-Control header and it seems like we should be specifying private instead of public. the attached patch fixes this.

John Pitcairn’s picture

I'm seeing this problem in Drupal 6.13 with ImageCache 6.x-2.0-beta9, private filesystem. Output from Rex Swains excellent HTTP viewer at :

Receiving Header:

Adding the following 2 lines (from #19, but private and 2 weeks cache) to the end of _imagecache_cache_set_cache_headers in imagecache.module corrects the problem:

$headers[] = 'Expires: ' . gmdate('D, d M Y H:i:s', time() + 1209600) .' GMT';
$headers[] = 'Cache-Control: max-age=172800, private, must-revalidate';

Would be nice if this could be rolled into the next beta. Hmm ... can the caching time be obtained directly from Drupal API?

David Strauss’s picture

Status: Needs review » Reviewed & tested by the community

I've applied nearly identical patches to my clients' sites with good results.

drewish’s picture

Status: Reviewed & tested by the community » Fixed

committed to DRUPAL-6--2 AND DRUPAL-5--2

drewish’s picture

Project: ImageCache » Drupal core
Version: 6.x-2.x-dev » 7.x-dev
Component: Code » image system
Status: Fixed » Patch (to be ported)

Realized that this issue made its way into D7.

drewish’s picture

Status: Patch (to be ported) » Needs review
1.09 KB
Passed: 12422 passes, 0 fails, 0 exceptions View
eojthebrave’s picture


+ 'Expires' => gmdate('D, d M Y H:i:s', time() + 1209600) .' GMT',


+ 'Expires' => gmdate(DATE_RFC1123, time() + 1209600) .' GMT',

And this is good to go.

drewish’s picture

1.08 KB
Passed: 12418 passes, 0 fails, 0 exceptions View

Ah, double checked and if we use that constant we need to drop the GMT. DateTime::RFC1123 is defined as "D, d M Y H:i:s O" and the O is defined as "Difference to Greenwich time (GMT) in hours Example: +0200". Which matches the Expires header in RFC2616 (it references RFC1123 which is really RFC822's date format with 4-digit years).

eojthebrave’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me. Minor white space fix that isn't necessary but doesn't hurt anything either.

Dries’s picture

Status: Reviewed & tested by the community » Needs work

Please add a code comment, and set back to RTBC. Thanks!

drewish’s picture

Status: Needs work » Reviewed & tested by the community
1.38 KB
Passed: 12247 passes, 0 fails, 0 exceptions View

I think this should do it.

webchick’s picture

Status: Reviewed & tested by the community » Needs work

Sorry to be a pain in the ass, but I'm missing the "why" in those comments. Why two weeks instead of 1 week or 1 day or 6 months? What's up with the Cache-control stuff?

Let's make sure the sizable discussion here is captured in these comments so we don't try and "fix" this later.

drewish’s picture

webchick, two weeks was an arbitrary number picked to match the mod_expires header that we're setting in .htaccess. It doesn't document the motivation behind that particular value so it would be wild speculation on my part. The cache control header is directed at caching proxies telling them how long it's good for and letting them know it's private so they won't share this file between their users, each will need to authenticate. Maybe I'm old fashioned but if I want all the nitty gritty that went into a patch I cvs blame the file then lookup the issue # in the commit message and read it there.

drewish’s picture

Status: Needs work » Reviewed & tested by the community
1.5 KB
Passed: 12400 passes, 0 fails, 0 exceptions View

how about this?

eojthebrave’s picture

I think I would like it better without the "...". Something like.

+          // Send headers describing the image's size, and MIME-type.
           'Content-Type' => $info['mime_type'],
           'Content-Length' => $info['file_size'],
+          // Allow the file to be cached for two weeks (matching the
+          // value we/ use for the mod_expires settings in .htaccess) and
+          // ensure that caching proxies do not share the image with other
+          // users.
+          'Expires' => gmdate(DATE_RFC1123, time() + 1209600),
+          'Cache-Control' => 'max-age=1209600, private, must-revalidate',

Also, what's up with the "we/" seems a little odd.

David Strauss’s picture

Title: Incorrect exipration headers with private file transfers » Incorrect expiration headers with private file transfers

Spelling fix.

drewish’s picture

eojthebrave, I really like the ... to indicate that two (or more) comments are part of the same thought. As for the "We" it's used all over core and I think it makes the comments much more readable as well. The comment's author is guiding your though the code so it makes sense to say "here's what *we*'re doing..."

Dries’s picture

Status: Reviewed & tested by the community » Fixed

I committed the patch in #59. It looks very good to me.

drewish’s picture

933 bytes

Oh... i just looked at the patch and saw that the slash after we was what eojthebrave was commenting on. I'd misunderstood his concern.

webchick’s picture

Committed to #64.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Herman Hiddema’s picture

When the private file transfer method is set, and the image is not modified, ImageCache will send a 304 Not Modified, but also send an incorrect (1978) expiration date and a Cache-Control: no-cache, causing some browsers to then dump the image.