Nginx:为来自不同根和位置的JPG图像提供服务 [英] Nginx : Serve JPG images from different root and location

查看:209
本文介绍了Nginx:为来自不同根和位置的JPG图像提供服务的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有3种不同的存储区域:存储图像的头像",物品",趋势".

I have 3 different stockage area : "avatars" , "articles", "trends" where I store my images.

我要链接" URL"/trends/123.jpg"到趋势文件夹,"/avatars/23.jpg"到头像等等.

I want to "link" the URL "/trends/123.jpg" to trends folder , "/avatars/23.jpg" to avatar and so on.

配置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;
    }
}

配置1:"GET/trends/123.jpg"与/trends/位置不匹配,为什么?

Configuration 1 : "GET /trends/123.jpg" never match /trends/ location, why ?

配置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;
    }
}

配置2:具有缓存内容的最后一条规则不匹配.从不同位置/根目录服务器JPG文件的最佳方法是什么?

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:

  1. 位置匹配的顺序;和
  2. 匹配位置会发生什么情况.

我将首先解释其工作原理,然后再介绍您的配置.

I'll first explain how it works, and then I'll address your configurations.

工作方式

位置匹配

您可以在 nginx Wiki页面上找到详细信息,但我总是能找到这样的措辞令人困惑. (它在行为描述中混合了实现细节.)这意味着位置按以下顺序匹配:

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:

  1. 完全匹配,例如location = /robots.txt
  2. 渴望非正则表达式前缀,例如location ^~ /trends/
  3. 正则表达式匹配,例如location ~* \.(jpg|png)或区分大小写的location ~ \.(jpg|png)
  4. 惰性非正则表达式前缀,例如location /trends/location /
  1. exact matches like location = /robots.txt
  2. eager non-regex prefixes like location ^~ /trends/
  3. regex matches like location ~* \.(jpg|png), or case-sensitive location ~ \.(jpg|png)
  4. lazy non-regex prefixes like location /trends/ or location /

如果多个正则表达式匹配,则第一个匹配将击败其他匹配.如果有多个非正则表达式前缀匹配,我认为它会选择最具体的匹配-我会检查并更新.

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.

位置行为

匹配位置负责提供指定内容.它还负责提供缓存控制标头等.您可以具有一个与特定URL模式匹配的位置,以应用特定的标头,但是该位置也必须提供内容.如果它不能提供内容,则很可能会出现404错误-它不会寻找其他匹配位置.

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.

配置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

location ^~ /trends {
    ...
}

但是,这样做会突出显示另一个配置问题.

However, doing so will highlight the other configuration problem.

配置2

您有两个可能与jpg文件匹配的位置.只有一个人会成功.如果第一个匹配,则不会应用第二个位置的缓存控件.如果第二个匹配,则别名将无效.

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

location ^~ /trends
{
    alias /var/storage/hottrend;

    add_header Cache-control "public";
    access_log   off;
    expires      90d;
}

location ~* ^.+\.(jpeg|gif|png|jpg)
{
    add_header Cache-control "public";
    access_log   off;
    expires      90d;
}

用于管理必须应用于多个位置的指令的更整洁的解决方案是将这些详细信息分解到另一个文件中,然后在两个位置中将其分解成include. (穆罕默德·阿布沙迪(Mohammad AbuShady)在他的示例中就是这样做的.)类似这样的东西:

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:

# Inside your main .conf
location ^~ /trends
{
    alias /var/storage/hottrend;
    include image-headers.conf;
}

location ~* ^.+\.(jpeg|gif|png|jpg)
{
    include image-headers.conf;
}

# Inside image-headers.conf
add_header Cache-control "public";
access_log   off;
expires      90d;

这篇关于Nginx:为来自不同根和位置的JPG图像提供服务的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆