Nginx の相対パス処理により 404 エラーが発生する

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 開発者で上記の画像の 1 つのアドレスを見ると、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?

プロキシパスが相対属性を正しく処理していないようです。以下は私のサンプルNginxサイトの設定です。問題は2番目の条件で発生しています。

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 開発者でカスタム ヘッダー 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 は 4 番目のサブディレクトリ レベルにあります。つまり、ブラウザーは../../../に解決できます/bos

2番目の例では:

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 は 2 番目のサブディレクトリ レベルにあります。ブラウザは../../../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 に関するもう 1 つの問題は、アンパサンド文字が URL エンコードされ、望ましくない最終結果につながる可能性があることです。

関連情報