codifica URL com URL - apache mod-proxy (ProxyPass)

3

Eu tenho um ProxyPass configurado para alcançar o seguinte: No meu servidor, inicio um serviço que fornece uma API de Restante ouvindo na porta 7777. Do lado do cliente, quero chamar essa API assim: http://example.org/servicename/PARAMETER

Uma chamada completa para esta API deve ficar assim: HTTP PUT @ http://example.org/servicename/PARAMETER (onde PARAMETER é alguma string). Internamente, isso deve ser traduzido para o seguinte URL: http://server.ip:7777/servicename/PARAMETER

Tudo funciona conforme o esperado, desde que o PARÂMETRO não seja (!) assim: http://parameter.org (na verdade, preciso codificar o URL: http%3A%2F%2Fparameter.org ). Então, apesar de tudo, a chamada é http://example.org/servicename/http%3A%2F%2Fparameter.org

O http:// no parâmetro confunde o apache levando à seguinte mensagem de erro na resposta da chamada:

!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /servicename/http://parameter.org was not found on this server.</p>
<hr>
<address>Apache/2.2.22 (Debian) Server at example.org Port 80</address>
</body></html>

Se eu substituir http%3A%2F%2Fparameter.org por, por exemplo, test , tudo funcionará como deveria. De alguma forma, o http:// no parâmetro confunde o apache. Existe uma maneira de deixar o apache ignorá-lo?

Minha configuração atual deste vhost é assim:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/example
        ServerName example.org
        ErrorLog /var/log/apache2/example_error.log
        LogLevel warn
        CustomLog /var/log/apache2/example_access.log combined

    <IfModule mod_proxy.c>
        ProxyRequests Off

        ProxyPass / http://localhost:7777/
        ProxyPassReverse / http://localhost:7777/
    </IfModule>
</VirtualHost>

Pré-requisitos:

  • Não consigo alterar o comportamento da API. é de terceiros.
  • Preciso fornecer URLs como parâmetros.

Editar 1:

tail -f /var/log/apache2/example_access.log yields

128.xxx.xxx.xxx - - [19/Aug/2015:16:53:17 +0200] "PUT /servicename/http%3A%2F%2Fparameter.org HTTP/1.1" 404 521 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36"
    
por beta 19.08.2015 / 14:16

2 respostas

4

Na configuração padrão do Apache, a diretiva AllowEncodedSlashes está definida como off . Isso significa que: " ... A diretiva AllowEncodedSlashes permite que as URLs que contêm separadores de caminho [...] codificados sejam usadas nas informações do caminho. Com o valor padrão, Off, essas URLs são recusadas com um Erro 404 (não encontrado) . ... "

Portanto, o problema é que o mod_proxy não é não proxeando suas solicitações POST baseadas em URL, já que o Apache está recusando-as (com um 404) antes que o mod_proxy tome medidas.

Outro possível problema está relacionado ao processo de codificação de URL: seu apache (front-end) certamente receberá uma string codificada em URL (aquela que você está enviando para ele: link ) e espero que o (apache) decodifique o URL enquanto processa internamente a solicitação POST relacionada. Então eu espero que o mod_proxy, dentro do Apache, receba um URL real (não codificado) e eu me pergunto se, enquanto estiver fazendo proxy, ele irá executar um ciclo codificado por URL. Em a documentação oficial do ProxyPass eu vejo: " Normalmente, o mod_proxy canoniza o ProxyPassed URLs. Mas isso pode ser incompatível com alguns backends, particularmente aqueles que fazem uso de PATH_INFO. A palavra-chave opcional nocanon suprime isso e passa o caminho da URL "raw" para o backend. Note que esta palavra-chave pode afetar a segurança do seu backend. ele remove a proteção normal limitada contra ataques baseados em URL fornecidos pelo proxy ", então você deve avaliar também o uso da opção" nocanon ".

Ambos os problemas ( AllowEncodedSlashes e nocanon ) foram mencionados em esta pergunta do StackOverflow

    
por 21.08.2015 / 22:51
0

Acho que tem esse comportamento porque, em http:// , o / ainda é visto como separador de diretório. Assim, você está procurando pelo recurso paramater.org sob a pasta http: (por pasta, eu realmente não quero dizer uma pasta real, pois pode ser apenas um caminho de acesso, mas você pode entender o assunto).

Eu não acho que você pode juste digitar / para um recurso em uma URL, então você tem que usar% 2F

    
por 19.08.2015 / 15:46