nginx config for Far Future expiration: use the Far Future feature directly in nginx, avoiding PHP

Hi Wim,

first, thanks for your quick reply. Second, I've looked into the module's Advanced Help info, but I'm still not sure what's the best way to workaround the problem I've experienced.

To give you some more insight on the issue here some additional info. I'm not using any commercial CDN solution, I've set up a origin pull local CDN solution based on nginx just to separate the HTTP requests and ease of the load on the main server.

After updating the module the websites didn't open, and all CDN requests where returning 404. For example the original CDN URL was something like:

http://cdn.example.com/sites/www.example.com/files/css/css_e26f771018dad4302bb944297ef2b2d8.css

after the update it became:

http://cdn.example.com/cdn/farfuture/mtime:1327487429/sites/www.example.com/files/css/css_e26f771018dad4302bb944297ef2b2d8.css

From the looks of it, I guess I have 2 options:

1. Turn the CDN far future off;
2. Change my nginx URL matching rules to work with these new URLs.

Do you see any other way to work around this?

Thanks again,
Rolando Isidoro

Hi Wim,

the solution you mention, to add some additional rewrite rules will only increase the type of URLs the nginx server can handle, but won't provide any significant improvement.

Regarding the nginx config, there's not much to it, we're using a shared FS mount for both the main server (Apache) and the CDN (nginx), so basically we only have the following to guaranty that the ImageCache files get created upon the 1st request:

# www.sub-domain.domain.com
location ~ ^/sites/ www.sub-domain.domain.com {
        set $domain 'www.sub-domain.domain.com';
        if (!-e $request_filename) {
                rewrite ^(.*)$ http://$domain/$1 last;
                break;
        }
}

# Fallback to default website if none of the other appy
if (!-e $request_filename) {
        rewrite ^(.*)$ http://www.domain.com$1 last;
        break;
}

Nonetheless, keeping the Far Future module setting turned off by default still seems the easiest and most compatible solution.

Best regards,
Rolando Isidoro

Hi Wim,

I understand what you're asking, but what I don't get is why this new feature is active by default. I find it even harder to conceive why can't I deactivate it, even if I explicitly uncheck the option in the configuration form.

Simply put, you added the far future option and there's no way someone using your module to not use it, right?

Best regards,
Rolando

Wim,

on the previous version of the module, 6.x-2.2, the "cdn_farfuture_status" variable wasn't written with value 0 on the DB when I saved the details configuration form, resulting on the behavior to fallback to the value set on the constant CDN_BASIC_FARFUTURE_DEFAULT. In the meantime I've update to 2.3 and now it does, which means that I'm now able to deactivate it.

But check my case, I have 20+ sites, all using the CDN module. At this point I would have to go through each site and save the CDN details settings form with the the Far Future expiration unchecked. Does it seem reasonable?

Best regards,
Rolando