Ich habe das Problem, dass beim Reverse-Proxy einer Seite die relativen Pfade der Dateien nicht gefunden werden.
Beispielarbeit:
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
Welches zum Suchergebnis weiterleitet:
https://lfportal.mohavecounty.us/bos/0/doc/1652027/Page1.aspx
In der Datei Page1.aspx gibt es Pfade, die den relativen Pfad verwenden, wie im folgenden Beispiel gezeigt
<img id="A_T0_0_1" unselectable="on" src="../../../Helper/TileData.aspx?reposName=MohaveDocs&docID=1652027&x=0&y=1&pageNum=1&scale=3782&ro=0&time=1607098159588&showAnn=1&pageID=7493796&search=">
Jetzt mit meiner Weiterleitung
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
Die Seite wird geladen, aber nicht fortgesetzt, da ein Fehler auftritt. Sie gibt viele 404-Fehler aus. Wenn man sich die Adresse eines der obigen Bilder im Chrome-Entwickler ansieht, zeigt der 404-Fehler die Adresse:
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=
Es scheint also, dass der Stammordner „bos“ fehlt. https://lfdocs.mohave.gov/Helper/TileData.aspx?
Sollte die URL sein: https://lfportal.mohavecounty.us/bos/Helper/TileData.aspx?
Es scheint also, dass mein Proxy-Pass das relative Attribut nicht richtig verarbeitet. Unten ist meine Beispiel-Nginx-Site-Konfiguration. Das Problem tritt in der zweiten auf, wenn die Bedingung
if ($saved_redirect_location !~* "10.4.1.81") { .. }
Meine Conf-Datei:
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;
}
}
}
Im Chrome-Entwickler schaue ich mir den benutzerdefinierten Header „x-debug-message“ an und er enthält den Wert:
x-debug-message: http://10.4.1.81/bos/0/doc/1652027/Page1.aspx
Ich habe versucht, den abschließenden Schrägstrich unter dem Standortabschnitt aus einem Artikel, den ich gelesen habe, zu entfernen, aber es hat nicht funktioniert.
Irgendwelche Ideen, warum die relativen Pfade nicht geladen werden?
Antwort1
Die relativen Pfade werden von Ihrer Backend-Anwendung hinzugefügt. nginx berührt die Pfade in keiner Weise.
Wenn Ihre Backend-Anwendung relative Pfade verwendet, muss Ihre Frontend-URL dieselbe Tiefe wie die Backend-URL haben.
In Ihrem ersten Beispiel:
https://lfportal.mohavecounty.us/bos/0/doc/1652027/Page1.aspx
Die URL befindet sich auf der vierten Unterverzeichnisebene. Das bedeutet, dass der Browser ../../../sie auflösen kann /bos.
In Ihrem zweiten Beispiel:
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
Die URL befindet sich auf der zweiten Unterverzeichnisebene. Nun versucht der Browser, ../../../die URL aufzulösen, und am Ende ist es /die URL.
Ich empfehle, die relativen URLs durch relative Site-Root-URLs zu ersetzen:/bos/Helper/TileData.aspx?reposName=MohaveDocs&docID=1652027&x=0&y=1&pageNum=1&scale=3782&ro=0&time=1607098159588&showAnn=1&pageID=7493796&search
Ein weiteres Problem mit Ihren URLs besteht darin, dass die Et-Zeichen URL-codiert sind, was zu unerwünschten Endergebnissen führen kann.