☰

Обработка относительных путей Nginx приводит к ошибкам 404

tag-icon • tag-icon nginx
Обработка относительных путей Nginx приводит к ошибкам 404

У меня возникла проблема: когда я проксирую страницу, относительные пути к файлам не находятся.

Пример работы:

https://lfportal.mohavecounty.us/bos/search.aspx?dbid=0&searchcommand=%28%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Date%5D%3D%2211/23/2020%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Type%5D%3D%22Special%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BItem%20Number%5D%3D%22Item%20001%22%7D%29%20

Что перенаправляет к результату поиска:

https://lfportal.mohavecounty.us/bos/0/doc/1652027/Page1.aspx

В файле Page1.aspx есть пути, использующие относительный путь, как показано в примере ниже.

<img id="A_T0_0_1" unselectable="on" src="../../../Helper/TileData.aspx?reposName=MohaveDocs&amp;docID=1652027&amp;x=0&amp;y=1&amp;pageNum=1&amp;scale=3782&amp;ro=0&amp;time=1607098159588&amp;showAnn=1&amp;pageID=7493796&amp;search=">

Теперь с моим перенаправлением

https://lfdocs.mohave.gov/bos/search.aspx?dbid=0&searchcommand=%28%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Date%5D%3D%2211/23/2020%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Type%5D%3D%22Special%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BItem%20Number%5D%3D%22Item%20001%22%7D%29%20

Страница загружается, но не продолжается, потому что она не работает. Она выдает 404 и, глядя на адрес одного из изображений выше в Chrome developer, ошибка 404 показывает адрес:

https://lfdocs.mohave.gov/Helper/TileData.aspx?reposName=MohaveDocs&docID=1652027&x=0&y=1&pageNum=1&scale=3782&ro=0&time=1607098058369&showAnn=1&pageID=7493796&search=

Похоже, корневая папка bos отсутствует. https://lfdocs.mohave.gov/Helper/TileData.aspx?

Должен быть URL: https://lfportal.mohavecounty.us/bos/Helper/TileData.aspx?

Так что, похоже, мой proxy pass не обрабатывает относительный атрибут правильно. Ниже приведен мой пример конфигурации сайта Nginx. Проблема возникает во втором if условие

if ($saved_redirect_location !~* "10.4.1.81") { .. }

Мой файл конфигурации:

server{

    listen       443 ssl http2; # default_server;
    server_name  lfdocs.mohave.gov;

    access_log  /var/log/nginx/lfdocs_mohave_gov_access.log;
    error_log   /var/log/nginx/lfdocs_mohave_gov_error.log info;
    
    include /etc/nginx/sites-available/mohave_gov_ssl.conf;

    location / {

        proxy_buffers 16 4k;
        proxy_buffer_size 2k;       

        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Port 443;

        proxy_pass http://10.4.1.81/;


        # This is used to handle the multiple redirect 301 that the server is doing
        proxy_intercept_errors on;
        error_page 301 302 307 = @handle_redirects;     

    }   

    location @handle_redirects {
        set $saved_redirect_location '$upstream_http_location';

    
        if ($saved_redirect_location ~* "10.4.1.81") {
            add_header X-debug-message 1$saved_redirect_location always;
            proxy_pass $saved_redirect_location;
        }

        if ($saved_redirect_location !~* "10.4.1.81") {
            add_header X-debug-message http://10.4.1.81$saved_redirect_location always;
            proxy_pass http://10.4.1.81$saved_redirect_location;
        }       
    }   
}

В Chrome Developer я смотрю на пользовательский заголовок x-debug-message и вижу следующее значение:

x-debug-message: http://10.4.1.81/bos/0/doc/1652027/Page1.aspx

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

Есть идеи, почему относительные пути не загружаются?

решение1

Относительные пути добавляются вашим внутренним приложением. nginx никак не влияет на пути.

Если ваше бэкэнд-приложение использует относительные пути, то URL-адрес вашего фронтэнда должен находиться на той же глубине, что и URL-адрес бэкэнда.

В вашем первом примере:

https://lfportal.mohavecounty.us/bos/0/doc/1652027/Page1.aspx

URL находится на четвертом уровне подкаталога. Это означает, что браузер может ../../../разрешить /bos.

Во втором примере:

https://lfdocs.mohave.gov/bos/search.aspx?dbid=0&searchcommand=%28%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Date%5D%3D%2211/23/2020%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Type%5D%3D%22Special%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BItem%20Number%5D%3D%22Item%20001%22%7D%29%20

URL находится на втором уровне подкаталога. Теперь браузер пытается разрешить ../../../URL, и в итоге получается /URL.

Я рекомендую вам заменить относительные URL-адреса на относительные URL-адреса корня сайта:/bos/Helper/TileData.aspx?reposName=MohaveDocs&amp;docID=1652027&amp;x=0&amp;y=1&amp;pageNum=1&amp;scale=3782&amp;ro=0&amp;time=1607098159588&amp;showAnn=1&amp;pageID=7493796&amp;search

Еще одна проблема с вашими URL-адресами заключается в том, что символы амперсанда закодированы в URL-адресе, что может привести к нежелательному конечному результату.

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