Многофункциональность Nginx Redirect

Question

В nginx я пытаюсь найти лучший способ обработать перенаправление, чтобы заставить весь трафик, не относящийся к https, к https тогда и только тогда, когда трафик не находится в пути/assets/*.

USE CASE: Чтобы включить javascript и css в кеширование через AWS CloudFront без необходимости связывать сертификат SSL с сервера.

Вот что я пытаюсь:

server { 
    listen 80; 

    if ($http_x_forwarded_proto = "http") { 
     set $redir please_redir; 
    } 

    location ~ ^/assets/|favicon.ico { 
     set $redir dont_redir; 
     root /home/deploy/www/public; 
     gzip_static on; 
     expires max; 
     add_header Cache-Control public; 
    } 


    if ($redir = please_redir) { 
     return 301 https://$http_host$request_uri; 
    } 

    location/{ 
     proxy_pass http://127.0.0.1:9292/; 
     proxy_set_header Host $http_host; 
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    } 
} 

Я попытался оберточной «please_redir» в кавычках, а также, не повезло. Есть идеи? Другие приемлемые решения приветствуются. Имейте в виду, что это должен быть запрос без https, а также НЕ в/assets/path. Благодаря!

Answer 1

Вопрос был о месте перенаправления. Глупая ошибка ... Для тех, кто хочет отправить конвейер ресурсов rails через CloudFront, у вас будет проблема с файлами woff и tiff с CORS, и вам нужно будет отправить дополнительные заголовки для разрешения запроса источника. Мы решили использовать статические активы через http до облачного интерфейса, чтобы избежать необходимости связывать сертификат SSL в CloudFront. Вот решение.

server { 
    listen 80; 

    location ~ ^/assets/|favicon.ico|robots.txt { 
     root /home/deploy/www/public; 
     gzip_static on; 
     expires max; 
     add_header Cache-Control public; 
     if ($http_origin ~* 'https?://subdomain\.cloudfront.net') { 
       add_header 'Access-Control-Allow-Origin' "$http_origin"; 
       add_header 'Access-Control-Allow-Credentials' 'true'; 
       add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS'; 
       add_header 'Access-Control-Allow-Headers' 'Accept,Authorization,Cache-Control,Content-Type,DNT,If-Modified-Since,Keep-Alive,Origin,User-Agent,X-Mx-ReqToken,X-Requested-With'; 
     } 
    } 

    location/{ 

     # ELB Injects: X-Forwarded-Proto: HTTP or HTTPS 
     if ($http_x_forwarded_proto = "http") { 
      return 301 https://$http_host$request_uri; 
     } 

     proxy_pass http://127.0.0.1:9292/; 
     proxy_set_header Host $http_host; 
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 

    } 
} 

Answer 2

Просто настройте основной сервер для прослушивания только https и отдельного сервера на http для перенаправления и активов.

Дополнительные конфигурации сервера может выглядеть

server { 
    server_name example.com; 

    location ~ ^/assets/|favicon.ico { 
    root /home/deploy/www/public; 
    gzip_static on; 
    expires max; 
    add_header Cache-Control public; 
    } 

    location/{ 
    rewrite ^(.*) https://example.com$1 permanent; 
    } 
} 

Answer 3

Используйте^~ и = места для лучшей производительности. Стоит использовать повторяющиеся директивы статического содержимого. Вы можете всегда помещать их в прилагаемый файл для удобства обслуживания:

server { 
    listen 80; 
    root /home/deploy/www/public; 

    location ^~ /assets/ { 
     gzip_static on; 
     expires max; 
     add_header Cache-Control public; 
    } 

    location = /favicon.ico { 
     gzip_static on; 
     expires max; 
     add_header Cache-Control public; 
    } 

    location/{ 
     return 301 https://$http_host$request_uri; 
    } 
}