By FortEZ on

Here is the deal:

My Drupal 6.14 lives in a typical LAMP installation (Linux distro: Fedora). The File System of my installation is set to Private, but I did not move the files from their original location (sites/default/files).

Whenever I use a path like the following:
/system/files/.../....png

in a block, page or in my theme (page.tpl.php), YSlow reports the following:

(1978/11/19) http://....com/system/files/images/....png

in the Expires Headers category. If I manually change the path to http://....com/sites/default/files/images/....png the expires headers are set properly and the file is cached without any issues.

However, since I already have a lot of pages with images that have a path with system/files, I would like to know if there is a "trick" to set a far-future expiration date to these images.

I hope that my description is clear enough.

Thanks in advance for any help.

⋅ Categories: Drupal 6.x

Comments

FortEZ’s picture

FortEZ commented

If you want to replicate this issue, please do the following:

- Install a fresh drupal 6.14
- Enable Clean Urls
- Enable Private File Transfer
- Go to Modules and enable the Upload module
- Create a simple Story and attach an image to it (e.g. MyImage.jpg)
- Write the following in the body of the story: <img src="/system/files/MyImage.jpg />
- Make sure that the Input Format is set to "Full HTML" and save your story

If you now open the specific story with a Mozilla Firefox that has Firebug and YSlow installed, you will see that the expiration date of the specific image is set to (1978/11/18).

I will appreciate any comments.

SimonV’s picture

SimonV commented

A couple of different websites that I am running have the same issue... bump

WorldFallz’s picture

WorldFallz commented

Not sure what you're asking, but adding 'system' to the path is exactly what setting the file system to 'private' does. And one of the side effects of the private files setting is performance degradation. Sorry, no clue about the expiration. imo, if you don't have a very specific reason for using the 'private' setting for the file system it's much better if you don't.

FortEZ’s picture

FortEZ commented

I agree about the Private File System. I have about 3 very good reasons to keep my file system private:

1) I could not find a way to create a URL alias that points to a file with the public file system. This is a very important feature for my website since I need to have "clean URL aliases" that point to specific files (the desktop application that my company is building needs to look for those specific aliases and you cannot create an alias that points to an exe file with the public file system as far as I know).

2) I need to keep track of a specific executable's downloads and with the private file system I am able to get very detailed statistics.

3) In the future I will definitely need to allow access to specific content per role.

However, even if there was no good reason for me to keep my file system to private, I do not think that it is wise to dismiss a problem because an option is "not the most commonly used" one. If the private file system has problems with the Expires Headers, we should create an issue so that it can be fixed or at least, state the problem somewhere (like in a "Known Issues" page or in a page like this.

Anyone else facing the issue?

WorldFallz’s picture

WorldFallz commented

The issue has already been fixed for d7 (which has replaced upload module with filefield module and which can mix public and private files), not sure about the status for d6. Regarding your 3 reasons for using private files, I can only tell you what I've used:

1) http://drupal.org/project/file_aliases

2) i use a filefield with the method described at http://drupal.org/node/189239

3) also uses #2