☰

Регулярное выражение Nginx для получения URI минус местоположение

tag-icon • tag-icon nginx regex
Регулярное выражение Nginx для получения URI минус местоположение

У меня Nginx работает как обратный прокси для пары приложений. Одна директива location работает правильно, отправляя запросы в файл сокета unix и далее в его вышестоящее приложение wsgi. Директива, с которой у меня проблема, этоlocation ~ ^/sub/alarm(.*)$. У меня есть пара переписываний, которые, кажется, работают, но на случай, если они вступают в противоречие с другими моими намерениями, я объясню свое намерение с каждой директивой:

  • Первая директива сервера должна перенаправлять все http на https. Кажется, это работает нормально.
  • Вторая директива сервера имеет одну директиву местоположения, которая направляет трафик в мое приложение wsgi. Это работает отлично. Другая директива местоположенияЯ имел в виду использовать для обслуживания статического контента с /home/myuser/alarm.example.com/момента получения GET дляexample.net/sub/alarm. (например, example.net/sub/alarm/pretty.css должен передать /home/myuser/alarm.example.com/pretty.css) Вместо этого загружается приложение wsgi.
  • Последняя директива сервера должна перенаправить alarm.example.net на example.net/sub/alarm, поскольку у меня нет wildcard-сертификата, но мне нужен простой ярлык и шифрование. Кажется, это работает нормально.

конф:

server {
    listen 80;
    listen [::]:80 ipv6only=on;
    server_name example.com www.example.com;
    rewrite ^/(.*) https://example.com/$1 permanent;
}

server {
        listen 443 ssl;
        listen [::]:443 ipv6only=on ssl;
        charset utf-8;
        client_max_body_size 75M;
        server_name example.com www.example.com;
        ssl_certificate /etc/ssl/certs/example.com.crt;
        ssl_certificate_key /etc/ssl/private/example.com.key;

        location / {
                include uwsgi_params;
                uwsgi_pass unix:///tmp/example.com.sock;
        }

        location ~ ^/sub/alarm(.*)$ {
                alias /home/appusername/alarm.example.com;
                index index.html;
                try_files $1 $1/;
        }
}

server {
        listen 80;
        server_name alarm.example.com;
        rewrite ^ $scheme://example.com/sub/alarm$request_uri permanent;
}

я посмотрел накак удалить блокировку местоположения из $uri в конфигурации nginx?чтобы попытаться получить часть моего файла местоположения после uri. Я думаю, что я что-то упускаю о приоритетах.

Еще одна попыткабыл без регулярного выражения:

location /sub/alarm/ {
        alias /home/appusername/alarm.example.com;
        index index.html;
        try_files $uri $uri/index.html =404;
}

В приведенном выше случае мне удалось загрузить index.html при переходе на alarm.example.com (который корректно перенаправил наhttps://example.com/sub/alarm/), но все ресурсы выдавали ошибку 404.

Наконец, я попытался объединить обе попытки, но, похоже, я не могу поместить тильду внутрь блока location («неизвестная директива» при перезагрузке Nginx):

location /sub/alarm/ {
        ~ ^/sub/alarm(.)$
        try_files /home/appusername/alarm.example.com$1 /home/appusername/alarm.example.com$1/;
}

Дополнительные замечания

  • Динамическое приложение на example.com совершенно не связано с приложением "будильник", которое является статическим. Оно включено только потому, что оно обслуживается вместо приложения будильника, когда я пытаюсь выполнить регулярное выражение.
  • Я всегда избегал изучать что-либо о регулярных выражениях (возможно, это неразумно, но за последние 7 лет до сегодняшнего дня они мне никогда не были нужны) и теперь расплачиваюсь за это, настраивая Nginx. Я использовалРегулярное выражение 101чтобы получить мою строку regex ^\/sub\/alarm(.*)$. Похоже, это указывало на то, что мне нужно использовать экранирующие слеши, но Nginx, похоже, не показывает это в примерах. Пожалуйста, дайте мне знать, если есть еще какие-то концепции, которые мне нужно изучить. Я официально прекращаю свою позицию избегания regex с сегодняшнего дня.
  • Если синтаксис был достаточно корректен для перезагрузки Nginx, то моя ошибка была 2015/10/12 20:25:57 [notice] 30500#0: signal process startedво всех попытках.

решение1

Итак, пользователь (э-э... я) пропустил что-то, что должно было стать очевидной подсказкой:

В приведенном выше случае мне удалось загрузить index.html при переходе на alarm.example.com (который корректно перенаправил на https://example.com/sub/alarm/), но все ресурсы выдавали ошибку 404.

Хотя этот пример все еще не был правильным, яследовало бы проверить права доступа к файлам ресурсов. Nginx работает как www-data и в группе для файла index.html, но должен быть в группе для всех файлов. Владелец файла — пользователь appusername.

С тех пор я добавил еще одно приложение (под названием «пиво»), которое маршрутизируется как сигнализация. Теперь я изучил основы регулярных выражений и смог сделать это в одном блоке расположения:

server {
    listen 80;
    listen [::]:80 ipv6only=on;
    server_name example.com www.example.com;
    rewrite ^/(.*) https://example.com/$1 permanent;
}

server {
        listen 443 ssl;
        listen [::]:443 ipv6only=on ssl;
        charset utf-8;
        client_max_body_size 75M;
        server_name example.com www.example.com;
        ssl_certificate /etc/ssl/certs/example.com.crt;
        ssl_certificate_key /etc/ssl/private/example.com.key;
        error_log /var/log/nginx/error.log warn;

        location ~ ^/sub/(alarm|beer)(.*)$ {
                alias /home/appusername/$1.example.com/;
                #index  index.html index.htm;
                try_files $2 $2/ =404;
        }

        location / {
                include uwsgi_params;
                uwsgi_pass unix:///tmp/example.com.sock;
        }
}

server {
        listen 80;
        server_name alarm.example.com;
        rewrite ^ $scheme://example.com/sub/alarm$request_uri permanent;
}

Не обращайте внимания на переключение порядка расположения блоков. Это всего лишь совпадение набора и повторного набора.

Связанный контент