Eu tenho um problema que quando eu reverto o proxy de uma página, os caminhos relativos dos arquivos não são encontrados.
Exemplo de trabalho:
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
Que redireciona para o resultado da pesquisa:
https://lfportal.mohavecounty.us/bos/0/doc/1652027/Page1.aspx
No arquivo Page1.aspx existem caminhos usando o caminho relativo conforme mostrado no exemplo abaixo
<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=">
Agora com meu redirecionamento
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
A página carrega, mas não continua porque falha. Dá alocação de 404 e olhando o endereço de uma imagem acima no desenvolvedor Chrome e o erro 404 mostra o endereço:
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=
Parece que a pasta raiz bos está faltando. https://lfdocs.mohave.gov/Helper/TileData.aspx?
Deve ser URL: https://lfportal.mohavecounty.us/bos/Helper/TileData.aspx?
Parece que meu passe de proxy não está manipulando o atributo relativo corretamente. Abaixo está meu exemplo de configuração do site Nginx. O problema está ocorrendo no segundo caso a condição
if ($saved_redirect_location !~* "10.4.1.81") { .. }
Meu arquivo conf:
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;
}
}
}
No desenvolvedor Chrome, vejo o cabeçalho personalizado x-debug-message e tenho o valor:
x-debug-message: http://10.4.1.81/bos/0/doc/1652027/Page1.aspx
Tentei remover a barra final na seção de localização de um artigo que li, mas não funcionou.
Alguma ideia de por que os caminhos relativos não estão carregando?
Responder1
Os caminhos relativos são adicionados pelo seu aplicativo back-end. O nginx não toca nos caminhos de forma alguma.
Se seu aplicativo de back-end usar caminhos relativos, seu URL de front-end deverá ter a mesma profundidade que o URL de back-end.
No seu primeiro exemplo:
https://lfportal.mohavecounty.us/bos/0/doc/1652027/Page1.aspx
A URL está no quarto nível de subdiretório. Isso significa que o navegador pode resolver ../../../para /bos.
No seu segundo exemplo:
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
A URL está no segundo nível de subdiretório. Agora, o navegador tenta resolver ../../../o URL e acaba sendo /URL.
Minha recomendação é que você substitua os URLs relativos por URLs relativos da raiz do site:/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
Outro problema com seus URLs é que os caracteres e comercial são codificados em URL, o que pode levar a resultados finais indesejados.