Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Disclaimer: I'm not 100% certain this is a bug with the module itself, so filing it as a support request.
Background: I recently migrated a Pressflow 6 site from one server to another. In the process, I flushed all ImageCache presets before rsyncing the filesystem. I have been using far future expiration with the insert.module, so hundreds of node body fields have hardcoded CDN urls formatted with far future expiration.
The CDN I am using is Amazon CloudFront.
Problem: In cdn.basic.farfuture.inc, when the cdn_basic_farfuture_download() function gets to line 28 (see code below), it fails to find the file (which I can verify does not exist in the appropriate ImageCache preset files folder) and generate the appropriate imagecache image file.
if (!file_exists($path)) {
watchdog(
'cdn',
'CDN Far Future 404: %file.',
array('%file' => $path),
WATCHDOG_ALERT
);
header('HTTP/1.1 404 Not Found');
exit();
}It adds the expected alert to watchdog: "CDN Far Future 404: sites/default/files/imagecache/full-post-width/images-on-cdn/weird-target-sf-tees.jpg."
While attempting to debug this issue (and find a temporary solution to prevent broken images on production), I manually re-generated all the ImageCache files on my and now the CDN no longer returns 404 errors.
I have isolated an example of this problem can be seen on production: http://uptownalmanac.com/2012/10/what-does-mission-and-pac-heights-have-...
The offending, 404 image is here (if it helps to evaluate response headers): http://cdn1.uptownalmanac.com/cdn/farfuture/QN8KBdeiJBEBuWrtDkwsOKbFuYVI...
(Note: you remove cdn/farfuture/$token/mtime:[TIME] from the path and it loads as expected. Within minutes, the full url works again)
There is one caveat: any new nodes created since migration have no errors--upload an image using filefield, insert it, and the full-length CDN w/ far-future URL loads properly + generates the imagecache file).
I'm fairly stumped. Any ideas of how to proceed debugging?
Comments
Comment #1
Wim LeersOh boy. This is the root of your problem. You want to prevent this from happening, because this is what makes it hard to switch from one CDN to another.
However, there is more to this matter, and I need to document that, so I'm repurposing this issue to do that. I'm going to give a full answer to your question below.
What you call $token is what I call the "security token" in the code base. It's based on the UFI (Unique File Identifier), the filename, the Drupal private key and the hash salt. So if you migrate your site, you have to ensure those stay the same (otherwise your passwords also wouldn't work anymore).
However, in Drupal 6, there's no salt built in… So I had to figure out some way of generating a salt in 6. I came up with this, which is analogous to how it's done in 7:
The root cause here is that the URLs that insert.module inserts are the CDN URLs already. I need to fix that. See #1863530: Don't generate CDN URLs when using the Insert module by blacklisting file/ajax/*.
Comment #1.0
Wim LeersOffering further clarification.
Comment #2
Wim LeersComment #4
Wim Leers