Nginx меняет путь - PullRequest
       16

Nginx меняет путь

0 голосов
/ 07 апреля 2019

Я искал документацию и публикации thuhg nginx в Интернете, но не могу найти ответ на этот вопрос.

Я запускаю приложение на python и хочу, чтобы один из путей был слегка изменен.Я не могу сделать это в python по разным причинам.

Я хочу, чтобы входной URL: / public / web / apidocs *** (где * мог быть чем угодно - включая ничего) был передан вприложение python как / apidocs *

Это моя конфигурация:

server {
    listen      80;
    server_name localhost; ##ignored if there is only one server block
    charset     utf-8;
    client_max_body_size 75M;

    location = /frontend/webfrontendConnectionData {
        try_files $uri @yourapplication;
    }
    location /public/web/frontend {
        alias /frontend/;
        autoindex off;
    }
    location /public/web/adminfrontend {
        alias /adminfrontend/;
        autoindex off;
    }
    location ^(/public/web)(/apidocs.*)$ { 
        try_files $2 @yourapplication;
    }
    location / { 
        try_files $uri @yourapplication;
    }
    location @yourapplication {
        include uwsgi_params;
        uwsgi_pass unix:/app/uwsgi.sock;
    }    
}

Обновление основано на ответе до сих пор:

Спасибо, что указали на ошибкуили пропустить ~ в конфиге.Конфигурация изменилась следующим образом:

location ~ ^(/public/web)(/apidocs.*)$ { 
    try_files $2 @yourapplication;
}
location / { 
    try_files $uri @yourapplication;
}
location @yourapplication {
    include uwsgi_params;
    uwsgi_pass unix:/app/uwsgi.sock;
}    

К сожалению, она все еще не работает должным образом:

  • wget 127.0.0.1:80/apidocs -> Переход к приложению Python иработает как ожидалось
  • wget 127.0.0.1:80/apidocs/ -> Переход в приложение Python и работает как ожидалось
  • wget 127.0.0.1:80/apidocs/swagger.json -> Переход кПриложение Python и работает как ожидалось
  • wget 127.0.0.1:80/public/web/apidocs -> FAILS Я хочу, чтобы это давало тот же ответ, что и wget 127.0.0.1:80/apidocs
  • wget 127.0.0.1:80/public/web/apidocs/ -> FAILS Я хочу, чтобы это давало тот же ответ, что и wget 127.0.0.1:80/apidocs/
  • wget 127.0.0.1:80/public/web/apidocs/swagger.json -> FAILS Я хочу, чтобы это давало тот же ответ, что и wget 127.0.0.1:80/apidocs/swagger.json

Все неудачные ответы дают мне:

robert@ansiblerunner:~/t$ wget 127.0.0.1:80/public/web/apidocs/swagger.json
--2019-04-08 09:50:39--  http://127.0.0.1/public/web/apidocs/swagger.json
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... 404 NOT FOUND
2019-04-08 09:50:39 ERROR 404: NOT FOUND.

Может кто-нибудь предложить правильный синтаксис для правила, которое я хочу.

Обновление # 2

После прочтения дополнительной документации nginx, которую я основалВыясните, что он не принимает правила расположения по порядку и использует первое, на которое попал, скорее, он имеет сложный алгоритм наибольшего совпадения.Я был обеспокоен тем, что блок "location /" переопределял все пути, поэтому я изменил конфигурацию так, чтобы она выглядела следующим образом:

location /api/public { 
    try_files $uri @yourapplication;
}
location /api/authed { 
    try_files $uri @yourapplication;
}
location ~* ^(/public/web)(/apidocs.*)$ { 
    try_files $2 @yourapplication;
}
#location / { 
#    try_files $uri @yourapplication;
#}
location @yourapplication {
    include uwsgi_params;
    uwsgi_pass unix:/app/uwsgi.sock;
}    

/ api / public и / api / authed оба работают как обычно,это / public / web / apidocs этого не делает.Разница в том, что в этом случае мне нужен nginx, чтобы изменить путь к приложению python.Вот почему у меня есть регулярное выражение с двумя частями, которое передает $ 2, а не $ uri.Я не думаю, что он делает то, что я ожидаю, что передать / apidoc в приложение.

Ответы [ 2 ]

1 голос
/ 07 апреля 2019

Я не вижу здесь регулярного выражения, так как ему не хватает тильды.Вы, вероятно, хотите пункт, который начинается с:

location ~ ^(/public/web)(/apidocs.*)$ { 

Вы не упомянули, какие документы вы читали.Обращаясь к учебному пособию , Понимая Алгоритмы выбора сервера Nginx и блока местоположения, мы видим синтаксис:

location optional_modifier location_match {

, и мы дополнительно можем указать:

~: Если присутствует модификатор тильды, это местоположение будет интерпретироваться как регистрозависимое совпадение с регулярным выражением.

Я не могу объяснить ваш сообщенный признак 404, так как предложение префикса location / должно было поглотитьGET запрос и, по крайней мере, предоставил @yourapplication возможность log необработанный URL.

0 голосов
/ 08 апреля 2019

у меня есть ответ Я был совершенно не в себе с моим пониманием того, что try_files не сработал, как я ожидал. Я нашел статью, в которой говорилось, что если я использую ее с подчеркиванием, он не будет пытаться использовать файлы, а просто использует ее как запасной вариант. Я также узнал, что мне нужно использовать переписать, чтобы изменить путь. Избавиться от корневого расположения, возможно, не было необходимости, но я предпочитаю не иметь его в любом случае. Мой окончательный конфиг выглядит следующим образом:

server {
    listen      80;
    server_name localhost; ##ignored if there is only one server block
    charset     utf-8;
    client_max_body_size 75M;

    #location = /frontend/webfrontendConnectionData {
    #    try_files $uri @yourapplication;
    #}
    location /public/web/frontend {
        alias /frontend/;
        autoindex off;
    }
    location /public/web/adminfrontend {
        alias /adminfrontend/;
        autoindex off;
    }
    # try_files _ @xxx means don't look at any file go to xxx block
    location /api/public { 
        try_files _ @yourapplication;
    }
    location /api/authed { 
        try_files _ @yourapplication;
    }
    location /public/web/apidocs { 
        rewrite ^/public/web(/apidocs.*)$ /$1? break;
        try_files _ @yourapplication;
    }
    #location / { 
    #    try_files _ @yourapplication;
    #}
    location @yourapplication {
        include uwsgi_params;
        uwsgi_pass unix:/app/uwsgi.sock;
    }    
}

Спасибо J_H за комментарии и ответы.

...