I have 3 different stockage area : "avatars" , "articles", "trends" where I store my images.
I want to "link" the URL "/trends/123.jpg" to trends folder , "/avatars/23.jpg" to avatar and so on.
Configuration 1:
server
{
listen 8089;
server_name localhost;
root /var/www;
location /trends/
{
alias /var/storage/hottrend/;
}
location ~* ^.+\.(jpeg|gif|png|jpg)
{
add_header Cache-control "public";
access_log off;
expires 90d;
}
}
Configuration 1 : "GET /trends/123.jpg" never match /trends/ location, why ?
Configuration 2:
server
{
listen 8089;
server_name localhost;
root /var/www;
location ~ ^/trends/(.*)\.jpg$
{
rewrite ^/trends/(.*)$ /$1 break;
root /var/storage/hottrend;
}
location ~* ^.+\.(jpeg|gif|png|jpg)
{
add_header Cache-control "public";
access_log off;
expires 90d;
}
}
Configuration 2: The last rule with the caching stuff is not matched. What is the best approach to server JPG files from different location/root ?
The two configurations have different but related problems. The two issues are:
I'll first explain how it works, and then I'll address your configurations.
How it works
Location matching
You can find the details on this nginx wiki page, but I have always found the wording to be confusing. (It mixes implementation details in the description of behaviour.) What it means is that locations are matched in the following order:
location = /robots.txt
location ^~ /trends/
location ~* \.(jpg|png)
, or case-sensitivelocation ~ \.(jpg|png)
location /trends/
orlocation /
If multiple regular expressions match, then the first match beats the others. If multiple non-regex prefix match, I think it selects the most specific match -- I'll check this and update.
Location behaviour
A matching location is responsible for serving the designated content. It is also responsible for providing cache-control headers and so on. You can have a location that matches particular URL patterns to apply specific headers, but that location must also serve the content. If it cannot serve the content, you will most likely get an 404 error -- it won't look for other matching locations.
Lastly, be extra careful if you have a rewrite within a location. An internal redirect can happen earlier than some directives, in which case, those directive may not apply before the redirect causes the locations to be searched again.
Configuration 1
Your trends location is a lazy non-regex prefix, so it would only match if the regex location fails to match. You can fix this by using an eager non-regex match, such as
However, doing so will highlight the other configuration problem.
Configuration 2
You have two locations that could potentially match jpg files. Only one will succeed. If the first matches, then the cache control of the second location won't be applied. If the second matches, then the alias won't take effect.
The fix is to make sure that all directives needed are applied within the location that matches. You can either be explicit in one file, such as
The neater solution for managing directives that must be applied to several locations is to factor those details into another file, and then
include
it at both locations. (Mohammad AbuShady did so in his example.) Something like this:well I don't usually use alias but I think this is a good example to use alias for, you can put your caching settings inside
/etc/nginx/image_caching.conf
. Iftrends
is only used for images i would not try to complicate the regex and assume that it always has imagesAnd for your example config, you should have not added
/trends
insideroot /var/storage/trends;
because it's already used in the location, so i think it would show404
becuase it's looking for/var/storage/trends/trends/123.jpg
Nginx checks locations defined as regular expressions in the order in which they appear in the configuration file and uses the location with the first matching expression.
Therefore, you should make sure
location ~\.jpg$
appears before any other locations defined as regular expressions